There’s a specific kind of interview moment that most candidates dread: the question lands and your internal response is something close to “I have no idea.” What happens next tends to separate people who get offers from people who don’t, and it has almost nothing to do with knowing the answer.
I’ve seen engineers who knew less ace technical interviews and engineers with deep domain knowledge bomb them, and the difference was usually how they handled the questions they couldn’t answer cleanly. Interviewers at most serious companies understand that nobody knows everything. What they’re evaluating is how you operate at the edge of what you know.
What interviewers are actually measuring
The Stack Overflow Developer Survey 2024 found that problem-solving ability consistently ranks above specific technical knowledge in what engineering managers say they value in candidates. That’s been true for years and it keeps being true even as the specific technologies keep changing.
When an interviewer asks a question you can’t fully answer, they’re often watching for: whether you can decompose a problem without already knowing the solution, whether you’re honest about the limits of your knowledge, and whether uncertainty makes you freeze or think. Freezing is the worst outcome. It signals that your performance is brittle when conditions aren’t ideal, which is most of the time in actual engineering work.
Buy yourself time without stalling
Silence is uncomfortable, and most candidates rush to fill it with something. That something is often half-formed and doesn’t help them.
A few seconds of genuine thinking is fine. “Let me think about that for a second” is a completely acceptable thing to say in an interview. What you don’t want is to use filler language as a delay while you’re actually panicking. The interviewer can usually tell, and it doesn’t buy you the recovery time it feels like it should.
What actually helps is starting to say what you do know, even if it’s partial. “I haven’t worked directly with that pattern, but from what I know about event-driven systems, I’d expect the constraint to show up around…” gets you into thinking mode. It’s also honest. Interviewers respond better to “here’s what I know adjacent to this” than to a long pause followed by a wrong confident answer.
The reasoning-out-loud move
For technical questions where you genuinely don’t know the answer, the most reliable approach is to state your starting assumptions and derive from there. Interviewers in system design and architecture rounds often prefer this to a candidate who recites a memorized answer, because derivation demonstrates understanding and memorization doesn’t.
Something like: “I’m not certain about the specific numbers here, but let me reason through what constraints would apply…” shows that you have a mental model of how things work, even when you’re missing a specific fact. That’s almost always more valuable than the specific fact.
For behavioral questions you’re not prepared for, the same principle applies at a different level. Acknowledge you’re taking a moment to think of the right example. Pick one that’s real even if it’s not perfectly polished. Interviewers who are good at behavioral interviews know the difference between someone who’s genuinely recalling an experience and someone who’s reciting a scripted story. Real is better, even if it’s rougher.
What to avoid
A few patterns that consistently hurt candidates, based on what interviewers describe most often.
Fabricating specifics. If you’re not sure whether Redis uses a particular data structure, don’t say it does. Say you’re not certain and reason from first principles. Getting something wrong when you’re presenting it as fact damages trust in everything else you’ve said. Getting something wrong while being transparent that you’re uncertain doesn’t have the same effect.
Over-apologizing. “I’m sorry, I should really know this” accomplishes nothing. It doesn’t make the interviewer feel better and it makes you feel worse. Acknowledge the gap, move into what you know, keep going.
Mentally checking out after one hard question. This happens more than interviewers talk about. A candidate hits a question they can’t answer, visibly deflates, and their performance on the next three questions is worse because they’re still processing the miss. The question you didn’t answer is already behind you. The one in front of you is what still matters.
Preparation that actually addresses this
The standard advice is to “practice common interview questions.” That doesn’t help much with questions you don’t know. What helps is practicing under conditions where you’ll encounter questions you can’t answer cleanly, so the discomfort of not knowing becomes familiar before the real thing.
This means doing mock interviews with someone who asks genuinely hard questions, not questions pitched to make you feel good. It means practicing reasoning out loud when you’re uncertain, not just when you’re confident. And it means building the habit of finishing your thinking rather than stopping when you hit an obstacle.
Craqly’s mock interview mode is useful here because it surfaces questions calibrated to create exactly this situation, asking things slightly outside your stated experience to see how you handle the edge. If you’re prepping for technical rounds or any interview where you expect to hit unfamiliar territory, working through a few sessions where you practice handling “I’m not sure” in real time is worth more than reviewing answers you already know.
The honest thing about this
Sometimes you just don’t know and there’s no clever framework that covers it. Some interviewers will penalize you for that. Most good ones won’t, but some will. The honest truth is that you can’t control every evaluator’s rubric. What you can control is staying engaged, being transparent about your uncertainty, and demonstrating that you don’t fall apart when the question gets hard.
What do you do when you don’t know? You say so, and then you keep thinking.