How to Test Your Code in an Interview

How do you test your code in a coding interview?

Trace through three examples out loud before you declare you're done: the original example from the prompt, one edge case, and one adversarial case. Dry-running means stepping the program by hand and speaking the variable values, because most live rounds give you no compiler. That trace is the whole game. Most "this code works" claims fall apart on the second or third trace, and finding the bug yourself, in the test pass, scores higher than letting the interviewer find it five minutes later.

As of the 2026 hiring cycle, "tested my own code" is an explicit positive marker on most coding rubrics, and "declared done without verifying" is a documented reason candidates get marked down on solutions that were correct. For Jordan, the new grad who's sent 487 applications and is still chasing the offer that ends the search, this is a free point that nothing technical is blocking. The verification pass is a habit, not a talent. I tell every candidate I coach: the test pass is the cheapest two minutes of signal in the whole round, and almost nobody spends them.

Dry-running vs skipping the test pass: what the interviewer sees

The fastest way to see why the test pass matters is to watch the same finished solution graded two ways: once where the candidate verifies it, once where they say "looks good to me" and stop. A dry run is tracing the program by hand against a chosen input; skipping the test pass is trusting that code you just wrote does what you think it does.

| Moment after you finish coding | Skip the test pass | Run the three-example dry run | |---|---|---| | Your code has an off-by-one bug | Interviewer finds it; reads as careless | You catch it in the edge-case trace and fix it on the record | | The empty-input case crashes | Surfaces only when they test it | Surfaces in trace two, where catching it is a positive signal | | You used the prompt's example to write the code | "Works" just means you re-ran your own assumption | A fresh adversarial input actually exercises the logic | | Time is tight | Looks rushed and unfinished | A narrated trace earns partial credit even unfinished | | Solution is correct | Capped low; no test discipline shown | Correctness plus the verification signal the rubric grades | | You declare "done" | Reads as overconfident | You hand the lead back and invite one more case |

A correct solution that the candidate never verified routinely scores below a slightly rougher one that the candidate test-drove out loud, because the second candidate proved a habit the first only hoped they had. The companion motion is narrating the work as you go; the guide on how to think aloud during a coding interview covers that rhythm, and this verification pass is where it pays off.

The three-example test pass (the numbered method)

Lock this into a habit. Once your code compiles in your head, run these traces in order:

1. Trace the original example. Walk the prompt's example, line by line, with values. "Input is [2,7,11,15], target is 9. First iteration: i=0, num=2, complement=7. Hash map is empty, so we add 2 -> 0. Second iteration: i=1, num=7, complement=2. We find 2 in the map at index 0. Return [0, 1]." If your code matches the expected output, that's confirmation, not proof.
2. Trace an edge case. Pick the most boring possible input: empty list, single element, all duplicates, all the same value, or the smallest non-trivial case (n=2). "What does my code do on [5] with target 5?" If your loop never enters, do you return the right sentinel? If you reference arr[0] before checking length, you've found a bug, and that's the win.
3. Trace an adversarial case. This is the one most candidates skip. Pick the input most likely to break your solution. For a hash-map approach, that's an input with duplicates that need both indices. For a two-pointer approach, it's an input where the pointers should cross. For a recursive approach, it's the input that hits the deepest recursion, often degenerate or sorted-descending. The adversarial case is where the bug almost always hides.
4. Name and re-trace any bug you find. Don't bury it. "Good, the trace caught that I'm not handling the empty case. Adding an early return on line 2 and re-tracing." Then re-run the fixed example so the repair is on the record.
5. Hand the lead back. After three clean traces, state what you checked and ask for more. Don't unilaterally declare you're done; the interviewer often hands you the one case you missed, and handling it live is extra graded signal.

Knowing which adversarial input to reach for is its own skill, and it starts at the clarifying stage; the guide on how to handle clarifying questions on a coding problem covers how to surface the constraints that tell you where your code is exposed.

How to trace out loud without losing the thread

Tracing is itself a learned skill. The technique:

• Write down the state. On the whiteboard or in a comment, sketch a small table: variable name to value, updated each iteration. This is the state table, and it's the single biggest difference between a trace that holds together and one that drifts.
• Speak the values, not the variable names. "i is now 1, and num is 7," not "i increments and num updates."
• Mark the decision points. "We hit the if-branch here because complement is in the map."
• State the output when you reach the return. "Returns [0, 1], matches expected."

This is slower than tracing silently in your head, by design. The point is to make the trace audible, so the interviewer can catch a misstep if you make one, and so you can catch one yourself. Per the Pragmatic Engineer's writing on technical-interview signal, candidates who systematically verbalize their trace catch their own bugs at a much higher rate than candidates who run the trace silently.

