System design interviewers usually ask the same question at every level. "Design a notification system" works for a mid-level loop and a staff loop. What changes is the rubric. Knowing what each level's answer looks like matters twice: it tells you what to demonstrate, and it explains the down-level outcome ("we liked you, but at L5 instead of L6") that surprises so many candidates in 2026's stingier market.
Mid-level: a working system
The mid answer is graded on soundness. Can you turn requirements into a coherent design: an API, a data model, sensible components, correct use of a queue and a cache? Do you know the tools' basic failure modes? The design can be guided. If the interviewer nudges "what about read scaling?" and you answer well, that's a pass at this level.
What caps a mid answer: waiting for prompts rather than driving, and knowing that a component is used without knowing why. "We'd add Kafka here" is only half a sentence. For what property?
Senior: trade-offs, owned end to end
The senior answer is graded on judgment under constraints. You drive the session. You clarify requirements, state scale assumptions, propose an architecture, and, this is the core signal, present decisions as trade-offs with a recommendation. "Fan-out on write gives cheap reads but the celebrity problem; fan-out on read is the reverse; at this read/write ratio I'd take write fan-out with a special case for the top 1%." You quantify roughly (QPS, storage, cost drivers), you cover the operational story unprompted (deploys, dashboards, the 3am failure), and you flag what you'd cut to make the deadline.
What caps a senior answer: perfect-world designs. No numbers, no costs, no failure narrative. The design might be right, but nothing proves you've ever run one.
Staff: the system around the system
The staff answer is graded on scope beyond the diagram. Everything senior, plus evolution ("v1 is the monolith with an outbox table — the queue infrastructure isn't justified until volume proves it"), organizational reality ("this splits cleanly across two teams if we cut here; that interface is the contract worth spending design time on"), risk sequencing ("the migration is the dangerous part, so I'd de-risk it first with dual writes"), and knowing which corners are safe to cut for a decade versus a quarter. Staff candidates also push back on the prompt itself when it's warranted: before designing multi-region, ask whether the business need is latency or compliance, because those produce different architectures.
What caps a staff answer, oddly enough, is too much solution. Diving into perfect detail on one component while never asking why the system should exist in this form at all.
Using this when you interview
Decide your target level's behaviors and rehearse them as habits. Seniors state trade-offs and numbers unprompted. Staff candidates narrate sequencing and team boundaries. And if you're asked a question that feels too simple for your level, that's usually deliberate: the prompt is simple precisely so the level signal has to come from you.