Mock Interviews & Communication

You know the design. Can you deliver it in 45 minutes?

Picture a candidate who has done all the reading. She can explain consistent hashing, leader election and Kafka consumer groups. The prompt is: "Design a service that runs scheduled jobs for other teams: cron, but for the whole company." Here are her 45 minutes, as the interviewer's notes would record them:

Nothing she said was false. The interviewer still can't recommend a hire, because the evidence never appeared: a design that works end to end, a reason behind each choice, and a steady response to a challenge. An interviewer can only score what they saw and heard.

Knowing a design and delivering it are different skills, and the second one improves only by doing it: out loud, against a clock, with someone pushing back. That's a mock interview. This lesson shows you how to run one on a fresh prompt and what to practice inside it.

Look at what broke, in order: the clock (the design never got finished), the reasons (choices arrived without trade-offs) and composure (pushback turned into retreat). Each has a move, and three more cover the rest of the session:

This lesson runs on the course's single interview framework from Interview Framework & Strategy (Scope, Sketch, Deep dive, Wrap-up) and assumes the questions from Requirements Gathering and the steps from Design Process Steps. Here you rehearse the whole thing under pressure.

What turns practice into a mock

Five ingredients. Drop any of them and you're studying: useful, but a different skill.

• Out loud, the whole time. Thinking silently doesn't train talking.
• A clock you don't pause. Stopping to look something up ends the rehearsal.
• Someone who knows things you don't: a prompt card with hidden facts and planned pushback.
• A record: audio, video or timestamped notes, so the debrief runs on evidence.
• A debrief that ends in one change for the next mock.

Move 1: Run the clock

Pressure: it's minute 25, and there's still no path on the board from request to result.

Your mock runs on the course's clock, the one Interview Framework & Strategy defines. Don't invent your own split; rehearse this one until it's automatic:

In a 45-minute mock you watch three checkpoints: 0:10, scope closed; 0:20, the sketch complete end to end; 0:35, at least one deep dive finished. The one that matters most is 0:20. A deep dive on a design that doesn't work end to end is polishing one part of a machine that can't run yet, and if time runs out mid-dive, you still leave a working design behind.

Three rules keep the clock honest:

• Behind schedule? Compress, don't skip. A shorter Scope with assumptions said aloud beats a missing sketch; a shorter deep dive beats a missing wrap-up.
• The interviewer outranks the plan. If they steer you somewhere, go (Move 4). The checkpoints are for when nobody is steering.
• A longer slot buys depth, a second deep-dive topic, not a much longer Scope (it grows by one minute).

Predict first: it's 0:14. You've asked your questions but computed nothing, and nothing is drawn. The interviewer is quiet. What do you do in the next 60 seconds?

The prompt card

A mock needs someone who knows more than you do. That person holds a prompt card: the prompt, the facts they reveal only when you ask, the pushback they'll deliver, and one mid-session change. Here is the card for this lesson's running example:

PROMPT (read aloud)
  "Design a service that runs scheduled jobs for other teams:
   cron, but for the whole company."

HIDDEN FACTS (reveal only when asked)
  - 2 million runs a day. About 40% of each hour's runs are due at the
    top of the hour (hh:00:00); the rest are spread out.
  - A run must start within 60 seconds of its scheduled time.
  - Runs last about 3 minutes on average; some last hours.
  - The service only triggers runs; each team's own workers execute them.
  - A failed run may be retried, but two runs of the same job must never
    overlap, and a due run must never be silently skipped.
  - Out of scope unless asked: the UI, deploying job code, job output.

PLANNED PUSHBACK
  - During the deep dive: "Why not keep the schedule in a Redis sorted set?
    It's faster."
  - "A worker freezes for 90 seconds in a garbage-collection pause while it
    holds a run. Then what?"
  - "Isn't your database a single point of failure for every team's jobs?"

MID-SESSION CHANGE (around 0:30)
  - "Each team may have at most 200 runs going at once."

If you're the interviewer: reveal facts only when asked, and let a reasonable assumption stand. Deliver the planned pushback even when the design is right, because the candidate is practicing the response. Give one hint if they're stuck for more than about two minutes. Write timestamps. Don't teach during the mock; save it for the debrief.

