The staff-level design interview

What it is

A 45 to 60 minute conversation in which you are given a deliberately vague problem and asked to design a system. What is being scored is not the design. It is whether you can take an ambiguous goal and produce the spec, which is the single largest behavioural difference between senior and staff.

The senior version of this round is: given requirements, produce a good architecture. The staff version is: given a sentence, produce the requirements, then the architecture, then name what you are trading away and under what conditions you would revisit.

Commonly confused with a whiteboarding test of knowledge. Knowledge is necessary and it is not what separates candidates; almost everyone at this level knows what a message queue is. What separates them is sequencing, committing to a decision, and saying what it costs.

The problem it solves

Most candidates run the round as: hear the prompt, draw boxes, connect the boxes, answer questions. That produces a design with no numbers in it, no stated requirements, and no evidence of judgement, and the feedback is invariably "solid engineer, didn't demonstrate staff scope".

The structure below exists to force three things the freeform version omits: requirements as numbers, the partition key decided deliberately, and the tradeoff stated rather than implied.

The structure

Timings for a 45-minute round. Say the plan out loud at the start; interviewers take notes in your structure, and announcing it buys you the benefit of the doubt for the next forty minutes.

1. Clarify and scope (5 minutes)

Not "who are the users" as a ritual. The questions whose answers change the design:

• "What is the read to write ratio?" (Decides caching, replication, whether you need a read model.)
• "How stale can a read be?" (Decides consistency, and therefore half the architecture.)
• "What is the p99 target and is that at the edge or at the service?"
• "What happens if we lose the last minute of writes? Is that an inconvenience or a financial loss?"
• "What is explicitly out of scope? Auth? Billing? Mobile?"

Write the answers on the board as numbers. A design round with no numbers on the board is a design round you lost, because every subsequent decision then has no justification.

If the interviewer will not give you a number, supply one and label it: "I'll assume 10 million daily actives and check that assumption if it starts driving the design." That is better than proceeding without, and it demonstrates the exact behaviour the round is testing.

2. Capacity math (3 minutes)

Out loud, on the board, with round numbers.

10M DAU x 20 actions/day  = 200M writes/day
200M / 86,400             = 2,300 writes/sec average
Peak 3-5x                 = ~10,000 writes/sec
Reads 50:1                = ~500,000 reads/sec  <- this is the design driver

2 KB/record x 200M/day    = 400 GB/day = 146 TB/year
Replication 3x            = 440 TB/year

500k reads/sec cannot come from a primary database.
=> the read path is a cache or a materialised read model. That decision is
   now made by arithmetic, not preference.

The value is not the numbers. It is that the arithmetic produced a constraint, and now every later decision can be justified by pointing at it. Interviewers consistently report that doing capacity math out loud is the single clearest separator, and it takes three minutes.

3. API contract (3 minutes)

Before any boxes.

POST /v1/posts            {content, media_ids}  -> {post_id, created_at}
GET  /v1/feed?cursor=&limit=  -> {items[], next_cursor}
POST /v1/posts/{id}/like  Idempotency-Key: <uuid>  -> {like_count}

Three things you get for free by doing this: pagination (cursor, not offset, and say why), idempotency on anything that mutates, and versioning. Each is a small thing that signals production experience, and all three take thirty seconds.

4. Data model and partition key (5 minutes)

This is where designs live or die and it deserves the time.

State the key and the reason in one sentence: "Partition by user_id because every read is scoped to one user, which keeps a feed read to a single partition. The risk is a celebrity with 50 million followers creating a hot partition, and I'll handle that with a separate path for high-fanout accounts."

The pattern to demonstrate: choose the key, name the failure mode it creates, say how you would detect and handle it. Choosing a key without naming its hot-key risk is the most common way to lose this section.

5. High-level architecture (10 minutes)

Draw at container level in C4 terms, and say you are doing so: deployable units and datastores, not classes and not individual machines. Label every arrow with a protocol and a rough rate.

Keep it to seven or eight boxes. A diagram with twenty boxes says you have not decided what matters, and you will not have time to defend any of them.

