What changes at senior and staff
Read firstThe 45 minute round
Give a mid level engineer and a staff engineer the same prompt, and they will often draw nearly the same boxes. A load balancer, some stateless servers, a cache, a queue, a database. If the boxes were the answer, levelling would be impossible.
What changes is everything said around the boxes: which constraint the design is really about, what each choice costs, how the system gets from version one to version three, and who has to keep it running at 3am. This page is about those four things, because they are what a senior or staff round is actually listening for.
Pick a design question you know well. What is the one constraint that, if it doubled, would force you to redesign it? Write it down before reading on.
The bar moves in one direction#
At mid level, the round checks that you can produce a design that works. At senior, it checks that you can choose between several designs that work and defend the choice. At staff, it checks that you can find the constraint that decides the design, often one the prompt never mentioned, and shape the problem around it: what to build first, what to leave out, and what it will cost the people who run it.
That last part is why staff prompts are vaguer. "Design a URL shortener" becomes "we want our own link platform, design it". The vagueness is the test. Nobody is hiding the requirements from you; finding them is the job.
Shift one: from requirements to the constraint#
Requirements are a list. A constraint is the one item on the list that the whole design bends around. For IRCTC tatkal it is the second the window opens, not the daily volume. For a UPI style rail it is that money must never be created or lost, which outranks latency. For an LLM inference platform it is GPU memory, not requests per second.
The question that finds it: which of these numbers, if it doubled, would change the design? Most of them would not. Doubling daily users of a URL shortener adds servers. Doubling the number of people pressing "book" in the same second at tatkal time changes where the queue goes. Say the constraint out loud once you find it, and point back at it every time a later decision depends on it.
Shift two: from options to decisions with a price#
Listing options is what a good blog post does. Picking one, and saying what it costs, is what an engineer who owns the outcome does.
The shape that works is one sentence: I would pick X, which costs Y, and I would switch to Z if W. "I would keep like counts eventually consistent, which means a count can be a few seconds stale, and I would only pay for strong consistency on the follow graph, where a stale read shows someone a private post." The cost is the part interviewers write down. A choice with no cost named sounds like a choice you have not thought about.
Shift three: from one design to its evolution#
A staff answer has a version one. "For the first year this is a single Postgres primary with two replicas, because the write rate is a few hundred a second and one database is far easier to run than ten. The signal that we have outgrown it is write latency at the 95th percentile, and when it moves, we shard by tenant, which is why the tenant id is in every primary key from day one."
That answer does three things the boxes cannot: it avoids building for scale you do not have, it names the measurement that ends version one, and it makes a cheap decision now (the key) that keeps the expensive one later (sharding) possible. The migration itself, running old and new side by side, backfilling, and cutting over, is a fair deep dive at this level, so be ready to talk about it.
Shift four: from the system to the people running it#
Every box you draw is something a team has to deploy, upgrade, page on and pay for. A staff design counts that cost. "We could run our own Kafka here, but at 3,000 events a second a managed queue does the job and saves a team a quarter of on-call. I would revisit that if the bill passes what one engineer costs."
The questions to answer before the interviewer asks: what pages someone at 3am, how a bad deploy is rolled back, what you would see on a dashboard first when it breaks, and which team owns each part. (Mitigation vs root cause covers what good paging and incident handling look like, and design doc vs RFC vs ADR covers how decisions like the Kafka one get written down.)
Pick the staff answer#
Three moments from real shaped rounds, each with three answers. All three answers are reasonable engineering. Choose the one that sounds like staff.
InterviewerHow would you store the chat messages?
Show which is which without guessing
- Answer A: Senior. A strong answer: the key comes from the access pattern and the cost is named. What it does not do is question the requirements behind the storage.
- Answer B: Staff. Finds the constraint the prompt did not mention, then commits to a design and names the failure mode that design will hit in production.
- Answer C: Mid level. Not wrong, but it is a technology, not a design. No key, no access pattern, no cost.
InterviewerI do not think you need that queue. Why not call the email provider directly?
Show which is which without guessing
- Answer A: Mid level. Folds without a reason. Either the queue was never thought through, or the candidate is not willing to defend it.
- Answer B: Senior. Defends the choice with the right reason. It does not engage with what the interviewer might be worried about.
- Answer C: Staff. Asks what the pushback is really about, gives a version one that drops the queue, and names the measurement that would bring it back. Updating a position for a stated reason reads as strength.
InterviewerWe have two minutes left.
Show which is which without guessing
- Answer A: Staff. Summarises, then says what to do first and why: the riskiest unknown, and how to retire it.
- Answer B: Mid level. Spends the last two minutes inside a deep dive. The interviewer leaves without the shape of the design.
- Answer C: Senior. A clean summary. The staff version adds where it would start and which risk it would retire first.
When the interviewer pushes back#
At this level, pushback is often deliberate. The interviewer disagrees to see whether you can hold a position for a reason, or drop it for a better reason. Both are good outcomes. The bad ones are folding with no reason and defending with no reason.
The move that works every time: ask what they are worried about, answer that, and say what would change your mind. "If the write rate is ten times what I assumed, you are right, and I would move this to a log." That is the conversation two senior engineers have in a design review, and the round is checking whether you can have it.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Hold your position | Shows the decision was made for a reason you can state, and that you will not drop a good design under mild pressure. | If the interviewer has a real point, holding on reads as not listening. | You can name the cost of their alternative in a sentence, and they have not added a new constraint. |
| Update your position | Shows you weigh evidence over ego, which is the main thing a staff engineer brings to a review. | Done without a reason, it looks like you never believed the first answer. | Their pushback adds a constraint or a cost you had not counted. Say which one changed your mind. |
| Ask what they are worried about | Turns a challenge into a requirement, and often reveals the deep dive they want. | Costs twenty seconds, and repeated on every point it looks like stalling. | The pushback is vague, like "are you sure about that?" |
Score the staff layer#
Run a question you already know, out loud, and score only the four shifts. These rows sit on top of the 45 minute round rubric, not instead of it.
- The constraint
- Decisions with a price
- Evolution
- Running it
Checkpoint#
1. Which question best finds the constraint that decides a design?
2. The interviewer says "I am not sure about that cache." What is the strongest response?
3. What makes "version one is a single Postgres primary" a staff level answer rather than an under-designed one?
- Which number, if it doubled, would change the design? That one is the constraint. Say it out loud.
- I would pick X, which costs Y, and switch to Z if W. One sentence per decision.
- Version one, the signal that ends it, and the cheap choice that keeps version two possible.
- Who gets paged, how it rolls back, and what it costs to run. Answer these before you are asked.
At senior and staff the boxes are the same; what changes is what you say around them. I look for the one constraint that, if it doubled, would change the design, and I say it out loud and point back at it. Every choice comes with its price and the condition for switching. I give a version one, the measurement that tells me it is time for version two, and the cheap decision I make now so the move is possible. And I count the people: what pages someone, how a bad deploy rolls back, and what it costs to run. When the interviewer pushes back, I ask what they are worried about, answer that, and say what would change my mind.