Don't know the answer in an interview? What to say

The question lands, and you realize you don't know the answer. Five seconds of silence feel like a minute. Two options come to mind: go quiet, or confidently say something, anything.

Both are bad. And the situation itself is completely normal. Interviewers often keep asking until they hit the edge of your knowledge: that's how they figure out your level. So in a good interview, "I don't know" will almost certainly come up. What matters is what you say next.

Three steps

Clarify the question. Maybe you do know the answer and just didn't recognize the wording. "Just to check, you mean…?" takes a couple of seconds and sometimes saves the whole answer.
Reason from what you know. Say what you know about related things and try to work your way to the answer. Just be honest about where your knowledge ends and the guessing begins: "I'm not sure, but I'd guess…"
Admit the gap and say how you'd close it. Briefly, without apologizing: "I'm not sure here. At work, I'd check the docs or test it on a small example."

What not to do:

Bluff. The interviewer will ask a follow-up, and a confident made-up answer will fall apart. That's worse than an honest "I don't know".
Apologize at length. One "I don't know" is enough, then move on.
Go silent. Even "let me think" is better than silence.

Theory: a question you can't answer

The most viewed question in the Go section of the Sobes question bank, with almost 10,000 views: "How does the garbage collector work in Go, and what are its implications for application performance?" Let's say you don't really know how it works inside.

Interviewer: How does the garbage collector work in Go?

Candidate: I don't know the details, I haven't dug into it. I know it runs concurrently with the program and tries to keep pauses short, so it hasn't caused problems in my services. Are you more interested in how it works inside, or in how it affects performance?

Interviewer: Let's go with performance. The service has slowed down and you suspect the garbage collector. What do you do?

Candidate: First I'd check whether it's really the cause: take a profile and see how much memory is allocated and where. If the program creates lots of short-lived objects, I'd work on reducing allocations. As for the collector's tuning options, honestly, I don't remember them, I'd look them up in the docs.

The candidate doesn't know the internals, but the interviewer learned a lot: where the edge of their knowledge is, whether they understand why it matters, and how they'd act in practice. That's far better than retelling an article you barely remember.

Coding: you forgot how to do something

In live coding, some small thing often slips your mind: a method name, the order of arguments, the syntax. The key is not to get stuck on it.

Candidate: I don't remember exactly what the method for this is called. I'll write it the way I remember and mark it with a comment. Should we check the docs later, or can we assume it's called this?

Interviewer: Let's assume it is. Go on.

If you don't know how to solve the task itself, start simple:

Candidate: I don't see an elegant solution right away. Let me first write a simple brute-force version so we have something that works, and then I'll look at where it's slow and how to speed it up.

A slow working version is almost always better than twenty minutes of searching for the perfect one. And while you're writing it, a better idea often comes on its own. We cover how to talk while you code in Live coding interview: what to say while you code.

System design: you haven't used the technology

Interviewer: How would you design a notification system for 10 million users? You'll probably need Kafka here.

Candidate: I haven't used Kafka in production, I've only read about it. So let me start with what we need from a queue, and then we'll pick a tool that fits. We can't lose notifications if the sender crashes, we need to handle a spike when a campaign goes out to everyone at once, and we shouldn't send the same notification twice. If Kafka gives us that, it works. I have worked with RabbitMQ, so I can walk you through how I'd build it on that and where I see the limits.

In system design, not having used a specific tool isn't a deal-breaker. The interviewer cares more about whether you understand which requirements the tool covers. Start with the requirements, then be honest about what you have and haven't worked with.

Phrases to keep handy

"Just to check, the question is about…?"
"I'm not sure, but here's how I'd reason about it…"
"This is the edge of what I know. I know this part, the rest would be a guess."
"I haven't used that tool, but I've used a similar one. Want me to explain how I'd do it with that?"
"I don't remember exactly. In practice, I'd check the docs."
"Give me half a minute to think."

If you use Copilot

If Sobes Copilot is running during the interview, it recognizes the question on its own and shows a hint within a few seconds. The phrases above help you fill those seconds calmly.

After the interview

Write down the questions you couldn't answer and go through them over the next few days. How to do that without beating yourself up is covered in Failed a job interview? What to do next.

And you can practice answering at the edge of your knowledge in a mock interview: pick an interviewer who digs deeper with follow-up questions, and answer out loud without peeking.