Pacing the 45-Minute Staff Interview

Chapter 19 of Part III, Interview Mastery & The Staff Evaluator. The next chapter is What Interviewers Are Actually Evaluating.

Part III — Interview Mastery & The Staff Evaluator

Forty-five minutes is not enough time to demonstrate everything you know.

That is not a bug. It is the design.

The system design interview is not testing how much ground you can cover. It is testing whether you can prioritize ruthlessly under time pressure — because that is exactly what Staff engineers do every day. You have a limited runway. The design is underspecified. The tradeoffs are real and the clock is running. What do you do first?

The engineers who fail Staff loops almost always fail on pacing. Not on knowledge. They spend twelve minutes on requirements. Eight minutes on the algorithm everyone already knows. Three minutes on the interesting part — the part that would have earned the hire — before the interviewer says "we're running short on time, let's wrap up." The debrief reads: "Strong technical knowledge. Didn't demonstrate L6 thinking."

What they needed was not more preparation. They needed a different framework for the 45 minutes.

This chapter is that framework.

The Hidden Evaluation

Before the pacing framework, understand what you are actually being evaluated on.

The interviewer is not filling in a scorecard as you speak. They are running a parallel process: every time you say something, they are classifying it. Does this signal ownership or implementation? Does this signal system thinking or solution thinking? Does this candidate see failure modes or only happy paths?

The evaluation happens at six signal levels, and the level that determines your hire-or-no-hire is almost never the one you think it is.

Signal 1 — Problem Framing. Did you name the intent before drawing? Did your clarifying questions change the architecture, or did they just confirm the plan you already had? L5: asks clarifying questions, then draws what they were already planning. L6: asks one question, hears the answer, and says "that changes the entire architecture — let me explain why."

Signal 2 — Tradeoffs. Did you name who pays? Did you commit? L5: lists pros and cons of both options and waits. L6: names the tradeoff, names the stakeholder who absorbs the cost, commits to a position, and acknowledges what the committed position gives up.

Signal 3 — Scalability. Did you give numbers? L5: "We can add more replicas." L6: "Scatter-gather across 64 shards means p99 response time equals the max of 64 shard p99s. At 10ms median per shard, your scatter-gather p99 is 40–50ms, not 10ms. That's the ongoing tax — I want to make sure the interviewer agrees that tax is acceptable before we commit to this design."

Signal 4 — Failure modes. Did you surface failure before being asked? L5: handles failures when the interviewer asks "what if X fails?" L6: pre-empts failures before they are asked. The difference is not about what you know — it is about what you volunteer. Every time you name a failure mode before being asked, the interviewer's internal signal meter goes up.

Signal 5 — Ownership. Did you name who owns each component? Who gets paged when it fails? L5: produces a technically correct design with no owner. L6: after describing each component, says "the team that owns this also owns the runbook, the alert thresholds, and the decision about whether to fail-open or fail-closed during degradation."

Signal 6 — Clarity. Can you be interrupted at any point in your presentation and pick back up coherently? L5: the design only makes sense if you heard it from the beginning. L6: at any point in the interview, if the interviewer says "stop — tell me what you've decided so far and why," the answer is a clear, defensible position.

Most candidates optimize for Signal 3 (scalability numbers). Experienced interviewers weight Signals 1, 4, and 5 most heavily — because those are the signals that are hardest to fake and most predictive of actual Staff-level behavior.

STAFF MOVE

Senior: Completes the architecture, then waits for the interviewer to ask about failure modes.

Staff: After sketching the high-level architecture, says: "Before we go deeper — let me name the three places this breaks in production and how I'd handle each. Then you can tell me which one you want to spend time on."

Why: Volunteering failure modes before being asked is the single clearest signal that you've operated systems, not just designed them.

The Four Phases

A 45-minute Staff interview has four phases. The proportions are not suggestions — they are the difference between demonstrating L5 thinking and demonstrating L6 thinking.

Phase 1: Commit to Intent	Phase 2: High-Level Design	Phase 3: Deep Dive	Phase 4: Wrap and Synthesize
2–3 minutes	7–10 minutes	25–30 minutes	3–5 minutes

Most candidates invert this. They spend 20+ minutes on Phases 1 and 2 — requirements and high-level design — and have 15 minutes left for Phase 3. Phase 3 is where every L6 signal is demonstrated. Running out of time before reaching Phase 3 is the most common pacing failure.

