Performance in a Senior interview
Our performance questions cover Go, Python and Node, the browser, databases and distributed systems. In each they ask what dominates, the saturated resource or the cost, and how you would know. Many give the numbers and expect the arithmetic.
An axis of our Senior fullstack target.
The check comes with every pass, covers all 10 competencies of our Senior fullstack target, and takes 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 measurement that cannot see the problem
A mutex profile with no samples because no profiling rate was set, health-check latency graphs that stop at the first byte, a CPU profile that stays flat while goroutines wait. Our questions ask what an instrument records before trusting what it shows.
- 2.
Throughput without the multiplier
In DynamoDB, an update that changes a global secondary index's key costs the index two writes, one to delete the old entry and one to add the new. In a Service Bus session processor, a session slot stays held through its idle timeout after the last message. Throughput comes from multipliers like these, and our questions give the numbers so you can do the arithmetic.
- 3.
Memory counted in the wrong place
In Node,
Buffermemory lives outside the V8 heap, so with the heap limit set to the container's limit, the container can be OOM-killed while the heap is still far from its limit. In CPython, a million parsed strings holding five distinct values are a million objects unless they are interned. Our questions ask where the bytes are and what is counting them. - 4.
A fix that hides the symptom
setMaxListeners(0)silenced the warning and kept the leak, and a goroutine blocked on an unbuffered send after a timeout outlives its request. Our questions put the change that makes a warning or a metric go away beside the one that removes its cause.
What a strong answer sounds like: A strong answer does the arithmetic from the numbers given, names the resource or the cost that dominates, and says which measurement would confirm it and what the current one cannot show.
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 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 10 in our Senior 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.