What to Say When You Don't Know the Answer in a Technical Interview

When you don't know the answer in a technical interview, say so plainly, then show how you would get there: name the closest thing you do know, reason from it out loud, and state an assumption the interviewer can correct. "I haven't used that, but here's how I'd expect it to work, and here's how I'd check" earns far more than a confident guess that falls apart at the next question.

Why bluffing is the expensive option

Every technical interview reaches the edge of what you know; good interviewers push until it does. The question is not whether you will hit a gap but what you do there. Bluffing is tempting because silence feels like failure, but interviewers ask follow-up questions for a living. A bluff usually survives one question and collapses at the second, and once it does, the interviewer starts doubting things you said earlier that were true.

Honest reasoning, by contrast, is often exactly what is being assessed. Google's published guidance on structured interviewing, written for every role, says interviewers "want to judge the analytical thought process used to explore, define, and offer a solution to the problem", and that they may not be assessing a correct answer at all. A gap handled well shows that process more clearly than a question you happened to know cold.

This page is about gaps in knowledge: a fact, a technology, a concept you have not met. If what you are missing is an idea for a coding problem, a different procedure applies, covered in what to do when you get stuck in a coding interview.

The three-part answer: admit, anchor, reason

1. Admit it in one sentence. "I haven't used that directly." No apology, no story about why.
2. Anchor to what you do know. The nearest technology, concept or experience: "I've used a similar system, ..." or "I know the general problem it solves, which is ..."
3. Reason out loud from there, and end with an assumption or a way to check: "So I'd expect it to ..., and I'd confirm that by ..."

The structure matters because each part does a job. The admission keeps your credibility. The anchor shows your knowledge is adjacent rather than absent. The reasoning shows how you think, which is what the question was probing in the first place.

Four kinds of gap, and what to say for each

1. A fact or an API you don't remember

You are mid-solution and cannot remember a method's name, a default, or whether a library call sorts in place. Interviewers almost never care. Say what you need and move on:

You: I don't remember whether this returns a new list or sorts in place. I'll assume it returns a new one and assign the result, which is correct either way.

Write code that is correct under either answer when you can, as above. When you cannot, state the assumption and write a one-line comment so you can point back to it.

2. A technology or concept you have never used

In system design and knowledge questions you will meet names you know only vaguely: a particular database, a consensus protocol, a cloud service. Anchor on the problem it solves:

Interviewer: How would you use a Bloom filter here?

You: I haven't implemented one, but I know what it's for: a compact set that can say "definitely not present" or "probably present", with some false positives and no false negatives. So here I'd put it in front of the database lookup, to skip the database for keys that definitely don't exist. The thing I'd want to size carefully is the false positive rate, because each false positive costs a wasted lookup.

The candidate admitted the gap in seven words, then showed they understood the property that matters, and applied it to the design. That answer is better than a memorized definition.

3. A follow-up that goes past your depth

Interviewers often keep drilling down a layer at a time: from your API to the database, from the database to the index, from the index to the disk. At some layer you will run out. Give the layer you know well, then say where your knowledge thins:

Interviewer: What actually happens on disk when that index is updated?

You: I know it at the level of the data structure: a B-tree index means the update touches a leaf page and sometimes splits it, which is why random inserts are slower than sequential ones. Below that, how the storage engine writes the page to disk, I'd be guessing. My understanding is that it logs the change first so it can recover after a crash, but I haven't looked at that closely.

Marking the boundary is a skill in its own right. It tells the interviewer which of your statements to rely on, which is exactly what they need from a colleague.

4. A behavioral question with no matching story

"Tell me about a time you disagreed with your manager" when you never have, or "a time you led a project" when you have not formally. Do not invent a story; the follow-ups will expose it. Use the closest real one and say why it is the closest:

You: I haven't had a direct disagreement with a manager, but the closest is a disagreement with a senior engineer on my team about how to roll out a schema change. Let me tell you that one, because the question of how I pushed back on someone more senior is the same.

The guide to framing failures in the behavioral loop covers stories that went badly, and the behavioral themes help you prepare one story per theme so this happens less often.

When the interviewer fills the gap

Often, once you have said what you know, the interviewer supplies the missing piece: "It's actually a log-structured store, so writes go to memory first." That is not a mark against you. It is a test of something else: can you take a new fact and use it straight away?

You: Thanks, that changes my answer. If writes go to memory first and are flushed in batches, writes are cheap and the cost moves to reads and to the background merging, so for this read-heavy workload I'd want to look at how many files a read has to check.

Repeat the fact back, say what it changes, and carry on with it. Candidates who absorb a hint well recover most of the ground the gap cost them, and sometimes end up ahead, because using new information under pressure is exactly what the job asks for.

What not to say

• "I don't know," and then nothing. It ends the line of questioning and leaves the interviewer with nothing to assess. Always follow it with what you do know.
• A long apology. "Sorry, I should know this, I'm really nervous" spends time and draws attention to the gap.
• A confident invention. Made-up specifics, such as a default value or a limit, are easy for the interviewer to check and costly when wrong.
• "I'd just Google it." True of everyone, so it says nothing. Better: what you would search for, and how you would judge the answer.
• Changing the subject. Answering a different question you do know is noticed every time.

Phrases to keep ready

• "I haven't used that directly. What I do know is ..."
• "I'm not certain, so let me reason it through."
• "My guess is ..., and here's why I think so."
• "I'll assume ... for now. If that's wrong, the part that changes is ..."
• "That's below the level I know well. I can tell you how it behaves from the outside."
• "I'd want to verify that by ... before relying on it."
• "I haven't been in exactly that situation. The closest is ..."

After the interview

Write the question down the same day and look it up. Topics that come up once tend to come up again, sometimes in the next round of the same loop. If several gaps cluster in one area, such as databases or concurrency, that is your next week of preparation, and the pattern and building block guides are a good place to start.

Practicing the moment itself

You cannot rehearse a specific gap, but you can rehearse the response. Ask a friend, or an AI assistant, to keep asking "why?" and "what happens underneath?" about a topic until you run out, and practice the admit-anchor-reason answer each time you do. Devana's system design and coding mock interviews ask follow-up questions about your own answers, which is where most gaps show up.

Related in this series: how to think out loud in a coding interview, how to explain trade-offs in a system design interview, and how to practice interview communication on your own.

Frequently asked questions