The target: exit Phase 2 no later than the 12-minute mark. Everything before that is table stakes.

Phase 1: Commit to Intent (2–3 Minutes)

The first signal the interviewer receives is not your architecture. It is whether you clarify intent before drawing.

The standard pacing error: the candidate spends 5–8 minutes on requirements. They enumerate functional requirements one by one, ask about each edge case, and fill the whiteboard with bullet points. This signals L5 thinking — it demonstrates thoroughness, not judgment. Staff engineers don't catalog requirements. They identify the constraint that shapes everything else.

The Phase 1 formula:

State functional requirements in one sentence (30 seconds). Invest the remaining time on the one non-functional constraint that drives the entire design.

For rate limiting: "We're limiting request rates per client. The constraint I care about: is this abuse protection, billing enforcement, or multi-tenant fairness? These have incompatible failure modes — I can't design one system that serves all three correctly. I'll assume abuse protection."

For payments: "We're processing e-commerce payments. The constraint: correctness over throughput. An unbalanced ledger is a regulatory violation. Every design decision follows from that."

For chat: "We're building consumer messaging for 100M users. The constraint: delivery guarantee with offline support. The WebSocket layer is an optimization — I'll design the store-and-forward path first, because that's what ensures correctness when the real-time path fails."

Notice the pattern: functional requirement in one sentence, then immediately commit to the constraint that drives the architecture. This is not the same as asking the interviewer "what are the requirements?" and transcribing the answer. It is naming the constraint that you, as a Staff engineer, have identified as the load-bearing beam of the design.

What if you're wrong about the intent?

Good. The interviewer will correct you, and your response to the correction signals L6 thinking: "That changes the architecture significantly — let me show you how." This is a better signal than spending five minutes asking about every edge case before committing.

The two clarifying questions worth asking:

Not every question is worth the time it costs. Two questions are almost always worth asking:

"What's the scale target — order of magnitude?" (Shapes whether you need sharding, distributed state, edge caching.)
"Is there an existing system we're replacing, or greenfield?" (Shapes migration constraints and organizational context.)

Everything else — "Do we need mobile support? What about internationalization? What about audit logs?" — can be assumed and stated: "I'll assume we need mobile support and I'll note where the design changes for that."

CONTROVERSIAL OPINION

"The most common Phase 1 mistake is asking too many questions. Every question costs 60–90 seconds. Five questions is 5–7 minutes of interview time that could have been Phase 3 depth."

Interviewers are not grading you on the completeness of your requirements. They are watching whether you can identify the one constraint that drives everything else and commit to it. A candidate who says "I'll assume X, Y, Z, and note where my design changes if any of those are wrong" demonstrates more judgment than a candidate who asks about each assumption individually.

Phase 2: High-Level Design (7–10 Minutes)

Phase 2 has one goal: establish the architecture skeleton so Phase 3 has something to go deep on.

Draw at most eight nodes. Name specific technologies (Redis, not "cache"; PostgreSQL, not "database"; Kafka, not "message queue"). State failure behavior proactively for the most critical component. Then stop.

The Phase 2 mistake is continuing to add components. Each component you add in Phase 2 is a component you're not going deep on in Phase 3. The interviewer is not counting boxes. They are waiting for the moment you move from architecture to reasoning.

The 90-second architecture walk:

After drawing, walk the request flow in 90 seconds — not as a tour of your diagram, but as a sequence of decisions:

"Request comes in at the gateway. The rate limit check happens here, in-process with the gateway middleware — not as a separate network call, because adding network hops to the critical path is a design anti-pattern. Local token bucket check: sub-millisecond. If tokens are available, request passes to the backend. If not, 429 plus a Retry-After header. In the background, every 500ms, local counters sync to Redis for cross-instance coordination. Redis is never in the critical path — only in the coordination path."

Notice what this achieves: it describes the design AND names a design principle ("adding network hops to the critical path is a design anti-pattern") that signals L6 thinking. The principle is more important than the diagram.

The Phase 2 handoff move:

At the end of Phase 2, before the interviewer steers the conversation, name the fault lines explicitly:

"The basic architecture is straightforward — this part is well understood. The three places where the real tradeoffs live are: what happens when Redis fails (fail-open vs fail-closed — not an obvious decision), distributed coordination across multiple gateway instances (where accuracy and latency trade off), and policy management as an organizational problem (the technical implementation is done in 2 weeks; getting 15 product teams to maintain correct policies is a 6-month problem). Which of those do you want to go into first?"

