How to say 'I don't know' in a technical interview

At some point in every technical interview, you hit a question you can’t answer. Maybe it’s a distributed systems concept you’ve only read about. Maybe it’s a language you’ve never used. Maybe the interviewer just went deeper than your experience goes.

That moment — when you realize you don’t know — is one of the highest-signal moments in the entire interview. Not because of what you know, but because of what you do next.

Most people either freeze or fake it

Either you go silent — “I don’t know” — and wait for the next question, or you start talking and hope something coherent comes out.

Faking it is worse. When you bluff through an answer, the interviewer usually notices. They probe deeper. You get more tangled. The credibility you built over the last 40 minutes starts to erode. I’ve seen this from the interviewer side — you can almost watch the candidate realize they’re in too deep, and then they just keep going anyway because stopping feels like giving up.

The urge to fill silence with something is hard to resist in the moment. Same freeze response that hits people who technically know the material.

What works better

There’s a middle ground between “I don’t know” and faking it. It’s not complicated, but it takes practice to do under pressure.

Name the gap, then bridge to what you do know.

That’s basically it. You acknowledge what you don’t know — directly, without apologizing or hedging for thirty seconds — and then you connect it to something you can reason about.

Something like:

“I haven’t worked with consensus protocols directly. But I’ve dealt with consistency trade-offs in distributed caches — I know the problem space. Let me think through how that might apply here.”

Why this works: it gives the interviewer a map of your knowledge. They can see the boundary, and they can see that you don’t just stop at the boundary. You reason past it. That’s what engineers do on the job every day — nobody knows everything, and the good ones figure things out from adjacent knowledge.

Sometimes the question is so far from your experience that there’s no obvious bridge. No adjacent knowledge to draw from. In that case, just be honest: “That’s outside my experience. I don’t want to guess and waste your time — can we come back to it, or would you like me to reason from first principles?”

I wish I could say this always goes well. Sometimes the interviewer just moves on and you can feel the score dropping. That’s the reality — not every interviewer values honesty the same way. But the alternative (bluffing through something you clearly don’t know) has a worse expected outcome.

Why interviewers push past your knowledge

A lot of candidates think hitting a question they can’t answer means they’re failing. Usually it means the interviewer is doing their job.

Good interviews are supposed to find your edges. If you answer everything perfectly, the interviewer hasn’t probed deep enough. They need to see how you handle the gap — that’s where they learn the most about how you actually work.

Sometimes it’s not even intentional. The interviewer asks something they think is straightforward and it happens to be outside your background. Either way, the response that works is the same: be honest, bridge to what you know, reason forward.

A couple of examples

I don’t want to script out perfect responses — that’s part of the problem with most interview advice. But here’s roughly what this looks like:

“How would you implement rate limiting in a distributed system?” (and you’ve only done it on a single server)

“I’ve done token bucket rate limiting on a single server, but not the distributed case. The obvious problem is each node only sees local traffic. I’d probably start with a centralized counter in Redis — it’s simple, even if it adds a network hop. Not sure if there’s a better approach for high-throughput, but that’s where I’d start.”

“What’s your experience with Kubernetes operators?” (and you’ve used Kubernetes but never written one)

“I’ve deployed stuff on Kubernetes — Helm charts, HPAs, the usual. Never written an operator. My understanding is it’s basically a custom controller that watches CRDs and reconciles state. I’d probably reach for the Operator SDK if I needed to build one, but I haven’t actually done it.”

Both of these are rough on purpose. They end with uncertainty. They don’t cover everything. That’s the whole point — you’re showing the boundary of your knowledge, not pretending it doesn’t exist.

The trap

The failure mode that’s worse than “I don’t know” is confidently giving a wrong answer. Interviewers can work with gaps. They can’t work with someone who doesn’t know what they don’t know.

The gap between knowing you should be honest and actually being honest under interview pressure is bigger than you’d think. Your brain genuinely prefers fabricating a plausible-sounding answer over sitting in the discomfort of admitting a gap. It’s not a character flaw — it’s how stress works.

There’s a cultural layer here too, at least from my experience. In Poland — and from what I’ve seen in a lot of European tech companies — admitting you don’t know something is less stigmatized than in some US interview cultures where confidence is weighted heavily. I don’t know if that’s actually true or just my perception. But it’s worth thinking about who’s interviewing you and what they might value.

Practicing this

You can’t get better at this by reading about it. You need to actually say the words out loud, in a situation where you feel at least some pressure.

Pick a topic adjacent to your expertise but outside your comfort zone. Have someone ask you a question about it. The goal isn’t to study the topic first — it’s to practice the moment of hitting the wall and responding well.

Record yourself. Listen back. You’ll hear the hesitation, the filler words, the rambling that happens when you’re buying time.

The goal isn’t to eliminate “I don’t know” from your interviews. It’s to make sure that when it happens — and it will — you handle it in a way that shows how you think, not just what you’ve memorized.

One last thing. I’ve noticed that the candidates who handle “I don’t know” best are usually the ones who are most comfortable with it in their daily work too. The developer who says “I don’t know, let me check” in a code review handles the interview version better than the one who always has an answer for everything. Something to think about.