System design & trade-offs in a Staff interview
At Staff our design questions start from a system that already exists, with traffic on it and a team around it. They test the second design as much as the first: the one you did not choose, and why.
An axis of our Staff backend and Staff fullstack targets.
The check comes with every pass and covers all the competencies of the target you choose: 10 for Staff backend (about 20 minutes) and 12 for Staff fullstack (about 24 minutes). It reports each one as Ready, Borderline or a Gap for this level. It never predicts a pass.
Patterns our questions are designed to test at Staff
These are the distinctions the questions on this axis are written to separate — our judgement from writing them and having them reviewed, not a measurement of candidates. We have run no study, so nothing here is a statistic and none of it is phrased as one.
- 1.
The trade-off is stated but not priced
Our Staff questions assume you will name the trade-off. They test whether you can say what it costs and who pays: latency on which path, spend, operational burden on which team, and over what horizon.
- 2.
One design, defended
A single architecture with no alternative reads as a preference rather than a decision. Our Staff questions expect two workable designs and a reason for the choice that somebody else could re-derive from the same constraints.
- 3.
Scale asserted rather than bounded
“This scales” is not a claim anyone can check. The useful answer says where it stops working — which resource saturates first, at roughly what load — and what the next move is when it does.
- 4.
No migration
The design is for a system that exists and cannot be turned off. How traffic moves from the current shape to the proposed one, what runs in both meanwhile, and which steps are not reversible is the Staff half of the question, and an answer that stops at the target design has left it out.
What a strong answer sounds like: A strong answer names the condition under which it would pick the other design, and what switching would cost then rather than now.
How the check measures it
3 questions drawn on this axis alone — 1 medium and 2 hard for a Staff target, because the bar is the level. Hard counts for one and a half times a medium, which is what makes the verdict relative:
| Medium right | Hard right | Verdict |
|---|---|---|
| 1 of 1 | 2 of 2 | Ready |
| 0 of 1 | 2 of 2 | Ready |
| 1 of 1 | 1 of 2 | Borderline |
| 0 of 1 | 1 of 2 | Gap |
| 1 of 1 | 0 of 2 | Gap |
| 0 of 1 | 0 of 2 | Gap |
Three questions is coarse and the report says so beside every verdict. It is enough to separate this axis from the others in your target, which is what the check is for — there is no total, no percentage and no single number anywhere in the report.
This axis is weighted 1.5× when the report picks your highest-risk gap: our judgement that it is the most consequential at this level, not a measured weight.
What there is to practise
Questions here most often also test technical judgment: decisions and trade-offs, distributed systems, messaging & async integration and data modelling & storage. Few questions on this axis test it alone, which is why the check reports every competency separately rather than averaging them.
One of them, in full
A question from the free demo, not written for this page. A demo quiz opens with it; the answer, the explanation and the source come when you submit — no account needed.
Answer it on the demoOne axis is not the loop
This axis is one of 10 in our Staff backend target and one of 12 in Staff fullstack, and being strong here says nothing about the others. The check covers all of them in one sitting and reports each separately, so what comes back is a profile rather than a score.