Practicing alone? Have a friend write cards, or write a batch yourself and use each one weeks later, when you've forgotten the details. Keep a visible timer, record audio, and read the pushback lines from the card at the planned points.

The run, traced

Here is a strong run on that card: what was said or drawn, when, and why it counts.

The numbers at 0:07

Scope ends with two or three numbers that decide something. These come from the card plus two design assumptions said aloud: the scheduler records each trigger with one write, and a running job renews a lease every 30 seconds.

The average, 23 runs a second (2 million ÷ 86,400), is 24 times smaller than the top-of-hour rate, which is exactly why it's a trap. The writes don't all land in the same second: the claims and trigger records come in the first minute, and the renewals peak just after it, while the runs thin out as they finish. Added up second by second (with 3-minute average runs, plus the runs spread over the rest of the hour), the peak comes to about 2,000 a second; adding every term at its maximum gives about 2,400. Both fit one primary.

💡 The sentence that changes the interview: "The average, 23 runs a second, is a trap. The design is sized by one minute an hour: 33,333 runs due in the same second, 556 claims a second, and about 2,000 database writes a second at the worst moment. That fits one PostgreSQL primary, so no sharding." Say it at 0:07 and nobody spends ten minutes partitioning a jobs table that fits on one machine.

Notice what is not in the numbers box: storage. A run record of about 500 bytes, 2 million times a day, is 1 GB a day; thirty days of history is 30 GB. Computing it would take two minutes and decide nothing. Compute the numbers that change a decision.

Where the clock goes wrong

• Requirements sprawl. Twenty questions, including ones whose answers change nothing ("What color are failed runs in the UI?"). Ask the ones that change a decision; assume the rest out loud.
• A deep dive before the design works. At 0:08 you're explaining how to parse cron expressions. Write "cron parsing" on the parking list (Move 3) and keep drawing.
• No wrap-up. Time ends mid-sentence, and the last thing the interviewer heard is a detail. At 0:35 you start the wrap-up, whatever is happening.
• Refusing to be steered. If the interviewer takes the wheel at 0:15, the plan bends. Follow them, and pick the checkpoints up again when they let go.

Your turn: the interviewer says this mock will run 60 minutes. Using the 60-minute column, what does the extra time buy on this card, and where are your checkpoints?

Move 2: Say the trade-off in four parts

Pressure: you say "I'd use Postgres here" and move on. Or you say "it depends" and stop.

Naming a component is not evidence of judgment; anyone can name a database. The evidence is the reasoning, and it has four parts:

Decision: what you chose. Because: the stated requirement or number it serves. Cost: what you give up, with a number if you have one. Switch if: the condition that would make you choose differently.

As a sentence: "I'll use X, because [requirement or number]. It costs [what we give up]. If [condition], I'd switch to Y." It takes about twenty seconds to say, and it answers the interviewer's next three questions before they ask them.

Three upgrades from the mock

Leases.

• Weak: "Workers send heartbeats."
• Strong: "A worker's lease on a run lasts 90 seconds and it renews every 30, because with up to 33,333 runs in flight after the top of the hour that's 1,111 renewals a second, which one primary takes. It costs up to 90 seconds before a dead worker's run is retried. If teams needed faster recovery, I'd use a 30-second lease renewed every 10 seconds, at up to 3,333 writes a second."

Replication.

• Weak: "Postgres with a replica for high availability."
• Strong: "Jobs and leases live on one Postgres primary with synchronous replication to either of two standbys, because a claim we've acknowledged must survive the primary dying: lose it, and a second worker can start the same job. It costs a round trip to a standby on every commit, typically low single-digit milliseconds inside one region and nothing at about 2,000 writes a second, and if both standbys are down, commits wait until one returns. For run logs, where losing the last second is harmless, I'd replicate asynchronously and skip the round trip."

In PostgreSQL that is the quorum setting synchronous_standby_names = 'ANY 1 (a, b)': each commit waits until at least one of the two standbys has written the commit record to durable storage. The PostgreSQL docs are blunt about the cost: the minimum extra wait is the round trip between primary and standby, and commits may never complete if too few synchronous standbys are available.

"It depends."

