Courses › Coding Interviews › Getting Started
Common Mistakes
The 15 process mistakes that sink coding rounds — and what to do instead.
Most failed coding rounds aren't caused by not knowing the algorithm. They come from a small set of process mistakes: coding too early, testing too little, or handling pressure badly. Every one of them can be fixed with practice. Here are the ones interviewers see most.
Before coding
1. Jumping straight into code. You solve a slightly different problem, or commit to an approach that doesn't scale. Spend the first 5 minutes clarifying and working through an example. See Communicating While You Code.
2. Ignoring the constraints. n ≤ 10⁵ rules out O(n²). n ≤ 20 hints at exponential backtracking or bitmasks. The constraints are a hint about the intended solution. See the Big-O Cheat Sheet.
3. Skipping the brute force. Saying it takes 30 seconds, proves you understand the problem, and gives you something to fall back on. Then improve it with a reason: "The repeated work is X, so I'll cache it."
4. Getting stuck on the optimal solution. A working O(n log n) solution beats an unfinished O(n) one. If the better idea isn't coming, code the good solution and mention how you'd improve it.
While coding
5. Clever code nobody can follow. Dense one-liners and single-letter names make your code harder to verify, for you and for the interviewer. Readable code is easier to debug under pressure.
6. Not using helper functions. One 60-line function hides bugs. Pull out is_valid(r, c), neighbors(node), build_graph(). Helpers also make it easy to say "assume this works for now" and come back to it.
7. Mutating input you still need, or sharing references. [[0] * n] * m creates m references to the same row. Reusing a list for every recursion path without copying it shows up in backtracking. Mutating the caller's input without saying so is another version.
8. Forgetting the language's details:
- Python:
list.pop(0)is O(n), so use adeque. Strings are immutable, so build them with"".join(parts). Recursion depth is limited to about 1000.heapqis a min-heap, so negate values for a max-heap. - Java/C++: integer overflow in sums and products, and
==on boxedIntegers.
Testing
9. Saying "I think it works" without tracing. Walk through one normal example by hand, then the edge cases: empty input, a single element, all duplicates, negative numbers, the largest values.
10. Testing your idea instead of your code. Trace what you actually wrote, line by line. Off-by-one bugs hide in the gap between what you meant and what you typed.
11. Fixing bugs by trial and error. When the output is wrong, find the first step where the state goes wrong, then fix the cause. Randomly changing < to <= until the test passes is visible to the interviewer.
Under pressure
12. Going silent when stuck. The interviewer can't help you, or give you credit for your reasoning, if they can't hear it. Say what you're trying.
13. Resisting hints. A hint isn't a penalty. Ignoring one is. Take it and build on it out loud.
14. Letting one bad round sink the next. Every interviewer scores independently. Reset between rounds. The round that felt worst often wasn't.
15. Bad time management. Check the clock at the halfway point. If you're still designing at minute 25 of 45, commit to the best approach you have and start coding.
Preparation mistakes
- Grinding problems without reviewing them. Revisiting problems you've already solved, with spaced repetition, teaches more than solving new ones. See How to Prepare.
- Practicing silently. If you never practice out loud, you'll find the interview much harder than practice.
- Never practicing under a timer, or without your editor's autocomplete, if the interview editor won't have it.
[!TIP] Run a post-mortem After each practice problem, write down one sentence: what slowed you down? After 20 problems you'll see your own top three mistakes, and those are the ones to fix first.