Performance in a Staff interview
Our Staff performance questions are about feedback over time: a fleet that removes its slow members and overloads the rest, or many small changes that erode a latency improvement the organisation paid for. They test whether you can see the loop as well as the bottleneck.
An axis of our Staff fullstack target.
The check comes with every pass, covers all 12 competencies of our Staff fullstack target, and takes 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 local rule with a global effect
Taking a slow backend out of rotation helps the requests it would have served and moves its share to the rest, at the moment slowness is likeliest. Past a certain number of removals the survivors saturate, and the rule has turned brief slowness into an outage.
- 2.
Latency treated as a clean-up job
In one of our questions, an organisation spends a quarter optimising latency every few years, and within months it creeps back as hundreds of small changes each improve result quality and add a little delay. Our Staff questions ask what would make latency a cost every change is measured against, instead of a debt paid back in emergencies.
- 3.
A component's tail multiplied by fan-out
A leaf that is slow on one request in a hundred makes nearly two in three user requests slow when each of them waits for a hundred leaves. Our questions ask where that tail has to be fixed, in the component or within the request, and what a hedged second request costs in load.
- 4.
Defaults that disagree
In Go,
http.Transportcloses idle connections after its idle timeout andnet.Dialersends TCP keep-alive probes after its keep-alive period, and a firewall that forgets idle flows after five minutes runs a third timer. Which client loses its connections depends on how the three combine, and none of them decides it alone.
What a strong answer sounds like: A strong answer says what the system does next after the change, and at what point that stops being stable.
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, technical judgment: decisions and trade-offs, data modelling & storage and go language & runtime. 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 12 in our Staff fullstack target, 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.