Section E · Putting It Together

Day-Of Tactics

The last thing to read the morning of — the method to hold in your head, how to run the whiteboard and defend a call, the red flags to dodge, and how to recover when you freeze.

The method in your head

If you remember nothing else, remember the six steps. They're the difference between a structured hour and a ramble. Say them silently as you start, and narrate the ones that matter out loud.

Step	The move	The one-liner you say
1 · Requirements	Functional + non-functional. Who consumes, which queries, freshness SLA, volume/velocity/variety, correctness bar, retention, budget, compliance.	"Before I draw anything, let me pin down what we're building and for whom."
2 · Estimate	Events/sec → bytes/day → storage with retention; read QPS; rough cost. Numbers turn opinion into decision.	"Let me size this roughly — it'll tell us whether this is a big-data problem or a Postgres problem."
3 · Architecture	Sources → ingestion → storage → processing → serving, orchestration + catalog/governance underneath.	"Here's the whole platform end-to-end; then let's dig where it's interesting."
4 · Decisions / trade-offs	The named forks — CDC strategy, batch vs streaming, lake vs warehouse vs lakehouse, build vs buy — each tied to a requirement.	"Given the hourly SLA, I'd batch this rather than stream — here's why."
5 · Deep dives	Follow their pulls: CDC correctness, hotspots/skew, exactly-once, schema evolution, failure.	"Want me to go deeper on the CDC correctness story or the hot-partition risk?"
6 · Evolution	Scale 10×, first bottleneck, failure & DR, migration, cost control.	"At 10× the first thing to break is X; here's how I'd stay ahead of it."

The through-line

Every decision points back to step 1. Keep returning to the requirement that drives the call — "because the freshness SLA is five minutes for fraud but daily for BI, I'd split the paths." Requirements are the argument you never stop making.

Whiteboarding a platform

A clean diagram makes you look like someone who's built one. Draw it the same way every time so your hands know the layout while your head works on the problem.

Layers, left to right. Sources → ingestion → storage (raw/curated) → processing → serving. Get the whole flow on the board before you go deep on any one box.
Cross-cutting concerns underneath. Draw orchestration and catalog/governance as bands spanning the flow, not as steps in it — they touch every layer.
Arrows carry a cadence and a shape. Label them ("orders CDC, log-based, ~2k changes/s" / "clickstream, streaming, 50M/day"), not just lines.
Mark decision points with ◆. Put a small diamond where a real choice lives — the CDC method, the batch/stream split, the storage layer. These are your invitations into the deep dives you're prepared for.
Annotate SLAs and boundaries. Write the freshness target near serving; 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 shape; if it helps, redraw it once from memory the morning of.

Defending a trade-off

This interview is a series of forks, and the whole game is turning "it depends" into a defended decision. One sentence pattern carries you through every one:

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 is the one that separates a senior answer from a memorized one. "I'd revisit if…" proves you understand the boundary of the decision, not just the decision — that you'd choose differently if volume 10×'d, if the freshness SLA tightened to seconds, or if the team doubled. Have the decision matrices from Chapters 05, 06, and 07 ready as the axes; the sentence is how you deliver them out loud.

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 cues. Lead the structure, let them choose the depth.

When they push back on a choice, don't crumble and don't 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. Check in every few minutes: "does this level of depth work, or should I move on?"

Questions to ask them

Good clarifying questions early are part of the score; good questions at the end signal you think like an owner. Keep a few ready:

Up front (clarifying): Who consumes this data and for what? What's the freshness SLA per use case? Rough volume and growth? Correctness bar — can we tolerate eventual consistency? Retention and compliance constraints? Team size and existing stack?
At the wrap (for them): "What's the hardest data problem your team is fighting right now?" · "Where does the current platform hurt — cost, reliability, or velocity?" · "Build-heavy or buy-heavy shop, and why?" · "How do you handle schema change and data-quality incidents today?"

