What to Do When You Don't Know the Answer in an Interview

TL;DR

Blanking or not knowing an answer happens in every interview. Handling the moment well matters more than having the answer.
Three failure modes: freezing, guessing without flagging it, and giving up entirely. None of these help you.
The right approach: say what you don't know, say what you do know, reason toward an answer out loud, and ask a clarifying question if appropriate.
"I don't know this fact" and "I don't know how to approach this problem" are different situations that need different responses.
Honesty paired with effort reads much better than confident wrongness or silence.

There are two types of candidates in technical interviews: those who have hit a blank and had to deal with it, and those who are about to.

It happens in every interview at every company, to candidates of every experience level. The person interviewing you has been in the same position. They know what it looks like. They also know that how you respond to that moment tells them something real about what you'd be like to work with.

The candidates who handle it well don't necessarily know more than the ones who don't. They handle the moment differently.

The Three Failure Modes

Before getting into what to do, it's worth naming what not to do, because these are common.

Freezing

The question lands and you go completely silent. Not "I'm thinking" silent. Blank, disconnected silent. You're trying to will the answer into existence through sheer force of mental effort, but nothing is coming, and the silence is getting longer.

The problem with freezing is that it gives the interviewer nothing to work with. They can't help you. They can't evaluate your reasoning. They can only observe that you stopped. After a certain amount of time, they have to do something, which usually means moving on. That's not a good outcome for anyone.

Guessing Without Flagging It

You don't know the answer, but you say something anyway and present it with confidence. Maybe you're 40% sure. Maybe you're guessing. But you say it like you believe it.

This is worse than it sounds. Interviewers often know the answer to what they're asking. If you give them a confidently wrong answer, they now have to figure out whether you actually believe this wrong thing or whether you're bluffing. Either way, your credibility takes a hit. If they probe and you double down on something incorrect, that's a significant problem.

Giving Up

"I don't know" and then nothing. No attempt to reason. No adjacent knowledge offered. Just a statement that you don't have the answer and an implicit request to move on.

Giving up early reads as low effort and low resilience. Real engineering work involves constant encounters with problems you don't immediately know the answer to. What would it mean for your day-to-day work if your default response to unknown territory is to stop?

What to Do Instead

There's a process that works. It has four parts, and you don't always need all of them.

1. Name what you don't know

Be direct about it. Don't pretend you know something you don't. Don't pad your answer with confident-sounding words that say nothing.

"I don't know the specific answer to that off the top of my head" is a fine thing to say. It's honest. It moves the conversation forward. It doesn't damage your credibility the way a confidently wrong answer would.

What you say next is what matters.

2. Say what you do know that's adjacent

Almost every question you don't know the answer to sits next to things you do know. Name them.

If you're asked about a specific database behavior you're not familiar with: "I haven't worked directly with that specific scenario, but I know that most relational databases handle concurrency through locking or MVCC, so my guess would be..."

If you're asked about a concept from a CS course you never took: "I'm not familiar with that particular algorithm, but I've worked with similar tree traversal problems. My instinct is it might be related to..."

This isn't faking knowledge. It's demonstrating that your knowledge isn't an island. You can reason from what you know toward what you don't.

3. Reason toward an answer out loud

Now work from what you know toward what was asked. Don't do this silently. Say it as you go.

"Let me think through this. If the goal is to find the shortest path between two nodes, and I can't remember the exact algorithm name, I know that breadth-first search explores neighbors level by level, so it naturally finds the minimum number of hops. That feels like what we'd want here. Is that in the right direction?"

Notice the structure: you named what you didn't know (the specific algorithm name), you used adjacent knowledge (BFS behavior), you reasoned toward an answer, and you asked for confirmation rather than presenting a guess as fact.

4. Ask a clarifying question

Sometimes the right move is to ask a question that helps you get closer to the answer.

"When you say 'rate limiting,' are you asking about how to implement it at the application level, or how it works in infrastructure like an API gateway? That would change my answer."

A good clarifying question shows that you understand the question has layers and that context matters. It also buys you a moment to think without going silent.

The Difference Between Two Types of "Not Knowing"

This is important because the right response depends on which situation you're in.

"I don't know this fact"

Some questions have specific factual answers. "What HTTP status code is returned for an unauthorized request?" has a correct answer (401). If you can't remember it, you're in a factual blank.

In this case, the right move is to say you don't know the specific answer but reason toward it. "I believe it's either 401 or 403. I think 401 is 'unauthorized' meaning you haven't authenticated, and 403 is 'forbidden' meaning you're authenticated but don't have permission. So for an unauthenticated request, I'd say 401, but I'm not completely certain."

That answer is honest, shows reasoning, and demonstrates a practical understanding even if the exact number was fuzzy. Most interviewers will confirm or correct you, and either way the conversation moves forward.

"I don't know how to approach this problem"

This is different. The question is a problem to solve, not a fact to recall. You've read the problem and you genuinely have no idea where to start.

This is more common in coding interviews and system design, and it requires a different response.

Don't just say you're stuck. Name what properties of the problem you do observe. "I can see that the input is an array of integers. The output needs to be a single value. The constraint is that we can only look at each element once. I'm not immediately seeing the path to a solution, but let me think about what operations are even possible given that constraint..."

From there, try the strategies from how to approach a coding problem you've never seen before: work through a tiny example by hand, try to identify constraints, start with a brute force even if it's obviously too slow.

In live coding interviews specifically, narrating your process through the stuck moment is exactly what interviewers want to see. They're not just grading the answer. They're grading the behavior.

An Honest Word About What This Looks Like in Practice

Some interviewers explicitly look for how candidates handle "I don't know" moments. They'll ask questions outside your expertise on purpose. They're not trying to embarrass you. They're testing intellectual honesty and problem-solving behavior under uncertainty.

Others are just asking what they ask and will be surprised if you don't know. In that case, the process above still applies.

What almost never helps: rambling to fill time without actually reasoning toward anything. Interviewers notice the difference between "I'm working through this out loud" and "I'm making sounds to avoid silence." Keep your narration tied to actual reasoning.

If you truly cannot make any progress on a factual question and none of your adjacent knowledge gets you close, it's okay to say: "I don't have enough of a foundation here to reason toward a good answer. I'd want to look this up and come back to it." That's honest, and for junior engineers asking about an unfamiliar technology or concept, it reads as self-aware rather than weak.

The place this gets harder is in behavioral interviews, where the question is sometimes "tell me about a time you did X" and you genuinely can't think of an example. In those moments, the equivalent move is to be honest that you haven't directly encountered that situation but to describe how you'd approach it and what your closest relevant experience is.

After the Moment Passes

Once you've navigated the stuck moment, don't dwell on it. Some candidates get rattled and carry the anxiety into the next question. The interview isn't over because you didn't know one answer.

Interviewers make complete evaluations. A candidate who handles a tough moment well and then recovers to answer subsequent questions clearly can still leave a strong impression. The candidate who gets rattled by one blank and then spirals through the rest of the interview has turned a small setback into a larger problem.

Take a breath. Move on. Answer the next question as if the last one went fine.

If the whole interview went rough because of a single stuck moment, know that this is recoverable too. The system design section or the coding section might go better than the one you struggled in. Give yourself the chance to show up fully for the rest of it.

Technical interviews test a lot of things at once. Not knowing a specific answer in one moment doesn't determine the outcome. What you do in that moment matters more than whether you knew the answer.