The first fifteen minutes have gone well. You explained your project, you got the SQL question, you even remembered the difference between an abstract class and an interface. Then the interviewer leans back and asks, "Have you worked with message queues? How would you use one here?"
You have not. You have read the words "Kafka" and "RabbitMQ" in job descriptions. You know nothing about them, and the silence in the room has started to feel like it has weight. Your brain offers two options: say something, anything, right now, or say "no" and watch the interview deflate.
Both of those are wrong, and neither is what the interviewer is hoping you will do.
The short answer
Not knowing the answer is normal, expected, and by itself costs you very little. A well-run interview is designed to find the edge of what you know, because that edge is where the useful information is. What decides the question is the thirty seconds after you hit it. Pause deliberately, say exactly what you do and do not know, reason from the nearest thing you understand toward the question, ask one clarifying question if it would genuinely help, and finish by saying how you would find out. That sequence turns a knowledge gap into a demonstration of how you think, and how you think is what the interviewer is there to assess.
Why freshers find this moment so hard
Four years of college examinations teach one lesson very thoroughly: a question you cannot answer is a question you lose marks on. Leave it blank and move on. There is no partial credit for saying "I have not covered this but here is my reasoning" on a semester paper.
Interviews work almost exactly the other way round, and nobody tells freshers this. The interviewer knows a final-year student has not used a message queue in production. The question was never really "do you know Kafka". It was "show me what you do when you meet something new", because that is most of what the first year of a software job consists of. Google's description of its own process in How we hire puts it in terms of assessing how candidates approach problems; Amazon lists "Learn and Be Curious" explicitly among the Leadership Principles it interviews against. Nearly every hiring manager values the same thing, published or not.
So the exam instinct, to either bluff or go blank, is the thing to unlearn.
The two responses that reliably go wrong
The first is guessing to fill the silence. A confident-sounding sentence comes out before the brain has caught up. The interviewer, who knows the answer, asks a follow-up. The guess cannot support a follow-up, so a second guess is stacked on the first, and now you are defending something you never believed. Worse, the interviewer has to wonder whether your earlier confident answers were also guesses.
The second is shutting down. "I don't know." Full stop. Eyes on the table. The interviewer waits, then moves on. You have said nothing wrong and scored nothing either, and a whole question's worth of marks for reasoning and communication has been left on the table.
Both come from the same mistake: treating the question as a test with one right answer instead of as a problem to be worked on out loud.
The five steps
The steps are simple. Doing them under pressure takes practice, which is the point of the last section.
First, take the pause on purpose and announce it. "Let me think about that for a second." Then actually think. A three-second silence you announced reads as composure. The same three seconds unannounced reads as panic.
Second, say exactly where the edge is. "I have not used a message queue directly. I understand the general idea, that a producer puts messages somewhere and consumers pick them up later, but I would be guessing about the specifics of how Kafka handles ordering or failures." This is honest, it is specific, and it hands the interviewer a map of where to take the conversation. It also protects you: nothing you say after this can be mistaken for a claim of expertise.
Third, reason from what you do know. An unfamiliar question almost always contains something familiar. "In my project, when a user uploaded a file, the request waited for the whole thing to be processed, which was slow. If I understand queues correctly, I could have put a 'process this file' message on a queue and returned immediately, and a separate worker could pick it up. The thing I would worry about is what happens if the worker crashes halfway." You have now used a technology you have never touched to reason correctly about your own project. The interviewer is scoring the route, not the destination.
Fourth, ask one clarifying question if it would actually change your answer. "Is the concern here that uploads are slow for the user, or that the server falls over when many people upload at once?" A good clarifying question shows you understand the shape of the problem. One is useful. Three in a row looks like stalling.
Fifth, say how you would find out. "I would read the docs for one queue, set it up locally, and deliberately kill the worker mid-job to see what happens to the message, because that is the failure I would be scared of." This turns the gap into evidence of how you learn, and for a hiring manager that is often the more valuable signal about a fresher anyway.
Two worked examples
Here is the unfamiliar-technology case. Interviewer: "Have you used Redis pub/sub?"
Weak: "Yes, Redis pub/sub is a publish-subscribe messaging system for real-time communication between services." This is a guess in the costume of an answer, and the next question will expose it.
Strong: "I have used Redis as a cache in one project, but not pub/sub. From the name I would expect a publisher to push messages to a channel and any subscribers listening at that moment to receive them, and I would guess they are not stored, so a subscriber that is down misses them. If the messages had to survive, I would want to know whether Redis has something more durable or whether a proper queue is the right tool. Is durability a requirement in the case you are thinking of?"
Nothing in the strong answer required having used pub/sub. All of it scores.
Here is the unseen-design case, which is rarer for freshers but does come up at product companies. Interviewer: "How would you stop one user from calling our API a thousand times a second?"
Weak: silence, then "I would add a counter." Then silence again.
Strong: "I have not built rate limiting, so let me reason it through. The core is counting requests per user per time window. The first problem is where the count lives, because the API probably runs on more than one server, so a counter in memory on one server would not see the others. Something shared, like Redis, would work. The second problem is what happens at the edge of the window; a fixed window lets someone send a burst at the end of one minute and the start of the next. I would start with the simple fixed window per user in Redis with an expiry, and then ask whether that burst behaviour is acceptable." That is a reasonable first design from someone who has never done it, and it is exactly what the interviewer wanted to see.
When a guess has already escaped
Sometimes step one gets skipped and a guess is out before you can stop it. The recovery is to name it. "Actually, I want to walk that back. I said X and I am not confident in it. What I do know is Y." Interviewers see this rarely and rate it highly, because it is exactly what they want a colleague to do in a design review. A wrong guess costs a little. Defending a wrong guess costs a lot. Codecademy's advice on what to say when you don't know an answer makes the same point: pretending backfires, and interviewers can usually tell.
How to practise the thirty seconds
You cannot rehearse this from a question bank, because the whole point is that the question is one you did not prepare for. You need a source of questions you cannot predict and a listener who follows up.
The cheapest version is a developer friend with instructions to ask about things you have not used and to keep asking "why". If you do not have that, a structured practice round is built for this: on 99Interview an AI interviewer draws on your background, pushes into follow-ups you did not plan for, and scores the whole transcript, and a live mock interview with a working engineer adds forty minutes of genuinely unpredictable conversation and written feedback afterwards; if the roles you are applying for include a design discussion, the system design practice track is the one most likely to take you somewhere unfamiliar, and the options and prices are on the pricing page. After each round, find the question you knew least about and read your answer. Did you pause on purpose? Did you mark the edge? Did you reason forward, or guess? That review, more than any score, is what changes the next thirty seconds.
Frequently asked questions
Is it okay to say "I don't know" in a technical interview?
Yes, as long as it is not the whole answer. "I don't know" followed by what you do know, how you would reason about it and how you would find out is one of the strongest things a fresher can say. "I don't know" followed by silence is one of the weakest.
What do interviewers think when a fresher cannot answer a question?
Usually nothing bad on its own. They expect it, and many ask a hard question deliberately to see what happens. What they judge is the response: honesty, reasoning, and whether you stay engaged.
Can I pass an interview without answering every question?
Almost everyone who passes has left at least one question unanswered. Interviews are scored on the overall picture of how you think and communicate, not on a percentage of correct answers.
What should I do when I am stuck in a coding interview?
Say what you are stuck on, out loud. State the approach you were trying and why it is not working. Ask whether you are heading in a sensible direction. Interviewers can help a candidate whose reasoning they can see; they cannot help one who has gone quiet.
How do I stop myself from guessing under pressure?
Build the pause into your habit. Practise saying "let me think about that" before every answer in mock rounds, even easy ones, until it is automatic. The pause is what gives your brain the second it needs to choose honesty over bluffing.
The one habit to start now
The next time anyone asks you a technical question you do not fully know, in a class, a group chat or a mock round, refuse to guess and refuse to go quiet. Say what you know, reason toward what you do not, and say how you would find out. Do it enough times and it becomes what you do when it counts.
Interviewers are not hiring the fresher who knows everything, because that person does not exist. They are hiring for what happens in the thirty seconds after you do not know. What would yours look like right now?