60–70% of candidates fail interviews on communication, not knowledge

Hiring managers at Indian IT companies cite the same pattern: 60–70% of candidates who clear aptitude get rejected at technical or HR rounds, and most of those rejections aren't about not knowing the answer. They're about not being able to explain it.

A common failure mode: the candidate has memorised that "useState manages state in functional components." The interviewer asks "why does the setter run asynchronously?" The candidate stalls. The follow-up exposes that the first answer was pattern-matched, not understood.

Two practical changes that move the needle.

First, go deep on fewer topics. Pick five things you can talk about for ten minutes each, three layers down. "How does HashMap work" → handles collisions via chaining → resizes at load factor 0.75 → in Java 8 buckets convert to a tree above 8 entries for O(log n) lookup. That depth signals real understanding far more than knowing twenty topics at one layer.

Second, rehearse out loud, alone, before the interview. Most engineers think faster than they speak. The first time you say a complex idea is the worst version of it. Make the first time happen in private, not in front of the interviewer.

A quick filter: if you can't teach a concept to a non-technical friend in three minutes, you don't know it well enough to defend it under interview pressure.