6. Deep dive (12 minutes)

Hand the choice to the interviewer: "The two hard parts here are fan-out on write versus read, and the hot-partition problem for celebrity accounts. Which would you like me to go into?"

That sentence does three things: it demonstrates you know which parts are hard, it respects their time, and handing someone a choice is itself a leadership behaviour being scored. Then go genuinely deep: actual data structures, actual failure handling, actual numbers.

7. Failure modes and operations (5 minutes)

The section almost nobody reaches, and the one that most distinguishes the answer.

• What pages? Not "we'd monitor it". Name the SLI and the alert: burn-rate alerting on the read-path availability SLO.
• What degrades, in what order? "Under load I'd drop personalised ranking before I'd drop the feed itself, and serve a chronological fallback. That's a product decision I'd want confirmed, and it's the kind of thing to agree before the incident."
• Blast radius. "Fan-out workers are partitioned by user, so a poison message affects one partition rather than the fleet."
• The rollout. "I'd ship this behind a flag, dual-write for a week, compare the outputs on a sample, then cut reads over by percentage."

8. Tradeoffs and 10x (2 minutes)

Close with the sentence the whole round is listening for, and say it at least twice during the session:

"The alternative here was X. I'm not choosing it because Y. If Z changed, I'd revisit."

Concretely: "The alternative to fan-out on write is fan-out on read, which I'm not choosing because the read:write ratio is 50 to 1 and read latency is the product requirement. If the follower graph got much denser, or if write volume grew faster than reads, I'd revisit. The crossover is roughly where average fanout exceeds the read amplification."

A worked micro-example: the first four minutes

Prompt: "Design a notification system."

Weak opening: "So we'd have a service that takes events, puts them on a queue, and workers send them out. Let me draw that."

Strong opening:

"Before I draw anything, let me pin down scope, because 'notification system' spans three very different products. Are we doing transactional notifications (your order shipped) or engagement notifications (someone liked your post)? The first is low-volume and must not be lost; the second is high-volume and can be dropped under load. Which are we building?"

"Say both. Then I want four numbers: peak notifications per second, the channels (push, email, SMS, in-app), the latency requirement per channel, and whether we own delivery or hand off to a provider. I'll assume 50,000 per second at peak, four channels, sub-30-second delivery for push, and third-party providers for push and email."

"One more: what's the delivery guarantee? At-least-once with client-side dedupe is much cheaper than exactly-once, and for engagement notifications a rare duplicate is acceptable while a missed order confirmation isn't. I'll design at-least-once with idempotency keys, and treat the transactional path as the one with the strict requirement."

Four minutes, and the interviewer now knows you can produce a spec. Everything after that is downhill, because every decision has a stated requirement to point at.

Production evidence

Google's hiring guidance for L6 and above is explicit that hiring committees read a written packet, which means your interviewer must be able to write down your scope and judgement. Answers that are hard to summarise score badly regardless of quality, which is the practical reason for structure and for quotable sentences.

Amazon's bar raiser process weights whether the candidate identified the right problem, not only whether they solved the stated one, and their Leadership Principles include "Dive Deep" specifically to test whether the reasoning survives three layers of follow-up.

The C4 model (Simon Brown) gives you the vocabulary to say which zoom level you are drawing at, which removes an entire class of confusion in a design conversation. Narrating "I'm drawing at container level" is cheap and reads as structured communication.

Kleppmann's Designing Data-Intensive Applications is the shared reference for the technical content of these rounds, particularly chapters 5 to 9, and its vocabulary (partitioning, replication, consistency models) is the one interviewers use.

The debate

The case against a rigid structure: it can read as rehearsed, and a good design conversation is collaborative rather than a presentation. Some interviewers explicitly want to see how you think when you are not following a script, and a candidate marching through eight phases while the interviewer is trying to probe something specific has stopped listening.

The case for it: without structure, most candidates omit capacity math, never state the partition key rationale, and run out of time before failure modes. Those three omissions are the most common feedback in this round, and structure fixes all three.

