Here's the uncomfortable truth about live coding interviews: a candidate who solves the problem silently with perfect code often scores lower than one who solves it while narrating, making a small mistake, and recovering visibly. Interviewers can't see your thoughts — only what you externalize. Silence reads as flailing even when you're thriving; structured narration reads as competence even mid-struggle. These are learnable performance skills, and this post teaches them.
The 45-minute structure#
Interviews reward candidates who manage time deliberately:
- Restate and clarify (3–5 min): repeat the problem in your words, ask the scoping questions — input size? sorted? duplicates? empty cases? This isn't ceremony; constraints determine which patterns apply.
- Examples and edge cases (3 min): walk a small example by hand; name edge cases before touching code. Empty input, single element, duplicates, extremes.
- Approach out loud (5–7 min): propose a brute-force first if needed, state its complexity, then improve. Saying "the naive approach is O(n²); I think we can do better" demonstrates judgment, not weakness.
- Code (20–25 min): narrate as you write (below).
- Test and dry-run (5+ min): trace your example through the actual code line-by-line. Skipping this step to "look finished" is how silly bugs survive.
Narration that helps instead of distracting#
Thinking aloud is a skill with technique:
- Narrate decisions, not syntax: "I'm using a hash map so lookups stay O(1)" beats "so I type curly brace..."
- State intent before each block: "This loop finds the first duplicate" lets interviewers follow architecture even if a line has a typo
- Think in questions: "What do I know? The array is sorted... which suggests two pointers" — reasoning audibly is exactly what's being graded
- Silence budget: genuinely silent thinking is fine for 15–30 seconds. Beyond that, surface something: "I'm considering whether BFS applies here because of the shortest-path phrasing."
When you're stuck: the recovery playbook#
Everyone blanks. Grading hinges on what happens next:
- Return to the example. Hand-tracing input usually reveals the pattern your abstraction hid.
- Solve badly on purpose. "Brute force would be nested loops — O(n²). Let me write that, then optimize." Working brute force beats elegant nothing, and optimization targets emerge from concrete code.
- Change representation. Rewrite the input differently — indices vs values, sorted copy, counts table. New views expose structure.
- Ask directed questions (not "what do I do?"): "Is a logarithmic solution expected given the sorted input?" Good hint-asking shows collaboration, and interviewers are instructed to give progressive hints anyway.
- Take the hint gracefully. The fatal move is ignoring a hint to defend sunk-cost thinking. "Got it — that changes things; let me reframe" scores better than grinding alone toward a dead end.
Bugs under pressure: the triage#
When your code fails its own test:
- Dry-run first, patch second. Trace variables line-by-line on the example; most bugs surface without any editing.
- Fix forward, explain backwards. "Off-by-one here — right pointer should start at length minus one." Naming the bug class earns credit for diagnosis speed.
- Never thrash. Three rapid blind edits signal panic more than one bug ever could. One careful trace, one deliberate fix.
Practice loop for performance skills#
Solving problems solo trains knowledge; performing them trains delivery:
- Mock weekly with real humans (friends, platforms) — recorded if possible
- Watch yourself back once: counting your silences and filler phrases is unpleasant and effective
- Simulate constraints honestly: camera on, timer running, no autocomplete (set up a bare editor or plain notes mode)
- Rehearse your stuck-recovery lines until they're automatic — scripts hold up under stress; improvisation doesn't
Interviewers consistently report the same thing separates hires: not flawlessness, but watching someone reason calmly through difficulty. That calm is rehearsal, available to anyone willing to perform practice problems before an audience of one rubber duck — then real ones.
Related: 12-week plan schedules mocks · behavioral STAR stories covers the other half of loops
