Day-Of Tactics

The framework in your head

You don't walk in with an architecture memorized — you walk in with a loop you can run on any prompt and any sub-question inside it. Five beats, in order:

1. Clarify. Volume, freshness SLA, correctness bar, consumers. Two or three sharp questions before you draw a single box.
2. Structure. State the simple, correct version — an idempotent batch pipeline, sources → land raw → transform → serve, orchestrated and reconciled. Get a complete, buildable system on the board fast.
3. Level up. Proactively add the production concerns the scenario invites — late data, incremental processing, reconciliation, failure handling — naming the naive version and the upgrade.
4. Trade-offs. Latency vs cost vs correctness vs complexity. Make the call, don't just list options.
5. Failure & evolution. What breaks, how it recovers, what you'd change at 10× scale.

The full version lives in Chapter 09; this is the pocket copy.

Whiteboarding technique

A clean diagram makes you look like someone who has actually built these. A messy one becomes a distraction you spend the hour apologizing for. A few rules keep the board an asset:

• Left to right, one row for the happy path. Sources → ingestion → raw/landing → transform → serve. Draw the orchestrator and observability underneath as cross-cutting lanes, not inline boxes.
• Boxes are systems; arrows are data with a cadence. Label every arrow with frequency and grain — "orders, hourly, by event_date" — not just a bare line.
• Annotate the SLAs and the boundaries. Write the freshness target near the serving layer, and mark where data becomes immutable. Those annotations are exactly where the good conversation happens.
• Mark failure points with a symbol. A small ⚡ on the riskiest arrows (network ingest, the dedup/merge step) openly invites the deep dive you're prepared for.
• Leave room to grow. Don't fill the board in the first five minutes — the deep dives need space for a windowing sketch or a reconciliation table.

Reproduce something like this and keep it uncluttered:

  sources            ingest            store (raw)        transform            serve
 ┌────────┐  orders  ┌────────┐        ┌──────────┐       ┌──────────┐        ┌────────┐
 │  app   │─hourly──▶│ CDC/   │──⚡───▶│ landing  │──────▶│ staging  │──────▶│ marts  │──▶ BI
 │  db    │ by event │ ingest │ dedup  │(immutable│       │→ interm. │  WAP   │(finance│  freshness
 └────────┘  _date   └────────┘        │ partns)  │       │→ marts   │  swap  │  grade)│  SLA: 08:00
 ┌────────┐          ┌────────┐        └──────────┘       └────┬─────┘        └────────┘
 │payments│──events─▶│ queue  │──⚡────────▲                   │ recon: sum(src)=sum(tgt)
 └────────┘  (late!) └────────┘   lookback │                   ▼ per event_date, tolerance
        orchestrate  ──────────────────────┴───────────────────────────  (Airflow / Dagster)
        observe      freshness · volume · schema · distribution · lineage  ───────────────▶ alerts

Demonstrating progression live

This loop is explicitly about level. The interviewer wants to see how high you can climb — so climb on your own initiative rather than waiting to be dragged. The mechanic is one sentence:

You don't force it on every point — but on the three things this loop tests hardest you should always have the next rung ready:

• Loading data: full refresh → idempotent incremental merge → lookback window for late data → CDC + contracts.
• Late data: "reprocess yesterday" → lookback + idempotent merge → watermarks + SCD2 + completeness SLA → bitemporal + reconciliation loop + downstream contracts.
• Correctness: not_null/unique tests → recon counts + freshness + block on critical → WAP + contracts + tolerances + quarantine → org-wide contracts, anomaly detection, automated break triage.

Narrate the climb as an arc: "the naive load is L1; I'd actually build the L2 incremental, and since you mentioned finance consumes this, I'd add the L3 reconciliation and probably the L4 WAP flow." That single sentence walks the whole ladder — the through-line of this entire guide.

Questions to ask them

Good questions signal seniority as loudly as good answers, and they're a low-risk place to show you think about production. Keep a few ready:

• "What's the current correctness bar — is there a reconciliation or financial-close process these pipelines feed?"
• "How do you handle late-arriving data today, and what's the completeness SLA you promise consumers?"
• "What does data downtime look like here — how do you detect it, and who gets paged?"
• "Are you task-centric in Airflow, or moving toward asset/data-aware orchestration?"
• "Where does the team spend its incident time — is it late data, backfills, schema changes upstream, or cost?"

Each of these doubles as a signal: it shows you already think in terms of SLAs, reconciliation, and failure — the exact things they're grading.

Red flags to avoid

Avoid these six and run the framework, and the depth in the rest of this guide carries you as high as any interviewer wants to go.

When you get stuck

You will hit a moment where you don't immediately know the answer. That's expected — how you recover is itself a signal. A few patterns that keep you moving:

• Return to first principles. Stuck on a mechanism? Fall back to the property you're protecting. "I want this to be re-runnable and reconcilable — so whatever I do here has to be idempotent and auditable." Reasoning from the property often regenerates the answer.
• Think out loud. Silence reads as a blank; narrated reasoning reads as problem-solving. "There are two ways to handle deletes here — let me weigh them" buys time and shows process.
• Reduce to the simple correct version. If the sophisticated answer won't come, state the naive one honestly and name what it's missing. "The simple version double-counts on late data; the fix is a lookback window, let me work through it." That's an L3 move even while you're recovering.
• Ask a clarifying question. A genuine one both narrows the problem and resets your footing.
• Admit the edge, don't bluff. "I haven't operated exactly-once Kafka sinks in anger, but here's how I'd reason about it" beats confident hand-waving every time. Interviewers trust calibrated honesty.

Pre-interview checklist

Walk in ready

Here's the reframe to carry in: this interview isn't a trivia gauntlet, it's a conversation about building something you already know how to build. The interviewer isn't trying to catch you not knowing an Airflow flag — they're trying to find out whether you design for correctness by instinct, whether you reach for late-data and reconciliation without being told, and how high you can climb when they push. You've done the work. This guide gave you the mechanisms — watermarks, SCD2, idempotent merges, WAP, the outbox, partition pruning — and the ladder to show them off deliberately.

So clarify before you draw. Get a simple, correct system on the board. Then level it up out loud, name your trade-offs, and tell them how it fails and recovers. Do that and you'll have shown exactly the judgment this loop is built to find.

If you want one last pass, skim the Start Here orientation and the guide hub to see the whole arc in one glance — then close the laptop and go do it. You're ready.

Takeaway

• Walk in with a loop, not an architecture: clarify, structure, level up, trade-offs, failure and evolution.
• The loop runs at two scales: the whole prompt over most of an hour and one follow-up question over ninety seconds.
• A clean board runs left to right, labels arrows with cadence and grain, shows SLAs and immutable boundaries, and leaves room for deep dives.
• Climb on your own initiative with the level-up sentence on loading, late data and correctness.
• When stuck, return to the property you are protecting, think aloud, state the naive version, or say plainly what you have not run in production.
• Avoid the six fast ways to look junior: tools first, no idempotency, ignored late data, vague reconciliation, over-engineering and monologues.

To keep going after the interview prep, the sibling guide on data systems design carries the same ingestion, CDC and platform thread at the architecture level. → Data Systems Design