DSA · Patterns, not puzzles

What are common coding interview mistakes?

Easyinterviewsdebuggingedge-casesUpdated Oct 2026
Quiz this track

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.

js
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;
}
On a match, the search continues left instead of returning, which correctly finds the first occurrence.

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.

Do not optimize prematurely. A correct O(n log n) solution that you can explain is usually better than an unfinished O(n) idea. Get correctness, then discuss improvements.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How do you test a solution before running it?
  2. 2What edge cases do you always check?
  3. 3How do you handle a bug you cannot find under pressure?
  4. 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.