Handling what you do not know

"You're asked something you genuinely don't know. What do you do?"

What it is

The set of responses to a question outside your knowledge, and the observation that this is tested deliberately. A staff interview will reach the edge of your knowledge, on purpose, because how you behave there predicts how you behave in production when a system does something nobody expected.

FOUR RESPONSES, and only two are good

BLUFF          Answer confidently and wrongly.
               Detected within one follow-up, and it
               retroactively discounts everything you said
               before it.

DEFLECT        "That's not really my area."
               True and useless. It ends the conversation
               and demonstrates nothing.

ADMIT AND STOP "I don't know."
               Honest, and it leaves the interviewer with
               nothing to score.

ADMIT AND      "I don't know. Here's how I'd find out, and
REASON         here's what I'd expect based on adjacent
               things I do know."
               The answer.

Commonly confused with a failure state. The interviewer is often not testing the fact; they are testing the edge. A candidate who reasons well from incomplete knowledge is more useful than one who has memorised more facts, because production regularly presents problems nobody has memorised.

The problem it solves

Bluffing is the single most expensive mistake available in a technical interview, and it is expensive in a specific way:

You bluff on question 4. The interviewer probes and finds
the bottom of it.

Now:
  - question 4 is a fail
  - questions 1 to 3 are re-examined: were those bluffs too?
  - questions 5 onward are heard sceptically
  - the interviewer's note says "confidently wrong", which
    is the worst thing that can be written about a staff
    candidate

*** One bluff costs more than three "I don't know"s. ***

And the reason it matters beyond the interview: a staff engineer who cannot say "I don't know" is dangerous. They make confident assertions in design reviews that others build on, and the cost lands months later.

Mechanics

The four-part response

1. SAY YOU DO NOT KNOW, PLAINLY AND QUICKLY.
   No hedging, no "well, it depends", no talking around it.
   "I don't know" or "I haven't worked with that."
   Getting this out fast is what buys credibility for the
   rest.

2. SAY WHAT YOU DO KNOW THAT IS ADJACENT.
   "I haven't used Cassandra, but I've worked with DynamoDB,
   and I'd expect the partition key considerations to be
   similar because both are..."
   This is where the reasoning is demonstrated.

3. REASON TOWARD AN ANSWER, LABELLED AS REASONING.
   "So my guess would be X, and here's why. I'd want to
   verify that."
   The label matters: an unlabelled guess is a bluff.

4. SAY HOW YOU WOULD FIND OUT.
   "I'd read the section of the docs on compaction, and I'd
   test it with a small experiment because the documentation
   for this kind of thing is often optimistic."
   Specific, not "I'd look it up."

Step 2 is where the value is. Almost nothing is genuinely disconnected from what you know, and reasoning from an adjacent system demonstrates exactly the transferable understanding a staff loop is trying to measure.

Worked, on a question outside the candidate's experience

Q: "How does Kafka's exactly-once semantics interact with
    compacted topics?"

BAD (bluff)
  "It works the same way, the transaction coordinator
   handles it." (Confidently wrong, probed in one question.)

BAD (deflect)
  "We didn't use compaction." (True, and it stops here.)

BAD (admit and stop)
  "I don't know." (Honest, unscoreable.)

GOOD
  "I don't know that specific interaction, so let me reason
   about it and then tell you what I'd check.

   What I do know: exactly-once in Kafka is the idempotent
   producer plus transactions, and consumers need
   read_committed to not see aborted messages. And log
   compaction keeps the latest value per key and removes
   older ones in the background.

   So the interesting question is what compaction does to
   the transaction markers, because a consumer needs those
   to know which messages are committed. My guess is that
   compaction has to preserve them, or at least preserve
   enough state that read_committed still works, because
   otherwise a compacted topic couldn't support
   transactional reads at all.

   What I'd check: whether transaction markers are exempt
   from compaction, and what happens to the last-stable-
   offset on a compacted topic. I'd look at the KIP that
   introduced transactions and test it with a small
   producer-consumer pair, because this is exactly the kind
   of thing where the documented behaviour and the actual
   behaviour diverge."

