Explaining solutions aloud

Why it matters

Interviewers see only what you say and type. A candidate who silently produces a correct solution gives less evidence than one who explains choices, catches a bug by testing and weighs alternatives, and a candidate who reaches a slightly weaker solution with clear reasoning can still do well. Several employers' public preparation pages make the same points: the path through the problem matters, ask clarifying questions, and test before declaring the solution done. Communication is also the part of interview skill that transfers most directly to the job, since code review, design discussion and incident response reward the same habits.

Core ideas

A reliable protocol for a 45 to 60 minute coding round:

1. Clarify (2-5 minutes). Restate the problem in your own words. Ask about input size and value ranges, which hint at the target complexity (n around 10^5 usually rules out O(n^2)), duplicates, empty or invalid input, and the exact output format. Work one small example by hand and confirm it.
2. Brute force (1-3 minutes). Describe the obviously correct approach and its complexity. This shows you understand the problem, gives you a fallback and often exposes the bottleneck ("we recompute every window's sum").
3. Improve. Name the insight that removes the bottleneck: "a hash map makes the lookup constant time", "the window only changes at its ends", "this is a shortest path with unit weights". Check the idea on the example and agree on the approach before coding.
4. Code with narration. Speak at the level of intent: "this loop keeps the window free of repeated characters; when that breaks, I move the left pointer". Use clear names and small helpers. If you skip a detail such as input parsing, say so and offer to fill it in.
5. Test. Trace the code you wrote on the example, then on the edge cases you listed earlier. When you find a bug, explain its cause before fixing it.
6. Analyze and discuss. State time and space complexity, then at least one tradeoff: memory versus time, simplicity versus asymptotic speed, behavior on adversarial input, or what changes for streaming data or concurrent access.

Recovering when stuck. Long silence is the worst outcome, so say what you are trying. Useful moves: solve a smaller or more constrained version (sorted input, two elements, small values); work a second example by hand and look for structure; ask what the constraints suggest; run through candidate patterns (sorting, hashing, two pointers, BFS, heap, DP) and say why each does or does not fit; or ask a focused question such as "may I modify the input?". Hints are normal in collaborative interviews. Acknowledge a hint, connect it to your reasoning and use it, rather than ignoring it or abandoning your plan.

Pacing. In a 45-minute round, aim to start coding by roughly the 15 to 20 minute mark so that testing time remains. If the optimal approach is not coming, a clean, tested brute force with an explanation of how you would improve it is better than an unfinished clever solution.

By level. Graduate candidates are mainly expected to reach a working, analyzed solution with clear reasoning, possibly with prompting. Mid-level candidates are expected to drive the process with less help, write cleaner code and handle follow-ups. Senior candidates are expected to resolve ambiguity themselves, discuss tradeoffs and extensions fluently (scale, concurrency, API shape, testing strategy) and keep the conversation structured; a correct but unexplained solution reads as weaker at senior level.

Common misconceptions

• "Jumping straight to the optimal solution looks strongest." Without a stated brute force and reasoning, the interviewer cannot tell insight from recall, and you lose your fallback.
• "Narrating means reading code aloud." Explain intent and invariants; the interviewer can read syntax.
• "Asking questions signals weakness." Clarifying requirements is part of the assessment, and unstated assumptions are a common source of misunderstandings.
• "Taking a hint means failing." Using a hint well is evidence of collaboration; ignoring one is the bigger problem.
• "Testing is optional when time is short." Tracing even one case catches the bugs the interviewer would otherwise point out.

How to approach it

Watch the Jane Street mock interview and note when the candidate clarifies, proposes, codes and tests, and what the interviewers say about communication afterwards. Then practice the protocol aloud on problems you have not seen, with a timer, ideally recorded or with a partner, and review for silent stretches, unexplained jumps and untested code. Before a real interview, read that company's official preparation page for format details such as language choice, coding environment and tool policy, and follow it over generic advice.