Practice

Reading about trade-offs is not the same as making them

Each scenario gives you a realistic problem and asks you to reason through it. You'll hit decision points, make choices, and see what actually happened and why.

scenario.md
designbuild before requirements are clear
diagnosefind root cause from symptoms
changemodify a live system safely
operatewhen the environment turns hostile
each scenario: real constraints, real consequences

Design

Reasoning under uncertainty before the system exists. Requirements accumulate mid-build — you won't know what it needs to become until it's almost too late to change.

req: ingest events from APIshipped
req: join with user profilesshipped
req: schema changes weeklyrethink ↑
req: backfill 2 years of historyredesign ↑↑
requirements reveal the architecture you needed
Read →

Diagnose

Reasoning under incomplete information after symptoms appear. You never start with the problem — you start with a complaint, a metric, or a failed job.

report: revenue down 12% since Tuesday
check: pipeline exits → all green
check: row counts → match source
check: upstream schema → changed Tuesday 9am
currency: string → float ← cause
symptom was business. root was infrastructure.
Read →

Change

Reasoning under live constraint with rollback risk. Every scenario has a system that cannot go down, a deadline, and at least one option that looks safe but isn't.

goal: rename user_id → customer_id
option A: rename + redeploy all consumers
risk11 teams, no coordination
option B: dual-write both columns
windowteams migrate at own pace
reversibility is a feature, not a workaround
Read →

Operate Under Pressure

Reasoning when the system is correct but the environment is hostile. The system isn't broken — the constraints changed. These test whether you understand what your system was actually designed for.

SLA30 min
month 1–6 avg28 min ✓
last week avg34 min ⚠
today45 min ✗
code unchanged — the environment changed
Read →