System design & trade-offs in a Senior interview
Our Senior design questions test two things: whether each choice follows from a constraint you established, and whether you can say what that choice costs.
An axis of our Senior backend and Senior fullstack targets.
The check comes with every pass and covers all the competencies of the target you choose: 8 for Senior backend (about 16 minutes) and 10 for Senior fullstack (about 20 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 Senior
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.
Requirements restated instead of constrained
The prompt is repeated back and the design starts. Without a read-to-write ratio, a data volume and a latency target, every later choice is a preference rather than a consequence — and there is nothing to revisit when one of them moves.
- 2.
The failure path designed in one sentence
Our questions put most of their weight on what happens when a dependency is slow, a consumer falls behind, or a write is retried. A design whose author never says what breaks first has not been tested, even by its author.
- 3.
Components named, mechanisms not
“Put a cache in front” and “use a queue” name components. The question underneath is which consistency the cache gives up, and what the queue does when the producer outruns the consumer: block, drop, or grow until something else breaks.
- 4.
Storage chosen before the queries
The access pattern picks the store. Naming a database first and fitting the queries to it afterwards gets the order backwards, and the design stops being defensible at the first query that does not fit.
What a strong answer sounds like: A strong answer keeps a running list of what has been assumed, and revisits it when one of the numbers changes.
How the check measures it
3 questions drawn on this axis alone — 2 medium and 1 hard for a Senior 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 |
|---|---|---|
| 2 of 2 | 1 of 1 | Ready |
| 1 of 2 | 1 of 1 | Ready |
| 2 of 2 | 0 of 1 | Borderline |
| 0 of 2 | 1 of 1 | Borderline |
| 1 of 2 | 0 of 1 | Gap |
| 0 of 2 | 0 of 1 | 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 8 in our Senior backend target and one of 10 in Senior 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.