How should you budget the phases of a 40-minute coding interview, and why set the split beforehand?
answer
- four phases, not one long stretch
- the biggest phase is under half the clock
- the phase that silently becomes zero
- checkpoints let you downgrade in time
- about 5 / 10 / 20 / 5 in forty minutes
basics
~20 sRoughly 5 minutes clarifying, 10 planning, 20 coding, 5 tracing in a 40-minute slot. Fixing the split in advance gives you checkpoints, so you notice time slipping at minute 15 instead of discovering at minute 35 that it is gone.
solid answer
~40 sA workable default for a 40-minute problem is about 5 minutes to clarify inputs, output shape and constraints, 10 to settle on an approach and its cost, 20 to write it, and 5 to trace a concrete example through what you wrote. The exact numbers matter less than having them: a budget converts the clock into checkpoints, so at minute 15 you can see that you have no approach yet and downgrade to something you can definitely implement, rather than finding out at minute 35. Without a budget the failure is always the same shape — clarify and plan expand to fill the space, coding gets compressed, and the tracing phase silently becomes zero. Practise with the phase timers visible, and log which phase overran rather than only whether you finished.
go deeper
Memorize a default split for a 40-minute slot and use it in every practice attempt. Be ready to say which phase you overran on your last timed problem, not just whether you solved it.
Explain why planning gets a quarter of the clock and why the final tracing phase does not shrink proportionally in a shorter slot. Show that you know where the mid-point decision point sits and what decision it forces.
Demonstrate that you adapt the budget to the problem — more clarifying on ambiguous requirements, less planning on a recognized shape — while never letting verification time reach zero. Talk about instrumenting practice with phase timers, not total times.
Own the calibration from the interviewer's side: if nearly every candidate on your team's problem runs out of clock, the problem is mis-scoped for the slot, not the candidate pool. Decide what a partial-but-verified answer is worth in your rubric before the loop, not during it.
## What the budget is A timed coding round is not one continuous activity. It is four, and they produce four different artifacts: | Phase | Rough share of 40 min | What it must produce | |---|---|---| | Clarify | ~5 min | Input shape, output shape, size bounds, what counts as invalid, one worked example | | Plan | ~10 min | A chosen approach, its time and space cost, and the reason it beats the obvious one | | Code | ~20 min | A written solution matching that plan | | Trace | ~5 min | The worked example run by hand through the written code, plus the boundary cases | A 45-minute slot usually means the same shape with a slightly longer coding phase; a 30-minute screen compresses everything, and the phase that must *not* be compressed to zero is the last one. ## Why the numbers land roughly there Clarifying is short because it is bounded: there is a finite list of things you need (what the input is, how large it gets, what to do with empty or degenerate input, whether the data is sorted or unique, what to return when nothing matches). Once you have them, more questions buy nothing. Planning is the surprising one — a quarter of the clock spent not typing. It is worth it because the cost of coding the wrong approach is not the minutes you spend on it, it is the minutes plus a rewrite plus the loss of composure. Planning is where you name the approach and its complexity, and where you notice that the obvious approach is quadratic and the intended one is not. Coding gets the largest single share but under half the clock. Most interview solutions are 15 to 30 lines; if the code phase needs more than 20 minutes, either the plan was not finished or the chosen approach is too heavy for the slot. Tracing is the phase that gets stolen, and it is the one that changes your score. Code nobody executed is code of unknown correctness. Five minutes of hand-tracing a six-element input catches off-by-ones, empty-input crashes and the case where the last element never gets processed. ## Why fix the split in advance A budget is not about discipline for its own sake. It is an instrument that makes a specific failure *observable while you can still act on it*. Without it, time is only visible in the past tense: you notice at minute 35 that you have 12 lines and no tests. With it, minute 15 is a decision point — do I have an approach I can implement in 20 minutes? If not, the budget tells you to stop optimizing and commit to the approach you can actually write, even a brute force whose cost you can state. The second effect is that it makes practice diagnosable. "I failed that one" teaches nothing. "I spent 19 minutes planning and never traced anything" names the defect and the rep that fixes it. ## Adapting the budget The split is a default, not a law. A deliberately ambiguous problem — vague requirements, an unstated data shape — legitimately shifts minutes into clarifying. A problem you recognize immediately can collapse planning to two minutes and hand the surplus to a careful trace. What should not move is the floor on the final phase and the existence of a mid-point checkpoint. A useful practice discipline: run attempts with an actual timer that marks the phase boundaries, not just a total. Many candidates who believe they are "a bit slow overall" discover they are on budget for three phases and 200% over on one. ## What the interviewer sees From the other chair, a budgeted candidate looks calm and legible: questions arrive early and stop, an approach is chosen and justified, code appears steadily, and the candidate tests their own work before the interviewer has to. An unbudgeted candidate looks the same at minute 10 and very different at minute 38.
- You reach the mid-point checkpoint with no approach you can implement. What does the budget tell you to do?Commit to the approach you can definitely write, even if it is the brute force, and state its cost. A working quadratic solution with a named path to the better one is a far stronger outcome than an empty board and a half-found optimal idea. The remaining budget then buys a real coding phase and a real trace.
- The interviewer keeps adding requirements after you have started coding. How does the budget survive that?Treat each addition as a small re-entry into clarify-and-plan and pay for it out of the coding phase, not out of the trace. If the addition is large enough to invalidate the approach, say so and re-plan deliberately rather than patching the existing code, because patched-in requirements are where boundary bugs come from.
- Does a 30-minute screen use the same split?The same shape, compressed: roughly 3 clarify, 7 plan, 15 code, 5 trace. The tracing phase does not scale down proportionally, because the cost of shipping unverified code is the same regardless of slot length. What shrinks is planning depth, which usually means picking a simpler approach on purpose.
It is the same reason an exam paper prints marks per question: the number does not make you smarter, it tells you when to stop and move on.
saying these in an interview costs you the question
- Coding is the only phase that counts
- Clarifying questions burn time you need for code
- Plan while typing; it saves minutes
- Test at the end if any time is left over
- A fixed budget is rigid, just play it by ear