With eight minutes left in a technical phone screen and a half-finished faster rewrite, what do you do?

## The situation Eight minutes remain. There is a solution that worked for the ordinary cases, and on top of it a partially written faster approach that does not yet run. This is the endgame of the single most common phone-screen failure: spending the clock reaching for the optimal solution and never running anything. The decision is not close, but the reasoning matters more than the answer. ## Why the working version wins After the call, the screener writes a short recommendation and the **shared-editor session link is archived with it**. Whoever reviews that recommendation — a hiring manager, a recruiter, a second engineer — reads the session in its *final state*. There is no recording of the middle of the call, and no reviewer reconstructs what existed at minute 31. So the practical question is: what artefact do you want the reviewer to open? A finished, checked, ordinary solution answers *yes, this person can produce working software under time pressure*. A half-built optimisation answers nothing at all — it does not even prove the optimisation was understood, because the reader cannot tell an incomplete correct idea from an incomplete wrong one. ## The move, concretely 1. **Say what you are doing and why.** Something like: I would rather leave you something that demonstrably works than an unfinished improvement, so I am going back to the earlier version. One sentence. It converts a retreat into an explicit tradeoff, which is what a screener can actually write down. 2. **Restore the working version.** If you copied it below before starting the rewrite, this takes seconds. If you did not, reconstructing it is now expensive — which is the lesson for next time. 3. **Run it, or trace it.** In a running session, execute two or three inputs including an empty or single-element case. In a non-running session, walk one small input through it out loud. Either way, produce the correctness evidence. 4. **Describe the improvement in words.** Name the approach, why it is faster, and roughly what the cost becomes. Ten seconds of clear description is worth more than four minutes of half-written code, because it is legible and complete. 5. **Leave the session tidy.** Remove dead fragments of the abandoned rewrite, or push them to the bottom under a line saying what they were. The reviewer should not have to guess which block is the answer. ## The habit that prevents the situation Before you start rewriting anything that works, **copy it**. Paste the working version below your cursor, or above, and start the new approach in fresh space. The cost is about fifteen seconds and it makes this whole scenario recoverable. Candidates skip it because it feels untidy; the tidiness argument evaporates the moment the clock does. The second habit is picking a stopping point in advance — a mark on the clock past which you stop building and start confirming. If you pass that mark with a rewrite unfinished, the decision has already been made for you. ## How this reads to a screener Screeners are writing a paragraph that must justify a recommendation to people who were not on the call. Consider two candidates with identical code quality: - **Candidate A** keeps typing until the screener says time. The write-up says: *ran out of time attempting a faster approach; nothing runnable in the session; could not assess correctness.* - **Candidate B** stops at minute 44, restores, runs three cases, and spends the last ninety seconds explaining the faster approach. The write-up says: *had a working, tested solution; recognised the clock and traded the optimisation deliberately; explained it clearly. Recommend advance.* B did strictly less work and gets the better write-up, because the stage measures what can be evidenced in the artefact, not what was attempted. ## The edge cases - **The screener explicitly asked for the faster version.** Then the rewrite is the assignment, and abandoning it silently is wrong. Surface the clock instead: say the rewrite will not be finished, ask whether they would prefer it described or attempted, and follow their steer. They own the schedule. - **The working version was clearly wrong, not merely slow.** Then restoring it proves nothing. Spend the remaining minutes getting the smallest correct thing to run, even a simplified variant of the problem, and say that is what you are doing. - **There is a second problem still to come.** Then the decision is even easier: stop the rewrite, close out the first problem quickly, and protect the second problem's time. ## The general principle A screen is short and its output is an artefact plus a paragraph. Optimise for what survives the call. Working code plus a spoken description of the better approach survives; an unfinished better approach does not.