How to Prepare
Preparation works best as a loop: learn one mechanism, retrieve it from memory, apply it to a new prompt, and review where your explanation failed.
What, why, when and how
What is it?
Preparation is a repeated cycle of independent attempts, diagnosis, focused study and transfer to a different prompt.
Why is it needed?
Recognizing a written solution does not prove you can construct one or recover when its assumptions change.
When should I use it?
Use a diagnostic mock to choose the next session, especially when time is limited or reading many topics has stopped improving your answers.
When should I choose something else?
Avoid treating chapter completion or an arbitrary numerical score as hiring readiness. Keep concrete evidence beside every self-assessment.
How do I use it?
Save an attempt, use the five study dimensions below, identify the highest-impact missed mechanism, practice it in another product, then retest after a delay.
Can you show a concrete example?
If a notification design treats a provider timeout as definite failure, study uncertain outcomes and stable operation IDs. Apply the same boundary to a payment design, then revisit the notification problem without notes.
Read the diagram
Mock: a provider timeout is called definite failure; Repair: preserve operation ID; reconcile uncertainty; Retest: explain the same boundary in payments
Follow the detailed diagrams below to trace the additional state changes and failure cases behind these answers.
Choose a preparation path
Use the Guided Course if you want concepts, practice and reviews in a deliberate order. Use the Reference Library when a mock exposes a specific gap. Switching paths should not reset your completed lessons or notes: both paths use the same activity identities.
Start with one timed design before building a calendar. Pick a familiar service, spend 35–45 minutes explaining it aloud, and save the diagram. Do not stop to research during this baseline. You are measuring where your reasoning breaks: scope, data ownership, scale, failure recovery or communication.
| Observation in the mock | Next study action | Evidence of improvement |
|---|---|---|
| Named many services but no complete request | Revisit Delivery Framework | Trace one request to durable completion in five minutes |
| Added caches without a freshness contract | Study Caching | Explain a stale-refill race and the selected remedy |
| Said “exactly once” after drawing a queue | Study Multi-step Processes | Handle a crash after commit and before acknowledgement |
| Used numbers without changing a decision | Study Numbers to Know | Identify the capacity threshold behind one choice |
| Ran out of time before failures | Rehearse a shorter baseline | Reach an end-to-end design by the middle of the session |
Build a useful study session
A 90-minute block can contain 15 minutes of retrieval from memory, 25 minutes learning one mechanism, 30 minutes applying it to a new problem, and 20 minutes reviewing the result. These are suggested budgets, not interview rules. The key is producing an explanation before looking at the answer.
For example, learn conditional updates, then apply them to a ticket hold. On another day, apply the same mechanism to an auction bid. If you can repeat the ticket example but cannot explain the auction, you memorized the story more than the guarantee. Ask what state is authoritative, which operation is atomic, and what a timeout leaves uncertain.
Read the diagram
Baseline mock → one diagnosed gap → targeted lesson; Blank-page recall → new problem → spoken explanation; Review evidence → delayed retest → revised study plan
Three study plans you can adapt
Choose the plan that fits the calendar you actually have. Each plan preserves the same loop: retrieve from memory, learn one mechanism, apply it to a different prompt, and review evidence. The plans are examples, not a promise that a fixed number of days guarantees interview readiness.
Three days: repair one urgent gap
| Day | Work | Checkable result |
|---|---|---|
| 1 | Run a 35–45 minute baseline mock without notes. Label each miss as scope, contract, state, scale, failure, or communication. Review only the two highest-impact misses. | A saved baseline and two specific learning questions. |
| 2 | Retrieve the relevant concept from memory, study one lesson, then apply its mechanism to a different problem. Example: learn conditional writes from a seat hold, then use them for an auction bid. | A new design that names the authority, invariant, retry identity, and losing request result. |
| 3 | Run a timed mock with a changed constraint. Compare it with the baseline and explain one rejected alternative aloud. | A revised diagram and evidence that the original gap changed. |
Seven days: build a complete interview loop
| Day | Focus | Deliverable |
|---|---|---|
| 1 | Baseline mock and error log | One prioritized gap; do not collect a list of vague topics. |
| 2 | Delivery Framework, networking, API contracts | A five-minute end-to-end baseline with measurable assumptions. |
| 3 | Data modeling, indexing, caching | One query path plus a concrete stale-read or write-amplification failure. |
| 4 | Sharding, consistency, capacity | A partition choice supported by arithmetic and a skew case. |
| 5 | One problem breakdown under a timer | A complete design before reading the worked explanation. |
| 6 | Failure and recovery practice | Inject a timeout, duplicate delivery, or region outage into yesterday’s design. |
| 7 | Unseen mock and review | Compare two saved attempts, schedule the next delayed retrieval, and stop adding topics until the largest gap is repaired. |
Twenty-one days: spaced practice and transfer
| Week | Main work | Evidence to keep |
|---|---|---|
| 1 · Foundations | Establish a baseline; study requirements, networking, APIs, data modeling, indexes, caching, and capacity. Use short retrieval sessions before opening each lesson. | Two scoped baselines, one access-pattern model, and a list of assumptions that changed a design decision. |
| 2 · Mechanisms | Study partitioning, contention, real-time updates, multi-step workflows, large blobs, and long-running jobs. Reuse each mechanism in at least two different prompts. | Two failure timelines, one state machine, and an explanation of when the mechanism would be the wrong choice. |
| 3 · Integration | Complete three timed designs from different categories, then revisit the earliest one after a delay. Add a senior-level change such as tenant skew, deletion latency, cost ceiling, or regional failure. | Three saved attempts, a revised design, a short answer recap, and the next practice date. |
If you have less time, reduce the number of new problems and preserve the practice-review loop. If you have more time, add spaced transfer exercises rather than rereading the same pages. For senior and staff roles, extend each design with rollout, observability, cost, ownership and the reasoning behind rejected alternatives.
What to write in an error log
Record the prompt, the failed claim, the corrected rule, a counterexample, and a date to retry. “Study Kafka” is too broad. “I assumed committing a consumer offset made an external email send atomic” is specific enough to repair. The next exercise should force that boundary again with a different side effect.
Use the same five study dimensions throughout this lesson: scope, complete path, correctness and recovery, justified deep dives, and communication. Score each from 0 to 2. Zero means absent; one means named; two means demonstrated with a mechanism and failure. A numerical score is a study aid, not a hiring prediction. Keep the actual evidence beside the score so confidence does not substitute for correctness.
Practice with increasing constraints
Start with Bitly, News Aggregator and Rate Limiter for focused designs. Move to Dropbox, Ticketmaster, WhatsApp and Notification System to combine multiple guarantees. Then attempt FB News Feed, Payment System, Google Docs and ChatGPT with strict time limits and unfamiliar follow-ups. These are suggested learning stages, not claims about company interview difficulty.
For every attempt, ask a partner to change one requirement: traffic grows tenfold, a region fails, deletion must propagate promptly, or one tenant produces most of the load. Repair the same design before replacing it wholesale. This reveals whether each component has a clear responsibility.
Before and after a mock
Before starting, prepare a blank canvas, confirm duration and scope, and choose a timer. During the mock, say assumptions aloud and invite correction. At the halfway point, check that every core user action has a path through the architecture. Reserve time for at least one concrete failure and a concise recap.
Afterward, save the original attempt before studying a solution. Compare decisions, not drawing similarity. Choose two changes you can explain precisely and repeat the problem later without notes. Improvement means making fewer unsupported claims and recovering more clearly from follow-ups.
Preparation exercise
You have seven days and repeatedly miss retry behavior. Design three sessions using one concept, two different problems and a delayed retest. State what observable result would convince you that the gap is repaired.
Show answer and explanation
Answer: Study durable acceptance and idempotency, apply them to Notification System, then apply them to Payment System without notes. Two days later, inject a lost provider response into a new workflow. The gap is repaired when you preserve the operation identity, distinguish uncertain from failed, and explain reconciliation without claiming that a queue guarantees exactly-once external effects.
Choose the next session from evidence
After one 45-minute attempt, use the five study dimensions from the error-log section: scope, complete path, correctness and recovery, justified deep dives, and communication. In this teaching example the scores are 2,2,0,1,2. The next session should repair the failed correctness claim before adding another scaling topic: name the ownership transition and replay the ambiguous timeout. Save the original diagram and annotate the repaired boundary so progress is observable.
attempt 1: scope 2; path 2; correctness/recovery 0; deep dives 1; communication 2
next session: versioned ownership + timeout replay
attempt 2: repeat the same failure, then transfer it to another product
Read the diagram
attempt 1: scope 2; path 2; correctness/recovery 0; deep dives 1; communication 2; next session: versioned ownership + timeout replay; attempt 2: repeat the same failure, then transfer it to another product
A one-week plan can allocate three foundation sessions, three independent case attempts, two failure-focused revisions and one timed mock, with breaks and a buffer. Adapt the duration to available time and the diagnostic, rather than claiming a universal number of days guarantees readiness. Prerequisites are concrete: model records before debating sharding; trace one request before choosing real-time delivery.
Show answer and explanation
Answer: Marking every article read is not evidence of being able to resolve a duplicate payment. A saved attempt, an identified bad assumption and a corrected mechanism are evidence. Keep a short error log with trigger, mistaken assumption, repair and next transfer exercise.
Choose your learning depth
Start with vocabulary and one concrete operation. Then practice the scaling trigger, concurrency boundary and failure repair. For senior/staff preparation, justify the alternative, operational ownership and a staged rollout with a rollback condition. Follow the Interview Playbook for clarification questions, a timed answer sequence and examples across messaging, video and expense sharing. These are learning tracks, not a universal hiring rubric.
Turn a vague review note into the next exercise
Suppose a reviewer writes “weak on retries.” That feedback is too broad to choose a useful lesson. Recover the exact operation history: a worker submitted delivery d7, its response timed out, and your design created delivery d8 to try again. The missed claim is that timeout proved the earlier submission failed.
| Keep in the error log | Concrete entry |
|---|---|
| Trigger | Provider response lost after request submission |
| Mistaken claim | No response means no side effect occurred |
| Corrected rule | The outcome is uncertain; preserve operation identity and reconcile using the available provider contract |
| Counterexample | Provider accepted d7 before its response was lost |
| Transfer exercise | Payment request p7 times out after submission |
| Retest evidence | Explain p7's unknown state and recovery without silently creating a new charge |
The corrected rule does not promise every provider supports deduplication or status lookup. If neither exists, state the duplicate-versus-omission decision instead of inventing certainty. The retest should require that exception as well as the happy path.
Show answer and explanation
Answer: A productive next session retrieves the rule from memory, applies it to payments, and revisits the original notification attempt after a delay. In the five-dimension study rubric, correctness and recovery earns stronger evidence only when the operation history, enforcing mechanism and remaining limitation are explained. Watching another solution without making an independent attempt does not supply that evidence.