What that demonstrates, none of which required knowing the answer: that the candidate understands exactly-once's mechanism, understands compaction's mechanism, can identify where two mechanisms interact, can form a hypothesis with a reason, and has a verification instinct. That is more staff-level signal than the correct fact would have been.

Knowing which kind of unknown it is

Different unknowns deserve different responses, and misclassifying is a separate mistake.

A FACT I HAVE NOT MEMORISED
  "What's the default value of X?"
  -> Say you would look it up, and move on quickly. Do not
     reason at length about a lookup. Reasoning about a
     constant looks like padding.

A SYSTEM I HAVE NOT USED
  "How does Vitess handle resharding?"
  -> Full four-part response. Reason from the systems you
     do know.

A DOMAIN I HAVE NOT WORKED IN
  "How would you design for HIPAA compliance?"
  -> Say what you do not know, ask what constraints matter
     here, and reason about the general shape: data
     classification, access control, audit, retention. And
     say you would involve counsel, because "I'd get a
     lawyer" is the correct answer to a legal question and
     candidates avoid it.

A QUESTION WITH NO ANSWER
  Sometimes the interviewer is probing whether you will
  invent one.
  -> "I don't think there's a general answer to that. It
     depends on X and Y, and here's how I'd decide in a
     specific case."

The fact-versus-system distinction matters practically: reasoning at length about a default value wastes the interviewer's time and looks like you are avoiding admitting a gap. Reasoning at length about an unfamiliar system is exactly what they want.

Calibrating confidence out loud

Signalling how sure you are, continuously, is what makes the whole interview more credible.

"I'm confident about this."
"I'm fairly sure, maybe 80 percent."
"I think this is right but I'd verify it."
"I'm speculating here."
"I don't know."

Using the full range rather than only the extremes is the signal. A candidate who says everything with equal confidence is either bluffing sometimes or under-selling their strong answers, and both are worse than accurate calibration.

And the consequence is asymmetric in your favour: a candidate who has said "I'm speculating" three times has earned belief when they say "I'm confident about this."

When you realise you were wrong mid-answer

"Actually, let me correct myself. I said X, and thinking
 about it, that's wrong because Y. It's actually Z."

This is a POSITIVE signal, not a recovery. It demonstrates
that you monitor your own reasoning, which is exactly what
you want in someone making architectural decisions.

What is negative is defending an answer you have realised is
wrong, and interviewers can usually tell the difference
between someone thinking and someone digging in.

The one time to guess

If the interviewer explicitly asks you to:
  "I know you haven't seen this. What's your instinct?"

Then guess, and label it: "My instinct is X, and I'd put
maybe 60 percent on it, for this reason."

Refusing to guess when invited reads as risk-aversion, which
is its own negative signal at staff level. The invitation is
usually a test of whether you can commit to a position under
uncertainty, which is a large part of the job.

A worked example: the same gap handled two ways

Q: "Walk me through how you'd debug a Kubernetes pod that's
    being OOM-killed, when the JVM heap looks fine."

THE CANDIDATE HAS NOT DEBUGGED THIS SPECIFIC THING.

VERSION A (bluffs, then unravels)
  "You'd look at the heap settings and increase the memory
   limit."
  Q: "Heap is fine and at 40% of the limit. What else?"
  "Maybe a memory leak?"
  Q: "In what?"
  "...the application?"
  -> Three questions to the bottom. Note reads
     "surface-level".

VERSION B (reasons from adjacent knowledge)
  "I haven't debugged this exact case, so let me reason
   about it.

   The key fact is that the container's memory limit counts
   ALL memory in the cgroup, not just heap. So heap being
   fine and the container being killed means the memory is
   somewhere outside the heap.

   The candidates, roughly in order of how often I'd expect
   them: metaspace, which isn't in the heap and grows with
   loaded classes; direct byte buffers, which NIO and Netty
   use heavily and which are off-heap by design; thread
   stacks, which at 1 MB default times a few thousand
   threads is gigabytes; and native allocations from
   something like a compression or crypto library.

   How I'd narrow it: NativeMemoryTracking on the JVM to
   get the breakdown, and compare the container's RSS
   against the JVM's reported total, because the gap is the
   native allocation. If NMT accounts for it, it's one of
   the JVM regions; if it doesn't, it's a native library.

   And the thing I'd check first, because it's the cheapest:
   whether MaxRAMPercentage is set, because a JVM that
   doesn't know it's in a container will size the heap
   against the host's memory rather than the limit."