• Weak: "What happens when a run is still going at the next due time depends on the job."
• Strong: "It depends on one thing: whether a missed run matters. For 'refresh a cache', skipping one is fine; for 'send the hourly invoice batch', it isn't. By default I'll skip the new run, record it and notify the owning team, because most periodic jobs catch up on their next run, and a skip nobody hears about is the silent skip the requirements forbid. It costs noise: a job that keeps overrunning sends a notice every hour until someone fixes it. Jobs that can't miss a run can opt into 'queue one behind'."

"It depends" is the start of a good answer, not the answer. Name the variable it depends on, pick a default, and say what would flip it.

The mock's decisions, in four parts

Predict first: what's missing from this? "I'll put Kafka between the scheduler and the workers, because it decouples them and it scales."

Traps

⚠️ Costs that aren't costs here. "Redis adds network latency", when a round trip inside one data center typically takes well under a millisecond and runs may start up to 60 seconds late. A cost only counts if it matters for these requirements.

⚠️ Costs that aren't true. "SQL doesn't scale horizontally" (sharded PostgreSQL and distributed SQL databases such as CockroachDB exist), or "NoSQL is eventually consistent" (DynamoDB offers strongly consistent reads). A wrong cost is worse than a missing one, because the interviewer will pull on it.

⚠️ Options without a choice. "We could use A, B or C" is a menu, not a design. Pick one, and put the runner-up in the switch condition.

⚠️ Hedging versus honesty. "Maybe we could possibly use a cache" sounds unsure of everything. "I don't remember Kafka's default retention; the property I need is a day of replay, so I'd set it explicitly" is precise about exactly one unknown.

What the interviewer asks next

Each part invites a follow-up, so have the number behind it ready:

• After because: "What number makes that true?"
• After cost: "How bad is that for a user?"
• After switch if: "And what would you switch to?"

Your turn: the scheduler finds due runs by asking the database every second, instead of keeping an in-memory timer per job. Say it in four parts, with a number.

Move 3: Make the board do the remembering

Pressure: eleven boxes, arrows with no meaning, and the interviewer can't tell which path a due job takes.

The board is shared memory. If a number, requirement or decision isn't on it, both of you have to hold it in your heads while you talk about something else. Lay it out in three columns:

+-----------------------+--------------------------------+----------------+
| REQUIREMENTS          | DIAGRAM                        | LATER          |
| never overlap         |                                | cron parsing   |
| never silently skip   |   request paths, one action    | UI             |
| start within 60 s     |   at a time (below)            | multi-region   |
|                       |                                | job output?    |
| NUMBERS               |                                |                |
| 33,333 due at hh:00   |                                |                |
| 556 claims/s          |                                |                |
| about 2,000 writes/s  |                                |                |
+-----------------------+--------------------------------+----------------+

The left column is the contract. When you justify a choice, point at it: that's the because from Move 2. The right column is the parking lot. A tangent goes there in three words, so you can defer it without losing it and pick it up among the wrap-up's top risks.

Draw request paths, not a component catalogue

1. One action at a time: register a job, trigger a run, run it, read its history. A path you can trace is a design; a pile of boxes is a list.
2. Label every arrow with the operation and its rate. claim ~556/s at hh:00 tells the interviewer where the load is without another word.
3. One sentence per box as you draw it: what it does and why it exists. If you can't say why, don't draw it. A Kafka box with no consumer is decoration.
4. Keep the board current. When the design changes, change the drawing. A stale diagram contradicts you ten minutes later.
5. Check in once, after the end-to-end path: propose your deep dive and say why.

Here is the board at 0:19, drawn as request paths. The bracketed notes are what the deep dive and the change add later, drawn in as they happen:

SCHEDULE PATH
  team --POST /jobs {cron, team}--> Jobs API --> Postgres: jobs (index on next_run_at)
  scheduler --every 1 s: due jobs, FOR UPDATE SKIP LOCKED--> Postgres
  scheduler --1. enqueue {job, run} (~556/s at hh:00)--> that team's queue
  scheduler --2. then advance next_run_at--> Postgres

