This happens in nearly every technical interview: a question comes up that you genuinely do not know the answer to. Most candidates treat this as the interview going wrong. It usually isn't — how you handle it is frequently more informative to the interviewer than the answer itself would have been.
Experienced interviewers frequently ask questions slightly beyond a candidate's expected level on purpose — not to fail you, but specifically to see what happens when you don't know something, because that is a direct preview of what happens on the job when you inevitably hit something you weren't taught. Nobody who has done this job for any length of time knows everything; the honest handling of not knowing is itself the thing being evaluated.
Bluffing — guessing confidently and hoping it sounds plausible — is the worse of the two. Experienced interviewers catch this quickly with one or two follow-up questions, and a candidate caught bluffing is trusted less afterward than one who was honest from the start, on that question and every one after it.
Freezing — going silent, visibly panicking, apologising repeatedly — doesn't damage trust the way bluffing does, but it wastes an opportunity to show something useful, and it makes the rest of the interview harder for everyone in the room.
A working structure: say plainly that you're not certain → say what you do know that's related → reason toward an answer out loud, even a partial or wrong one → say clearly how you'd actually find out.
Weak (bluffing): "Oh yeah, that's uh... I think it does the thing
with the... yeah, that's right, it handles that automatically."
Weak (freezing): "I... don't know. Sorry." [long silence]
Strong: "I haven't used that specifically, but based on how [related
thing I do know] works, I'd guess it does X — though I'm not fully
sure. If I hit this on the job I'd check the documentation first,
and probably test it with a small example to confirm before relying
on it."It demonstrates several things at once, none of which required actually knowing the answer: honesty, which builds trust rather than spending it; reasoning from what you do know, which is the actual skill being tested; and a real, credible plan for finding out, which is what you would genuinely do on the job. An interviewer walks away from that exchange with more confidence in you, not less — despite the fact that you didn't know the answer.
This is the actual skill, not a workaround
This is not a trick for making not-knowing look good. It is what competent, experienced developers actually do constantly, in real jobs, multiple times a week. Practising it in an interview is practising the real skill, not performing one.
Deliberately pick a few technical questions slightly beyond your current knowledge and practise the honest-reasoning structure out loud, in advance, rather than encountering this pattern for the first time under real pressure. It feels artificial the first few times and becomes natural with repetition, the same way any other rehearsed structure does.
If the gap is a whole concept rather than one fact you'd normally look up — something you would need real time to learn properly, not a quick search — it is fine to say that plainly too: "I haven't learned that yet, but I'd want to before working with it in production" is an honest, reasonable answer, and a considerably better one than pretending otherwise.