How should you budget the phases of a 45-minute live-coding round?
answer
- Coding expands to fill the whole round
- Roughly clarify, plan, code, verify
- About half the round is coding
- Protect the last stretch for tracing
- Cut scope, never verification
basics
~20 sA workable split of a 45-minute coding round is roughly 5 minutes clarifying, 5 planning, 25 coding and 10 verifying, with the last stretch protected. Track the split aloud and cut scope rather than the verification phase when you fall behind.
solid answer
~40 sI plan a 45-minute round as roughly four minutes clarifying, six planning aloud, twenty-four coding and nine verifying, leaving a couple of minutes of slack for the interviewer's own questions. The exact split matters less than protecting the last phase: verification is the one that gets silently eaten, and it is the one that produces evidence. I keep a rough sense of the clock and say it out loud at the transitions — *that is the plan agreed, I am about eleven minutes in, moving to code.* When I fall behind I cut scope, not verification: I ask whether to stub the awkward branch and describe it instead, so I still finish with something traced. Announcing the tradeoff is the point; a silent overrun into the last minutes is what sinks otherwise good rounds.
go deeper
Rehearse timed practice rounds with a visible clock so you learn what fifteen minutes of coding actually feels like. Aim simply to start writing code before the round is a third gone.
Be ready to say what each phase buys and roughly how much of a 45-minute round it deserves, and to explain why verification is the phase most often eaten and least safe to cut.
Show that you manage the clock out loud: announced transitions, an overrun named when it happens, and a scope cut proposed to the interviewer rather than discovered by the timer.
Own the allocation as a decision under uncertainty. Argue when a round justifies a longer scoping phase and a smaller build, and be able to defend spending minutes on evidence rather than on additional untested code.
## Why the split is a technique and not a formula A live coding round is short and the phases compete for the same minutes. Left unmanaged, coding expands to fill everything, because typing feels like progress and the other phases feel like overhead. The result is the most common shape of a failed round: a candidate still writing at minute forty-two, with nothing verified and no time to react to the interviewer's questions. A reasonable default for a 45-minute round is roughly five minutes of clarifying, five of planning aloud, twenty-five of coding and ten of verification. In practice a tighter version — about four, six, twenty-four and nine, with a couple of minutes of slack — survives contact better, because the interviewer will interrupt at least once and the slack absorbs it. Treat those numbers as a starting allocation you adjust, not a schedule you obey. ## What each phase is buying **Clarify (about four minutes).** Fixes the scope: input shape, scale, boundaries, return contract. Overspending here is a real risk; if you are still asking at minute eight, close it out by stating your remaining unknowns as assumptions. **Plan aloud (about six minutes).** The approach, its cost, and what you are choosing over what. This is the phase candidates cut first and should cut last, because it is where the interviewer can still redirect you cheaply. Fifteen seconds of *does that approach sound reasonable to you?* before writing anything can save ten minutes. **Code (about twenty-four minutes).** Roughly half the round. If you have not started writing real code by minute fifteen, that is the signal to compress, not to keep refining the plan. **Verify (about nine minutes).** A hand trace on one deliberate input plus the named boundaries. This is the phase that converts a claim into evidence, and it is the phase most likely to be eaten. ## Announce the transitions Saying the clock aloud costs seconds and does three useful things: it shows the interviewer you are managing the round rather than drifting, it invites them to correct your allocation if their rubric weights things differently, and it gives you a natural moment to check the plan is still right. Short is enough: *plan agreed, about eleven minutes in, starting to code*, and later *twenty to thirty minutes gone, I want to stop adding and start tracing.* This also protects you against the interviewer's own interruptions. If they spend four minutes on a tangent, an announced budget makes it natural to say *that took us a few minutes — I would like to keep the last stretch for testing, so shall I stub the retry path rather than write it?* ## When you fall behind, cut scope rather than verification This is the judgment call the phase budget exists to make possible. Falling behind is normal; the decision is what to sacrifice. Cutting verification leaves you with more code and no evidence — the worst trade in the round, because the extra code is exactly the code most likely to be wrong. Cutting scope leaves you with less code, verified, plus a described plan for the rest. The move is to make the cut explicit and get agreement: *I have about twelve minutes left. I can finish the merge and trace it properly, or start the deduplication and leave both untested. I would rather trace what exists and describe the deduplication — does that work for you?* Nearly every interviewer takes that trade, and asking demonstrates precisely the prioritisation the round is trying to observe. ## Worked example The mid-level mobile candidate at the Series C scale-up loses time early: the interviewer's problem statement is ambiguous about ordering, and clarification runs to seven minutes rather than four. The candidate names it — *that took longer than I planned, so I am going to plan briefly and start coding* — compresses planning to three minutes, and is writing on the blank whiteboard by minute ten. At minute thirty-one, with the main path written and one branch missing, they stop and say: *I have about nine minutes. Rather than write the tie-breaking branch, I will trace what is here and then describe the branch — I would rather show you this works.* They trace one input plus two boundaries, catch a bound error, fix it, and spend the last two minutes describing the missing branch precisely enough that the interviewer can see they know how it goes. The round ends with less code than the plan called for, all of it demonstrated. ## The failure this replaces The contrast is the candidate who codes in silence with no announced allocation at all, discovers at minute forty that a branch is broken, goes quiet under the pressure, and stops narrating entirely for the last few minutes. The interviewer's notes for that round contain no plan, no tradeoff, no trace and no recovery — only that time ran out. It is worth noticing that this outcome is usually decided in the first ten minutes, not the last five.
- Your clarifying phase has eaten twelve minutes — how do you recover the round?Name it and compress downstream. Say the clarification ran long, close it by turning open items into stated assumptions, cut planning to a couple of sentences with an explicit check that the approach sounds right, and start coding. Then plan a reduced scope from the outset rather than discovering at minute forty that you cannot finish.
- Is it better to finish a slower correct solution or leave an optimal one half-written?In most rounds, a complete solution you have traced beats a half-written optimal one. Say the tradeoff aloud and let the interviewer weigh in: some are explicitly grading the optimal approach and will happily see partial code with a clear plan. What loses either way is running out of time silently, with neither finished nor verified.
- How do you keep track of the clock without appearing anxious?Check it at natural transitions rather than continuously, and phrase it as management rather than worry. 'About twenty minutes gone, moving from coding to testing' is calm and informative; repeatedly asking how much time is left, or glancing at the clock mid-sentence, reads as nerves and pulls attention away from the problem.
saying these in an interview costs you the question
- Still writing new code in the final minutes with nothing traced
- Cutting verification instead of cutting scope when behind
- Never noticing aloud that a phase overran
- Refining the plan past the point of diminishing returns
- Going silent under time pressure instead of renegotiating scope