skip to content

learn.smmeyer.devsystem-design15

menu

system-design/15

interview mode · capstone · ~4h practice

Interview execution framework

outcome

Run a clear 45–60 minute design interview and recover gracefully when pushed.

Plan a practice session · ~4h including exercises
Read + trace the worked example
25 min
Assignment + constraint variations
95 min
Timed drill + repeated explanations
100 min
Closed-book recall + self-review
20 min

This is a suggested practice budget, including drawing, variations, and repeated drills. Reading is the first block. Split the work across sessions and use the rubric to judge when to move on.

why this matters

Excellent knowledge can disappear inside an unstructured interview. A time-boxed narrative lets the interviewer steer, exposes judgment, and ensures you reach bottlenecks, failure, and operations.

coverage

  • Opening: clarify, scale, critical constraints in five minutes.
  • Core: high-level design, APIs, data model, request flows.
  • Depth: bottlenecks, failure, security, observability, cost.
  • Interaction: invite steering, defend decisions, revise openly.
  • Recovery: surface a flaw, protect invariants, migrate the design.
  • Seniority: reason in product outcomes and ownership boundaries.

mental model

Time-box the breadth, earn the deep dive, and close the loop.

  1. 1 →0–5

    Contract + scale

  2. 2 →5–15

    Skeleton + API

  3. 3 →15–40

    Critical deep dive

  4. 4 →40–50

    Failure + close

Read in numbered order: 0–5 → 5–15 → 15–40 → 40–50.

lessons

01Drive a shared agenda

Restate the problem, ask architecture-changing questions, state assumptions, estimate scale, and propose the two areas worth deeper attention. Tell the interviewer how you plan to spend time and invite correction.

Open with a short restatement and a few questions whose answers change architecture. For a public inference API, ask who the tenants are, which capabilities are required, whether requests stream, and what latency and spend limits matter. State supplied facts separately from assumptions. You do not need to collect every possible requirement before showing a first design.

Propose an agenda after the initial estimate: “I will cover the request contract and data ownership, then go deep on admission and streaming recovery.” This gives the interviewer a chance to redirect. Keep a visible list of invariants and unresolved questions so later choices can refer back to them. Check that the discussion is still solving the same problem after a constraint changes.

Allocate time adaptively. If the interviewer chooses the data model, shorten a less important capacity discussion rather than ignoring the request to preserve a memorized timeline. Reserve time to close with failure, security, cost, and risks. A useful structure prevents omissions while leaving room for collaboration.

  • Keep a visible requirements/SLO list
  • Use named arrows and numbered request flows
  • Pause for steering at phase boundaries

02Narrate decisions, not drawing

Instead of ‘then add Redis,’ say ‘reads outnumber writes 100:1 and allow 30 seconds of staleness, so a regional cache removes primary load; here is invalidation and failure behavior.’

Narrate one numbered request end to end. A tenant submits an operation ID; admission reserves estimated token capacity; a worker streams typed events; completion reconciles usage and persists status. At each boundary explain authority, durability, deadline, and recovery. This exposes correctness more effectively than naming a gateway, queue, and database without connecting them.

Use numbers where they decide something. If the survivor region cannot serve failed-over traffic within the SLO, calculate the shortfall and choose admission or reserved capacity. If the bottleneck is one hot key, do not present aggregate capacity as the answer. Distinguish illustrative assumptions from measured limits so the listener can see what needs a benchmark.

Make tradeoffs in complete sentences. “This queue absorbs bursts but adds waiting time and an operational dependency; the client gets durable status and can cancel before execution” connects mechanism to consequence. Name the drawback before you are asked. A design review evaluates judgment, not whether every component seems beneficial in isolation.

  • Mechanism follows constraint
  • Every component gets an owner and failure mode
  • Revisit estimates at bottlenecks

03Recover like a senior engineer

When a flaw appears, acknowledge it precisely, preserve the product invariant, and change the smallest necessary part. Explain migration or reconciliation if data/state already exists.

When you discover a flaw, name its effect precisely. “A retry can create a second charge because the provider result is not durably tied to the operation ID” is actionable. “Reliability is a concern” is too broad. Preserve the business invariant, then add the smallest repair and explain any new failure state it introduces.

For existing data, include transition behavior. Adding an idempotency table today does not identify yesterday's ambiguous operations. You may need a reconciliation process before enabling automatic retries. Acknowledging that limitation demonstrates operational reasoning; quietly redrawing the happy path leaves the real system in an undefined state.

After the mock, use evidence rather than a feeling of fluency. Pick timestamps showing whether you quantified the bottleneck, traced an uncertain effect, or revised a changed assumption. Rehearse the weakest segment by itself, then try a fresh prompt. Improvement should appear in a new decision or clearer explanation, not only a higher self-assigned number.

  • Do not erase the whole design reflexively
  • State what remains valid
  • Close with risks, metrics, and next experiment

worked example

Recover when the interviewer removes a region

At minute 28 of a 50-minute design, you are told the primary region has failed. Your original diagram has one write owner and an asynchronous replica.

  1. Restate the changed constraint and ask whether accepted-write loss is tolerable. Do not keep polishing the original healthy-state path.
  2. Trace in-flight requests, primary fencing, replica lag, promotion, and survivor capacity. State any availability-versus-data-loss choice.
  3. Spend the remaining deep-dive time on that path, then reserve time to recap residual risks and recovery.
  4. Score the recording using concrete evidence: when you noticed the new constraint, which assumption you changed, and what remained unresolved.

Design decision: Treat steering as new design input and reallocate time while keeping the critical contract visible.

