the 5 mistakes that made me fail every coding interview for 6 months (not DSA-related)
Anonymous User
669

my DSA was fine. i could solve mediums consistently. still got rejected 6 times in a row. here's what was actually killing me — none of it was about algorithms:

mistake 1: coding in silence

i'd read the problem, go quiet for 5 minutes thinking, then start typing. interviewer had zero signal during those 5 minutes. they cant give you hints if they dont know what you're thinking.

fix: narrate everything. "i'm thinking this looks like a sliding window because of the 'longest subarray' phrasing. let me check if the constraint is monotonic... yes, so i'll expand right and shrink left when the window becomes invalid."

mistake 2: jumping to optimal without mentioning brute force

i'd immediately code the optimal approach. sounds good right? no. if i got stuck halfway, there was nothing to show. zero partial credit.

fix: always say brute force first (10 seconds). "brute force would be O(n²) — check every subarray. but we can do O(n) with sliding window because..." now even if you mess up the optimal, the interviewer knows you understand the problem.

mistake 3: not asking clarifying questions

"given an array of integers..." — i'd start coding immediately. then 20 minutes in: "wait, can there be negative numbers?" and my whole approach breaks.

fix: spend 60 seconds asking: "can there be negatives? duplicates? is the input sorted? can the array be empty? how large can n be?" this takes 1 minute and saves 10.

mistake 4: testing with examples only in my head

i'd finish coding and say "i think this works." interviewer: "walk me through an example." me: fumbles through tracing.

fix: before writing code, trace through the first example BY HAND on paper/whiteboard. this catches logic errors BEFORE you code them. and it shows the interviewer you have a systematic process.

mistake 5: not handling edge cases until asked

interviewer: "what if the array is empty?" me: "oh... let me add a check." makes it look like i only thought of the happy path.

fix: after coding, proactively say: "let me check edge cases — empty input returns 0, single element returns itself, all duplicates handled by the hashset initialization." shows maturity.


the realization: interviewers are evaluating 4 things, and only ONE is "can you solve the problem":

  1. communication (35%) — do they understand your thought process?
  2. problem solving approach (25%) — brute force → optimize → code
  3. code quality (25%) — clean, modular, good names, handles edges
  4. correctness (15%) — does the code actually work?

i was scoring 15/15 on correctness and 0 on the other three. once i fixed my PROCESS, same DSA skills started converting to offers.

the resource that helped me practice pattern recognition so i could spend more time communicating and less time figuring out the approach: systemcraft.in/dsa-fundamentals — when you have the template memorized, you free up brainpower for steps 1-3 above.

what non-DSA mistake was silently killing your interviews? for me it was #1 — i'm naturally quiet when thinking, and it took conscious effort to start narrating my thoughts out loud. practice this with a timer and a voice recorder.

Comments (4)