This move does four things simultaneously: it signals you know the basics are table stakes, it names specific fault lines by name, it invites the interviewer into the direction of Phase 3, and it demonstrates organizational awareness — which is the signal most closely correlated with Staff-level decisions.

STAFF MOVE

Senior: Continues adding components after the basic architecture is established — caching layer, CDN, monitoring system, analytics pipeline.

Staff: After drawing 6–8 nodes: "The architecture is straightforward — this is where it gets interesting." Then pivots immediately to the fault lines.

Why: Every component added in Phase 2 is a component not going deep on in Phase 3. The interviewer is waiting for the pivot to depth. The candidate who pivots first demonstrates that they know the basic architecture is not the interview.

Phase 3: Deep Dive (25–30 Minutes)

Phase 3 is the interview. Everything before it is setup.

Phase 3 has one rule: go deep on two or three fault lines rather than shallow on six. The candidate who covers six topics at surface level is demonstrating breadth. The candidate who covers two topics with quantitative reasoning, named stakeholders, explicit failure modes, and committed positions is demonstrating Level 6.

The Phase 3 structure for each fault line:

For every fault line you go deep on, follow this four-step pattern:

State the tension. Name the two forces pulling in opposite directions. Not "it's a tradeoff" — name the specific tension: "Accuracy pulls toward centralized state. Latency pulls toward distributed state. The same component can't optimize both."
Name who pays for each option. Not "there are advantages and disadvantages." Name the stakeholder: "Centralized Redis: users pay in latency. Distributed local counters: engineering pays in drift debugging. I need to decide which of those costs is more acceptable before I pick an architecture."
Commit to a position. Not "it depends." A committed position with a named condition: "For abuse protection, I'll go local-first with bounded drift. The drift bound with 10 instances syncing every 5 seconds is approximately 83 extra requests per window — about 8% over the configured limit. For abuse protection where limits are set conservatively, that's acceptable noise. For billing enforcement, I'd flip to centralized because the 10% overshoot is revenue exposure."
Name what breaks. After committing, stress-test with failure: "If Redis goes down while I'm running local-first, the risk is silent fail-open — instances stop coordinating and each enforces its own local limit, which is effectively no coordination. The mitigation: bypass_rate metric alerts within 30 seconds if enforcement rate drops below 95%. The runbook: check Redis health, escalate to on-call if unresolved in 5 minutes."

This pattern — tension, who pays, commit, what breaks — is the Staff Decision Loop compressed into Phase 3 pacing. Run it for every fault line.

Choosing which fault line to lead with:

If the interviewer gives you a choice, lead with the fault line that surfaces the most organizational complexity. Not the most technically impressive one — the one that demonstrates you think beyond the system to the team that owns it.

For rate limiting: lead with fail-open vs fail-closed — it forces an organizational conversation about who signs off on "we might let some abuse through" vs "we might block legitimate users."

For payments: lead with the pending resolution state — it is the fault line that most clearly demonstrates you've operated payment systems rather than designed them theoretically.

For chat: lead with store-and-forward as the primary path — it reframes the entire architecture from "real-time system" to "guaranteed delivery system with a real-time optimization layer."

The fault line you lead with tells the interviewer what you consider most important. That choice is itself a signal.

The Pivot

At some point in Phase 3, the interviewer will pivot. They will ask a question that pulls you away from the thread you were developing. This is not a problem. This is the interview testing a different dimension.

The pivot comes in three forms, and each requires a different response.

Pivot Form 1: The Deepening. The interviewer asks you to go deeper on something you just said.

"You mentioned token leasing. Walk me through exactly how that works and what happens when a gateway instance crashes before returning the tokens."

This is an invitation to show quantitative depth. Accept it fully. Stop whatever you were doing and go deep. This is not a distraction — it is an opportunity to demonstrate the exact kind of reasoning that separates levels.

Your response: go deep with specifics. "Token leasing: each instance requests a batch of N tokens from Redis rather than decrementing per-request. With 1,000 requests per minute and 10 instances syncing every 500ms, each lease is approximately 8–9 tokens. If an instance crashes before returning remaining tokens, those tokens are stranded — effectively lost from the window's budget. The mitigation: set lease size to the expected request rate per instance per sync interval, plus a 20% safety margin. Stranded tokens are bounded by the lease size — at most 11 tokens per crashed instance per window. Acceptable for abuse protection."

