DSA · Patterns, not puzzles
What are common coding interview mistakes?
Short answer
Common mistakes are skipping clarifying questions, ignoring empty or single-element inputs, off-by-one boundary errors, mutating input unexpectedly, and claiming the wrong complexity. Testing edge cases out loud catches most of them.
Most failed interview solutions are not conceptually wrong; they are incomplete. The candidate solves the main example, then misses the empty input, the duplicate value or the case where the answer is at the boundary. A short checklist before coding prevents a large share of these.
function firstIndex(values, target) {
let left = 0;
let right = values.length - 1;
let result = -1;
while (left <= right) {
const mid = Math.floor((left + right) / 2);
if (values[mid] === target) {
result = mid;
right = mid - 1;
} else if (values[mid] < target) {
left = mid + 1;
} else {
right = mid - 1;
}
}
return result;
}The checklist
- Clarify input size, value ranges, duplicates and whether the input may be mutated
- Test empty, single-element and all-equal inputs
- Check loop boundaries and inclusive versus exclusive ranges
- State time and space complexity after the code, not before
- Walk through the code with a small example instead of only describing it
Another common mistake is silently changing the problem. If the prompt asks for the first occurrence, returning any occurrence is wrong. If it asks for indices, sorting without preserving them is wrong. Repeat the requirement before you commit to an approach.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you test a solution before running it?
- 2What edge cases do you always check?
- 3How do you handle a bug you cannot find under pressure?
- 4When should you mention complexity during an interview?
Say it in the interview
The mistakes I see most are skipping clarification, missing empty or single-element inputs, and getting loop boundaries wrong. I try to repeat the requirements, write a small example, and test edge cases before declaring done. I also state complexity after the code so it matches what I actually wrote. If a solution is correct but not optimal, I would rather finish it and then discuss the improvement.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live DSA mock interview and get scored feedback on depth, clarity and confidence.