Debugging and incident reasoning in a Senior interview
These questions hand you a symptom — a latency spike, a stalled consumer, a pod that will not start — and test whether you reach the mechanism before reaching for a fix.
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.
A hypothesis nothing could refute
“It is probably the database” becomes a hypothesis only when you say what you would see if it were true and what you would see if it were not. Without that, every observation confirms it and the investigation cannot converge.
- 2.
Correlation read as mechanism
A restart curing the symptom is equally consistent with a memory leak, a backlog, a stale connection pool and corrupted in-process state. It discriminates between none of them, so it is evidence for none of them.
- 3.
Fixing before bounding the blast radius
Who is affected, and whether it is still getting worse, come before why. Mitigation and diagnosis are different jobs with different urgencies, and conflating them spends an outage on the interesting question rather than the expensive one.
- 4.
Reading the report instead of the effect
A green deploy, an exit code of zero, a metric that is flat because nothing is reporting into it. Separating what was measured from what was assumed is most of the skill, and our questions plant it on purpose.
What a strong answer sounds like: A strong answer states what it expects to see if the hypothesis holds, and what would rule it out, before it looks.
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 reliability & failure modes, operations & sre, observability 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.