Pivot Form 2: The Stress Test. The interviewer introduces a failure scenario.

"Your primary Redis cluster goes down for 30 seconds during peak traffic. Walk me through exactly what happens, minute by minute."

This is the most valuable pivot in any interview. Every Staff-level answer to a stress test follows the same structure: immediate failure response, degraded mode, recovery path, and retrospective signal (what metric would have warned you this was coming).

Your response structure: "Second 0: Redis connections start returning timeouts. The rate limit middleware has a 5–10ms circuit break threshold — aggressive, because I don't want the rate limiter to become a latency amplifier. Second 1: circuit breaker opens, middleware switches to local-only enforcement. Second 1–30: each instance enforces its own local limit independently. Effective enforcement per identity is approximately 10x configured limits — 10 instances, no coordination. This is acceptable for abuse protection: we're still blocking extreme abusers, just with 10x the drift. Second 30: Redis recovers, circuit breaker detects healthy connection, coordination resumes. The recovery: no thundering herd — instances resume async sync naturally. The signal: bypass_rate metric should have started rising at second 1. If we're paged at second 31, the alert threshold is wrong — it should fire within 30 seconds of the anomaly."

Pivot Form 3: The Tangent. The interviewer pivots to a topic that seems unrelated.

"Let's switch gears — how would you handle multi-region deployment of this rate limiter?"

This is testing breadth, and it is a trap. The L5 response: drops everything and spends 10 minutes on multi-region design. The L6 response: brings the multi-region question back to the principles already established.

"Multi-region is actually a direct extension of the local-first vs centralized tradeoff we just discussed. Cross-region coordination for abuse protection has 50–200ms of latency — which means centralized global enforcement is off the table for anything in the critical path. Per-region enforcement with async reconciliation is the right model. A user who distributes their traffic across regions effectively gets Nx their regional limit — that's a known property of distributed rate limiting at global scale, and for abuse protection it's acceptable. For billing enforcement, we'd scope quotas per region rather than globally — 'this user has 1,000 API calls in us-east-1 and 1,000 in eu-west-1' rather than 'this user has 2,000 globally.' The consistency tradeoff is the same one we discussed — the mechanism is just applied at regional granularity."

This response uses the tangent as an opportunity to demonstrate that the earlier principles weren't just memorized patterns — they're a framework that applies to new situations.

Recovery Moves

Every candidate hits a moment where they don't know something. The question is not whether this will happen — it is what you do when it does.

The L5 response to not knowing: silence, a vague answer, or visible anxiety.

The L6 response: name it, reason from principles, and get back on track.

Recovery Move 1: Reason From Principles

When you don't know a specific number or implementation detail:

"I don't have the exact figure in front of me — but I can reason about it. Cassandra write throughput is typically in the low tens of thousands of writes per second per node, depending on replication factor and write consistency level. With RF=3 and LOCAL_QUORUM, you're roughly halving that. If we need 50,000 writes per second, I'd start with 4–6 nodes and scale based on observed write latency. Does that directional reasoning work, or do you want me to nail down a specific number?"

This response demonstrates something more valuable than the number: it shows you can reason under uncertainty. That is a Staff-level behavior. Candidates who can only answer questions they have memorized answers to are not demonstrating L6 judgment.

Recovery Move 2: Name the Unknown

When you hit a design decision you genuinely don't know how to make:

"This is an area where I'd want to dig into the specifics before committing — the right answer depends on whether the write pattern is bursty or steady, which I don't have data on. Here's how I'd think about it: if bursty, I'd lean toward X because Y. If steady, I'd lean toward the opposite because Z. What's the traffic pattern here?"

Naming the unknown is not a weakness. It is the same skill that makes Staff engineers valuable in production: knowing what you know, knowing what you don't, and being explicit about the boundary.

Recovery Move 3: The Reframe

When the interviewer catches a design flaw:

"You're right — I hadn't accounted for that. Let me think through it."

Then think through it out loud. Don't apologize. Don't go silent. The interviewer already knows you made an error — what they're evaluating now is how you respond to being wrong. Staff engineers are wrong sometimes. The signal is how quickly they incorporate new information and how they adjust their position.

A design that gets corrected and then improved is a better interview signal than a design that was right from the start — because the correction and improvement demonstrate exactly the kind of reasoning that Staff engineers exercise in production incidents and architecture reviews.

