How to Test Your Own Code in a Coding Interview

You pass all visible test cases on the screen, but the hidden evaluator fails your submission because you did not trace your variables line by line before clicking finish. Stop guessing whether your solution works and start dry running it systematically. Pick a normal case, an empty input, and a boundary case, then walk through your pointers and indices manually to catch off-by-one errors and null pointer exceptions before the interviewer points them out.

The Three Test Cases You Must Run

Every time you write a solution for a problem like Two Sum or Reverse Linked List, you need three distinct inputs before you declare the code ready. The first is a normal, mid-sized case with positive numbers and standard constraints, such as arr = [2, 7, 11, 15] and target = 9. The second is an empty or minimal input, such as an empty array [] or a single node head = [1]. The third is a boundary case where values repeat or reach the absolute limit of the constraints, such as arr = [3, 3] with target = 6. If you skip these three checks, your code will fail on the hidden test cases that evaluate your placement round.

Tracing Variables Line by Line

Write your index variables, pointers, and accumulator values on your scratchpad, then step through your for loop or while loop manually. For example, if you are writing a binary search function for arr = [1, 3, 5, 7] and target = 5, set left = 0 and right = 3. Calculate mid = (0 + 3) / 2 = 1. Check arr[1], which is 3. Since 3 is less than 5, update left = mid + 1, which makes left = 2. Write down the new values of left, right, and mid for the next iteration. Doing this on paper prevents the exact mental blind spots that cause infinite loops in technical interviews.

Fixing Bugs Calmly

When your manual trace reveals that left becomes equal to right and skips the final element, do not panic or rewrite the entire function. Look specifically at your loop condition. Change while (left < right) to while (left <= right) if your boundary logic requires checking the final overlapping index. Common bugs hide in plain sight at the edges of your loops. Check your increment statements, verify what happens when the input size is zero, and ensure your return type matches the function signature before you speak to the interviewer.

A Quick Rule of Thumb for Your Next Mock Test

Never say your code is complete until you have manually traced an input of size zero, an input of size one, and an input with duplicate values. Keep this rule taped near your desk during practice sessions on DSA Tracker.

Keep going with practice problems and the online compiler.

Further reading: Binary search on Wikipedia.