Coding interview mistakes

Most no-hires are process failures, not missing a trick. You coded the wrong problem, went silent, or sat on a blank editor hunting for O(n). Recovery is a skill: name the miss, reset, and leave a correct path on the board.

Walking through the usual misses

If you discover a bug at minute 40, stay calm: name the failure, patch, re-run the example.

If the problem is truly unfamiliar, fall back to the process: correct brute force → identify bottleneck → apply the nearest pattern → communicate residual risks. A clear partial is better than a clever wrong answer.

Keep an edge-case checklist you actually say: empty input, one element, duplicates, already sorted, overflow, "what if n is 1?" Write the examples before the function body so the dry-run has somewhere to land.

Pick the approach you can implement cleanly when two ideas have similar complexity. A finished two-pointer with names beats a half-typed segment tree you cannot debug.

Common mistakes about recovery

• Pretending you meant the bug. Name it. Then patch.
• Abandoning a working brute force to chase a rumor of O(log n) with eight minutes left.
• Cascading tilt. One rough round is survivable. Replaying it in the next intro is not.

Check yourself

1. Minute 12, you realize you missed "the array is sorted." What do you do?

Stop, restate the constraint, discard or adapt the approach, and say the new complexity. Do not keep typing the unsorted solution.

2. Why is a clear partial better than a clever wrong answer?

The packet can credit process, communication and a correct subset. A clever wrong answer looks like you cannot test.

Key takeaways

• Most fails are process: clarify, narrate, ship a correct slower path.
• Recover by naming the bug, patching and re-testing out loud.
• Keep an edge-case checklist and a brute-force fallback.

Further learning

Back to the map: coding interviews.