STAFF MOVE

Senior: When caught in a design flaw, says "good point" and makes the minimal fix without examining the root cause.

Staff: "You're right — and that flaw probably propagates. If I handle timeouts wrong here, the reconciliation pipeline will also be wrong because it's assuming the same state model. Let me fix the root assumption and then show how it changes both."

Why: Staff engineers look for the systemic implication of a flaw, not just the local fix.

Phase 4: Wrap and Synthesize (3–5 Minutes)

The Phase 4 mistake: re-stating the architecture. The interviewer already heard the architecture. They don't need a summary.

Phase 4 is for synthesis — one insight that wasn't obvious at the start, stated at the level of a principle rather than an implementation.

The synthesis formula: "The reason [system] is hard is not [what everyone thinks it is]. The actual challenge is [organizational/systemic insight]."

For rate limiting: "The reason rate limiting is hard is not the algorithm. Token bucket is solved. The actual challenge is organizational: 15 product teams setting limits too high because they fear blocking customers, and nobody maintaining them as usage patterns change. The enforcement infrastructure is a 2-week project. The governance model is a 6-month project."

For payments: "The reason payment systems fail in production is not transaction processing — Stripe handles that. The actual failure mode is reconciliation: the system that detects when our ledger disagrees with the provider. At $500M per month, a 0.01% discrepancy rate is $50K of unresolved money per month. The payment flow is the easy part. Reconciliation is where Staff engineers earn their pay."

For chat: "The reason chat systems are hard is not WebSocket protocol. The actual challenge is the delivery guarantee contract across failure scenarios that don't exist in demos — offline devices, dropped connections, key rotation storms when a group member is removed. Design for those cases first. The happy path designs itself."

The synthesis should feel like a lesson. Something the interviewer might actually write down or repeat to a candidate they're evaluating next week.

The organizational closer:

End every Phase 4 with an ownership statement — not a technical one.

"If I were building this at a company I joined tomorrow, the first two conversations I'd have are not with the engineering team. I'd talk to finance about the reconciliation SLA — how quickly do they need discrepancies resolved, and what's the dollar threshold that triggers escalation vs manual review. Then I'd talk to the product team about the pending resolution user experience — what exactly do we show a user whose payment is in PENDING_RESOLUTION state, and who owns that decision. Those conversations shape the system more than any technical choice I make in the next six months."

This kind of closer does something no technical summary can do: it demonstrates that you understand the system as an organizational artifact, not just a technical one. That understanding is the thing that separates Staff engineers from Senior engineers in practice.

The 45-Minute Map

Put all four phases together with a complete time map:

Time	Phase	What's Happening	What Signal You're Sending
0:00–0:30	Phase 1	State functional requirement in one sentence	You know the basics; you're not going to waste time on them
0:30–2:30	Phase 1	Name the load-bearing constraint; commit to an intent	First L6 signal: framing before solving
2:30–4:00	Phase 2	Draw the architecture: <= 8 nodes, named technologies	Technical fluency
4:00–6:00	Phase 2	Walk the request flow: 90 seconds; name one design principle	Second L6 signal: reasoning, not just drawing
6:00–10:00	Phase 2	Name 2–3 fault lines; invite the interviewer to steer	Third L6 signal: you know the interesting parts
10:00–12:00	Phase 2	Volunteer one failure mode without being asked	Fourth L6 signal: operational experience
12:00–35:00	Phase 3	Go deep: tension, who pays, commit, what breaks	Primary evaluation window
35:00–40:00	Phase 3	Handle pivots; demonstrate recovery moves	Judgment under uncertainty
40:00–43:00	Phase 4	Synthesis: one principle-level insight	What you'll take out of the room
43:00–45:00	Phase 4	Organizational closer: who owns what, who gets paged	Fifth L6 signal: system as organizational artifact

The window between minute 12 and minute 40 is the interview. Everything outside that window is setup and synthesis. Every minute you spend before minute 12 is a minute borrowed from Phase 3.

The Timing Mistakes — In Order of Frequency

Mistake 1: The Requirements Spiral (most common)

Spending 10+ minutes on requirements. Asking about every edge case. Treating completeness as a virtue. The result: you enter Phase 3 at minute 20 with 15 minutes left. Fifteen minutes is not enough to demonstrate depth on even one fault line.

