Section A · Orient

The Design Interview & the Method

How a 60-minute data systems design discussion is actually graded, the repeatable method that keeps you structured, and how to defend a trade-off so a "it depends" becomes a decision.

How the 60 minutes flow

There's no fixed script, but these sessions move through recognizable phases. Knowing the shape lets you budget time and avoid the classic failure of designing a beautiful ingestion layer and never reaching the trade-offs that carry the score.

Phase	Rough time	What's happening
Framing	0–8 min	The interviewer gives a scenario ("design the data platform for product X"). Your job: ask clarifying questions and rough the requirements & scale before drawing.
High-level architecture	8–25 min	You sketch sources → ingestion → storage → processing → serving. Breadth first — get the whole platform on the board with the major choices flagged.
Trade-offs & deep dives	25–52 min	The interviewer pulls threads — CDC strategy, batch vs streaming, lake vs warehouse, build vs buy, a scaling bottleneck. This is most of the score.
Evolution & wrap	52–60 min	What breaks at 10×, what you'd migrate, cost control, and your questions for them.

Pace discipline

Spend the first 5–8 minutes on requirements and a back-of-envelope estimate — it feels slow, but it's what lets you justify every later decision ("streaming isn't worth it here because the freshness SLA is hourly and volume is modest"). Then get a complete, simple architecture on the board fast and invite the interviewer to steer: "there are real decisions at ingestion, at storage, and at the processing layer — where do you want to dig in?"

What the interviewer scores

The session feels open-ended, but the assessment is consistent. Interviewers look for:

Requirements first. Do you establish volume, freshness, consumers, correctness, and budget before architecting? Naming Kafka and Snowflake in the first minute is a red flag.
Structured breadth. Can you cover the whole platform — ingestion, storage, processing, serving, governance — without getting stuck in one corner?
Defended trade-offs. When you hit a fork, do you make the call and justify it against the requirements, or do you list options and stall?
Depth on the named topics. Ingestion and CDC especially — do you have real mechanisms (log-based CDC, snapshot-plus-stream, delivery guarantees), or hand-waving?
Cost & operability awareness. Do you weigh cost, lock-in, team size, and who operates this — not just throughput? This is the fastest tell of seniority.
Communication. Can the interviewer follow your diagram and your reasoning? Do you check in and let them steer?

Notice what's absent: a single "correct" architecture. Two candidates can design different platforms and both pass — if both fit the requirements and the trade-offs are honestly reasoned.

The six-step method

Run this on any scenario. It is the backbone of the whole guide, and it keeps you from the two failure modes — freezing, and rambling.

Requirements. Functional: what data, which sources, which consumers, which queries. Non-functional: volume/velocity/variety, freshness/latency SLA, availability, durability, consistency, budget, compliance. (Chapter 02.)
Estimate. Back-of-envelope: events/sec, bytes/day, storage with retention, read QPS, rough cost. Numbers turn opinions into decisions.
Architecture. Sketch sources → ingestion → storage → processing → serving, with orchestration and catalog/governance as cross-cutting layers underneath.
Decisions / trade-offs. Make the named calls — CDC strategy (Ch 04), batch vs streaming (Ch 05), lake vs warehouse vs lakehouse (Ch 06), build vs buy (Ch 07) — each tied back to a requirement.
Deep dives. Follow the interviewer into CDC correctness, hotspots and skew, exactly-once, schema evolution, failure. (Chapters 08, 09.)
Evolution. Scale 10×, name the first bottleneck, failure and DR, migration path, cost control.

The through-line

Every decision points back to step 1. "Because the freshness SLA is five minutes for fraud but daily for BI, I'd stream the fraud path and batch the rest" is a senior answer. "I'd use streaming because it's real-time" is not. Requirements are the argument you keep returning to.

Defending a trade-off

This interview is a series of forks, and the single most important skill is turning "it depends" into a defended decision. Use one repeatable sentence pattern whenever you hit a fork:

The decision sentence

"Given [the requirement that matters most here], I'd choose [option] over [alternative], because [how it satisfies the requirement]. The cost is [honest downside], which is acceptable because [context] — and I'd revisit it if [the condition that would flip the decision]."

That last clause — the condition that would flip your choice — is what separates a senior answer from a memorized one. It shows you understand the boundary of the decision, not just the decision. Each trade-off chapter (05, 06, 07) hands you a decision matrix and a "when to choose what" heuristic so you have the axes ready; the sentence above is how you deliver them in the room.

Whiteboarding a platform

A clean platform diagram makes you look like someone who's built one. Keep it disciplined:

