How should you run the deep dive when a system-design interviewer points at one component?

## The one beat that is not yours Everything else in a system-design round is candidate-driven. The deep dive is the exception: the interviewer usually picks the component, and the pick is not arbitrary - it is where they think the interesting difficulty lives, and often where their rubric has the most room to discriminate. Treating their choice as a suggestion, and steering back to the part you rehearsed, is one of the most reliably damaging moves available in the last fifteen minutes. ### Move one: restate the ask A vague pointer - *tell me more about the delivery side* - can mean at least three different things: the data it keeps, its failure behaviour, or how it holds up under load. Guessing costs you the beat. One sentence fixes it: *so you would like how a send that fails partway through gets retried, rather than how the fan-out works?* The interviewer either confirms or corrects, and either outcome is worth the five seconds. ### Move two: one layer down, not a new design Depth means opening the box you already drew, not drawing a different picture. In practice, one layer down is some combination of: - **What it holds.** The shape of the state inside it and why that shape rather than another. - **How it fails.** What happens when its dependency is unavailable, when it is restarted mid-work, when the same request arrives twice. - **How it behaves at the number you estimated.** Take the figure already written on the shared canvas and push it through this component. - **What it costs.** In operational burden, not currency - what someone gets paged about. The common error is scope inflation: the interviewer points at one component and the candidate redraws the whole system around it. With a quarter of the round left, that restarts the exercise and finishes neither version. ### Move three: narrate tradeoffs, do not pronounce A design choice stated flatly is unscoreable - the interviewer cannot tell whether you weighed anything. A narrated tradeoff has three parts, and it is short: > I am keeping the retry state in the delivery component itself rather than pushing it into a shared store, because the requirement line about acceptable delay lets us tolerate a short outage. The cost is that a restart loses in-flight retries, so if that line said no losses, this decision flips. That is the whole pattern: **the choice, the alternative you rejected, and the condition under which the rejection reverses**. The third part is what distinguishes a senior answer, because it shows the decision is attached to a requirement rather than to taste. In an invented example - a Series C scale-up, a senior backend role, the notification-delivery prompt - the difference between a mid and a senior deep dive is almost entirely this. Both candidates may reach the same component design; only one says what would have to be true for it to be wrong. ### Move four: land it back on the requirements list Close the dive by pointing at the line at the top of the shared canvas that this component exists for. *That covers the delivery-delay line and the duplicate-tolerance line; the reporting line is still only sketched.* It shows the deep dive was in service of the agreed problem rather than a tangent, and it hands the interviewer a natural next question if minutes remain. This is also the honest defence against the round's central failure mode. **Boxes drawn before requirements were agreed** cannot be landed anywhere - when the deep dive asks *why is this here*, the answer is silence, and the interviewer learns something conclusive about the earlier beats. ### Handling probes inside the dive Expect the interviewer to push: *what if that dependency is down for an hour?* *what if the same request arrives twice?* These are not traps and they are not evidence you got it wrong; they are the rubric asking its questions directly. Answer the probe, then resurface - state what the answer changes in the design, or say explicitly that it changes nothing and why. A probe answered without connecting it back to the design reads as trivia recall. If a probe genuinely defeats your choice, say so and take the alternative. *That case does break this - with an hour-long outage the in-component retry state is not viable, so it moves out to a durable store and here is what that costs.* Changing your mind under a good argument scores well; defending a broken choice does not. ### Watch the clock inside the beat A deep dive that runs to the buzzer mid-sentence loses the landing. Leave two or three minutes: enough to summarise what the dive settled, name the one thing you would look at next given more time, and let the round close cleanly. Interviewers write their notes right after the round, and a clean summary is what they write from.