Fix: cap Phase 1 at 3 minutes. State what you're assuming, note where the design changes if the assumption is wrong, and move to architecture. If you're wrong, the interviewer will tell you.

Mistake 2: The Algorithm Deep Dive (second most common)

Spending 8+ minutes explaining the Token Bucket algorithm, or Raft consensus, or consistent hashing ring mechanics. These are table stakes. The interviewer already knows them. Explaining them at length signals that you are optimizing for appearing knowledgeable rather than demonstrating judgment.

Fix: name the algorithm choice, state why in one sentence, and redirect: "I'd use token bucket — it handles burst traffic cleanly. The algorithm is the least interesting decision. The interesting decisions are in the failure modes. Let me show you those."

Mistake 3: No Commitment (third most common)

Spending Phase 3 presenting balanced options without picking one. "We could do X, which has pros A, B, C. Or we could do Y, which has pros D, E, F. It really depends on the specific use case." The interviewer is waiting for you to pick. Every sentence that doesn't end in a committed position is a sentence that didn't signal L6.

Fix: commit, then qualify. "I'd pick X. The reason is [one sentence]. The cost is [one sentence]. If [specific condition], I'd revisit and switch to Y." A committed position you can defend is always better than a balanced presentation of options.

Mistake 4: No Numbers (fourth most common)

Scalability and failure claims without quantitative backing. "Redis might add some latency." "We could have hot shards." "The cache might get stale." Vague claims signal L5. Numbers signal operational experience.

Fix: carry five or six key numbers for any system you're likely to be asked about. For rate limiting: Redis p99 latency 5–10ms, local bucket check ~0ms, worst-case drift with 10 nodes syncing every 5s is ~83 extra requests per window. For chat: WebSocket connections per gateway ~500K, presence at 50M users requires 20 Redis shards, fan-out threshold ~256 members. For payments: reconciliation every 15 minutes, 0.01% discrepancy at $500M/month is $50K. These numbers give your positions specificity and credibility.

Mistake 5: The Technical Closer (fifth most common)

Ending Phase 4 with a technical summary. "In conclusion, we designed a local-first rate limiter with async Redis coordination and fail-open behavior." The interviewer already knows this. They were in the room.

Fix: close with an organizational insight. Who owns the system? What's the first non-engineering conversation you'd have? What organizational failure mode will materialize 18 months from now if the system is built correctly but operated incorrectly?

What Interviewers Actually Write Down

After the interview ends, the interviewer has to write a hire or no-hire recommendation, usually within an hour. They are trying to recall specific moments that justify their recommendation.

Here are the moments they write down from a strong hire:

"When I asked about fail-open vs fail-closed, they named the stakeholder who absorbs the cost before I asked — finance for billing, engineering for abuse protection."
"They proactively named the bypass-rate metric as the critical monitoring signal before I asked anything about monitoring."
"When I caught an error in their timeout handling, they immediately said the flaw probably propagates to the reconciliation pipeline — and fixed both."
"They asked to go into fan-out economics rather than WebSocket protocol. That's the L6 choice."
"The organizational closer at the end: 'the first conversation I'd have is with finance about the reconciliation SLA.' That's not something a senior engineer says."

And here are the moments they write down from a no-hire:

"Strong technical knowledge. Spent 15 minutes on algorithm selection."
"When asked about failure modes, waited for my question rather than volunteering."
"Gave the tradeoffs for both options without committing to either. Asked twice, still didn't commit."
"No numbers. 'Redis might add latency' — how much latency?"
"Technically correct design. No owner. No one gets paged."

The difference between these two lists is not knowledge. It is the five patterns this book has been building toward: naming intent before solving, finding the fault lines, naming who pays, making the call, and stress-testing with failure.

The interview is 45 minutes long. The Staff Decision Loop runs in about 90 seconds. You have time to run it at least twice — more, if your Phase 2 is disciplined.

That's the whole game.

STAFF CHECKLIST: Before Every System Design Interview

Can I state the design problem in one sentence — specific constraint, not topic?
Do I know which non-functional requirement drives the architecture?
Have I identified the 2–3 fault lines I want to spend Phase 3 on?
For each fault line, can I name the tension, name who pays, and commit to a position?
Do I have 3–5 numbers memorized for this system?
Can I name one failure mode without being asked within the first 12 minutes?
Do I have an organizational closer ready — who owns this, who gets paged, what organizational failure mode materializes 18 months post-launch?