My position: use the structure as a checklist, not a script. Announce it at the start so the interviewer knows where you are going, then abandon it instantly when they steer. The one thing to protect regardless of how the conversation goes is the capacity math, because it is the cheapest and most reliable signal you can produce, and it makes every later decision defensible.

The structure is the wrong approach when the interviewer opens with a specific deep question ("how would you shard this?"), in which case answer it and work outward; or in a domain deep-dive where the point is depth in one component rather than breadth across a system.

Follow-up Q&A

"Walk me through how you'd run a design round." Clarify and scope for five minutes, getting non-functional requirements as numbers on the board. Capacity math out loud for three, because the arithmetic produces the constraint that justifies everything after it. API contract before boxes. Data model and partition key with the hot-key failure named. Architecture at container level, seven or eight boxes, arrows labelled with protocol and rate. Then hand the interviewer the choice of deep dive. Then failure modes, degradation order and blast radius. Then the tradeoff sentence.

"What if the interviewer won't give you requirements?" Supply them and label them. "I'll assume 10 million daily actives; tell me if that's the wrong order of magnitude." Refusing to proceed without numbers reads as inflexible, and proceeding without any is what the round is testing you against. Stating an assumption and checking it when it becomes load-bearing is exactly the behaviour being scored.

"How do you handle a question you can't answer?" State the boundary, reason from adjacent knowledge, and name how you would find out. "I haven't run Scylla in production. Here's what I'd expect to transfer from Cassandra, here's where the shard-per-core model should change the tuning story, and here's what I'd benchmark first." Never bluff: at this level interviewers probe two layers past your claimed knowledge specifically to find it, and one caught bluff outweighs several strong answers.

"You're running out of time and you're only halfway through the architecture." Say so and hand over the tradeoff: "We have ten minutes. I can finish the architecture at a high level, or go deep on the ranking service, which I think is the harder problem. Which is more useful?" Managing the clock out loud is a leadership behaviour and it is being scored; running out of time silently is not.

"What's the single biggest differentiator in this round?" Doing capacity math out loud, and then using the result to justify a decision. It takes three minutes, almost nobody does it, and it converts every subsequent choice from preference into consequence. Second place is naming the failure mode of your own partition key before being asked.

Common misconceptions

The most common is that this round tests knowledge of components. It tests whether you can produce a specification from ambiguity and defend a decision under pressure. A candidate who knows fewer technologies but states requirements as numbers and commits to a tradeoff will out-score one who names more systems.

The second is that more boxes is more thorough. A twenty-box diagram means you have not decided what matters and cannot defend any of it in the time available.

The third is that saying "it depends" is safe. It is safe and it is worthless unless immediately followed by the variables it depends on and a committed default. Conditional then decisive: "it depends on read:write ratio and staleness tolerance, and for what you've described I'd pick X."

Interview delivery note

Open by announcing the structure: "I'll spend about five minutes on requirements, three on capacity math, then the API and data model before I draw anything, and I'd like to leave ten minutes for failure modes. Stop me whenever you want to go deeper."

Then protect two things above all: the capacity math, because it is the cheapest signal available and it makes every later decision defensible; and the tradeoff sentence, said at least twice: "the alternative was X, I'm not choosing it because Y, and if Z changed I'd revisit."

The depth signal in this round is naming the failure mode of your own choice before being asked. Anyone can defend a design. Volunteering "the risk with this partition key is a hot partition on celebrity accounts, here's how I'd detect it and here's the separate path I'd build" is what a staff-level answer sounds like.

Further reading

• Kleppmann, Designing Data-Intensive Applications, chapters 5 to 9, for the technical vocabulary these rounds are conducted in.
• Simon Brown's C4 model, for naming the zoom level you are drawing at.
• Public engineering blogs from Uber, Netflix, Discord, Cloudflare and Stripe, read for the shape of how they present a design rather than for the specific systems.
• Public design documents (Kubernetes KEPs, Kafka KIPs, Rust RFCs) as training material for the design-review round, which uses the same skills in reverse.