If you don't know the answer in an interview, pause, make sure you understood the question, say what you do know that is related, and reason out loud toward an answer. If you still can't get there, say so honestly and explain how you would find out. Bluffing is the one move that reliably makes things worse, because a follow-up question usually exposes it.
The right approach depends on the kind of question. Not having a story for a behavioral question is a different problem from not knowing a technical concept, and both differ from a factual question about a tool or a number. This guide covers each type, gives scripts we wrote, and explains when to admit the gap quickly rather than working at it. It is part of our common interview mistakes series.
Why do interviewers ask questions you can't answer?
Often on purpose. Many interviewers, especially in technical rounds, keep asking harder follow-ups until they find the edge of your knowledge, because that edge tells them your level. Reaching it is expected, not a failure.
At that point the interviewer can learn several useful things: whether you reason clearly under uncertainty, whether you are honest about what you don't know, whether you can connect a new problem to things you do know, and how you would close the gap on the job. A candidate who says "I haven't used that, but here's how I'd think about it" often comes across better than one who guesses confidently and is wrong.
Strategies by question type
| Question type | Example | What it usually tests | Best move |
|---|---|---|---|
| Behavioral, no matching story | "Tell me about a time you managed a vendor." | Relevant experience and judgment | Use the closest real story and say how it's adjacent |
| Technical concept you don't know | "How does consistent hashing work?" | Depth and reasoning | Reason from related knowledge out loud |
| Coding problem you can't solve | A problem with no obvious pattern | Problem-solving process | Brute force first, then work toward better |
| Factual or tool-specific | "What's the default isolation level in this database?" | Hands-on experience | Admit it, give what you'd expect and how you'd check |
| Estimation or case | "How many coffee shops are in Chicago?" | Structured thinking | Build the estimate step by step; the exact number isn't the point |
| Company-specific | "What do you think of our latest product launch?" | Preparation and interest | Be honest about what you've seen and ask a smart question |
What should you say when you don't know a technical answer?
Use a think-aloud approach anchored in adjacent knowledge. It turns a blank into a demonstration of how you reason.
- Clarify. Sometimes the question is easier than it sounded. "Do you mean in a single-node setup or across a cluster?"
- Say what you know that's related. Name the nearest concept you understand well.
- Reason toward an answer. Apply that knowledge out loud, labeling guesses as guesses.
- Check with the interviewer. "Am I heading in the right direction?" Many interviewers will give a hint.
- Say how you'd verify it. Documentation, a quick experiment, a colleague who owns that system.
Script we wrote (a backend engineer asked about consistent hashing, which they've never used): "I haven't implemented consistent hashing, but I know the problem it solves. With plain modulo hashing, adding a server changes where most keys map, so you'd move a lot of data. I'd guess consistent hashing arranges servers and keys on some kind of ring so that adding a server only moves the keys near it. Is that the right idea? If I needed to build it, I'd read how an existing distributed cache handles it before designing my own."
That answer is honest, shows real understanding of the underlying problem, and gives the interviewer something to build on. For coding problems specifically, the same idea applies: state a brute-force solution, then improve it. Our list of coding interview mistakes covers how to keep going when you're stuck, and our guide to practicing thinking out loud in coding interviews shows how to build the habit.
What if you have no example for a behavioral question?
Behavioral questions ask about past experience, so "I've never done that" can feel like a dead end. It usually isn't. You have three honest options, in this order of preference.
- An adjacent real story. Find the closest experience you have and name the link. Never managed a vendor? Maybe you coordinated with another team that had different priorities.
- A story from outside work. School projects, volunteering, side projects and freelance work count, especially early in your career.
- A clearly labeled hypothetical. If you truly have nothing, say so and explain what you would do. This is the weakest option, so keep it short and specific.
Script we wrote (a junior analyst asked about managing a vendor): "I haven't managed a vendor contract directly. The closest thing is when I depended on the data engineering team for a pipeline they didn't prioritize. I wrote a one-page request showing which reports were blocked, agreed a delivery date with their lead, and checked in weekly. It shipped two weeks later than I wanted but before our quarterly review. I'd use the same approach with a vendor: clear written requirements, an agreed date and a regular check-in."
The best prevention is a story bank. If you prepare eight to ten flexible stories using the STAR method, most behavioral questions map onto one of them. Our guide on how to prepare for a behavioral interview walks through building one.
How to handle factual and tool questions
For a narrow fact, such as a default setting, a specific function or a regulation, guessing is risky and reasoning won't get you much further. Admit it quickly, show what you do know, and say how you'd find out.
Script we wrote: "I don't remember the default isolation level for that database. I know the trade-off between the levels, stricter isolation means fewer anomalies but more locking, so on the job I'd check the documentation and confirm what our configuration actually uses rather than assume the default."
For company-specific questions you can't answer, don't pretend you've read something you haven't. "I've read the announcement but haven't used the feature yet. From the outside, my question would be how you're measuring adoption" is honest and still shows interest.
When should you admit you don't know?
Admit it quickly when the question is purely factual, when you have no related knowledge to reason from, or when you've tried for a minute or two and aren't making progress. Keep working at it when you have related knowledge, when the question is open-ended (design, estimation, cases), or when the interviewer is clearly hinting.
Whichever you choose, avoid these:
- Bluffing. A confident wrong answer followed by "can you go deeper?" is far worse than an honest gap. It also raises doubts about your other answers. Our guide on whether it's ever OK to lie in a job interview explains why.
- Freezing in silence. If you need time, say "Let me think for a moment" and take ten seconds.
- Over-apologizing. "I don't know" said once, calmly, is enough.
- Dismissing the topic. "We never needed that" can sound defensive. Show curiosity instead.
If you realize later that you could have answered after all, you can come back to it. See how to recover from a bad interview answer for timing and phrases.
Practice it
The skill here is staying composed and reasoning out loud when you're unsure, and that only improves with practice under realistic conditions. Rehearse with a free mock interview you can run in your browser, or use the Mock Interview mode in the CoPilot Interview desktop app, which builds questions from your résumé and the job description, asks them aloud, and scores each spoken answer out of 10 with what to fix. Pick harder levels on purpose so you practice reaching the edge of what you know. It's free for 15 minutes a day, with no account. Follow each employer's rules on AI tools, and use AI to prepare beforehand.
Practice the questions you can't answer yet
Run a mock interview at a level slightly above your comfort zone, answer out loud, and see what to fix in each answer. Free for 15 minutes a day, no account needed.
Try a free AI mock interviewFAQ
Is it OK to say "I don't know" in an interview?
Yes, when it's true and you follow it with something useful: what you do know that's related, how you'd reason about it, or how you'd find out. An honest gap is usually better received than a confident wrong answer.
How long should I think before answering a hard question?
A pause of five to ten seconds is normal. Say "Let me think for a moment" so the silence is clearly intentional. If you need longer, think out loud so the interviewer can follow your reasoning.
What if I have no example for a behavioral question?
Use the closest real story and say how it relates, or use an example from school, volunteering or a side project. Only use a hypothetical as a last resort, and label it clearly as what you would do.
Should I guess the answer in a technical interview?
Reason, don't guess. Say what you know that's related, work toward an answer out loud, and label any guesses as guesses. Pure guessing on a factual question is risky because a follow-up will usually expose it.
Does not knowing an answer mean I failed the interview?
No. Many interviewers push until they find the edge of your knowledge on purpose, because it helps them judge your level. How you handle that moment often matters as much as the answer.
Can I look up the answer and send it after the interview?
You can include a short, accurate addition in your thank-you note if it would genuinely change the interviewer's view, for example on a technical point central to the role. Keep it to two or three sentences.