--- title: What to Do If You Don't Know the Answer in an Interview description: What to do if you don't know the answer in an interview — the four-step script that scores partial credit instead of freezing, and what never to say. url: https://usegreenroom.app/blog/what-to-do-if-you-dont-know-the-answer-in-an-interview last_updated: 2026-08-01 --- ← Back to blog Interview prep # What to do if you don't know the answer in an interview August 1, 2026 · 11 min read ![What to do if you don't know the answer in an interview — guide cover from Greenroom, the AI mock interviewer](/assets/blog/what-to-do-if-you-dont-know-the-answer-in-an-interview-hero.webp) The question was about database isolation levels. He knew what a transaction was. He knew what a deadlock was. He had, at some point, read the word "phantom" in this context. What he did not know was the actual answer, so he said "um" and then nothing at all for eleven seconds, which in an interview is roughly a geological era. Then he said "I'm not sure," and the interviewer moved on, and a question he could have earned half the marks on scored zero. If you are looking for **what to do if you don't know the answer in an interview**, start here: interviewers almost never expect you to know everything. Most technical rounds are deliberately calibrated to run past the edge of your knowledge, because the interesting signal is what you do at the edge. Silence scores zero. Bluffing scores below zero. Everything in between scores something. I built Greenroom after walking out of an interview I had prepared hard for, having gone quiet at exactly this moment, so this guide is the script I wish I had. ## Why the question you cannot answer is often deliberate Good interviewers push until you stop knowing. That is not cruelty; it is calibration. They need to place you on a scale, and the only way to find the top of your range is to go past it. Which means the moment you hit a question you cannot answer, two things are true at once: you are probably doing fine, and the round has just switched from testing knowledge to testing reasoning and honesty. Candidates who understand that switch outperform candidates who treat the moment as failure. There is a second, quieter reason. In real engineering work you constantly hit things you do not know, and the person interviewing you wants to know what you are like on that day. Do you go quiet? Do you make something up? Do you say "here is what I would check first"? They are auditioning a colleague, not a search engine. ## The four-step script ![Diagram of the four-step script for when you don't know the answer in an interview — buy time, say what you do know, reason out loud, then ask](/assets/blog/what-to-do-if-you-dont-know-the-answer-in-an-interview-diagram.webp) Every step of this earns something. Silence and bluffing are the only two responses that score zero. **Step one: buy two seconds, honestly.** "Let me think about that for a second" is a complete and professional sentence. It is far better than a filler-word spiral, and it buys you the moment you need. Our [how to stop saying um in interviews](/blog/how-to-stop-saying-um-in-interviews) guide covers replacing filler with a deliberate pause. **Step two: say what you do know, and where it stops.** "I know isolation levels control what a transaction can see from other in-flight transactions, and I know read committed prevents dirty reads. I am less sure about which anomalies repeatable read still allows." That sentence just earned partial credit and, more importantly, showed you can locate the boundary of your own knowledge — which is a genuinely rare and valued trait. **Step three: reason out loud from first principles.** "If repeatable read guarantees the same row reads the same way twice, the thing it probably cannot prevent is a new row appearing that matches my query — so I would guess phantom reads." That is derived, not memorised, and interviewers write it down as a strength even when the guess is wrong. **Step four: ask a real question.** Not "can you give me a hint" — a specific one. "Is this in the context of a single database, or across services?" Specific clarifiers frequently unlock the rest of the answer, and they demonstrate that you narrow problems rather than freeze on them. **Optional step five: name what you would check.** "I would confirm that against the Postgres documentation on transaction isolation." Naming a real source is credible. "I'll look it up" is not. **The core truth:** interviewers are not scoring whether you knew it. They are scoring what happened in the fifteen seconds after you did not. That is a rehearsable skill, and almost nobody rehearses it. ## What never to say - **Nothing.** Silence longer than about five seconds reads as a freeze, and the interviewer cannot score thinking they cannot hear. Our [how to think out loud in interviews](/blog/how-to-think-out-loud-in-interviews) guide covers narrating under pressure. - **A confident invention.** Bluffing is the single most damaging option, because a good interviewer will follow up and the collapse is much worse than the original gap. It also converts a knowledge gap into an integrity question. - **"That's not really my area."** Even when true, it sounds like a refusal. Say what is adjacent to your area instead. - **"We had a library for that."** Fine as a footnote, disastrous as the whole answer. - **Self-attack.** "Sorry, I'm terrible at this" makes the interviewer manage your feelings for the rest of the round, and it colours how they hear your next three answers. ## In a coding round specifically The rules shift slightly when there is a problem on the screen and a clock running. - **Say the brute force first.** Always. A correct O(n²) solution stated aloud is worth far more than four minutes of silent searching for the optimal one. Then say "that is my baseline, let me see if I can do better." - **Name the pattern you are searching for.** "This feels like it wants a sliding window, but the constraint about duplicates breaks the version I know." That sentence is worth real marks. - **Write something.** Partially working code plus a clear explanation of the missing piece beats a blank editor and a good verbal description. - **Use the hint.** Interviewers give hints because they want you to succeed; refusing one out of pride is a strange way to lose. Take it, say thank you, and keep narrating. - **If you are truly stuck, ask to simplify.** "Can I solve it for the case where all values are positive first, then generalise?" is almost always allowed and often turns into the full solution. Our [coding interview communication tips](/blog/coding-interview-communication-tips) and [common coding interview mistakes](/blog/common-coding-interview-mistakes) guides go deeper on this. ## In an HR or behavioral round Here the honest version is even more effective, because behavioral answers are unverifiable and interviewers are unusually sensitive to invention. If asked for an experience you have never had — "tell me about a time you managed a team" as a fresher — do not manufacture one. Say what is closest and be clear about the scale: "I have not managed a team formally. The closest is coordinating four people on our final-year project, where I ran the split of work and handled it when one member dropped out." That is a real answer, and it is far stronger than a fabricated one that dissolves under a follow-up. If you genuinely do not know what a role-specific term means, ask. "I'm not familiar with that term — could you describe what it covers?" costs you very little and prevents you from answering a completely different question. ## When you can and cannot say "I don't know" Say it plainly when it is a factual lookup — a specific syntax, a version number, an acronym. "I don't know that one offhand" is fine and fast, and it lets the round move on. Do not say it flatly for a reasoning question, a design question or a behavioral question. Those have no lookup answer; they are asking you to think in front of someone. "I don't know" there is a refusal to attempt, and it is scored as one. The useful compound form for the middle ground: "I don't know that specifically, but here is how I would work it out." Every interviewer I have ever spoken to counts that answer. ## Where each prep option actually helps - **Question banks and GeeksforGeeks** — genuinely useful for shrinking how often this happens, which is the real long-term fix. - **ChatGPT** — good for filling the gap after the interview, and for generating the follow-up questions you should expect on a shaky topic. It will not reproduce the specific silence of a stranger waiting for you to speak. - **A friend doing a mock** — helpful, but friends rescue you. Rescue is exactly the thing that stops you learning the script. - **Greenroom** — the spoken layer. [Ari, the AI interviewer](/) pushes past what you know on purpose and keeps waiting, so you get to practise the fifteen seconds that matter, repeatedly, at no cost. Honest tradeoff: closing the underlying knowledge gap still needs the reading. ## A drill for the edge of your knowledge - **Pick your weakest topic on purpose.** Have someone ask three questions about it, on a timer, and practise the four-step script rather than the answers. - **Ban two words for a week.** No "um", no "sorry". Replace both with a two-second pause. - **Record one attempt.** Count how long your silence actually was. Almost everyone overestimates it by a factor of three, which is why it feels unsurvivable. - **Practise recovering, not avoiding.** Our [how to recover from blanking in an interview](/blog/recover-from-blanking-in-interview) guide covers the harder case where the answer is gone entirely. ## Frequently asked questions ### What should you do if you don't know the answer in an interview? Use a four-step script instead of going silent. Buy two seconds with a clear line like let me think about that for a moment, state what you do know and where your knowledge stops, reason out loud from first principles towards a guess, and ask one specific clarifying question. Then optionally name the source you would check to confirm. Every step earns partial credit, while silence and bluffing are the only two responses that reliably score zero. ### Is it OK to say I don't know in an interview? Yes for factual lookups such as a specific syntax detail, a version number or an acronym — saying you do not know that offhand is fast and honest. It is not acceptable as a flat answer to a reasoning, design or behavioral question, because those are asking you to think in front of someone rather than recall a fact. In those cases use the compound form: you do not know it specifically, but here is how you would work it out. ### What should you do if you can't solve a coding problem in an interview? State the brute-force solution out loud immediately, even if it is inefficient, and call it your baseline. Name the pattern you are reaching for and why it does not quite fit, write partially working code rather than leaving the editor blank, accept hints when they are offered, and ask whether you can solve a simplified version first — for example assuming all values are positive — and then generalise. A partial solution with clear reasoning routinely scores better than silence. ### Should you bluff an answer in an interview? No. Bluffing is the single most damaging option because a competent interviewer will ask a follow-up, and the collapse under that follow-up is far worse than the original knowledge gap. It also converts a technical gap into a question about your honesty, which is much harder to recover from within the same loop. ### How long can you pause before answering an interview question? A deliberate pause of two to five seconds reads as thinking and is completely normal, especially if you signal it by saying you want a moment to think. Beyond roughly five seconds of complete silence it starts to read as a freeze, because the interviewer cannot score reasoning they cannot hear. Most candidates dramatically overestimate how long their silences lasted, which is why recording a practice round is useful. ### What do you say when asked about an experience you have never had? Do not invent one. Say what is closest and be explicit about the scale — for example that you have not managed a team formally, but you coordinated four people on a final-year project including redistributing work when a member dropped out. Interviewers are unusually good at detecting fabricated behavioral stories because they simply ask a second and third follow-up, and a real smaller example holds up where an invented larger one does not. The fifteen seconds after you do not know something is a skill, and it is the one nobody rehearses. [Greenroom](https://usegreenroom.app/) lets you practise it with Ari, who pushes past what you know on purpose and waits, so the silence stops being new. Free to start. Curious how it works? See [how AI mock interviews work](/blog/ai-mock-interview).