Version B does not know the answer either. It knows that the cgroup counts more than heap, which is one fact, and everything else is derived. That is the demonstration, and it is worth more than having debugged this exact case before.

Production evidence

Structured interview research consistently finds that assessing reasoning process predicts job performance better than assessing knowledge recall, which is why interviewers deliberately push to the edge of a candidate's knowledge rather than staying within it.

Amazon's "Are Right, A Lot" leadership principle is explicitly paired with "seek diverse perspectives and work to disconfirm their beliefs", and Amazon's interviewer guidance treats willingness to be wrong as part of the signal rather than a deduction.

Google's published interview guidance tells candidates to think aloud and states that the process is being assessed, not only the answer, which is the same instruction as labelling your reasoning.

The Dunning-Kruger literature and the broader work on calibration is the basis for the confidence-signalling advice: accurate self-assessment is itself a measurable skill, and people who use the full confidence range are better calibrated than those who use only the extremes.

Postmortem culture in SRE practice rests on the same behaviour: an engineer who cannot say "I was wrong about the cause" makes incident reviews useless, which is why the trait is assessed rather than tolerated.

The debate

The case for admitting gaps immediately: honesty is cheap, bluffing is catastrophic when detected, and the reasoning demonstration is worth more than the fact. Interviewers explicitly value it.

The case against over-admitting: a candidate who says "I don't know" to six questions has demonstrated a knowledge gap regardless of how well they reasoned, and at some point the cumulative signal is that the candidate does not know enough for the level. There is a real threshold.

The case for attempting an answer: some interviewers read an immediate "I don't know" as giving up, particularly if the question was answerable by reasoning, and attempting it is what they wanted.

My position: say you do not know quickly, then reason from adjacent knowledge, and label the reasoning as reasoning.

The speed matters. Hedging around a gap for thirty seconds before admitting it is worse than admitting it in three, because the hedging reads as an attempted bluff that failed, and the interviewer has watched you decide whether to try it.

The labelling is what separates reasoning from bluffing, and it is a single phrase: "so my guess would be X, and I'd want to verify that". Without it, the same words are a confident assertion and are scored as a bluff if wrong. An unlabelled guess is a bluff regardless of intent.

On the cumulative-gaps objection, which is real: the answer is not to admit fewer gaps, it is that reasoning well converts a gap into a partial pass. Six "I don't know"s is a fail; six "I don't know, here's how I'd reason about it" answers where three of the reasonings are good is a mixed but recoverable signal, and the difference is entirely in what follows the admission.

The behaviour I would highlight as a positive rather than a recovery is correcting yourself mid-answer. It demonstrates that you monitor your own reasoning, which is precisely what you want in someone whose design-review assertions others will build on. Defending an answer you have realised is wrong is the negative, and interviewers can usually tell the difference.

Where I would push back on the conventional advice: when explicitly invited to guess, guess. "I know you haven't seen this, what's your instinct" is a test of whether you can commit to a position under uncertainty, and refusing reads as risk-aversion, which at staff level is its own negative. Label the confidence and commit.

Follow-up Q&A

"What do you do when you don't know something?" Four things, in order. Say I don't know, plainly and fast, because hedging around it for thirty seconds is worse than admitting it in three. Say what I know that is adjacent, which is where the reasoning gets demonstrated. Reason toward an answer and label it as reasoning, because an unlabelled guess is a bluff regardless of intent. And say specifically how I would find out, not "I'd look it up" but which document and what experiment.

"Why is bluffing so costly?" Because it is detected in one follow-up and it is retroactive. Question four is a fail, questions one to three get re-examined as possible bluffs, everything after is heard sceptically, and the note says "confidently wrong", which is the worst thing that can be written about a staff candidate. One bluff costs more than three admissions. And beyond the interview, a staff engineer who cannot say "I don't know" makes confident assertions in design reviews that others build on.

