Last week I sat across the table from five candidates interviewing for a frontend technical role. Different backgrounds, different colleges, different project stacks. But by the end of day two, I noticed the same patterns repeating — not in their code, but in how they communicated, how they handled pressure, and how they carried themselves in the room.
This isn't a rant. I'm writing this because I genuinely want the next batch of candidates to walk in better prepared. These are fixable problems. Every single one of them.
1. Filler Words Are Quietly Destroying Your Answers
Here's a real example from one of the sessions. I asked a candidate to explain how
async/await works under the hood. The answer started like this:
"So like… async await is basically like… when you want to like… wait for something, like an API call or like some data, so like it pauses and um… yeah it like waits and then like continues…"
The candidate actually understood the concept. But by the time they got to the point, I had mentally counted fourteen filler words. The signal was buried under noise.
Every "uh", "um", "like this", "like that" chips away at the confidence you're trying to project. Interviewers don't just evaluate answers — they evaluate how you think. Filler words signal disorganised thinking, even when the underlying knowledge is solid.
The fix is counterintuitive: silence. A three-second pause before answering reads as composure and clarity. A sentence packed with "like" reads as unpreparedness. Choose the pause. Every time.
2. Looping — When Your Brain Gets Stuck on Repeat
One candidate, when asked about the difference between == and === in
JavaScript, said roughly the same sentence four times in a row — each time slightly rephrased,
never moving forward:
"So double equals checks the value… it checks if the values are equal… like it compares the values… so basically the values are compared…"
This is a nervous system response, not an intelligence problem. When anxiety spikes, the brain defaults to what it already said because forward progress feels risky. But from the interviewer's side of the table, looping signals one thing: the candidate doesn't know where their answer ends.
If you catch yourself looping mid-answer, the best thing you can do is stop. Literally say: "Let me reframe that." Then start fresh with a structure: define the concept, give the difference, offer an example. Three steps. Done.
3. Speaking More Is Not the Same as Saying More
This was the most frustrating pattern I observed across all five sessions.
I asked one candidate: "How does browser rendering work?"
The response started like this:
"So browsers are very important in web development, we use browsers every day to access websites and the internet has changed how we communicate… so when we type a URL the browser goes to the server and browsers are also used on mobiles today and there are many browsers like Chrome, Firefox, Safari…"
Two minutes in. We still hadn't touched the DOM tree, the CSSOM, layout, paint, or compositing — the actual answer to the question.
A technical interview is not a board exam where volume of content earns partial marks. Interviewers are evaluating one thing above everything else: clarity of thought. Can you take a complex topic, identify what's relevant, and explain it precisely?
A tight, structured 45-second answer will always outperform a three-minute monologue that circles the point without landing on it. When you ramble, you don't sound more knowledgeable — you sound less confident in what you actually know.
The formula that works:
- Answer the question directly in one sentence.
- Explain the mechanism or reasoning.
- Give a concrete example if it adds clarity.
- Stop.
4. "I Don't Know" Is a Legitimate Technical Answer
I asked a candidate about Web Workers and how they interact with the main thread. They clearly hadn't worked with them. But instead of saying that, they spent four minutes constructing an answer that was a mix of vague generalisations and confidently stated inaccuracies.
Here's what I actually wanted to hear:
"I haven't worked with Web Workers directly, but from what I understand they run scripts in background threads separate from the main thread — so they can handle heavy computation without blocking the UI. I'd want to look deeper at the postMessage API for communication between them."
That answer — which acknowledges a gap but shows reasoning instinct — is worth ten times more than a fabricated answer. It tells me the candidate knows where their knowledge ends, which means I can trust the boundaries of what they claim to know.
Interviewers are not trying to catch you out on every question. We know freshers haven't seen everything. What we're testing is intellectual honesty and the instinct to reason through the unknown — not just recall the known.
5. The Overconfidence Problem — And I'll Say What Others Won't
This one is the hardest to write because it will sting for some readers. But it's the observation I keep coming back to.
One of the candidates had two personal projects on their resume — a portfolio site and a weather app built with a YouTube tutorial. Sharp-looking resume, confident body language, came in with energy. Good signs.
Midway through the session I asked a question about state management — then, fifteen minutes later, asked a variation of the same concept with a different framing to probe depth of understanding. It's a standard technique. The candidate clocked the similarity and said:
"Sir, I already answered this. It's the same question."
It wasn't the same question. And even if it were — that is not how you speak to someone who is evaluating whether to invest in your growth and pay your salary.
But here's my broader, more controversial observation: the current ecosystem of self-learning content is producing a confidence gap in junior developers that is becoming a hiring problem.
When a YouTube tutorial ends with "you're now job ready!" after six hours of content, and a bootcamp graduation certificate gets posted on LinkedIn with forty congratulations comments — it creates a false ceiling. Freshers arrive at interviews having never shipped to production, never debugged a race condition at 2am, never handled a live incident with actual users — and yet they carry the energy of someone who has.
Production experience is a specific kind of education that cannot be replicated by personal projects. When something breaks in production at 11pm and 50,000 users are affected, you learn things about systems, communication, pressure, and your own knowledge gaps that no tutorial teaches. That experience creates a kind of calibrated humility that is immediately visible in how someone answers questions.
The candidates who impressed me most were not the ones who had the most confident answers. They were the ones who said things like "I think it works this way, but I'd want to verify that before I stake anything on it." That self-awareness is rare. And it is worth more than confidence in the interview room.
How to Actually Improve Before Your Next Interview
Work on Your Vocabulary
Technical fluency isn't just about knowing concepts — it's about articulating them precisely. Read engineering blogs from companies like Vercel, Cloudflare, and the React team. Listen to developer podcasts. The language of the industry is absorbed through immersion, not memorisation. The more you consume well-articulated technical content, the more your own speech patterns shift.
Record Yourself Doing Mock Interviews
This is uncomfortable. Do it anyway. Set a timer for 60 seconds, ask yourself a common interview question out loud, and record the answer on your phone. Watch it back. You will immediately hear every "like", every loop, every moment where your answer lost its thread. One session of this is worth ten hours of reading interview prep articles.
Practice the Pause
Before every answer, give yourself three seconds of silence. It feels awkward to you — it reads as composure to the interviewer. Use that time to identify the core of your answer before you open your mouth. Starting with the answer and building outward is far stronger than narrating your way toward it.
Structure Every Answer
Adopt a simple framework: Answer → Explain → Example. One sentence that directly addresses the question. Two to three sentences that explain the mechanism or reasoning. One concrete example if it adds clarity. Then stop. Resist the urge to keep going once you've answered the question.
Build Something That Has Real Users
Before your next interview, try to ship something — anything — to real users. A small tool, a side project with actual traffic, an open source contribution that gets merged. The experience of someone else using your work changes how you think about code quality, edge cases, and reliability. It will show in how you answer questions.
Treat Humility as a Technical Skill
In a fast-moving field where the tooling, frameworks, and best practices shift every eighteen months, knowing what you don't know is an operational advantage. Interviewers aren't looking for candidates who know everything. They're looking for candidates who can learn fast, communicate clearly, and operate with intellectual honesty under pressure.
The Line That Stayed With Me
At the end of one session, a candidate who had stumbled through several answers said something I didn't expect: "I realise I didn't answer that well — can I try again with a clearer structure?"
That self-awareness, in the middle of a stressful interview, told me more about their potential than any technically correct answer could have.
The tech industry is patient with skill gaps. It is not patient with attitude gaps. Come in knowing what you know, honest about what you don't, and hungry to close the distance between the two. That combination is rarer than any specific technical skill — and it gets noticed every time.
Top comments (0)