The system design mock interview guide

System design rounds are rarely lost on architecture knowledge. They are lost on sequence: candidates draw before they scope, go uniformly shallow, and never say out loud what they traded away. The fix is a repeatable running order you have rehearsed under time pressure — which is exactly what a mock interview is for.

How to run the 45 minutes

1. 0–5 min

   Scope the problem

   Restate the prompt in one sentence, name the primary user journey, and agree what is explicitly out of scope. Write the agreed scope down — you will refer back to it when the interviewer widens the problem later.

2. 5–12 min

   Pin the non-functional requirements

   Read volume, write volume, growth curve, latency budget, consistency need, durability target, failure tolerance and cost ceiling. Nothing on the diagram is defensible until these numbers exist.

3. 12–20 min

   Sketch the high-level design

   Clients, entry layer, services, storage, async paths. Keep it to six or seven boxes; depth comes later and only where the interviewer pushes.

4. 20–33 min

   Deep-dive one or two components

   Pick the component the requirements make hardest — usually the write path, the hot read path, or the consistency boundary. Show the data model and the failure behaviour.

5. 33–40 min

   Scale, fail, and operate

   What breaks at 10x? What is the blast radius of a region outage? What do you alert on, and what does the on-call runbook say?

6. 40–45 min

   Summarise the trade-offs

   Two or three sentences: what you optimised for, what you gave up, and what you would revisit with more time or data. This closing is one of the strongest signals in the whole session.

Five non-functional requirements to pin down first

Our feedback model tracks this explicitly: sessions where the candidate establishes numbers before drawing score materially higher on structure and trade-offs.

What is the latency budget, end to end?

p99 of 100 ms versus 2 s decides caching, synchronous versus queued writes, and whether cross-region reads are allowed at all.

Where can the system be eventually consistent?

Naming the one place that needs strong consistency lets you keep everything else cheap and available.

What is the read:write ratio and the peak multiplier?

A 1000:1 read-heavy workload is a caching and fan-out problem; a write-heavy one is a partitioning and durability problem.

What failure is unacceptable versus merely expensive?

Data loss, double charges, and stale prices sit at different tiers. Ranking them justifies replication, idempotency keys and reconciliation jobs.

What is the cost ceiling and the operating team size?

A three-person team cannot run five stateful systems. Constraining operability is a senior signal, not an excuse.

Say the trade-off, not just the component

A trade-off statement names the choice, the benefit, the cost, and why the cost is acceptable here. Compare:

Five mistakes that cost senior candidates the offer

• Drawing boxes before agreeing on numbers — every later answer becomes unanchored.
• Silent thinking. Interviewers score the reasoning they can hear, not the design in your head.
• Uniform depth. Fifteen shallow components beat by two deeply argued ones, every time.
• Ignoring operations. No monitoring, no rollout story, no on-call view reads as junior regardless of the architecture.
• Defending the first design. Changing your mind out loud with a reason is a strength, not a retreat.

Rehearse it in a timed mock interview

Reading the running order takes ten minutes. Holding it while a timer runs and an interviewer widens the scope is the part that needs practice. These sessions follow the same 45-minute shape and score your requirements gathering and trade-off language directly.