Distributed systems in a Senior interview
A distributed service is several machines pretending to be one. Our questions are less about consensus algorithms than about what that pretence costs: what your system does while one of its parts is unreachable and nobody knows it yet.
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.
At-least-once delivery without idempotency
At-least-once delivery means redelivery by design. The design question is what makes processing it twice harmless, where the deduplication key lives, and how long it is honoured. Preventing the duplicate is, in general, not possible.
- 2.
Consistency named rather than chosen
“Eventually consistent” is a property with a window. How long it is, what a reader sees inside it, and which operations cannot tolerate it are the actual answer; the label on its own commits to nothing.
- 3.
Retries with no budget
Retries compose down a call chain: three layers each making three attempts can send 27 to the bottom one. Without a bound and a backoff, a dependency that merely got slow becomes an outage caused by its callers.
- 4.
Partial failure treated as failure
Harder than a dependency being down: three of five writes have landed and the process coordinating them has died. What happens to the other two, and who finds out, is the question.
What a strong answer sounds like: A strong answer treats a duplicate, a reorder and a partial failure as ordinary inputs rather than exceptions.
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.
What there is to practise
Questions here most often also test system design & trade-offs, data modelling & storage, reliability & failure modes and technical judgment: decisions and trade-offs. 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.