Technical judgment: decisions and trade-offs in a Staff interview
This axis is about decisions: the one you made, the options you weighed, and what you gave up. Our questions test whether the reasoning survives being re-run with different inputs.
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.
Reversibility never enters the comparison
The cost of a decision is its downside multiplied by how hard it is to undo. A cheap reversible choice and a one-way door deserve very different amounts of analysis, and treating them alike spends a fortnight on the first or an afternoon on the second.
- 2.
Optimising for the technically better system
A Staff decision is constrained by the team that has to run the result, by the deadline, and by everything else already in flight. A better architecture nobody has the capacity to operate is the worse decision, and saying so is what our questions look for.
- 3.
No condition that would falsify it
A decision with no stated trigger for revisiting it cannot be reviewed later; it quietly becomes the way things are. “We move to X if write volume passes Y, or if the p99 stops meeting Z” is a decision. “X felt right” is a preference.
- 4.
The do-nothing option unscored
Keeping the current system, with its known cost, is a real option and is often the correct one. Leaving it out makes every alternative look good by default, which is why our questions put the baseline among the options.
What a strong answer sounds like: A strong answer states what would have changed the decision — and can point at an occasion when something did.
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 system design & trade-offs, data modelling & storage, security and networking. 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.