Dry-Running and Testing Whiteboard Code
Fast recall
Quick revision
Core answer
Whether the candidate has a testing mindset and systematically verifies their code rather than assuming it works.
Freshers often finish writing code and immediately say 'done' without any verification, missing obvious bugs or edge cases.
Walk through the code out loud while testing, pointing out specific edge cases you're considering and explaining why they matter for production code.
Interview-ready guide
Interview answer
After writing the solution, I first confirm the method's contract. In this example, an empty array returns OptionalInt.empty(), so I am not using Integer.MIN_VALUE as a value that could be confused with valid data.
For [3, 7, 2, 9, 1], I initialise max to 3. At index 1 it becomes 7, it stays 7 for 2, becomes 9 at index 3, and stays 9 for the final value. The method therefore returns 9. I would also trace an all-negative case such as [-3, -1, -5] to check that initialising from the first element—not zero—returns -1.
I write the index and current maximum beside the code so the state change is visible. If the trace exposes an off-by-one error, I correct the loop boundary and repeat the affected case. The tests come from this method's contract and branches rather than a fixed list.
Dry-Running and Testing Whiteboard Code
Direct Answer
After writing whiteboard code, trace through it line-by-line with the given example, writing down variable values at each step. Then mentally test edge cases like empty input, single element, or null values. Verbally explain what you're checking and why, showing you think about correctness before declaring the solution complete.
Code Example
OptionalInt findMax(int[] values) {
if (values == null || values.length == 0) {
return OptionalInt.empty();
}
int max = values[0];
for (int i = 1; i < values.length; i++) {
if (values[i] > max) max = values[i];
}
return OptionalInt.of(max);
}
// Trace for [3, 7, 2, 9, 1]
// start: max=3
// i=1: 7 > 3 -> max=7
// i=2: 2 > 7 -> false, max=7
// i=3: 9 > 7 -> max=9
// i=4: 1 > 9 -> false, max=9
// result: OptionalInt[9]
// [] -> OptionalInt.empty()
// [-3, -1, -5] -> OptionalInt[-1]
Common Mistakes & Pitfalls
- Testing an undefined contract — decide what null or empty input means before claiming the result is correct.
- Repeating only the sample — add a boundary case that targets the algorithm's branch or initialisation.
- Tracking too much state — record the variables that can change the decision, not every temporary value.
- Fixing silently — name the failed condition, make the correction visible, and recheck the affected path.
Check your understanding
Answer these without looking back at the article.
- How do you trace through a recursive function on a whiteboard?
- What edge cases do you always think about for array problems?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.