Skip to content
InfraDrill

System design & trade-offs in a Senior backend interview

A Senior design round is usually forty-five minutes on one system, and what is graded is not whether you arrive at the reference architecture. It is whether each choice follows from a constraint you established, and whether you can say what the choice costs. Interviewers are listening for the sentence after the decision.

Check whether this one is a gapTry real questions first — no signup

The check comes with every pass, covers all 8 competencies of a Senior backend loop, and takes 10–15 minutes. It reports each one as Ready, Borderline or a Gap for this level. It never predicts a pass.

Where this usually breaks down 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. 1.

    Requirements restated instead of constrained

    The prompt is repeated back and the design starts. Without a read-to-write ratio, a data volume and a latency target, every later choice is a preference rather than a consequence — and there is nothing to revisit when one of them moves.

  2. 2.

    The failure path designed in one sentence

    Most of the signal is in what happens when a dependency is slow, a consumer falls behind, or a write is retried. A design whose author never says what breaks first has not been tested by anyone, including them.

  3. 3.

    Components named, mechanisms not

    “Put a cache in front” and “use a queue” name products. The question underneath is which consistency the cache gives up, and what the queue does when the producer outruns the consumer: block, drop, or grow until something else breaks.

  4. 4.

    Storage chosen before the queries

    The access pattern picks the store. Naming a database first and fitting the queries to it afterwards answers a question nobody asked, and it is the usual way a design stops being defensible halfway through.

What a strong answer sounds like: A strong answer keeps a running list of what has been assumed, and revisits it when the interviewer changes one of the numbers.

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 rightHard rightVerdict
2 of 21 of 1Ready
1 of 21 of 1Ready
2 of 20 of 1Borderline
0 of 21 of 1Borderline
1 of 20 of 1Gap
0 of 20 of 1Gap

Three questions is coarse and the report says so beside every verdict. It is enough to separate this axis from the other 7, 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, because loops at this level weight it more than the rest.

What there is to practise

168 questions on this axis
132 medium, 36 hard. Easy is not drawn for a Senior target.

Every answer cites the source it was checked against.

Drawn from System Design (77), Messaging & Event Streaming (27), Networking & APIs (14), Databases & SQL (13), Google Cloud (10).

Practised in the System design round
Design a system to requirements and defend the trade-offs: storage, messaging, caching, capacity and cost. The round weighted most in 2026 loops.

Practice is arranged by interview round rather than by topic, because loops are graded that way.

Questions here most often also test technical judgment: decisions and trade-offs, distributed systems, messaging & async integration and data modelling & storage. Nothing on this axis is asked in isolation, which is why the check reports every competency separately rather than averaging them.

One of them, in full

A real 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.

System design & trade-offsmedium

A team removes a deprecated int32 legacy_id = 4; field from a protobuf message and ships the new schema. Six months later someone adds string region = 4;. Old clients still exist in the field. What goes wrong, and what should have been done when the field was removed?

Answer it on the demo

One axis is not the loop

A Senior backend loop tests 8 competencies, and being strong here says nothing about the other 7. The check covers all of them in one sitting and reports each separately, so what comes back is a profile rather than a score.

See the passesWhat the whole Senior backend loop tests