In a timed coding interview with five minutes left and untested code, do you write more or trace?

## The decision At minute 35 of a 40-minute round you have code that is close but unverified. The instinct is to keep writing, because incomplete code feels like the visible failure. The instinct is usually wrong, and the reason is about what the remaining minutes can actually buy. Five minutes of new code buys, at best, a few more lines that are also unverified. Five minutes of tracing buys a definite claim about the code you already have: it works on this input, and here is the boundary that breaks. Those are not equivalent outcomes, because the person on the other side is not scoring line count. They are trying to answer one question: *if this candidate shipped this, would the bug reach production?* A candidate who finds their own off-by-one has answered it. A candidate who hands over untested code has left it open, and the interviewer will answer it by finding the bug themselves. ## What tracing actually means Tracing is not "reading it over again" and it is not mentally running the algorithm you intended. It is executing the code as written against a specific small input, keeping the state visible: - Choose the input deliberately: an input where the interesting thing happens at the **last** position, or an all-equal input, or the empty and single-element cases. The example the interviewer gave usually walks the happy path, which is precisely where bugs are not. - Track the actual variables in a small table on the side — index, accumulator, whatever the loop maintains — one row per iteration. Written state is what makes a missing update visible; state held in your head reproduces the same assumption that created the bug. - Check what happens after the loop exits, not just inside it. The single most common interview bug is a final element or final run that the loop body handles but the exit path never emits. ## The exception There is one case where finishing wins: the remaining work is small and mechanical, and its absence makes the solution incoherent rather than incomplete — a missing return, a final accumulation, a result never assembled. If that takes under a minute, do it, because tracing an unfinishable fragment tests less. What does not qualify is "one more case to handle" or "the optimization I was going to add": those are new logic, and new logic at minute 37 is where the boundary bugs come from. ## Naming the gap Whatever is unfinished, state it explicitly and concretely: which case is unhandled, what the code currently does on it, and what the fix would be. That costs 20 seconds and changes the interpretation of the whole artifact — an acknowledged gap is a scoped known issue; an unacknowledged one is indistinguishable from not knowing. "I have not handled the empty input; the loop would read index zero and fail, so it needs a guard before the loop" is a strong sentence to end on. ## Practising the endgame The last five minutes are a skill, and they are almost never practised because untimed practice has no endgame — you simply keep going until it works. Two drills fix that: 1. **Hard stop at minute 35.** Whatever state the solution is in, stop writing and spend the last five minutes tracing. Do this even when you are two lines from done. The point is rehearsing the switch from producing to verifying, which is the part that fails under pressure. 2. **Trace someone else's half-finished attempt.** Take a fragment — your own from a previous session, or a peer's — and find the boundary bug in three minutes. This trains the specific habit of picking adversarial inputs rather than confirming ones. ## Why the switch is hard Producing and verifying are different mental modes, and switching under time pressure feels like giving up: you stop making visible progress. That feeling is the reason a protocol beats judgment in the moment. Decide the rule before the round — at five minutes, I stop writing — so that the decision is not being made by the part of you that is stressed and behind.