The five signals every panel scores
1. The thing nobody writes down
Every system design panel — Google, Stripe, AWS, the rest — scores you on the same five signals. The questions differ. The bar shifts by level. The signals do not.
Hiring managers will tell you this is not a rubric. They will say "we look for whether you can have an engineering conversation." That sentence is the rubric, compressed. Decompressed, it is these five things.
2. The five
Scoping
Can you turn an underspecified prompt into a problem you can actually design?
The interviewer says "design YouTube." A weak candidate starts drawing a load balancer. A strong candidate asks: are we designing upload, playback, recommendations, or all three? How many uploads per day? Are we serving live or only on-demand? Is the question about read scale or write scale?
The five questions take ninety seconds. They cut the design space by an order of magnitude. They also tell the panel you have done this before.
Estimation
Can you ground your design in numbers?
QPS, storage, bandwidth, fan-out ratio. Back of envelope. Two minutes. Wrong by a factor of two is fine; wrong by a factor of a thousand is the no-hire. The number you need is not the number itself — it is the order of magnitude that decides which component class you reach for. One hundred QPS does not need Kafka. One hundred thousand QPS does not work on Postgres.
Design
Can you draw a coherent system, end to end, that satisfies the requirements you scoped?
This is the visible part of the interview. Boxes, arrows, data flow, where the database lives, what sits in front of it, what sits behind. The mistake here is thinking this is the whole interview. It is one signal. A clean diagram with no estimation behind it scores worse than a messy diagram with defended choices.
Depth
When the interviewer points at one component and says "tell me more about that," can you?
This is where the level shifts. At L4, naming the component correctly is enough. At L5, you can describe how it works at the read/write path. At L6, you can defend the choice over the next three alternatives and tell the interviewer which of the alternatives would beat your choice under a different constraint.
Depth is the most-failed signal at the senior bar. Candidates draw a beautiful diagram, get pointed at "the database," and have nothing past "it's Postgres."
Tradeoff
Can you articulate what your design costs, and would it look different under a different set of constraints?
This is the senior tell. A junior candidate defends their design. A senior candidate names the constraint that would invert it. "I chose write-time fan-out because we're optimizing for read latency at the cost of write amplification. If we had a million followers per account instead of a thousand, I'd flip to read-time fan-out and accept the read latency hit."
That sentence — the if we had different constraint, I'd flip sentence — is the highest-leverage thing you can say in any system design interview. It is also the rarest.
3. How the panel weights them
Roughly:
- L4 (early-career senior) weights design heaviest. Scope and estimate well enough to draw the right diagram and you pass.
- L5 (senior) weights depth heaviest. You need at least one deep dive that the interviewer cannot trivially extend.
- L6 (staff) weights tradeoff heaviest. You need to articulate the design space, not just one point in it.
Scoping and estimation are gatekeepers at every level. You cannot make up for bad scoping with deep components. You will be designing the wrong system.
4. The next page
The thirty-minute clock — how a strong candidate spends the time. The five signals show up on a schedule, and missing the schedule is the most common way panels graded candidates as "didn't get to depth."