How to Dry Run Code Manually: The Missing Skill for Coding Interviews

You've written your solution. You hit "Run." It fails. You stare at the screen, change a < to a <=, and hit "Run" again. It still fails.

This cycle of "Guess-Run-Fail" is the hallmark of a junior developer.

In a whiteboard interview, there is no "Run" button. If you can't simulate the computer's execution in your head (or on paper), you are flying blind.

Dry running—the act of manually walking through code step-by-step—is not just a debugging tool; it is the primary way you prove correctness to an interviewer.

TL;DR

• What it is: Manually tracking variables and logic flow line-by-line, exactly as a CPU would.
• Why it matters: It's the only way to debug in a whiteboard setting and proves you understand your own code.
• The Method: Use a "Trace Table" to track every variable's state change over time.
• Common Mistake: "Reading" code (skimming logic) instead of "running" code (executing instructions blindly).
• Outcome: You catch off-by-one errors and edge cases before the interviewer points them out.

The "Reading" vs. "Running" Trap

The biggest mistake beginners make is reading their code.

When you read, your brain fills in gaps. You see i++ and think "it increments," assuming it happens at the right time. You see a loop and assume it stops correctly. You are projecting your intent onto the code.

When you dry run, you must become a dumb machine. You don't know what the code should do; you only know what it does.

• Reading: "This loop goes through the array."
• Dry Running: "i is 0. Array[0] is 5. 5 < 10 is True. Enter loop."

Step-by-Step Guide: How to Dry Run Effectively

1. Set Up Your "Memory" (The Trace Table)

Don't try to hold variables in your head. Your working memory is for logic, not storage. Write them down.

Create a table where columns are your variables and rows are time steps.

Example Snippet:

def reverse_array(arr):
    left = 0
    right = len(arr) - 1
    while left < right:
        arr[left], arr[right] = arr[right], arr[left]
        left += 1
        right -= 1
    return arr

Trace Table:

2. The "Finger" Technique

Literally put your finger (or cursor) on the current line of execution. Do not move it until you have updated your trace table.

1. Execute: Read the line.
2. Update: Change the value in your table.
3. Move: Go to the next line.

This physical anchor prevents your eyes from skipping ahead.

3. Test "Boring" and "Dangerous" Inputs

Don't just test [1, 2, 3]. That's a "happy path."

To truly verify correctness, dry run these specific cases:

• Empty Input: []
• Single Element: [1]
• Two Elements: [1, 2] (Checks swap logic)
• Duplicate Elements: [2, 2]

Common Mistakes to Avoid

The "Auto-Correct" Brain

You see if i < len(arr) but you wrote if i <= len(arr). Your brain reads the correct version because that's what you meant.
Fix: Read the symbols out loud. "If i is less than or equal to length." Hearing it helps catch the mismatch.

Skipping Loop Iterations

"Okay, it loops 5 times, so at the end i is 5."
Fix: Never skip. Off-by-one errors live in the last iteration. Always trace the final loop check where it becomes False.

Ignoring Scope

Forgetting that a variable inside a loop resets or persists unexpectedly.
Fix: If a variable is re-declared, cross out the old column or start a new scope block in your table.

Tools to Build Intuition

While the goal is to do this manually, you can build the muscle memory using tools that visualize this process.

Tools like LeetCopilot can generate these execution traces for you. By asking it to "explain the execution flow," you can see exactly how the computer "thinks" and compare it to your mental model. This feedback loop corrects your intuition faster than guessing.

FAQ

How do I dry run recursion?

Recursion requires a Stack Trace instead of a simple table. List each function call as a new "box" with its own local variables. When a function returns, cross out the box and pass the value back to the caller.

Should I write the table during an interview?

Yes! Writing a small table for a few iterations shows the interviewer you are rigorous and careful. It's much better than staring at the ceiling and mumbling numbers.

What if the input is huge?

Don't trace a 100-item array. Pick a small, representative input (e.g., size 3 or 4) that captures the complexity (odd vs. even length, etc.).

Conclusion

Manual code tracing is the difference between hoping your code works and knowing it works.

It slows you down initially, but it speeds you up overall by preventing the "write-run-fail" loop. In an interview, that confidence is contagious. When you can methodically prove your logic, you stop looking like a student and start looking like an engineer.

Next time you solve a problem, resist the urge to hit "Submit." Grab a pen, draw a table, and be the computer.