What Interviewers Actually Think When You Say “I Don’t Know”

Here’s the thing candidates almost never believe: “I don’t know” is one of the most useful sentences you can say in a technical interview. I’ve watched candidates spiral through five minutes of confident nonsense rather than admit a gap, and I’ve watched interviewers quietly mark them down for it. The cost of bluffing is almost always higher than the cost of honesty.

A 2015 University of Guelph study – led by researchers Leann Schneider and Prof. Deborah Powell – found that 94% of mock interview participants admitted to being dishonest, usually by exaggerating contributions or skills rather than fabricating facts outright. The researchers also found interviewers were “pretty bad at detecting” those lies in the moment. But here’s the catch: “in the moment” isn’t the only moment that matters.

What interviewers are actually assessing

Most technical interviewers are not trying to catch you on trivia. They’re trying to answer a few practical questions about you as a future teammate: Can you reason under pressure? Do you know what you know? Will you waste engineering hours confidently solving the wrong problem?

A meta-analysis of 27 studies published in the Canadian Journal of Behavioural Science, summarized by CERIC in 2021, found that deceptive impression management had “almost zero association” with better interview evaluations, while honest impression management – truthfully highlighting real skills and genuine fit – correlated with better outcomes. The interviewers weren’t just being naive; they were picking up on something real.

Self-awareness is a skill. It’s also a relatively rare one. When a candidate says “I haven’t worked with Kafka directly, but I’ve dealt with similar backpressure problems using RabbitMQ, so let me think through how I’d approach this” – that’s actually impressive. It shows they know their mental map well enough to navigate from a known point to an unknown one. That’s exactly what a senior engineer does on the job.

When “I don’t know” genuinely hurts you

Let me be direct about the cases where it does hurt you, because pretending otherwise is just dishonest from my end too.

If the role is 70% Kubernetes and you’ve never touched it, saying “I don’t know much about Kubernetes” to four separate questions is going to close the loop on your candidacy. Not because the interviewers are cruel, but because the signal is clear. That’s not a knowledge gap – that’s a mismatch with the job spec, and a good interviewer will name it as such.

Frequency matters too. One or two “I don’t knows” in a 45-minute session reads as self-aware. Six or seven reads as underprepared. There’s no magic number, but you can feel the difference if you pay attention to how the conversation is flowing.

The delivery also carries a lot of weight. “I don’t know” said while sitting back and waiting for the interviewer to fill the silence is very different from “I don’t know, but here’s how I’d start figuring it out.” The first signals disengagement. The second signals the kind of junior engineer who will actually survive in a real codebase.

The redirect that actually works

There’s a pattern candidates who do this well tend to follow. It looks roughly like:

• Name the gap cleanly. “I haven’t used Terraform in production” – not “I’m not really super familiar with it in a deep sense kind of.”
• Anchor to something adjacent that you do know. “But I’ve done similar infra-as-code work with Pulumi, which covers a lot of the same problems around state management and drift.”
• Show your reasoning toward the unknown. “The specific syntax would be new to me, but the underlying model is close enough that I’d expect to be functional in a few days with the docs.”

This isn’t a magic formula. Some interviewers will still mark it down if the gap is too central to the role. But it gives you the best possible outcome from a position of genuine uncertainty, which is the only position worth arguing from.

What this looks like across different interview types

Coding rounds

In a coding round, “I don’t know the optimal algorithm for this off the top of my head” is almost always fine, as long as you follow with a brute-force approach and talk through why it’s suboptimal. Interviewers at most companies – Google and Meta included – are looking for problem decomposition and communication, not memorized optimal solutions. The ones who jump straight to O(n log n) without explaining the thought process are often harder to hire than the ones who arrive there slowly with good narration.

I’ll admit I’m less certain how this holds at certain elite firms doing competitive programming-style rounds. That’s a different screening function, and I don’t have direct experience interviewing for those teams.

System design

In system design interviews, admitting uncertainty often earns you points. “I’m not sure how many concurrent users this needs to handle – can we establish that?” is the right question to ask. Interviewers get concerned when candidates lock in assumptions without surfacing them. Uncertainty articulated is a strength here.

Behavioral rounds

For behavioral questions, the honest answer is almost always better than the polished one, specifically because interviewers are trained to probe. If you construct a slightly embellished story about a conflict you resolved, a good behavioral interviewer will ask follow-up questions that expose the seams. “Tell me more about what you said in that meeting” is a question you don’t want to answer about a meeting that didn’t happen the way you described it.

One thing worth saying plainly

There’s a version of “I don’t know” that does signal a problem, and it’s the one where you’ve never tried to know. If you’re applying for a senior backend role and you can’t describe at a rough level how a database index works, that’s a different conversation than not knowing the specific implementation details of a B-tree. Interviewers are generally good at telling the difference between a genuine knowledge boundary and a knowledge absence.

Practice finding your actual edges before you walk in. Not so you can perform ignorance, but so you know which questions to answer confidently, which ones to redirect, and which ones to work through out loud. That mental map is what you’re really being evaluated on.

If you want to practice the redirect out loud before your real interview, mock interviews on LastRound AI give you a low-stakes environment to say “I don’t know” a few dozen times until it stops feeling like a confession.