Reliability & failure modes in a Staff interview
Our Staff reliability questions are less about which timeout to set and more about what the system promises, what that promise costs, and who decided — including what you would let fail.
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.
A target with no budget
An availability number nobody is allowed to spend makes every incident equally urgent and nothing prioritisable. An error budget turns the same number into a decision about whether to ship or to stabilise, which is the decision our Staff questions ask you to make.
- 2.
Redundancy that shares a failure
Two replicas behind one config rollout, one control plane, one certificate or one deploy pipeline are one thing wearing two names. The question is not how many copies exist but what is genuinely independent.
- 3.
A remedy that installs a new failure mode
Fixes trade. Claiming a unit of work before doing it removes double execution and introduces work that is claimed and never done; adding a retry removes a transient failure and adds load exactly when the system can least take it. Naming what the fix introduces, and what closes that in turn, is what our Staff questions look for.
- 4.
Degradation treated as binary
Stale, partial or slower is usually better than an error, and what to shed under pressure is a decision taken calmly in advance rather than under load. If nobody has decided, whoever is on call decides under pressure, and differently each time.
What a strong answer sounds like: A strong answer says what it would shed, in what order, and who agreed to that before the incident.
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.
What there is to practise
Questions here most often also test debugging and incident reasoning, networking, operations & sre and messaging & async integration. 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.