The Minute-12 Rule: Coding Interview Time Management

I once watched a candidate produce the cleanest problem breakdown I'd seen all quarter. Constraints, two approaches with honest tradeoffs, complexity for both, a list of edge cases I hadn't thought of. It was minute 34 of a 45-minute slot. He had written zero lines of code. He didn't pass, and the note that sank him in the debrief wasn't "weak engineer." It was "no working solution." That's a coding interview time management failure, not an engineering one. The brutal part: he was better than half the people we hired that year. A 45-minute coding interview is really a ~35-minute slot after intro and closing questions. Budget it like a sprint, not an essay. slot after intro and closing questions. Budget it like a sprint, not an essay. The minute-12 rule: if you haven't written your first real line of code by minute 12, you are on the losing track. Almost every "ran out of time" rejection I've written traces back to minutes 8 through 12. if you haven't written your first real line of code by minute 12, you are on the losing track. Almost every "ran out of time" rejection I've written traces back to minutes 8 through 12. Candidates lose time in four predictable places: the silent tunnel, coding before the approach is agreed, debugging by re-reading, and the minute-38 panic rewrite. A working brute force at minute 20 beats an unfinished optimal solution at minute 45, every single time. You can always optimize out loud. Interviewers score recovery. Saying "I'm at 25 minutes, let me lock in the O(n²) and optimize after" is a senior signal, not an admission of defeat. What does coding interview time management actually mean? It means treating the 45 minutes as a resource you allocate on purpose, out loud, with the interviewer as your co-planner. Not "work fast." Working fast is how people skip the clarifying questions and solve the wrong problem. The scoring rubric usually has a hard gate on it: did the candidate reach a correct, running solution? Everything else — communication, code quality, complexity analysis — is graded around that gate. You can score well on all of it and still get a no-hire because the gate never opened. So the clock isn't a background constraint. It's the primary one. How should you budget time in a 45-minute coding interview? Here's the clock I run in my head as the interviewer. If yours matches mine, we're both relaxed. If yours lags, I start writing hedged notes. Minutes 0-3 — Intro. Free. Don't spend it on your full career history; I have your resume open. Two sentences, then "should we get into the problem?" Minutes 3-8 — Clarify. Input sizes. Types. Duplicates allowed? Sorted? Can I mutate the input? What should this return on empty? This is the highest-ROI five minutes in the interview and the one people skip when they're nervous. Minutes 8-12 — Approach. State the brute force in one sentence with its complexity. Then say whether you think you can do better and how. Get an explicit "yeah, go with that" from the interviewer before you type. Minutes 12-33 — Code. Twenty minutes. That's the whole budget. If your plan doesn't fit in twenty minutes of typing, it's the wrong plan for this room. Minutes 33-40 — Trace and fix. Run a real input through your code by hand, line by line, out loud. Not "this looks right." Minutes 40-45 — Your questions. Protected. Interviewers notice when a candidate is still flailing here, and they notice when someone lands the plane on time. Why is minute 12 the line? Because writing code surfaces problems that thinking about code does not, and you need the remaining budget to absorb those surprises. Every plan is wrong in some small way. You find the wrongness on line 14, not in your head. Past minute 12, the math stops working. Twenty minutes is roughly what an average interview problem takes to type, debug, and trace when things go fine. Start at minute 20 and you've pre-spent your entire error budget on planning that the code was going to correct anyway. There's a psychological trap here too. The longer you plan, the more you feel like you owe the interviewer a sophisticated solution, so you reach for the clever one exactly when you have the least time to debug it. Where do candidates actually lose time in a coding interview? 1. The silent tunnel. Someone goes quiet at minute 9 and re-emerges at minute 19 with a fully formed plan. That's a great outcome for them and a terrible one for me — I couldn't help, couldn't score their reasoning, and couldn't stop them if the plan was doomed. If you need to think silently, buy it explicitly: "give me sixty seconds." Sixty seconds is fine. Ten minutes is a black box, and black boxes get scored conservatively. 2. Coding before the approach is agreed. The candidate starts typing at minute 6 with a strategy they never said out loud. I now have to guess where they're going, and I can't course-correct without derailing them. Half the time they're building toward a solution I would have talked them out of in fifteen seconds. Cheapest insurance in the entire interview: one sentence, out loud, before your fingers move. 3. Debugging by re-reading. The test fails, and the candidate scrolls up and down the same twenty lines with their eyes, waiting for the bug to glow. This can eat ten minutes and produce nothing. Trace one concrete input by hand and say the variable values out loud. i=0, left=0, sum=3 . Bugs die in about ninety seconds under that treatment. 4. The minute-38 panic rewrite. Something's broken, panic hits, and they select-all and start over. I have never once seen a from-scratch rewrite after minute 35 finish. Not once. Your buggy code at minute 38 is worth vastly more than empty code at minute 38, because a buggy solution plus a correct verbal fix still scores as "solved." What do interviewers write down while you're stuck? Not "stuck." Everyone gets stuck. What actually goes in the notes is what you did about it — whether you narrated, whether you changed strategy or kept pushing the dead one, whether you checked the clock yourself or waited for me to say "about ten minutes left" in that tone. The nudge is not neutral, by the way. When an interviewer announces the remaining time unprompted, that's a rescue attempt, and it usually shows up in the writeup as a hint given. Beat them to it and you keep the point. How do you recover at minute 30 with nothing working? Say the quiet part out loud, then downgrade on purpose. "I'm at 30 minutes and the optimal approach isn't converging. I'm going to implement the O(n²) version so we have something correct, and then talk through the optimization." That single sentence converts a spiral into a plan. It reads as senior because it is the senior move: shipping the version that works and scheduling the optimization. Nobody on your future team will be impressed that you held out for the elegant solution until the deadline passed. And if you finish the brute force at minute 36 with time left, you often talk your way to the optimal solution anyway, with zero risk. Explaining an optimization is much faster than typing one. Does this scale to 60- or 90-minute interviews? Yes, and the ratio holds better than the raw numbers. Keep roughly a quarter of the slot for clarifying and approach, about half for coding, and the last fifth for tracing and questions. In a 60-minute round, that puts your first line of code near minute 15. In a 90-minute pairing session, closer to minute 22, and the clarifying phase is where the real signal lives. The one place the ratio breaks is a two-part problem, where part two is revealed after you solve part one. There, treat part one as its own 45-minute clock compressed into 25 minutes and be ruthless about it. Ask early: "is there a follow-up to this, or is this the whole problem?" Interviewers almost always tell you. So what is coding interview time management? It's the practice of budgeting a 45-minute interview as roughly 5 minutes of clarifying, 4 minutes of stating an approach, 20 minutes of coding, 7 minutes of tracing, and 5 minutes of your questions — with your first real line of code landing by minute 12. Candidates fail interviews not because they can't solve the problem, but because they spend their error budget on planning, go silent, debug by staring, or rewrite from scratch in the final ten minutes. A correct brute force delivered early, narrated clearly, and optimized out loud beats an unfinished perfect solution in every scorecard I have ever filled out.