Limit: A smooth delivery cannot compensate for incorrect failure semantics. Use the scorecard to separate fluency from correctness.

Teaching scenario · traffic, prices, and capacity values are illustrative.

assignment

Produce: Two recorded 50-minute mocks, two scorecards, and a rewritten weak section.

Paper, a text editor, or a spreadsheet is enough. Model access and paid services are optional.

  1. Run the mock workspace with different scenarios and preserve the diagrams and notes.
  2. For framing, correctness, depth, tradeoffs, and recovery, record a score plus one timestamped piece of evidence.
  3. Choose the weakest dimension, rehearse that section in isolation, and explain how the second rep changes your next practice session.

Change a constraint

  • Inject a cost cap instead of a regional failure.
  • Repeat one explanation in 90 seconds with all key assumptions retained.

Self-review rubric

  • The opening establishes scope and measurable constraints.
  • A changed requirement produces a visible design change.
  • The scorecard cites evidence and chooses a specific next drill.

If a criterion is missing, revise that part of the artifact before rating your practice below.

Compare a sample artifact after your attempt

One defensible answer under these assumptions. Compare the reasoning and checks with your work; other designs can satisfy the same contract.

This scorecard illustrates how to review your own two recordings; it is not a score you should award without evidence from an actual attempt.

Mock 1 evidence (fictional)
Framing 3: 04:00 states write ownership + SLO, misses RPO
Correctness 2: 28:00 region-loss answer promotes without fencing
Depth 2: 32:00 cannot explain missing accepted writes
Tradeoffs 3: 18:00 compares cache freshness/capacity
Recovery 2: 29:00 redraws everything instead of local repair
Revision: restate RPO → fence writer → assess durable position
          → reconcile missing operations → route with capacity bounds
Mock 2: timestamp whether the new scenario uses that reasoning unaided

A second mock should use a different constraint so it tests transfer. With asynchronous replication, identify exposed accepted writes before promising recovery. A cost-cap change instead revisits capacity, priority, and degradation. Preserve each diagram and one timestamped next exercise per weak dimension.

Check your artifact

  • The recording establishes measurable requirements and traces a critical request.
  • A changed premise leads to a visible, justified revision.
  • The score cites behavior and a targeted next drill; a higher number alone is insufficient.

A tempting mistake: Confident delivery can mask an invalid recovery protocol. Review the invariant and evidence before rating fluency.

cumulative practice

Relay · build and evolve a private file service

Project brief

Keep one design document for Relay, a tenant-aware file service. Start with 100k daily users, ten downloads per user/day, 10k uploads/day, 1 MB typical bodies, 30-day retention, and a 5× download peak. Files are private to workspaces. Treat these as fictional planning assumptions. Later chapters add previews, recovery, regional constraints, compute, and an assistant. Record each change rather than replacing the earlier version; the final review combines the whole packet. These activities share the chapter's existing practice budget.

Keep one project document across this track. Reconstruct earlier reasoning before opening notes, then revise the same artifact. Use part of the assignment and review budget for this work. If you enter mid-course, sketch the earlier decisions first using the linked chapters.

Add to your project: Relay capstone: final design packet, a recorded review, and one revised weak path.

Present the complete project in 50 minutes from a blank page. At minute 25, remove a region and revoke an assistant user's access. Recover workload estimates, ownership, current permissions, and safe effect semantics without reading prior answers. Then compare your new packet with the accumulated versions.

Compare cumulative reasoning after your attempt

A strong packet includes contract/SLO, workload table, APIs/data, numbered upload/download/preview/assistant paths, ownership and permission boundaries, capacity/degradation, failure matrix, quality tests, and rollback. Region loss changes authority, replicated-state confidence, and survivor load. Revocation changes evidence publication and action eligibility. Preserve unaffected paths, reconcile uncertain effects, and cite recording evidence for the next practice step. Alternative designs pass if they satisfy these same explicit promises.

Keep your first attempt and revision together. If your answer differs, identify the assumption or mechanism that explains the difference before rating your recall.

senior signal

Treat the interview as a design review with a colleague. Use decisive language, expose uncertainty honestly, and make it easy for them to push you deeper.

failure patterns

  • Talking continuously without checkpoints
  • Spending half the session on requirements
  • Narrating boxes rather than decisions
  • Hiding or hand-waving a discovered flaw

knowledge checks

Start with these quick checks, then explain the closed-book questions in your own words.

  1. 01Best response after discovering a flaw?

    select an option to check your answer

  2. 02Senior-level narration focuses on…

    select an option to check your answer

closed-book recall

Close the worked example and explain these from memory. Answers are self-reviewed. Drafts stay on this page; save anything you want to keep in chapter notes.

Rate the assignment and recall together

Use the assignment rubric as evidence. Completion is your own judgment; this score schedules practice.

interview drill

Run a full 50-minute mock: design a public, abuse-resistant AI inference API. Use the built-in scorecard afterward.

  • 50 min
  • whiteboard
  • recorded
  • self-score
compare a strong approach after your attempt

0–5 contract/scale; 5–12 API and high-level path; 12–20 quota/admission; 20–32 scheduling/streaming; 32–40 failure/fallback; 40–47 security/observability/cost; 47–50 recap. Score clarity, correctness, depth, tradeoffs, and recovery from 1–4.

Compare decisions and failure behavior, then repeat with a changed constraint. Keep your own wording.

Use the timed mock workspace →

references

Sources offer deeper context. Provider capabilities and API contracts can change; check current official docs before implementing.

notes

saved locally