RUN PATH (a team's worker)
  worker <--take {job, run}-- team's queue
  worker --claim: conditional UPDATE (~556/s at hh:00)--> Postgres
                                   [0:21: + 90 s lease, renewed every 30 s, up to ~1,111/s]
                                   [0:26: + fence number]
                                   [0:30: + team slot, in the same transaction]
  worker --finish--> Postgres      [0:26: must carry the current fence]

READ PATH
  team --GET /jobs/{id}/runs--> Jobs API --> Postgres: runs (last 30 days)

DATA
  Postgres primary                 [0:26: ==sync, ANY 1==> standby A | B]

Two details in that diagram carry requirements. The scheduler enqueues first and advances next_run_at second, so a crash between the two repeats a trigger instead of skipping one; the claim (below) rejects the repeat. And FOR UPDATE SKIP LOCKED lets several scheduler instances take due jobs without waiting on each other's rows; the PostgreSQL docs describe exactly this use, avoiding lock contention among consumers of a queue-like table.

In a remote interview with no drawing tool, type exactly this kind of path list into the shared editor, with the numbers at the top.

Pick the deep dive where the requirements bite

At 0:20 the Deep dive phase starts, with one topic in a 45-minute slot (two in 60). Pick the riskiest part, the one that:

• carries the hardest stated requirement ("never overlap" → the run claim),
• sees the biggest number (33,333 runs due in one second → the top-of-hour burst), or
• the interviewer keeps pointing at.

Not the part you know best. If you love parsers, cron expressions are tempting, and they're the least interesting box on the board.

Predict: you get one deep dive. From these five (the job-definition API, the run claim, the top-of-hour burst, run-log storage, cron parsing), which do you propose, and how do you say it?

Deep dive: one WHERE clause keeps the promise

"Never overlap" comes down to one idea: make starting a run a conditional write on the job's row. The database gives the run a lease only if nothing else holds one (or the holder's lease has expired) and this run hasn't already finished, and it tells you whether it did. Every claim also bumps a fence number. Finishing works the same way: only the worker holding the current fence can record the run as done.

SQLite stands in for PostgreSQL here so you can run it (RETURNING needs SQLite 3.35 or newer; check sqlite3.sqlite_version). Run ids are full UTC timestamps, so they keep increasing across midnight; 'HH:MM' strings would make the next day's 00:00 run look older than yesterday's 23:00 and refuse it forever.

import sqlite3

db = sqlite3.connect(":memory:", isolation_level=None)   # autocommit
db.execute("""CREATE TABLE jobs (
    job_id        TEXT PRIMARY KEY,
    running_run   TEXT,               -- the run (a UTC timestamp) that holds the lease
    lease_until   REAL,
    fence         INTEGER NOT NULL,   -- goes up on every claim
    last_finished TEXT NOT NULL)""")
db.execute("INSERT INTO jobs VALUES ('hourly-report', NULL, NULL, 0, '2026-09-24T08:00Z')")

CLAIM = """UPDATE jobs SET running_run = :run, lease_until = :now + 90, fence = fence + 1
           WHERE job_id = :job
             AND (running_run IS NULL OR lease_until < :now)
             AND last_finished < :run
           RETURNING fence"""
FINISH = """UPDATE jobs SET running_run = NULL, last_finished = :run
            WHERE job_id = :job AND running_run = :run AND fence = :fence"""

def claim(job, run, now):
    row = db.execute(CLAIM, {"job": job, "run": run, "now": now}).fetchone()
    return row[0] if row else None          # the fence, or None if refused

def finish(job, run, fence):
    return db.execute(FINISH, {"job": job, "run": run, "fence": fence}).rowcount == 1

RUN = "2026-09-24T09:00Z"
t = 32_400.0                                  # 09:00:00, as seconds since midnight
a = claim("hourly-report", RUN, t)            # worker A
print(a)                                      # 1: A holds the lease
print(claim("hourly-report", RUN, t + 0.004)) # None: a duplicate message, 4 ms later
b = claim("hourly-report", RUN, t + 91)       # A froze; the lease expired; a retry takes over
print(b)                                      # 2
print(finish("hourly-report", RUN, a))        # False: A woke up holding a stale fence
print(finish("hourly-report", RUN, b))        # True
print(claim("hourly-report", RUN, t + 200))   # None: this run already finished

