You come out of the technical round and your friend asks how it went. You say the questions were fine. You knew SQL joins, you knew what a REST API is, you knew how your final-year project worked. And you also know, with a sinking feeling, that you did not get through, because the interviewer kept saying "okay" in that flat way and moved on quickly.
Two days later the rejection mail comes and you cannot work out what went wrong. The answers were in your head. You had studied the right things. So why does it feel like you failed a test you knew the answers to?
The short answer
Because a technical interview is not a test of what you know. It is a test of whether you can get what you know out of your head and into the room, in a form another engineer can follow and score, while they watch. Studying trains the first skill. Almost nothing in a B.Tech or BCA course trains the second. Freshers fail technical interviews far more often on the second than the first, and the fix is a different kind of preparation, not more of the same.
Why this is a fresher problem specifically
Experienced developers explain their thinking every day. Code reviews, stand-ups, design discussions, arguing with a teammate about a database choice. By the time they interview, narrating a decision is a habit.
A fresher has spent four years being examined in writing, alone, with time to think. Even the viva is mostly recall. Then the first technical interview asks them to reason out loud, in English, under a clock, in front of someone who is writing notes, and it is genuinely the first time they have ever done it. The knowledge was never the gap. The performance was.
Placement drives make it worse. When an interviewer has fifteen candidates in a day, they cannot spend ten minutes coaxing an answer out of someone. A candidate who cannot explain quickly reads as a candidate who does not know, even when that is unfair.
What interviewers are actually scoring
Most freshers imagine the interviewer holds an answer key. Some do, for the first easy question. After that, they are doing something closer to what large employers describe publicly. Google's account of its process, How we hire, says interviews assess how candidates approach problems rather than whether they recall facts. Amazon structures its interviews around its Leadership Principles, which are about judgement and behaviour, and its technical rounds expect you to talk through your reasoning throughout. Most Indian product companies and the large service firms follow a similar structure in their own way: a few technical questions, then follow-ups, then a project discussion, and a written assessment of how you handled each.
Notice what that means. A correct answer said as a bare fact scores on one dimension only: did they know it. Everything else the interviewer is writing down is about how you got there and whether they could follow you. Knowing the answer is perhaps a third of the mark. The rest is available on questions you only half know, if you handle them well.
The memorised answer problem, with a real example
This exchange happens in some form in a huge number of fresher interviews.
Interviewer: "Why did you use MongoDB in this project?"
Candidate: "MongoDB is a NoSQL database that stores data in flexible, JSON-like documents, which makes it scalable and good for handling unstructured data."
Every word is true and none of it answers the question. The interviewer asked why you chose it. She got a definition from the first page of a tutorial. She has also just learned that the candidate may not have chosen it at all.
A stronger answer connects the technology to the actual project. "The data was student profiles and the fields kept changing while we were building, so I did not want to keep altering a SQL schema. A document database let us change the shape in code. Looking back, once the fields settled we could have moved to Postgres and got proper joins for the reports page, which we ended up doing awkwardly in JavaScript."
That takes about the same number of words. It contains a decision, a reason grounded in the project, a trade-off, and a piece of reflection. It also sounds like a person who built something. The habit to build is simple to state and hard to do under pressure: answer every "why" with a decision and its consequences, never with a description of the tool.
Your project is your best preparation material
Freshers spend most of their preparation on theory: question banks, definitions, the standard "difference between" questions that sites like Naukri's campus guide collect. Those have their place. But the one thing every interviewer will definitely ask about is your project, and it is the richest source of interview questions you own, because every decision in it can be questioned and only you can answer.
Before an interview, close the code and try to explain the architecture from memory. Where does a request come in? Where is authentication checked and what happens when it fails? How does data get from the database to the screen, and what changes it along the way? What would break first if a thousand students used it at once? What would you do differently now?
If you cannot say where authentication happens without opening a file, you have found a gap, and it is a gap in explanation rather than in knowledge. Those are the cheapest gaps to close and the ones the interview will find first.
Reasoning out loud is a habit, not a personality trait
Some candidates seem to narrate their thinking naturally. Almost none of them were born doing it. It is a habit, built by doing it in low-stakes settings until it stops feeling odd.
The mechanics are not complicated. Before answering, say what you think the question is asking, in your own words. Say any assumption you are making. Work through the answer in steps and name each step as you take it. If you change your mind halfway, say so and say why. At the end, sum up in one sentence.
It feels slow the first few times. It is not slow. A structured ninety-second answer is far easier to score highly than a thirty-second answer the interviewer has to reconstruct. It also gives you somewhere to recover. An interviewer who can see your reasoning can nudge you at exactly the step that went wrong. One who is watching you think silently can only wait.
What happens on the question you do not know
Reasoning aloud pays off most on the questions you cannot fully answer, and those are the questions where the interview is usually decided. A candidate who says "I have not used that, but here is what I know about the nearest thing, and here is how I would find out" has just demonstrated problem solving and honesty in one sentence. A candidate who guesses confidently and gets caught on the follow-up has demonstrated the opposite, and has made the interviewer wonder about the earlier confident answers too. There is a full article on this moment in how to handle a question you don't know the answer to.
Practise the performance, not just the material
If the skill that fails in interviews is the performance skill, then preparation has to include performances. Solving a problem silently in VS Code and checking the answer trains knowledge. To train the other thing, you need to answer aloud, to something that responds, under time.
A developer friend willing to be stern for forty minutes is the best free option. A study group where you take turns interviewing each other works if everyone commits to asking follow-ups instead of being kind. If neither is available, a structured practice round can fill the gap: on 99Interview you can run a round with an AI interviewer that asks, follows up on your answers and scores the transcript, or book a live mock interview with a working engineer who gives written feedback on each area afterwards, in the track that matches your target role, such as a backend or frontend interview; what each includes is on the pricing page. Whichever route you take, do the part most people skip and read the transcript afterwards. Not the score, the words. Find the moment your explanation became a definition or trailed off. That moment is what you practise next.
Frequently asked questions
Why do I fail technical interviews even though I know the answers?
Usually because knowing and explaining are different skills and you have only practised the first. Interviewers score how you reason and communicate, not just whether the fact was correct. Practising answers aloud, with follow-ups, closes most of the gap.
What do interviewers look for in a fresher's technical round?
Whether you understand your own project's decisions, whether you can reason through something unfamiliar without guessing, and whether they could follow your explanation. Correct facts matter, but they are the starting point, not the whole assessment.
How do I answer "why did you use this technology" in an interview?
With a decision, a reason from your project, and a trade-off. "We chose X because of Y, and it cost us Z" is the shape. Never with a definition of the technology.
How can I practise technical interviews alone?
Explain your project aloud from memory and record yourself, then listen for the places you went vague. Solve problems while narrating. Use an AI interviewer or a friend for follow-up questions, because follow-ups are what you cannot generate for yourself.
Is communication really scored in a technical interview?
Yes, in almost every structured interview process, and heavily. An interviewer cannot give credit for reasoning they could not follow, and they are also judging whether they could work with you when something breaks.
One thing to do this week
Pick the project on your resume you are most likely to be asked about. Explain it aloud, from memory, to a friend or to your phone's voice recorder, and answer "why" for every technology in it. Then listen back.
The knowledge you already have is probably enough for the job you are interviewing for. When was the last time you practised saying it out loud to someone who was allowed to interrupt?