When the trace catches a bug

The script is already written for you:

"Good, the trace caught that I'm not handling the empty case. Let me add an early return on line 2 and re-trace."

Three things happen when you do this:

1. You demonstrated test discipline; finding bugs is the whole point of tracing.
2. You owned the bug without apologizing: clean recovery.
3. You re-verified the fix with a fresh trace, completing the loop.

This is one of the highest-leverage moments in the interview. The candidates who self-catch a bug in the test pass routinely score higher than candidates whose first solution was correct but who skipped the test pass. When the bug is bigger than a one-liner (a wrong approach rather than a typo) the recovery is a different muscle, mapped in the guide on how to recover from a wrong solution mid-interview.

Common bugs the test pass catches

The bugs that show up most often, so pattern-recognize them and let your adversarial case target them:

• Off-by-one in loop bounds. An off-by-one error is iterating one element too far or one too few (range(len(arr)) versus range(len(arr) - 1)), and it's the single most common dry-run catch.
• Equality at boundaries in binary search. A boundary condition is the behavior at the first, last, or empty position, where == versus >= flips the result.
• Empty / single-element edge cases: loops that never enter and return garbage.
• Mutation while iterating: silent corruption, not a crash, which is exactly why a clean run on the original example never surfaces it.

When you trace, expect one of these. The adversarial case exists specifically to surface them. If you want the broader catalog of patterns and the templates that go with them, the coding interview cheat sheet for 2026 collects them in one place.

What to do after all three traces pass

Don't declare victory unilaterally. The script:

"I've traced through the original, the empty/single-element case, and the duplicates case, all return correctly. Is there a specific edge case you'd like me to verify, or anything else you'd like me to think about?"

This hands the interviewer back the lead. Half the time they'll say "looks good, let's talk complexity," and you'll want the complexity answer ready, which the guide on how to explain time complexity in an interview drills cold. The other half they'll suggest an edge case you didn't think of, and now you get to handle it under live pressure, which is more graded signal than the original solution.

Indeed Career Guide research on technical-interview rubrics explicitly highlights "systematic testing of own code" as a positive rubric marker, and "declares done without verification" as a common reason candidates get marked down on solutions that were correct. The discipline is: three traces, three different purposes, then hand the lead back.

Where the editor changes the test pass

The mechanics shift a little by platform, but the three-example discipline never does. In a runnable sandbox (a HackerRank or CodeSignal environment, or a CoderPad pad you can execute) do your dry run first, then add one or two quick assert-style checks to confirm what you traced. On a Karat-style shared screen or a whiteboard you only have the dry run, so narrate all three traces out loud. The verification habit is what transfers; the guide on how to explain your LeetCode solution out loud covers the narration motion that carries it across formats.

The honest way to make this automatic is reps under a timer with feedback, not a tool that whispers test cases mid-round. There is no undetectable shortcut, and rubrics in the 2026 hiring cycle are tuned to catch recited answers a candidate can't defend. If you want to rehearse the three-example pass against realistic prompts until it's muscle memory, try a timed mock interview run and practice catching your own bug before the interviewer does; the plans on the pricing page cover unlimited timed sessions, and the $3 trial is enough to run your first few and feel the difference before your next real loop. For Jordan and every new grad still chasing the offer that ends the search, a clean, self-tested solution is the version of "done" that closes the round.

Key terms

Dry run

Executing your code by hand, in your head or on paper, tracing the variable values line by line. The standard way to test code in a live interview where you usually can't actually run it.

The three-example test pass

Tracing the original example, one edge case, and one adversarial case: three traces with three different purposes, run before you declare a solution done.

Edge case

A boundary or degenerate input: empty list, single element, all duplicates, or the smallest non-trivial size. The trace that catches loops that never enter.

Adversarial case

The input chosen specifically because it is most likely to break your approach. The trace most candidates skip and where bugs most often hide.

State table

A small variable-to-value table you sketch and update each iteration so a verbal trace stays accurate instead of drifting halfway through.

Off-by-one error

Iterating one element too far or one too few: the most common bug a dry run catches, usually in a loop bound or an index.

Boundary condition

The behavior of your code at the first, last, or empty position, where an off-by-one or a wrong comparison operator flips the result.

Sentinel value

The agreed return for the not-found or empty case, for example -1 or an empty list. Edge-case traces exist partly to confirm you return the right one.

About the author: Sam K. is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside: what changed, what works for new grads, and where the old playbook fails.