The Discussion Interview & the Leveling Model

How the 60 minutes flow

There's no fixed script, but these sessions tend to move through recognizable phases. Knowing the shape lets you pace yourself and stop over-investing in the wrong part.

What the interviewer scores

Discussion interviews feel unstructured, but the assessment is not. Interviewers are looking for a consistent set of signals:

• Requirements before solutions. Do you pin down volume, latency, freshness, correctness, and consumers before architecting? Jumping straight to Kafka is a red flag.
• Correctness instincts. Is your default design idempotent and re-runnable? Do you reach for it without being prompted?
• Depth on the hard parts. When pushed on late data or reconciliation, do you have real mechanisms, or do you hand-wave?
• Production maturity. Do you talk about failure, retries, backfills, monitoring, and cost — the things that only matter once a pipeline actually runs?
• Trade-off reasoning. Do you present choices as trade-offs ("streaming buys latency at the cost of complexity and reconciliation difficulty") rather than as dogma?
• Communication. Can the interviewer follow your whiteboard and your logic? Do you check in, or monologue?

Notice what's not here: memorizing one canonical architecture, or knowing every flag in Airflow. Depth and judgment beat trivia.

Moving up a rung, out loud

The ladder from 00 is only useful if you can climb it deliberately in the room. The mechanic is simple and repeatable: state the naive version, name the production concern it ignores, then upgrade it — and say why.

You don't need to force it on every point — but on the three levers (design, late data, reconciliation) you should always have the next rung ready. Each content chapter in this guide gives you the specific rungs for its topic, usually as a leveling ladder table you can pattern-match against in the room.

A reusable answer structure

When handed a scenario — or any sub-question inside one — run the same five beats. It keeps you from rambling and makes your reasoning legible.

1. Clarify. "Before I design — what's the volume, how fresh does the output need to be, what's the correctness bar, and who consumes it?" Two or three sharp questions, not twenty.
2. State the simple, correct version. An idempotent batch pipeline that's obviously right. Get something buildable on the board.
3. Level it up. Proactively add the production concerns the scenario invites — late data, incremental processing, reconciliation, failure handling.
4. Name the trade-offs. Latency vs cost vs correctness vs complexity. Make the choice, don't just list options.
5. Address failure & evolution. What breaks, how it recovers, and what you'd change at 10× scale.

This mirrors the design-session framework in Chapter 09; here it's the micro-version you apply to every individual question, not just the opening prompt.

One question at four levels

To calibrate, here's the same everyday question — "How would you load orders from the app database into the warehouse each day?" — answered at rising levels. The goal is to hear the difference so you can aim high.

Every rung is a superset of the one below. In a real answer you'd narrate the climb — "the naive load is L1; I'd actually build L2, and given you mentioned finance cares about these numbers, I'd add the L3 reconciliation and probably the L4 WAP flow." That single arc covers the whole ladder.

Whiteboarding technique

The whiteboard is optional but powerful — a clean diagram makes you look like someone who's done this. A few rules keep it an asset instead of a distraction:

• Left to right, one row for the happy path. Sources → ingestion → raw/landing → transform → serve, with the orchestrator and observability drawn underneath as cross-cutting, not inline.
• Boxes are systems, arrows are data with a cadence. Label arrows with frequency and grain ("orders, hourly, by event_date"), not just a line.
• Annotate the SLAs and the boundaries. Write the freshness target near the serving layer and mark where data becomes immutable — those annotations are where the interesting conversation happens.
• Mark failure points with a symbol. A little ⚡ on the arrows most likely to fail (network ingest, the dedup/merge step) invites exactly 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.

You'll see this exact style used in the worked scenario in Chapter 09, rendered as an ASCII diagram you can reproduce on a physical or virtual board.

How candidates lose

Avoid these six and apply the answer structure above, and the rest of this guide gives you the depth to climb as high as any interviewer wants to go. Next: the foundations everything else rests on — 02 · Pipeline Design Foundations.

✓ Check yourself

Answer from memory before opening each one.

1. Ten minutes into a 60-minute session you have drawn half of the ingestion layer in detail and nothing else. What do you do next, and what does it cost you if you carry on?

   Show answer

   Stop and draw the rest of the system in its simplest correct form, then ask where the interviewer wants depth. Most of the score comes from the deep dives in the middle of the hour, so time spent gold-plating one box is time taken from late data, reconciliation and failure. See how the 60 minutes flow.

2. You name Kafka, Spark and a warehouse in your first 30 seconds. What signal does that send, and what should have come first?

   Show answer

   It signals tooling before requirements. Ask about volume, freshness, the correctness bar and who consumes the output, then pick tools that follow from the answers. The tempting view is that naming a modern stack shows breadth; scorers read it as a design with no stated constraints. See what the interviewer scores.

3. Your first design for loading orders is an incremental load on updated_at, upserting by order_id. Use the level-up sentence to move it up a rung.

   Show answer

   The simplest thing that works is a high-water-mark upsert. That breaks when updated_at moves backward or events arrive late, so in production add a lookback window of a few days and a daily count and sum reconciliation against source. It costs a larger re-scan and buys completeness you can prove. The sentence names the naive version, the production concern it ignores, the upgrade, and the trade-off. See moving up a rung.

4. What separates the L2 and L3 answers to the daily orders load? Name the concrete mechanisms, not the labels.

   Show answer

   L2 is idempotent and re-runnable, with a stored high-water mark and retries. L3 adds a lookback window for late and backdated rows, merges into the right event-date partition, and runs a row-count and sum reconciliation with a tolerance that blocks promotion on a break. The jump is from "it re-runs" to "it is provably complete". See one question at four levels.

5. A finance consumer needs totals that tie to the ledger. A growth team wants a dashboard that is roughly right by 9 a.m. Do you aim both pipelines at L4? Argue it.

   Show answer

   No. Match the rung to the correctness bar. Finance justifies log-based CDC, write-audit-publish and a published contract. The dashboard is usually served by L2 or L3 with a freshness check, and extra machinery there is over-engineering you would then have to run. Saying so out loud, with the cost of each rung, is the trade-off reasoning the scorers look for. See how candidates lose.

Takeaway

• Most of the score sits in the deep dives, so get a complete simple system on the board early and let the interviewer choose where to go deep.
• Interviewers score requirements before solutions, idempotent defaults, depth on late data and reconciliation, production maturity, and trade-off reasoning.
• Climb a rung out loud with one sentence: the simple version, what breaks it in production, the upgrade, and what the upgrade costs and buys.
• Every level is a superset of the one below, so you can narrate one arc from a full refresh to log-based CDC with write-audit-publish.
• Pick the rung from the correctness bar the consumer needs, not from the most advanced design you know.

The foundations that every rung rests on come next, starting with the anatomy of a pipeline and idempotency. → Pipeline Design Foundations