Why it holds under concurrency. In PostgreSQL's default Read Committed level, when two transactions update the same row, the second waits for the first to commit, then re-evaluates its WHERE clause against the new version of the row (PostgreSQL docs). If two workers take duplicate messages for the same run in the same millisecond, the second update waits, finds the lease taken, matches nothing and returns no fence. There's no "read, check in the app, then write" gap for a second worker to slip through.

Two production details, each worth one sentence in the interview:

• Use the database's clock (now() in PostgreSQL) for lease_until, not each worker's. A worker whose clock runs fast would otherwise treat other workers' leases as expired early.
• Expired leases need no cleanup to be safe: the WHERE clause already treats them as free. A background reaper only re-enqueues their runs so they get retried.

The sentence to say: "The invariant lives in two statements. Everything else, the scheduler, the queues and the workers included, can crash or repeat itself without breaking it."

Move 4: Read the interjection, then keep or change

Pressure: "Hmm. Why not keep the schedule in a Redis sorted set? It's faster."

Interviewers interrupt for different reasons, and they rarely say which:

You can't reliably tell a probe from a hint by tone, and you don't need to. The move is the same: check the concern against the requirements and the numbers, then decide. Keep the design with reasons, or change it with reasons. What loses points is changing it without reasons (caving) or keeping it without reasons (digging in).

The response takes about a minute and has four steps:

1. Restate the concern concretely: "You're asking whether Redis would make the schedule faster."
2. Check it against the board.
3. Decide: keep, modify or switch.
4. Cost: what your decision gives up, and what would change your mind.

Pushback 1: a probe of a sound decision

Interviewer: "Why not keep the schedule in a Redis sorted set? It's faster."

You: "You're suggesting Redis for speed. Checking the board: we write about 2,000 times a second at the worst moment, which PostgreSQL handles, so speed isn't our constraint. The constraints are 'never overlap' and 'never skip', so an acknowledged claim, and every registered job, has to survive a failover. Redis replicates asynchronously, and its docs say even WAIT doesn't make it strongly consistent: acknowledged writes can still be lost in a failover. A lost lease means a second worker can start the same job. So the schedule and the leases stay in Postgres. The cost is a slower write path than Redis, which nobody notices at 2,000 a second. If the write rate grew by orders of magnitude, I'd partition the jobs across Postgres primaries before giving up durability. Redis could still hold a cache of the next minute's due runs, rebuilt from Postgres if it's lost."

The Redis claim comes straight from the Redis replication docs. Notice that the answer kept the design without dismissing the question: it said where Redis could fit.

Pushback 2: a real gap

Interviewer: "A worker freezes for 90 seconds in a garbage-collection pause while it holds a run. Then what?"

You: "That's a real gap. At 90 seconds the lease expires, another worker claims the run, and the frozen worker wakes up still running it. A lease tells a healthy worker when to stop: it times the lease on its own monotonic clock and stops well before expiry. A frozen worker can't check anything, though, and a pause can fall between a check and a write. The fence number is what stops its stale writes: our finish already refuses the old fence, and every write the job makes to shared storage must carry the fence, so the storage rejects any fence older than the newest it has seen. Jobs whose targets can't check a fence must be safe to run twice. Cost: teams pass the fence through or make jobs idempotent, and the two runs can still overlap in time; the fence only stops the stale writes from landing, and only where they're checked."

This is the fencing-token technique; Martin Kleppmann has described it with exactly this garbage-collection example. Here the right move was to change the design and say so plainly. Holding your ground on a real gap isn't confidence; it's a miss.

Pushback 3: partly right

This one arrives at 0:36, when the wrap-up lists the top risks:

Interviewer: "Isn't your database a single point of failure for every team's jobs?"

You: "Partly. The schedulers and workers are stateless. The state is one Postgres primary with a synchronous standby and automatic failover, so losing the primary costs a failover, not acknowledged claims, as long as failover promotes the most up-to-date standby (Patroni's quorum mode, for example, checks this). While no primary is available, I fail closed: no claims succeed, so nothing starts without a lease. Failing open, starting runs without one, would break 'never overlap' for every job at once. Cost: runs due during the outage start late, possibly past the 60-second window. Nothing is skipped, though, because next_run_at only advances after a run is enqueued, so the schedulers catch up afterwards. Is a late start during a failover acceptable to the teams? If not, the next step is a faster failover, not failing open."

