How do you handle not knowing something in an interview or on the job?
What they’re really asking
Two things at once. In the interview itself: will you bluff? Bluffing is the single most disqualifying behaviour, because it means nothing else you said can be trusted either. On the job: what is your method for closing a gap, and does it involve other people at the right moment?
Interviewers deliberately ask things you will not know. The question is not whether you know; it is what you do in the two seconds after realising you don’t.
The strong answer pattern
- Say it plainly. “I haven’t worked with that.” No hedge, no preamble.
- Reason from what you do know. “I haven’t used X, but it sounds like it solves the same problem as Y, which I have used, so I’d expect…”
- Describe how you would find out, concretely: the docs, a small spike, a comparison against the thing you know.
- Ask a question back if the term is ambiguous. “Do you mean X in the sense of…?” turns a gap into a conversation.
Step 2 is where the value is. Reasoning out loud from adjacent knowledge shows the interviewer how you think, which is what they were going to test with the next question anyway.
An answer that works
Be direct. I say clearly when I don’t know something: “I haven’t worked with that” or “I’m not familiar with that yet.” I avoid guessing or overstating my experience; honesty builds trust and avoids misalignment.
Show how I’d learn. I describe how I’d get up to speed: “I’d start with the official docs and a small proof of concept,” or “I’d look for similar patterns in what I’ve used before.” On the Invest Planning Platform I learned LangChain/LangGraph, AWS services, and regulated AI flows on the job — I explain that process and the outcome.
Connect to what I know. When relevant, I tie the unknown to what I do know: “I haven’t used X, but I’ve used Y, which solves a similar problem,” or “I’d approach it like how I integrated third-party APIs — auth, retries, error handling.” That shows transferable skills.
Ask good questions. Instead of pretending to know, I ask: “Can you clarify what you mean by X?” or “What’s the main use case you have in mind?” That turns gaps into learning opportunities and keeps the conversation productive.
On the job. I treat unknowns as normal. I research first, try a small experiment, then ask for feedback or pairing if I’m stuck. I document what I learn so others benefit later.
Anti-patterns
- The confident guess. A plausible-sounding wrong answer costs more than “I don’t know”, because the interviewer now has to wonder what else was a guess.
- The apology spiral. “Sorry, I really should know this…” wastes the time you could spend reasoning from what you do know.
- Changing the subject. Answering a different, easier question is noticed every time.
- On the job: silence. Not knowing and not saying is how a wrong assumption ships. Senior engineers admitting gaps is what makes it safe for everyone else to.
What the answer signals
Honesty under pressure, and a learning method that is real rather than “I’d Google it”. The specific, named example of something you learned on the job and what it produced is the part that makes it credible.
Related
Interview angle 4
- “What do you do when you don’t know something?” - say so, then describe how you’d find out. Interviewers are testing honesty and method. Bluffing is the failure; “I haven’t used that, but here’s how I’d approach it and what I’d compare it against” is a strong answer.
- “How do you learn something under time pressure?” - narrow it to what the task needs rather than reading everything. Official docs first, then a small spike to validate understanding, then the parts you actually use in depth.
- “How do you handle not knowing in front of the team?” - the same way. Senior engineers admitting gaps openly is what makes it safe for everyone else, and pretending is how bad decisions survive review.
- “During this interview, if I ask something you don’t know?” - the same again: say you don’t know it, then reason out loud about where you’d start and what related thing you do know. That’s usually worth more than a memorised answer.