⚠️ COMMON INTERVIEW MISTAKE #3 - Not Testing Your Own Code
You finish coding, say "I think that's it," and stop. The interviewer asks "are you sure this works?" - and you just... shrug.
This is one of the most avoidable point losses in the entire interview.
✅ What to do instead: Before declaring you're done, manually trace through your code with the example input(s) given. Actually walk through it line by line, tracking variable values as you go - out loud.
"Let's trace through with nums = [2,7,11,15], target = 9. i=0, num=2, complement=7, not in seen yet, so seen={2:0}. i=1, num=7, complement=2, IS in seen at index 0 - so we return [0,1]. That matches the expected output."
This catches real bugs before the interviewer has to point them out (which is a much worse look), and it demonstrates the exact skill you'd use before merging a real pull request.
Bonus: always test at least one edge case too (empty input, single element, all duplicates) - don't just re-test the example they gave you.
Do you naturally trace through your code, or does it feel like an extra step you skip under time pressure? 👇
Post #1384
316