Fail open or fail closed is a decision, not a detail, and the requirement picks it. Here, an unleased run could overlap with another, so closed wins. A rate limiter in front of a like button would fail open, because letting a few extra likes through hurts nobody.

Hints are gifts

If the interviewer asks about the top of the hour while you're polishing the job-definition API, drop the API: "Good, the burst is the harder problem. Let me go there now and come back to the API if there's time." Insisting on finishing your current thought costs you the hint and the time.

When you don't know

Say what you don't know, reason from what you do know, and say how you'd find out:

"I don't remember exactly when our queue redelivers a message that nobody has acknowledged. If it redelivers while a slow worker is still running the job, we get a duplicate delivery; the claim refuses it, because the lease is still held. So correctness doesn't depend on the answer, only wasted work does. I'd check the queue's docs."

That's one honest unknown, bounded and with a plan, instead of a bluff the interviewer can puncture.

Predict: classify each of these, and give your first sentence. (a) "We're at 35 minutes." (b) "What about daylight saving time?" (c) "Couldn't two workers start the same job?"

Move 5: Re-derive out loud when the facts change

Pressure: 0:30. "Actually, each team may have at most 200 runs going at once."

The weak responses are panic ("Oh… then we'd need a different database?") and pretending nothing changed. The strong one has a shape: say what depends on the new fact, re-derive the numbers, update the board.

"That changes the claim, not the schedule. What depends on it: claiming (it now needs a team slot too), finishing and lease expiry (both must give the slot back). What doesn't: the scheduler, the queues and the history, as long as each team's limit covers its load, which is the next thing to check.

The limit is a count: one row per team with running and a maximum. A claim takes a slot with a conditional increment, adding 1 only while running is below the maximum, in the same transaction as the job's lease. Both rows live on the one primary, which is what makes that a single transaction. Runs that don't get a slot stay queued for their team instead of retrying in a tight loop.

Numbers: say the largest team owns 10% of runs, 200,000 a day. Over the whole day that's about 420 runs going at once on average (200,000 ÷ 86,400 × 180 s), so a limit of 200 is below its average load: 200 slots of 3-minute runs start about 67 a minute, 4,000 an hour, while 8,333 an hour arrive. Its backlog grows by about 4,300 an hour and never drains. Starting its top-of-hour runs within 60 seconds would take about 3,600 slots (3,333 due plus about 250 already running). Which do you want for that team: a higher limit, or rejecting its extra runs?"

That number comes from Little's law, covered in Key Concepts & Terminology: the average number of runs in progress equals their start rate times how long each lasts, L = λW. Here λ is 200,000 a day (about 2.3 a second) and W is 180 seconds, so L is about 420. Checked the other way, a limit fixes L at 200, so the most the team can start is λ = L ÷ W, about 67 a minute. Always check a limit against the whole day's load first, then against the burst.

Is one counter row a hot spot? Each update keeps the row locked until its transaction commits. With the synchronous-standby round trip, say 2 ms per transaction, one row tops out around 500 updates a second. With the limit binding, this row sees about one update per start and one per finish, roughly 2 a second; even with no limit it would see at most that team's 56 claims a second at the top of the hour, plus its finishes. One row is fine. Near the ceiling, you'd split the count across a few rows.

Then change the board: a new line in the numbers column ("team slots: 1 row per team; largest team needs about 420 on average, about 3,600 at hh:00") and the slot step on the run path. Here is the mechanism:

import sqlite3

db = sqlite3.connect(":memory:", isolation_level=None)
db.execute("""CREATE TABLE teams (team TEXT PRIMARY KEY,
              running INTEGER NOT NULL, max_running INTEGER NOT NULL)""")
db.execute("INSERT INTO teams VALUES ('payments', 198, 200)")

TAKE_SLOT = """UPDATE teams SET running = running + 1
               WHERE team = :team AND running < max_running"""
GIVE_BACK = "UPDATE teams SET running = running - 1 WHERE team = :team AND running > 0"

