Curating the interview question bank on this site means spending a lot of time not just on questions and answers, but on how questions get asked — the follow-ups, the intent behind them, the answers that impress and the ones that quietly end an interview. Across languages and seniority levels, the same seven mistakes keep appearing. None of them is about raw ability.
1. Jumping to code before understanding the problem
The most common failure by far. The interviewer finishes describing the task, and the candidate starts typing within ten seconds. Then, eight minutes in, a clarifying detail surfaces — "oh, the input can be empty" or "duplicates are allowed" — and the half-built solution collapses.
Interviewers deliberately leave problems underspecified to see whether you probe requirements. Spending the first two minutes asking "What should happen with an empty input? Can values be negative? Roughly how large is the dataset?" is not stalling — for the interviewer, it's the first signal that you'd be safe to put in front of a real, ambiguous ticket.
2. Coding in silence
An interview is not an exam; it's a pairing session with an evaluator. When you go silent for four minutes, the interviewer has no idea whether you're methodically working through the approach or completely lost — and they usually assume the worse option. Narrate at the level of intent: "I'll use a map from user ID to their last seen timestamp, so lookups are constant time." If narrating while typing is hard (it is, at first), practice it — it's a trainable skill, and it also slows you down just enough to catch your own bugs.
3. Ignoring the hint
When an interviewer says "interesting — what's the complexity of that inner loop?", they are not making conversation. They're handing you a lifeline. Candidates in tunnel-vision mode brush hints aside ("right, I'll get back to that") and keep digging their hole. Treat every unprompted interviewer comment as a signal flare: stop, engage with it, and be willing to say "you're right, this approach is quadratic — let me reconsider." Changing course on a hint is scored positively; needing the hint costs far less than ignoring it.
4. Claiming knowledge you don't have
Interviewers ask depth-probing follow-ups precisely to find the edge of your knowledge — the edge is expected to exist. The candidate who says "I haven't used database triggers in production, but my understanding is they're procedures that fire on row events — I'd want to read up on their performance behavior before relying on them" scores better than the one who improvises a confident, wrong explanation. One bluff, once detected (and experienced interviewers detect them with ease), taints every other answer you've given. Calibrated uncertainty is a senior-engineer trait; bluffing is a red flag at any level.
5. Never testing your own code
Writing the solution and immediately declaring "done" tells the interviewer exactly how you'd behave with production access. Strong candidates trace through their code with one normal input and one nasty one (empty input, single element, duplicate values, the boundary the problem statement hinted at) before being asked. Finding your own off-by-one during that trace is not embarrassing — watching the interviewer find it for you is.
6. Arguing with feedback
Sometimes the interviewer challenges a correct answer — occasionally as a stress test, more often because your explanation was unclear. The failing responses are the two extremes: instant capitulation ("oh, then I'm wrong") and defensiveness ("no, I'm right"). The passing response engages with the substance: "Let me re-check — for input [3,1,3], my approach gives X because… actually yes, this holds. Was your concern about the duplicate case?" Composure under technical pushback is often the thing being measured in that moment, especially for senior roles.
7. Treating behavioral questions as filler
"Tell me about a conflict on your team" gets rehearsed one-liners while candidates save their energy for the coding round — but at many companies, the experience round carries equal weight and vetoes hires on its own. Prepare five real stories (a bug, a disagreement, a failure, a deadline, a success) with concrete details and a clear "what I did" in the middle. Specificity is what separates a memorable answer from noise: not "we had performance issues and fixed them" but "checkout p95 was 4 seconds; I profiled it, found an N+1 query behind the cart totals, and after batching, it dropped to 400 milliseconds."
The pattern behind all seven
Read the list again and notice what's absent: algorithms. Every one of these failures is about communication and judgment under observation — skills interviews are specifically designed to surface, and skills that grinding problems alone will never train. The fix is the same for all seven: practice out loud, with another human when possible, and treat the interviewer as a collaborator you're working with rather than an examiner you're performing for. That single mental shift eliminates most of these mistakes automatically.
