The architecture deep dive on past work, at three zoom levels
What it is
The interview round where you present a system you built and are questioned on it. It is usually 45 to 60 minutes, it is the round that most reliably distinguishes staff from senior, and it fails for a specific reason: candidates prepare one level of detail and are asked for three.
THE THREE ZOOM LEVELS, and each is a different presentation
LEVEL 1 CONTEXT 2 minutes
What the business needed, what the constraints
were, what "good" meant. No boxes yet.
LEVEL 2 ARCHITECTURE 5 minutes
The components, the data flow, the boundaries,
and the two or three decisions that shaped it.
LEVEL 3 MECHANISM however long they want
One component, in depth: the algorithm, the
schema, the failure handling, the numbers.
Commonly confused with a system design round. A design round evaluates how you approach an unfamiliar problem; a deep dive evaluates the depth and honesty of your actual experience. The questions are different: a design round asks "how would you", a deep dive asks "why did you", and "why did you" has a right answer that you either know or do not.
Also commonly confused with a presentation. It is a conversation you are seeding, and a candidate who delivers twenty uninterrupted minutes has controlled the room and learned nothing about what the interviewer wanted to explore.
The problem it solves
For the interviewer, it is the only round where they can verify that your résumé is real.
Everything else is hypothetical. A design round shows how
you think about a problem you have not solved. A behavioural
round is stories you have chosen and rehearsed.
The deep dive is the round where they can ask "why 20
connections and not 50" and find out in one question whether
you were the person who chose it.
And the failure mode this produces: a candidate who was adjacent to the work. They can describe the architecture accurately because they have seen the diagram, and they cannot say why any specific decision was made, because they did not make it. Two follow-up questions expose that reliably, which is why the round exists.
Mechanics
Choosing the system
Not the most impressive one. The one where you can go three levels deep on your own decisions.
GOOD CANDIDATES
You made the significant decisions, or you can clearly
separate yours from the team's.
It had real constraints (latency, cost, compliance,
deadline) that forced trade-offs.
Something went wrong and you can say what and why.
Recent enough that you remember the numbers.
You can draw it from memory in ninety seconds.
BAD CANDIDATES
The most technically impressive system you were near.
Anything where the interesting decisions predate you.
Something under NDA that you have to keep abstracting.
Anything you would have to reconstruct from a document.
The test: pick a component and ask yourself "why is it that way, and what was the alternative?" If you cannot answer that for at least three components, choose a different system. A system you cannot defend at level 3 is worse than a less impressive one you can.
Level 1: context, and why candidates skip it
TWO MINUTES, NO ARCHITECTURE
What the business needed and why it mattered.
The constraints that shaped everything: scale, latency
budget, compliance, team size, deadline, existing systems
you had to live with.
What "good" meant, ideally as a number.
Your role, explicitly.
EXAMPLE
"We ran product search for a marketplace: nine locales,
fifty million items, about four thousand queries a second
at peak. The constraint that shaped everything was a 200
millisecond p99 budget, because the search box was on the
home page and a slow search measurably cost conversion.
I was the tech lead, so I owned the architecture and the
ranking decisions, and a colleague owned the indexing
pipeline."
Candidates skip this and go straight to boxes, and it costs them twice: the interviewer has no frame for evaluating the decisions, and the constraints that justify the design are never stated, so every choice looks arbitrary.
Naming your role explicitly, at the start, is the second thing candidates omit. It is not immodest; it is what lets the interviewer calibrate every subsequent "we".
Level 2: architecture, and the decisions rather than the components
FIVE MINUTES
Draw it. Six to ten boxes maximum, and if you need more
you are at the wrong altitude.
The data flow: follow one request through it.
The boundaries: what is a service and why.
And THE TWO OR THREE DECISIONS THAT SHAPED IT, each with
its alternative.
The last item is the whole level. A component list is a description; a decision with its rejected alternative is engineering.
WEAK
"There's an API layer, a ranking service, an OpenSearch
cluster, a feature store and a Redis cache."
STRONG
"The decision that shaped everything was keeping item
features in the serving process rather than in a remote
store. Four thousand queries a second times five hundred
candidates is two million feature lookups a second, which
isn't servable from Redis at any sensible cost. Two
million items at 256 fp16 features is about a gigabyte,
so it broadcasts to every replica. That's why the ranking
service is stateful and why deploys are slower than
you'd expect."
Notice the second version includes a cost. "That's why deploys are slower than you'd expect" is the sentence that signals you lived with the decision rather than made it on a whiteboard.
Level 3: mechanism, and being ready for any component
The interviewer picks the component, not you. So you need depth on several, and the question is always some form of "why is it like that".
FOR EACH MAJOR COMPONENT, HAVE READY
the algorithm or data structure, and why that one
the schema or data model, and the access pattern that
drove it
the numbers: throughput, latency, size, cost
the failure mode and what happens when it occurs
the thing you would change
EXAMPLE, if they pick the cache
"Read-through, Redis, keyed by normalised query plus
filters plus locale. Sixty second TTL. Hit rate about 35
percent, which sounds low and is fine because search
traffic is heavily skewed: the top one percent of queries
are around forty percent of volume, so a small cache
catches most of what repeats.
The failure handling is the interesting part. We had a
stampede when a popular query expired: about nine hundred
requests hit OpenSearch in the same second and took it to
a hundred percent CPU for forty seconds. We added a
single-flight lease so one request regenerates and the
rest serve the previous value.
What I'd change: we keyed by the raw filter string, so
semantically identical filter orderings produced
different keys. Canonicalising them would have added
maybe five points of hit rate for an afternoon of work."
The "what I'd change" is not optional. A system presented as having no regrets reads as either dishonest or as insufficiently examined, and volunteering a specific improvement with its cost is the cheapest credibility available.
Moving between levels deliberately
The skill being scored is the movement, not the depth.
SIGNPOST THE LEVEL YOU ARE AT
"At a high level..." -> level 2
"Going one level down..." -> level 3
"Stepping back..." -> back to 1 or 2
ASK WHICH THEY WANT
"I can go deeper on the ranking model or on the indexing
pipeline. Which is more useful?"
This is not deferring; it is respecting that they have a
thing they want to probe and you do not know what it is.
WATCH FOR THE SIGNALS
"Can you go deeper?" -> they want level 3
"So at a high level..." -> you are too deep
A question about business
impact -> they want level 1
Asking which component to go deep on, once, early, is a strong move, because the round has limited time and spending it on the component they did not care about is a wasted round.
The questions that separate the levels
These are the standard follow-ups, and they map to the three levels.
LEVEL 1 PROBES
"Why did this matter to the business?"
"What would have happened if you hadn't built it?"
"How did you know 200 ms was the right budget?"
LEVEL 2 PROBES
"Why is that a separate service?"
"What would you have done with twice the team?"
"Where's the bottleneck?"
"What breaks first as traffic grows?"
LEVEL 3 PROBES
"Why 20 connections and not 50?"
"Walk me through what happens when that call times out."
"What's the p99 and where does it come from?"
"Why that data structure?"
THE HONESTY PROBES, which appear at every level
"What went wrong?"
"What would you do differently?"
"What was the hardest part?"
"What did you get wrong at first?"
The honesty probes are scored more heavily than they look. A candidate with no failures, no regrets and no hard parts has described a project they did not struggle with, which at staff level means either the project was easy or they were not close to it.
A worked example: the same system, three depths
LEVEL 1 (2 minutes)
"Product search for a marketplace. Nine locales, 50
million items, 4,000 queries a second at peak. The
constraint was a 200 millisecond p99, because the search
box was on the home page. I was tech lead and owned the
architecture and ranking."
LEVEL 2 (5 minutes, drawing)
"Request comes in, query understanding, then two retrieval
arms in parallel: BM25 over per-locale OpenSearch indexes,
and dense retrieval over a shared multilingual embedding
space. Fused with reciprocal rank fusion, then a
cross-encoder rerank on the top fifty, then business
ranking.
Three decisions shaped it. Per-locale lexical indexes,
because analysis is language-specific and a shared
analyzer costs real recall on morphologically rich
languages. One shared multilingual embedding space, so
cross-lingual matching works and so we don't have nine
near-duplicate vectors per product. And rank fusion rather
than score fusion, because BM25's IDF is per index, so the
same term is worth about 28 percent more in a small French
index purely because it's smaller."
LEVEL 3 (if they pick the reranker)
"Cross-encoder, roughly BERT-base scale, over the top
fifty. About 35 milliseconds batched on GPU, which is 40
percent of the remaining budget after retrieval, so it's
the first thing we drop under load.
Fifty was measured rather than chosen: twenty gave NDCG
0.712 at 18 milliseconds, fifty gave 0.741 at 35, a
hundred gave 0.749 at 68. The curve bends around fifty to
a hundred, and doubling to two hundred bought 0.003 for
another 66 milliseconds, which isn't a trade you make in a
200 millisecond budget.
The failure handling: we circuit-break on the reranker's
p99 rather than on errors, because the realistic failure
is slow rather than dead, and on break we serve the fused
order.
What I'd change: we reranked every query. About 22 percent
were exact-identifier lookups where BM25's top result was
already correct, and an intent classifier skipping those
would have bought latency headroom for the queries that
actually benefit."
The movement is what is being scored. Level 1 has no components. Level 2 has three decisions with alternatives and no implementation detail. Level 3 has measured numbers, a failure mode and a regret, and it is about one component.
Production evidence
Amazon's, Google's and Meta's staff-and-above loops all include a round of this shape (variously "deep dive", "architecture review", "technical experience"), and their published candidate guidance consistently emphasises depth on your own contribution rather than breadth of exposure.
Structured interview research finds that past-behaviour questions with specific probing predict job performance better than hypothetical questions, which is the reason this round exists alongside a design round rather than instead of it.
Will Larson's Staff Engineer contains interview accounts noting that the deep dive is where candidates most often fail, and specifically that the failure is being unable to justify decisions rather than being unable to describe systems.
The "curse of knowledge" literature (Heath and Heath, and the underlying research) explains why level-1 context gets skipped: the candidate has held the constraints in their head for years and cannot easily model an interviewer who has not.
The debate
The case for choosing your most impressive system: it demonstrates scope, and scope is what staff level is about. A candidate who presents a small system has capped their own ceiling.
The case for choosing the one you know best: the round is won at level 3, and level 3 on a system you were adjacent to fails in two questions. Impressiveness you cannot defend is worse than modest scope you can.
The case for preparing a script: the round has a predictable shape and rehearsing it removes the risk of rambling.
My position: choose the system you can defend three levels deep on your own decisions, prepare all three levels separately, and ask early which component they want.
The choice is the decision that determines the outcome, and the test is concrete: pick any component and ask "why is it that way, and what was the alternative". If you cannot answer that for three components, the system is wrong regardless of how impressive it is. Two follow-up questions expose an adjacent candidate reliably, and that is precisely what this round is for.
Preparing the levels separately matters because they are different presentations, not one presentation truncated. Level 1 has no boxes at all. Level 2 is three decisions with their rejected alternatives, and almost no implementation. Level 3 is one component with measured numbers, a failure mode and a regret. A candidate who prepares "the architecture" has prepared level 2 and will be asked for the other two.
The move I would insist on is asking early which component they want to go deep on. The round has forty-five minutes, they have something specific they want to probe, and spending twenty minutes on the component they did not care about is a wasted round. Asking is not deferring; it is acknowledging that you cannot know what they are looking for.
And volunteer a regret, specifically, with its cost. "We reranked every query, and 22 percent were exact-identifier lookups where it bought nothing" is worth more than any success in the presentation, because a system presented as having no regrets reads as either dishonest or insufficiently examined. The honesty probes are scored more heavily than they appear.
Where I would push back on the impressiveness argument: scope is established at level 1 in two sentences, "fifty million items, four thousand queries a second, nine locales", and after that the round is entirely about whether you made the decisions. A larger system you cannot defend signals less scope than a smaller one you can, because the interviewer's conclusion is that you were near it rather than responsible for it.
Follow-up Q&A
"What is this round actually testing?" Whether your experience is real and whether you made the decisions. Every other round is hypothetical: a design round shows how you approach an unfamiliar problem, a behavioural round is stories you chose. This is the only round where they can ask "why twenty connections and not fifty" and find out in one question whether you were the person who chose it. The failure mode it catches is the candidate who was adjacent to the work and can describe the architecture accurately because they have seen the diagram.
"How do you choose which system to present?" Not the most impressive one. The test I would apply is: pick any component and ask "why is it that way, and what was the alternative". If I cannot answer that for at least three components, it is the wrong system, however impressive. Scope gets established at level one in two sentences, and after that the round is entirely about whether I made the decisions, so a bigger system I cannot defend signals less than a smaller one I can.
"What are the three levels?" Context, architecture, mechanism, and they are different presentations rather than one truncated. Level one is two minutes with no boxes at all: what the business needed, the constraints, what good meant as a number, and my role explicitly. Level two is five minutes of components, data flow, and crucially the two or three decisions that shaped it, each with its rejected alternative. Level three is one component in depth with measured numbers, a failure mode and a regret.
"What do candidates get wrong?" Preparing one level and being asked for three. Most prepare level two, the architecture, and then cannot supply the constraints that justify it or the mechanism underneath it. The second most common is skipping level one entirely and going straight to boxes, which costs twice: the interviewer has no frame for evaluating the decisions, and every choice looks arbitrary because the constraints were never stated.
"How do you make level two strong rather than a component list?" By making it decisions rather than components. "There's an API layer, a ranking service and a cache" is a description. "The decision that shaped everything was keeping item features in the serving process, because four thousand queries a second times five hundred candidates is two million lookups a second, which isn't servable remotely, and that's why the ranking service is stateful and deploys are slower than you'd expect" is engineering. The cost clause at the end is what signals you lived with it.
"How do you know which component to go deep on?" Ask, once, early. "I can go deeper on the ranking model or the indexing pipeline, which is more useful?" The round is forty-five minutes, they have something specific they want to probe, and spending twenty minutes on the wrong component wastes it. That is not deferring, it is acknowledging you cannot know what they are looking for.
"What are the signals you are at the wrong altitude?" Too deep: they ask something you already covered, or they say "so at a high level". Too shallow: they ask "but why", or they start proposing alternatives you already ruled out. And signposting removes most of the problem: "at a high level", "going one level down", "stepping back" tells them where you are and lets them steer.
"How important is the 'what would you do differently' question?" More than it looks. A system presented as having no failures, no regrets and no hard parts describes a project the candidate did not struggle with, which at staff level means either it was easy or they were not close to it. So I would volunteer a specific regret with its cost, unprompted: "we reranked every query, and 22 percent were exact-identifier lookups where it bought nothing, and an intent classifier skipping those would have been an afternoon's work". That is cheaper credibility than any success in the presentation.
"What if the system is under NDA?" Abstract the domain, not the engineering. "A financial services company" instead of naming it, "a compliance requirement that data stay in-region" instead of the specific regulation. What you must not abstract is the numbers and the decisions, because those are the content of the round. If you cannot give numbers at all, pick a different system, because a deep dive without figures is a description.
Common misconceptions
"Present the most impressive system." Impressiveness you cannot defend at level three signals that you were adjacent to it. Scope is established in two sentences at level one.
"It's a system design round about your own work." A design round asks "how would you"; this asks "why did you", and the second has a right answer you either know or do not.
"Prepare the architecture." That is one of three levels. The other two get asked for and are different presentations.
"Deliver it uninterrupted." It is a conversation you are seeding. Twenty uninterrupted minutes means you controlled the room and learned nothing about what they wanted to explore.
"Don't volunteer failures." The honesty probes are scored heavily, and a project with no hard parts reads as one you were not close to.
Interview delivery note
Open with level one and keep it to two minutes, because it is the part candidates skip and it frames everything: "Product search for a marketplace, nine locales, fifty million items, four thousand queries a second at peak. The constraint that shaped everything was a two-hundred millisecond p99, because the search box was on the home page and a slow search measurably cost conversion. I was tech lead and owned the architecture and the ranking decisions."
Note the role statement in that. Say it explicitly and early, because it is what lets the interviewer calibrate every subsequent "we", and omitting it is the second most common mistake in this round.
Ask early which direction to go: "I can go deeper on the ranking model or on the indexing pipeline. Which is more useful for you?" Forty-five minutes is not enough for both, and they have something they want to probe.
At level two, give decisions with alternatives rather than components, and include the cost you lived with: "...and that's why the ranking service is stateful and deploys are slower than you'd expect."
At level three, lead with a measured number rather than a description: "Fifty candidates was measured, not chosen: twenty gave NDCG 0.712 at 18 milliseconds, fifty gave 0.741 at 35, a hundred gave 0.749 at 68."
And volunteer the regret before being asked: "What I'd change is that we reranked every query, and about 22 percent were exact-identifier lookups where BM25's top result was already right."
Further reading
- Will Larson, Staff Engineer, for interview accounts of this round and where candidates fail.
- Amazon's and Google's published candidate guidance on technical experience interviews.
- Barbara Minto, The Pyramid Principle, for the level-one-first structure and why leading with context works.
- SCOR, STAR and the scar-tissue story, for the narrative structure the level-one framing borrows from.