def take_slot(team):
    return db.execute(TAKE_SLOT, {"team": team}).rowcount == 1

print(take_slot("payments"), take_slot("payments"), take_slot("payments"))   # True True False
print(db.execute("SELECT running FROM teams").fetchone()[0])                  # 200: never above
db.execute(GIVE_BACK, {"team": "payments"})                                   # a run finished
print(take_slot("payments"))                                                  # True

Why it works: the check and the increment are one statement on one row, so there's no moment where two workers both see "199 running". In PostgreSQL the second writer waits, then re-checks running < max_running against the committed value, exactly as with the lease.

⚠️ The version that looks equivalent isn't: SELECT running, check it in application code, then an UPDATE that adds 1 with no condition. Two workers can both read 199, both pass the check and both add, and the team runs 201. The condition has to be in the write.

When you were the one who was wrong

Sometimes you catch your own mistake. Own it in one sentence and fix it: "Correction: I said one row could take thousands of updates a second, but the lock is held through the commit round trip, so it's hundreds. We need about 2, so the decision stands." No long apology, and no quiet redrawing in the hope that nobody noticed. Interviewers notice.

Your turn: 0:37, in the wrap-up. "What changes at 10×? Twenty million runs a day, still 40% at the top of the hour." What changes, what doesn't, and what are the new numbers?

Move 6: Score it like an interviewer

Pressure: the mock ends. "That went OK, I think." A feeling can't tell you what to fix.

Score five rows from 1 to 4. This is a practice rubric, not any company's hiring scorecard (companies use their own); it covers what this course has asked you to do.

Every score needs evidence: a timestamp and what was said or drawn. "Trade-offs: 3" is an opinion. "Trade-offs: 3, four parts for the lease and for replication, but at 0:12 the queues appeared with no reason" is something you can fix.

Scoring the two runs you've seen:

Even a strong run has a lowest row. That's the point: the next mock targets it.

The 15-minute debrief

1. Timeline. Write down the clock time you hit each checkpoint (0:10, 0:20, 0:35) next to the plan.
2. Decisions. List every decision you said aloud, and mark which ones got all four parts.
3. Interjections. For each one: what it was (hint, probe, new fact, failure, time), what you did, what you'd do now.
4. Score the five rows, each with evidence.
5. One micro-goal for the next mock: the lowest row, written as a behavior you can check. "Every box I draw gets a reason in the same breath", not "better trade-offs". One, not five.

Keep a log so you can see the trend:

🧠 A mock without a debrief mostly rehearses the habits you already have. The micro-goal is what makes mock 3 different from mock 2.

Your turn: debrief notes from a mock on a chat app. Requirements done at 0:09; path complete at 0:21; a deep dive on message ordering; wrap-up at 0:35. Seven decisions, six of them in four parts. At 0:24 the interviewer asked "why not deliver through a queue per user?"; you said "sure, that works too" and redrew the design around it. At 0:33, "what if a device is offline for a week?" got "we'd handle that" and a move to the next topic. Which row is lowest, and what's the micro-goal?

Final round: three prompt cards

Real prompts don't say which move they need. Run each card as a 45-minute mock on the course's clock. Short on time? Run only Scope and Sketch and stop at the 0:20 checkpoint. If a friend holds the card, they reveal the hidden facts; if you're alone, open them only at the moment you'd have asked. Then open "What a strong run decides" and score yourself with the rubric.

Card 1: a folder on every device

"Design a file sync service: a folder that stays the same on all of a user's devices."

Card 2: restaurants near me

"Design the 'restaurants near me' search for a food app."

Card 3: the last ten seconds of an auction

"Design the bidding service for an online auction site."

Cheat sheet: pressure → move → cost

Before moving on, run one timed mock this week: a card above, or a design from this course you haven't yet practiced aloud, such as the URL shortener, the rate limiter, the news feed, video streaming or chat. Record it. Then, from a blank board, explain aloud as you would in the wrap-up at 0:35: the three decisions that mattered, the requirement each one served, what each one cost, and what would make you change it. If that takes you two minutes and no notes, you're ready for the real room.

For the rest of final prep (consistent hashing, consensus, sagas and a checklist), see Advanced Topics & Final Prep.