The clarifying questions do double duty — they're also how you avoid the number-one red flag below.

Red flags to avoid

The ways strong engineers still lose this round

Tooling before requirements. Naming Kafka and Snowflake in the first minute. Requirements and a rough estimate come first — always.
No sizing. Skipping the back-of-envelope, so every choice is ungrounded opinion. Even rough numbers change the design and prove you can tell a big-data problem from a small one.
Streaming / lakehouse 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. Justify complexity; don't default to it.
Ignoring cost & lock-in. Designing for throughput alone. Who runs this, what does it cost, and how do you get off it if the vendor doubles the price?
No CDC correctness story. Hand-waving how a source DB gets into the platform. Know query-based vs log-based, snapshot-plus-stream, and how deletes and ordering are handled — cold. (Chapter 04.)
Listing instead of deciding. "You could do A, B, or C" with no call. Make the call, name the trade-off, state what would flip it.

Recovery when stuck

You will hit a moment where your mind goes blank or a follow-up surprises you. That's normal; recovery is a skill you can rehearse.

Fall back to the method. Lost? Say where you are: "let me step back to requirements — what actually drives this choice is the freshness SLA." The six steps are a life raft; grab the next one.
Think out loud. Silence reads as being stuck; narrated reasoning reads as rigor. "I'm weighing two options here…" keeps you scored even mid-struggle.
Buy time with an estimate or a diagram. Sizing a number or redrawing a layer gives your brain a beat and often surfaces the answer.
Turn a surprise into a clarifying question. "Good question — it depends on whether we need exactly-once here; do we?" converts a stall into a dialogue.
Admit the boundary honestly. "I haven't operated Hudi at scale, but here's how I'd reason about whether it fits" beats bluffing every time. Interviewers trust calibrated candidates.

Pre-interview checklist

The compact version to skim while you wait:

Hold these six things

The six steps — requirements → estimate → architecture → decisions → deep dives → evolution.
The estimation chain — events/sec → bytes/day → storage×retention×replication → cost. One worked example in your pocket.
The four named forks — CDC strategy, batch vs streaming, lake/warehouse/lakehouse, build vs buy — with a one-line heuristic for each.
The decision sentence — including the "I'd revisit if…" clause.
The CDC correctness story — log-based, snapshot-plus-stream, deletes and ordering.
The whiteboard layout — layers left-to-right, governance underneath, ◆ on the decisions.

Then breathe. You've done the reps.

Go get it

You've got the method (01), the building blocks (02–04), a defended point of view on every big fork (05–07), the cross-cutting concerns (08, 09), and a full worked session (10). This interview doesn't reward one blessed architecture — it rewards structured breadth and honestly reasoned trade-offs. Run the method, tie every call to a requirement, name what would flip it, and let the interviewer steer the depth. That's the whole game.

Reread the morning of

This page is the one to skim on the way in. If you want a fuller refresher, loop back to 00 · Start Here and the hub at index. And if your loop also includes a build-and-operate round, the companion Production Data Pipelines guide is the one to warm up on — late-arriving data, incremental processing, reconciliation, and orchestration. Now go design something they'll want to hire you to build.

Takeaway

Hold the six steps in your head: requirements, estimate, architecture, decisions, deep dives, evolution. Every decision points back to the first.
Draw layers left to right with governance underneath, label arrows with cadence and shape, mark decisions with a diamond, and leave room.
Turn each fork into the decision sentence, including the condition under which you would change the call.
Lead the structure, let the interviewer pick the depth, and treat pushback as new information.
The red flags are tooling before requirements, no sizing, cargo-culting, ignoring cost and lock-in, no CDC story, and listing instead of deciding.
When stuck, return to the method, think aloud, size something, or turn the surprise into a clarifying question, and admit the edge of your experience plainly.

If your loop includes a build-and-operate round, warm up on the companion guide covering late data, incremental processing, reconciliation and orchestration. → Production Data Pipelines