Left to right, in layers. Sources → ingestion → storage (raw/curated) → processing → serving. Draw orchestration and catalog/governance as bands underneath, spanning the flow — they're cross-cutting, not steps.
Boxes are systems; arrows are data with a cadence and a shape. Label arrows ("orders CDC, log-based, ~2k changes/s" / "clickstream, streaming, 50M/day"), not just lines.
Mark the decision points. Put a small ◆ where a real choice lives (the CDC method, the batch/stream split, the storage layer) — these are your invitations to the deep dive you're prepared for.
Annotate SLAs and boundaries. Write the freshness target near the serving layer; mark where data becomes immutable or where a contract sits.
Leave room. Don't fill the board early; the trade-off discussion needs space for a decision matrix or a CDC sketch.

The worked example in Chapter 10 renders exactly this style as an ASCII diagram you can reproduce on any board.

Driving vs being led

Strong candidates drive: they lay out the structure, propose decisions, and then hand the interviewer the wheel at natural forks ("I'd default to a lakehouse here — want me to justify that, or go deeper on ingestion first?"). Weak candidates either wait to be asked each question or barrel ahead ignoring the interviewer's cues. Aim to lead the structure while letting them choose the depth. If they push back on a choice, don't crumble or dig in — treat it as new information: "fair — if durability matters more than I assumed, I'd move that to X." Updating on evidence while still committing to a decision is exactly the judgment they're testing.

How candidates lose

The recurring failure modes

Tooling before requirements. Naming products before establishing volume, freshness, and budget. Requirements first, always.
No sizing. Skipping the back-of-envelope, so every choice is ungrounded opinion. Even rough numbers change the design.
Cargo-culting. Reaching for streaming, a lakehouse, and the full modern data stack when a nightly batch into a warehouse meets the SLA at a fraction of the cost and effort.
Listing instead of deciding. "You could do A, B, or C" with no call. Make the call and defend it.
A weak CDC story. Hand-waving how a source DB gets into the platform. Know query-based vs log-based cold — Chapter 04.
Ignoring cost, lock-in, and operability. Designing for throughput alone. Who runs this, what does it cost, how do you get off it?

Avoid those six, run the method, and the rest of this guide gives you the depth to go as deep as any interviewer wants. Next: the step everyone rushes and seniors never skip — 02 · Requirements & Estimation.

✓ Check yourself

Answer from memory before opening each one.

Two candidates are given the same scenario and design different platforms. Both pass. What must be true of both answers?

Show answer
Each decision traces back to a stated requirement, and each trade-off is reasoned honestly, with its cost named. The interviewer is not matching against one correct architecture. See what the interviewer scores.
A candidate says: "I'd use streaming because the business wants real-time." Rewrite it as a defended decision, and say which part of your version a memorised answer would lack.

Show answer
For example: "Given a five-minute freshness SLA for fraud and a daily one for BI, I'd stream the fraud path and batch the rest. The cost is a second pipeline to run, which is fine for one consumer, and I'd revisit it if BI also tightened to minutes." The memorised answer lacks the final clause, the condition that would flip the choice. See defending a trade-off.
Twenty minutes into the session your board holds a detailed ingestion layer, with partition counts and key choices, and nothing else. What has gone wrong and what do you do next?

Show answer
You spent the architecture phase on one layer, and most of the score sits in the trade-off and deep-dive phase that follows. Stop, finish a simple end-to-end sketch with the decision points marked, then invite the interviewer to choose where to go deep. See how the 60 minutes flow.
You propose a lakehouse with streaming ingest. The interviewer says the whole dataset is 200 GB and refreshed nightly. Do you defend, drop it, or something else?

Show answer
Treat it as new information and run the sizing again. At that size and cadence a nightly batch into a warehouse almost certainly meets the requirement for much less effort, so move to it and state what volume or freshness would bring the lakehouse back. Holding the choice out of pride is cargo-culting. Dropping it without reasoning shows you had none. See driving vs being led and how candidates lose.
The six-step method runs requirements, estimate, architecture, decisions, deep dives, evolution. Why does the order matter, and what goes wrong if you start at step three?

Show answer
Steps one and two supply the facts that every later choice is defended with. Starting at the architecture means naming products before you know volume, freshness or budget, so each choice is opinion. The through-line is that every decision points back to a requirement. See the six-step method.

Takeaway

The session is scored on requirement-driven, defended trade-offs and real depth on ingestion and CDC. No single architecture is correct.
Spend the first five to eight minutes on requirements and a rough estimate. They are what let you justify every later decision.
The method runs requirements, estimate, architecture, decisions, deep dives, evolution, and every decision points back to the first step.
A defended trade-off names the requirement, the choice, its cost, and the condition that would flip it.
Draw layers left to right, label arrows with cadence and shape, mark decision points, and leave room for the trade-off discussion.
Lead the structure and let the interviewer pick the depth. Treat pushback as new information, not as an attack.
Candidates lose by naming tools before requirements, skipping sizing, cargo-culting, listing options without a call, telling a weak CDC story, and ignoring cost and operability.

The first step is the one people rush and seniors never skip. → Requirements & Estimation