You have done the work. You have shipped the thing. Then someone asks about it across a video call and the words are gone.
This is worth naming clearly: blanking is almost never a knowledge problem. It is a retrieval problem under time pressure. The information is still there. The path to it is temporarily blocked by the fact that someone is waiting.
Say something true instead of nothing
Silence is the thing that compounds. Ten seconds of quiet feels like a minute to you, and the panic of the silence makes retrieval harder. The fix is to say something honest that is also useful.
Any of these work:
- "Let me think about that for a second."
- "I want to give you a specific example rather than a general answer."
- "Can I check I understood the question — are you asking about X or about Y?"
None of these are stalling tactics you need to feel bad about. The third one in particular is what a senior engineer does by reflex, because answering the wrong question confidently is worse than pausing.
Start with the situation, not the insight
When you blank, you are usually reaching for the conclusion — the clever bit, the lesson, the punchline. That is the hardest part to retrieve cold.
Start somewhere easier. Describe where you were.
"This was on the billing service, about a year ago. We had a caching layer in front of Postgres."
You have now said three concrete facts, none of which required insight. And almost always, saying them out loud unlocks the rest. Concrete details are easier to retrieve than abstractions, and each one you say makes the next one easier.
Narrow the question yourself
Broad questions cause blanking. "Tell me about a hard problem" has too many valid answers, so your brain tries to evaluate all of them at once.
Pick the axis yourself and say so:
"I'll take that as the hardest debugging problem rather than the hardest design problem — is that useful?"
You have converted an open search into a much smaller one, and you have shown the interviewer how you scope ambiguous problems. That is a signal they are often looking for anyway.
Be willing to come back to it
If a question genuinely lands on something you do not know, say that plainly and move on. Interviewers generally read this as confidence, not weakness.
"I have not worked with that directly. What I have done is the equivalent with Kafka — is that a useful comparison, or would you rather I say what I would check first?"
You have declined to bluff, offered adjacent real experience, and handed the choice back. That exchange is often worth more than a half-remembered answer.
Prepare for retrieval, not recall
Most interview prep optimises for knowing things. If blanking is your failure mode, optimise instead for getting things out.
Practise saying your three or four main stories out loud — not writing them down, not rehearsing them in your head. Out loud, at speaking pace, ideally to someone. The gap between "I know this" and "I can say this while someone watches" is the entire problem, and it only closes with reps.
Keep a short written list of your projects with the concrete nouns attached: the systems, the numbers, the tools. Not a script — just anchors. When you blank, anchors are what you reach for.