How to talk through an algorithm in an interview

The uncomfortable secret of algorithm interviews: the code is maybe a third of the grade. Interviewers routinely pass candidates whose solution had a bug they were reasoning well about, and fail candidates who typed a perfect solution in silence — because the interview is a proxy for working with you, and silent perfection is unverifiable, unteachable, and slightly alarming. Talking is not commentary on the performance; it is the performance. This page is a protocol for the forty-five minutes, built around the specific sentences that carry weight.

Minutes 0–5: buy certainty cheaply

Restate the problem in your own words — one sentence — and ask the questions whose answers change the design: Can the input be empty? Duplicates? Negative numbers? Is it sorted? How big does n get? That last one is doing double duty: it scopes the design (see the constraint table) and it signals you know constraints drive choices. Then propose a tiny concrete example and confirm the expected output. Thirty seconds of example-agreement has saved more interviews than any clever trick, because solving the wrong problem brilliantly is the most common way to fail.

The sentence that does the work: “Before I design anything — n can be up to what, and is the array guaranteed sorted?”

Minutes 5–15: hypothesis before code, brute force without shame

Name the naive solution and its cost out loud, even when you already see something better: “Brute force checks every pair — O(n²) — which works but won’t scale past a few thousand; let me see if the sortedness buys a better shape.” This is not padding. It establishes a working baseline (if time collapses, you have something to implement), it demonstrates the complexity vocabulary in motion, and it frames the improvement as a reasoned upgrade rather than a memorized answer — which matters enormously, because pattern-recall without reasoning is precisely what interviewers are trained to probe past.

Then commit to a hypothesis and — this is the step most people skip — say the invariant. “I’ll keep two pointers with the property that every pair outside them is proven impossible.” “The queue will always hold the frontier in distance order.” An articulated invariant does three jobs at once: it’s your design (the code just maintains it), it’s your correctness argument (the interviewer hears why it works, not just that it might), and it’s your debugging oracle for later. Every algorithm page on this site has an invariant section for exactly this reason — it’s the sentence interviews are secretly about.

Minutes 15–35: narrate decisions, not syntax

While coding, the rule is: narrate at the level of decisions. Not “now I write a for loop” — the interviewer can see the for loop — but “I’m marking visited on enqueue, not dequeue, so nothing enters the queue twice.” Decision-level narration turns every line into evidence of understanding, and it has a second, underrated effect: saying your reasoning aloud is how you catch your own bugs before they’re typed. If you need silence to untangle something hard, buy it explicitly — “give me thirty seconds to think through the boundary here” — which reads as focus, where unexplained silence reads as drowning.

When you get stuck — and getting stuck is expected; easy problems don’t discriminate — think aloud through the stuck-ness itself: “the window invariant breaks with negative numbers… so shrinking doesn’t monotonically fix the sum… which means I need a different tool — prefix sums, maybe.” An interviewer watching you diagnose a dead end and pivot has learned more about working with you than any clean solution shows. And take hints gracefully: a hint incorporated with “oh — right, that means the state needs the index too” costs almost nothing; a hint resisted costs the room’s goodwill.

Minutes 35–45: verify like you mean it, then price it

Don’t announce “done” — announce a test. Walk your original example through the code line by line, tracking actual variable values — the exact discipline this site’s step-through visualizations train — and then, unprompted, walk the edges: empty input, single element, everything-equal, the target absent, n at its maximum. The unprompted edge-walk is one of the strongest signals available, because it’s what conscientious engineers do when nobody’s watching. If you find a bug: good. Fixing a bug you found yourself is worth more than not having had it, and visibly worth more than the interviewer finding it.

Close with complexity, both axes, with the qualifier pattern from the Big-O page: “O(n log n) time from the sort, O(1) extra space — average and worst are the same here; if the input came pre-sorted this drops to O(n).” Time and space, average and worst, unprompted. Then, if there’s air, volunteer the trade-off you didn’t take: “a hash map version trades O(n) memory for skipping the sort — I’d switch if the input can’t be reordered.” Naming the road not taken is the cheapest available demonstration that you chose, rather than recalled.

The failure modes, named

Silent coding — the cardinal one; the interviewer cannot grade what they cannot hear. Jumping to the clever answer — even when right, it reads as recall; thirty seconds of “brute force costs X, but…” converts it to reasoning. Arguing with hints — the interviewer knows the destination; hints are the room telling you the route. Skipping verification — “looks right” is not a test, and the habit of executing your own code by hand is trainable: every visualization here that pauses and asks you to predict the next step is a rep of exactly that muscle. Complexity on demand only — if they had to ask, it counted half. And the quiet one: never stating assumptions — every unasked question about duplicates or emptiness becomes a bug later, discovered by the person you least wanted to discover it.

The meta-skill under all of it: treat the interviewer as a colleague on a problem, not an examiner behind glass. Every sentence in this protocol — restate, baseline, invariant, decision-narration, self-verification, priced trade-offs — is just what good pairing sounds like, performed under time pressure. Practice the sentences until they’re reflexes; the algorithms are on the rest of this site.