interview-prep

name	interview-prep
description	Prepare for system-design interviews using a repeatable framework - requirements clarification, capacity estimation, API and data design, deep dives, and trade-off articulation. Use when coaching candidates, calibrating interviewers, or self-preparing for staff/principal/architect loops.

System Design Interview Prep

Strong candidates win on structure, not trivia. A repeatable framework keeps you driving the conversation, surfaces trade-offs the interviewer cares about, and leaves time for the deep dive that distinguishes seniority.

Stack Baseline (2026)

Concern	Recommended
Framework	Requirements -> Estimation -> API -> Data -> HLD -> Deep dive -> Trade-offs
Modeling	C4 Context + Container on the whiteboard
Reference text	Richards & Ford, Fundamentals of Software Architecture 2e
Distributed depth	Designing Data-Intensive Applications (Kleppmann), The Hard Parts
Patterns	Event-driven, CQRS, outbox, saga, CDC, sharding, consistent hashing
Practice format	Architecture Kata (Ted Neward), 45-min timeboxed mocks

When to Use

• Personal prep for staff/principal/architect interview loops.
• Coaching internal candidates on promotion panels.
• Calibrating interviewer rubric so signal is consistent.

Prerequisites

• Comfort with one cloud's primitives (compute, queue, KV, OLTP, OLAP, object store).
• Working mental model of CAP, latency numbers, and consistency models.
• A whiteboard or digital canvas; a stopwatch.

Instructions

flowchart LR
  R[Requirements<br/>5 min] --> E[Estimation<br/>5 min]
  E --> A[API + Data<br/>10 min]
  A --> H[High-Level Design<br/>10 min]
  H --> D[Deep Dive<br/>10 min]
  D --> T[Trade-offs + Wrap<br/>5 min]

1. Clarify requirements: functional, non-functional (RPS, latency, durability, consistency), constraints. Write them on the board.
2. Estimate capacity: users, QPS read/write, storage/day, bandwidth. Show the math; round aggressively.
3. Sketch API + data model: 3-6 endpoints, key entities, access patterns, primary/secondary indexes.
4. Draw HLD as C4 Containers: clients, edge, services, datastores, async backbone. Mark sync vs async.
5. Pick a deep dive the interviewer signals interest in (hot path, sharding, consistency, failure mode).
6. Articulate trade-offs: what you chose, what you rejected, what would change your mind.

# Mock Scoring Rubric (per dimension, 1-5)

- Requirements & scoping
- Capacity estimation (numbers, units, sanity)
- API & data modeling
- High-level design clarity (C4-ish)
- Distributed-systems depth (consistency, partitioning, failure)
- Trade-off articulation
- Communication & time management

Pass bar (Staff): >=4 average, no dimension <3, deep dive shows production scars.

Common Pitfalls

Pitfall	Why it hurts	Fix
Jumping to a diagram	Misses the actual problem	Spend the first 5 min on requirements + NFRs
Hand-waved estimates	Signals lack of rigor	Always show units and assumptions
Buzzword stacking	Reads as Golden Hammer	Justify each component against an NFR
One-way design	Can't defend choices	Pre-load 2-3 trade-off pairs (consistency vs availability, etc.)
No deep dive	Looks junior	Pick the riskiest piece and go three layers deep
Time blowouts	No wrap, no trade-offs	Use the 5/5/10/10/10/5 timebox

Output Format

• A one-page personal cheat sheet: framework, latency numbers, estimation templates.
• A library of 10-15 practiced prompts with notes on chosen designs and rejected options.
• Mock recordings or transcripts scored against the rubric above.

Authoritative References

• Mark Richards & Neal Ford, Fundamentals of Software Architecture, 2e (O'Reilly, 2024).
• Mark Richards & Neal Ford, Software Architecture: The Hard Parts (O'Reilly).
• Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly).
• Ted Neward, Architecture Kata format — neward.net/architecturalkatas.
• C4 model — c4model.com.
• ThoughtWorks Technology Radar — thoughtworks.com/radar.