The Real Reasons You're Failing Tech Interviews
After 3 years as an interviewer, I've found that coding skill isn't usually what separates candidates
It Looks Different from the Other Side
I've been conducting technical interviews for three years. About 213 candidates so far, and the ones who don't make it share common traits. Surprisingly often, the reason isn't "they couldn't code."
When two candidates have similar coding ability and only one gets the offer, the deciding factor is almost always outside the code. Interviewers are human too. We don't expect perfect answers. What we're really looking at is: "Would I want to work with this person?"
If You Don't Know, Just Say So
This is the most common mistake I see. Faking knowledge when asked something you don't know. "Umm... that's probably... something to do with memory..." and stalling for 30 seconds -- the interviewer already knows. They know you don't know.
Someone who honestly says "I'm not sure about the specifics, but given the context, I'd reason through it like this" scores far better. "That's something I haven't studied yet" isn't bad either.
Once, when asked "explain Redis's internal data structures," a candidate said: "I don't know the exact details, but I know it's hash-table based, and here's how I've used it in practice." They got the offer. In real work, no developer knows everything. What matters is how you handle not knowing.
(I'm an interviewer and there's plenty I don't know either. But that's a secret.)
What Interviewers Really Want to Hear Is "Why"
"Why did you choose Zustand over Redux?" When someone answers "everyone's using it these days," that's a red flag. Following a trend and making a technical decision are completely different things.
"The project was small enough that Zustand's minimal boilerplate was a better fit. It supports devtools without middleware for easy debugging, and the bundle size is about 1KB so the performance impact was negligible" -- that's plenty.
Every technology choice should have a rationale. "People said it was good" is not a rationale. In my experience, this is where candidates diverge the most. But it's something you can practice -- just get into the habit of asking yourself "why?" whenever you make a tech choice.
Numbers Need a Story Behind Them
"I improved performance by 50%" -- I'll always follow up with "how?" And half the candidates get stuck right there.
Which metrics did you measure (Lighthouse? Core Web Vitals? Internal APM?), where was the bottleneck (network? rendering? DB?), what did you try, and why did you pick that approach?
"I first tried image compression but the impact was minimal, so I switched to code splitting and got a 32% improvement" -- this lets the interviewer see your problem-solving process. Being honest about failed attempts is better than inflating numbers. Being able to talk about failure is itself evidence of competence.
30% of Candidates Don't Ask Questions
At the end of the interview, when I ask "any questions for us?" about 30% say "no." That reads as a signal of disinterest. Even asking 2-3 questions about the team's code review culture, deployment process, onboarding, or how tech stack decisions are made completely changes the impression.
A good question leaves just as strong an impression as a good answer. Though this might vary by company -- this is just my take as an interviewer.
If You Can't Have a Conversation, It's Tough No Matter How Good You Are
Technical interviews are conversations, not presentations. During whiteboard coding, candidates who silently work for 10 minutes and say "done" have lower pass rates than those who check in mid-way with "I'm thinking of approaching it this way -- does that seem reasonable?"
In practice too, asking one question midway beats struggling alone for three hours. Interviewers are imagining "how would this person work on a team?" No matter how skilled someone is, if you can't have a conversation with them, working together is hard.
Even Seniors Stumble on Basics
I'm not talking about algorithms. I've seen senior candidates stumble on "what's the difference between HTTP GET and POST?" Frontend candidates who can't properly explain == vs. === in JavaScript.
If you're great with frameworks but don't understand the principles underneath, a deep conversation becomes impossible. To use React well, you need to understand JavaScript -- the event loop, prototypes, all of it.
(This applies to me too, which stings a bit. I sometimes skip reviewing fundamentals myself.)
When people get rejected, it's easy to feel like you're not good enough. But from three years of interviewing, I've found it's more often about failing to communicate what you know rather than lacking the knowledge. Start by explaining something you learned today to a colleague.