Dry-Run Three Cases Before You Say Done in a Coding Interview

Dry-Run Three Cases Before You Say Done in a Coding Interview

Saying “done” without a dry run is how correct-looking code fails the last two minutes. Interviewers are not only grading the algorithm. They are grading whether you catch your own bugs without being asked.

The three-case rule

Before you claim finished, walk these out loud while pointing at the code:

  1. The example they gave — prove you solve the stated problem.
  2. One boring edge — empty input, single element, all duplicates, already sorted, n = 1.
  3. The breaker — the input most likely to break your approach (off-by-one, overflow, wrong map key, mutable shared state).

If you cannot invent a breaker, your mental model of the code is still fuzzy. That is the real signal.

How to narrate without sounding robotic

Do not recite a checklist. Tie each case to a line:

Touch the code. Interviewers watch your eyes as much as your mouth.

Where people fake the dry run

Pair it with a finish ritual

A clean ending sounds like:

  1. Complexity (time/space) in one breath
  2. Three-case dry run
  3. One known limitation (“this assumes unique keys; if not, I’d…”)

Then stop talking. Do not keep polishing unless they ask.

Practice under live constraints

In mocks, ban “done” until the three cases are spoken. Record yourself once. You will hear the skips.

If you practice with a live side panel that keeps the question and pad in view while you narrate, tools like Luna Interview can help you stay oriented—use them for rehearsal, not as a crutch that replaces understanding.

Cheat sheet

Case typeExamples
GivenSample from the prompt
Boring edge[], [x], all same, already sorted
BreakerMax constraints, negatives, ties, Unicode, concurrent mutation

Unprompted testing is free senior signal. Spend ninety seconds. It often saves the round.