Common Coding Interview Mistakes — and How to Fix Them

The 15 Most Common Mistakes

Mistake 1: Coding without clarifying

What happens: You solve the wrong problem. Signal: Poor communication, impulsive. Fix: Always repeat the problem in your own words and ask 2-3 targeted questions before writing a single line.

Mistake 2: Jumping to optimal too fast

What happens: You get stuck mid-solution because you skipped the brute-force scaffolding. Signal: Overconfident, can't handle ambiguity. Fix: Always state brute force first, even in one sentence: "Naively I'd try all pairs — O(n²)."

Mistake 3: Silent coding

What happens: You code for 10 minutes without speaking. Signal: Can't communicate technical ideas, poor team fit. Fix: Narrate every 30 seconds: "Now I'm building the frequency map... checking if prefix minus k exists..."

Mistake 4: Wrong complexity analysis

What happens: You say O(n) for an O(n log n) solution or miss hidden loops. Signal: Doesn't understand their own code. Fix: After coding, trace every loop and recursive call. Ask: "Is there a loop inside a loop here?"

Mistake 5: Not testing

What happens: Your solution has a bug you would have caught with one trace-through. Signal: Ships buggy code, poor quality bar. Fix: Save 5 minutes to trace through one example. Also explicitly test edge cases: empty, single element, all duplicates.

Mistake 6: Giving up too easily

What happens: You say "I don't know" after 2 minutes of being stuck. Signal: Low persistence, can't handle novel problems. Fix: State what you're thinking. "I'm not sure of the optimal approach yet, but let me try to reduce it to a subproblem I know..."

Mistake 7: Over-engineering

What happens: You design a 500-line solution for a 30-line problem. Signal: Can't identify simplest solution, will build unmaintainable code. Fix: Ask yourself: "Is there a simpler data structure that achieves the same thing?"

Mistake 8: Ignoring edge cases

What happens: Your solution crashes on n=0, n=1, all negatives, or overflow. Signal: Writes fragile code. Fix: Before coding, list: empty input, single element, all same value, min/max constraints, negative numbers.

Mistake 9: Hardcoding test values

What happens: if len(nums) == 3: return [1,2,3] — you hacked the example. Signal: Dishonest, can't generalise. Fix: Never hardcode; always generalise. If you notice you're hardcoding, stop and rethink.

Mistake 10: Wrong variable names

What happens: a, b, x, temp everywhere — unreadable code. Signal: Poor code quality, will write unmaintainable code. Fix: Use left_max, curr_sum, freq_map. Takes 2 extra seconds, signals professionalism.

Mistake 11: Not handling None/null

What happens: NullPointerException in Java, AttributeError in Python. Signal: Sloppy defensive programming. Fix: First line of tree/linked-list functions: if not root: return ...

Mistake 12: Missing the simpler approach

What happens: You implement a complex solution when a simple one exists. Signal: Pattern recognition gap. Fix: If your solution is > 30 lines for an Easy/Medium, pause and ask "is there a cleaner way?"

Mistake 13: Forgetting to return

What happens: Function runs correctly but returns None. Signal: Bugs in production code. Fix: Add return statement check to your post-coding review.

Mistake 14: Not recovering gracefully from hints

What happens: Interviewer gives a hint, you get flustered and can't integrate it. Signal: Defensive, poor coachability. Fix: When given a hint, pause, say "that's a good point — so if I think about it that way...", then pivot.

Mistake 15: Ending abruptly

What happens: "I'm done." with no summary. Signal: No communication wrap-up. Fix: Always end with: "This solution runs in O(n log n) time and O(n) space. I tested it against the example and edge cases. Happy to optimise further if needed."