Your recorded mock spent 22 of 40 minutes before the first line of code — what do you diagnose?
answer
- the number alone is not a verdict
- ask what those minutes bought
- timestamp when the used approach appeared
- circling looks like planning on the clock
- the fix is a cutoff, not more speed
basics
~20 sTwenty-two minutes before coding is not automatically a defect: check what those minutes bought. If the plan let you code in one pass, the split was earned; if you circled without committing, the fix is a cutoff, not talking less.
solid answer
~40 sThe raw number is evidence, not a verdict. Watch the recording for what the 22 minutes produced: if the approach was chosen at minute 12 and the remaining 10 were spent restating the problem or hunting a better idea you never used, the defect is a missing commit deadline. If the plan was complete and the code went in without rework, the split was expensive but correct — and the real finding is whichever phase got squeezed to zero, usually verification. Two other tells are worth timestamping: how many times you restated the problem (a restatement loop signals unfamiliarity, not thoroughness), and whether any planning minute changed the approach. The corrective rep is a cutoff that forces committing at a fixed minute, not an instruction to think faster.
go deeper
Know that timing your own attempt by phase, rather than only end to end, is what makes a practice session diagnosable. Be able to say which phase ran long on your last attempt.
Explain how the same elapsed number can mean two opposite things, and name the tape evidence that separates them: when the implemented approach first appeared, whether any code was rewritten, and which phase reached zero.
Show that you convert a diagnosis into a mechanical rep — a binding commit deadline, a clarifying checklist — rather than a resolution to be faster. Talk about looking for the pattern across several attempts instead of over-fitting to one recording.
Own the practice loop for a group: decide what gets logged after every mock so the data is comparable across people and weeks, and resist advice that cannot be tied to an observation. Cheap, consistent instrumentation beats sophisticated one-off coaching.
## Why record at all Memory of a timed attempt is unreliable in a specific direction: the phases that felt uncomfortable feel long, and the phases that felt fluent feel short. Candidates routinely report "I ran out of time at the end" for an attempt whose recording shows the loss happened in the first third. A recording — screen plus audio, or just phase timestamps written down by a peer acting as interviewer — replaces that impression with evidence. ## The number is not the diagnosis 22 of 40 minutes before the first line of code is more than half the slot. That is far above a typical budget, and the reflex reading is "I over-plan, I should code sooner." That reading is wrong about as often as it is right, and acting on it produces the opposite failure: coding at minute 6 with an approach that does not work, then rewriting at minute 25. The question to put to the tape is: **what did those minutes buy?** Two very different recordings produce the same 22. **Reading A — the split was earned.** The problem was genuinely ambiguous, the clarifying phase found a constraint that eliminated the obvious approach, the plan was complete by minute 22, and the code then went in as one pass with no rework and finished at minute 36. Expensive, but coherent. The lesson here is not "plan less"; it is that this problem class costs you more planning, so the coding approach must be one you can write quickly. **Reading B — the split was circling.** The approach was actually settled at minute 12. Minutes 12 to 22 were spent restating the problem, re-deriving the same complexity, or looking for a nicer solution that never made it into the code. That is not planning, it is reluctance to commit — and it is the common case. The two are easy to separate on tape: mark the timestamp at which the approach you *actually implemented* first appeared. Everything after that timestamp and before the first line of code is waste, by definition. ## The other things the tape shows - **Which phase hit zero.** If coding ended at minute 40, the verification phase did not get compressed, it was deleted. That is usually the more damaging finding than the slow start, because untested code carries unknown correctness. - **Restatement loops.** Counting how many times you restated the problem is a cheap, objective signal. Three restatements in the first ten minutes generally means the problem never got resolved into a concrete example, and a fixed clarifying checklist with a hard stop fixes it faster than any general advice. - **Rework.** Did any code get deleted and rewritten? Rework after a long plan means the plan was not actually finished, only long. - **Dead air versus working silence.** Silence while writing an example on the side is productive; silence while staring is the circling signature. ## The corrective rep The fix that follows from Reading B is mechanical, not motivational. Set a commit deadline — an alarm at the planning boundary — and treat it as binding: whatever approach is on the table at that minute is the approach you implement, with its cost stated. Run several attempts with the alarm before deciding whether your planning is genuinely too slow. Most of the time it is not slow; it is unbounded. The fix that follows from Reading A is different: keep the planning, but change the approach selection to favour what you can write in the minutes that remain. A candidate who plans for 22 minutes and then chooses the implementation-heavy solution has made two decisions that are individually reasonable and jointly fatal. ## How to avoid over-fitting to one tape One recording is an anecdote. The value appears across five or six attempts, when the same phase overruns on every unfamiliar problem and on none of the familiar ones — which tells you the problem is recognition, not pacing. Keep the phase timestamps in a simple log; the pattern across attempts is the real signal, and it is invisible from inside any single attempt.
- What would make 22 minutes before coding the right call rather than a defect?If the problem was genuinely ambiguous and the long plan bought a single-pass implementation that finished with time to verify, the split was earned. The tape confirms it by showing no rework: nothing deleted, no approach change mid-code. In that case the corrective is to pick lighter-to-implement approaches when planning runs long, not to plan less.
- The tape shows you restated the problem three times in the first ten minutes. What does that suggest?Restatement loops usually mean the problem never got reduced to a concrete worked example, so each pass re-reads the same words hoping for new meaning. The rep is a fixed clarifying checklist — input shape, size bounds, degenerate input, one small example written down — with a hard stop, which converts open re-reading into a bounded step.
saying these in an interview costs you the question
- Long planning always means you should talk less
- Any minute not spent typing is wasted
- Recording adds nothing over remembering the attempt
- The problem is coding speed, not a missing cutoff
- One bad tape proves a persistent pacing habit