"Doesn't admitting too much look bad?" There is a real threshold, and the answer is not to admit fewer gaps but that reasoning well converts a gap into a partial pass. Six flat "I don't know"s is a fail. Six "I don't know, here's how I'd reason about it" answers where several reasonings are good is a mixed but recoverable signal, and the entire difference is in what follows the admission.

"Give me an example of reasoning from adjacent knowledge." For a JVM being OOM-killed in a container with the heap looking fine: I might not have debugged that exact case, and I know that the container's limit counts everything in the cgroup, not just heap. So the memory is outside the heap, and the candidates are metaspace, direct byte buffers, thread stacks and native library allocations. Then NativeMemoryTracking to get the breakdown, comparing container RSS to the JVM's reported total, because the gap is native. That is one fact plus derivation, and it is more signal than having seen it before.

"Are all unknowns the same?" No, and misclassifying is its own mistake. A fact I have not memorised, like a default value, deserves "I'd look it up" and moving on quickly, because reasoning at length about a constant looks like padding. A system I have not used deserves the full four-part response. A domain I have not worked in, like HIPAA, deserves saying what I do not know, asking which constraints matter, reasoning about the general shape, and saying I would involve counsel, which candidates avoid and which is the correct answer to a legal question.

"What if you realise mid-answer that you were wrong?" Say so immediately: "let me correct myself, I said X and that's wrong because Y". That is a positive signal rather than a recovery, because it demonstrates you monitor your own reasoning, which is exactly what you want in someone making architectural decisions. The negative is defending an answer you have realised is wrong, and interviewers can usually tell the difference between thinking and digging in.

"Should you ever guess?" Yes, when explicitly invited. "I know you haven't seen this, what's your instinct" is a test of whether you can commit to a position under uncertainty, and refusing reads as risk-aversion, which at staff level is its own negative. Guess, label the confidence, and give the reason: "my instinct is X, maybe sixty percent, for this reason".

"How do you signal confidence during the rest of the interview?" By using the full range rather than only the extremes. "I'm confident about this", "fairly sure, maybe eighty percent", "I think so but I'd verify", "I'm speculating", "I don't know". A candidate who says everything with equal confidence is either bluffing sometimes or under-selling their strong answers. And it compounds in your favour: someone who has said "I'm speculating" three times has earned belief when they say "I'm confident".

Common misconceptions

"Admitting a gap is a fail." It is unscoreable only if you stop there. Reasoning from adjacent knowledge converts it into a demonstration of exactly what a staff loop measures.

"Reasoning out loud sounds like waffling." Not if you label it: "this is a guess and here's why" is a completely different act from an unlabelled assertion.

"Interviewers ask things they expect you to know." They deliberately reach the edge, because behaviour at the edge predicts behaviour in production.

"You should attempt every question." For a memorised constant, reasoning at length is padding. Say you would look it up and move on.

"Correcting yourself looks bad." It is a positive signal. Defending an answer you know is wrong is the negative one.

Interview delivery note

The whole point is behavioural, so the delivery note is the technique itself.

The phrase to have ready, so you are not composing it under pressure: "I don't know that one. Let me reason about it and then tell you what I'd check." Then the adjacent knowledge, then the labelled guess, then the specific verification.

Get the admission out fast, because hedging around a gap is what reads as an attempted bluff: "I haven't worked with that" in three seconds is much better than thirty seconds of "well, it depends on the configuration" before arriving at the same place.

Label every guess: "so my guess would be X, and I'd want to verify that". That single phrase is what separates reasoning from bluffing, and without it the same words are scored as a confident assertion.

Use the confidence range throughout the rest of the interview, not just at the gaps, because it is what makes the range meaningful: "I'm confident about this one" only carries weight if you have also said "I'm speculating here" somewhere.

And if you realise you were wrong, say so immediately and plainly: "Let me correct myself." It is a positive, and hoping the interviewer did not notice is the worse bet.

The Staff & Team Lead Interview Reference