Interview Prep II — System Design & Behavioral
This is where the whole curriculum pays off. The SQL screen tested whether you can write code; the design round tests whether you can think like an engineer — make tradeoffs, reason about scale, and explain your choices out loud. And the behavioral round tests whether they'd want you in the room. The good news: you've already designed and built a real platform. You're not learning this for the interview — you're describing what you already did.
The data system design interview
Somewhere in the onsite — usually a 45-to-60-minute session — an interviewer will say something like "Design a data pipeline for X" or "How would you build the analytics platform for a company like ours?" There's no compiler, no test cases, and crucially no single right answer. They're not checking whether you memorized an architecture diagram. They're watching how you reason.
Specifically, a good design interviewer is probing for judgment:
- Do you ask questions before charging in, or do you build the wrong thing confidently?
- Do you know the building blocks — ingestion, storage, transformation, serving — and when to reach for each?
- Can you name a tradeoff instead of pretending one option is free?
- Do you connect choices to requirements (latency, cost, scale) rather than reciting buzzwords?
Every part of the design round maps onto something you built in the capstone: you chose an ingestion pattern, modeled tables, wrote transformations, orchestrated them, and served results. The interview is just narrating those decisions for someone new. When you feel the panic of a blank whiteboard, remember — you have a working system that already answers most of these questions.
An 8-step framework for data design interviews
Walking in with a framework is the single biggest thing that separates calm candidates from flailing ones. It gives you a checklist to think against so you're never stuck staring at the board. Memorize these eight steps — they follow the natural flow of data from source to consumer, which is exactly the mental model the rest of this course gave you.
| # | Step | What to say out loud | Where you learned it |
|---|---|---|---|
| 1 | Clarify requirements & scale | Who uses this and how fresh must it be? Data volume? Batch hourly or real-time? Budget? Don't design until you know. | Orientation · the mental model |
| 2 | Identify sources | App databases, third-party APIs, event streams, files in object storage, SaaS exports. What format, what volume, who owns them? | Ingestion course |
| 3 | Ingestion | Batch pulls for slow-moving data, streaming for events, CDC to mirror a database without hammering it. Pick per source. | Ingestion · batch / stream / CDC |
| 4 | Storage & modeling | Warehouse vs lakehouse; land raw, clean, then model. Medallion (bronze/silver/gold) and dimensional (facts & dimensions). | Storage & Modeling course |
| 5 | Transformation & orchestration | SQL transforms (dbt) turning raw into models; a scheduler/DAG running them in order with retries and dependencies. | Transformation & Orchestration |
| 6 | Serving | How consumers get data: a BI tool, a metrics/semantic layer, an API, reverse-ETL back into apps. | Serving & BI course |
| 7 | Quality & governance | Tests & freshness checks, lineage, access control, PII handling, documentation. The "is it trustworthy?" layer. | Quality & Governance |
| 8 | Scale & tradeoffs | Where it breaks at 10×, what's expensive, failure modes and backfills, and the choices you'd revisit. | Systems-design reference |
Beginners rush step 1 and skip step 8 — exactly the two steps interviewers care about most. Clarifying requirements shows maturity; discussing tradeoffs shows seniority. The middle steps (3–6) are where you demonstrate you know the tools, but they're also the easiest part for you because you built them.
Worked example: design a platform for a GPU-rental marketplace
Let's run the framework on a real prompt — and not a hypothetical one. Imagine the interviewer says: "We run a marketplace that rents out GPU compute. Sellers list machines, buyers rent them by the hour. Design the data platform." That's GridDP — the platform you built in the capstone. Watch how naming choices and tradeoffs out loud turns a scary prompt into a guided tour of work you've already done.
Notice what made that strong: at every step a specific choice was named and justified by a requirement from step 1. We chose CDC for the app DB because we shouldn't load production. We chose hourly batch because nobody needs real-time. We flagged the usage-meter table as the cost and scale risk because it's the high-volume source. That "choice → reason" rhythm is the whole game.
Example answer — handling a curveball follow-up
Interviewer: "Now finance says billing must be exact to the minute and can never double-count. What changes?"
"Good — that raises the bar on the usage-meter path specifically. Three things. First, idempotency: each meter event needs a unique event id so that if it's delivered twice, my silver layer dedupes it — I'd make the load idempotent on that key rather than blindly appending. Second, late and out-of-order events: I'd build fact_usage incrementally with a lookback window so a meter reading that arrives an hour late still lands in the right rental, and I'd reconcile the billing model on a delay rather than instantly. Third, auditability: I'd keep the raw bronze events immutable so finance can always recompute a disputed invoice from source. The tradeoff is latency — exact billing means I publish the billing gold table on, say, a 2-hour delay instead of live. For finance that's a fine trade; for the ops dashboard I'd keep the faster, approximate path."
That answer works because it doesn't panic — it isolates the affected path, names concrete mechanisms (idempotency, lookback, immutability), and ends on the tradeoff (latency vs correctness) rather than pretending the change is free.
Design-interview tips
Knowing the framework is half the battle; performing the interview is the other half. A few habits make you read as senior even when you're nervous:
| Do this | Why it works |
|---|---|
| Think out loud, always. | The interviewer is grading your reasoning, not your silence. A wrong idea you talk through beats a right idea you keep in your head. |
| State your assumptions. | "I'll assume read-heavy, hourly freshness is acceptable — stop me if not." This shows judgment and lets them correct your scope early. |
| Discuss tradeoffs explicitly. | Every choice costs something. "Streaming gives freshness but adds operational complexity and cost" signals you understand there's no free lunch. |
| Draw boxes and arrows. | A simple source → ingest → store → transform → serve diagram organizes the whole conversation and keeps you on the framework. |
| Manage your time. | Sketch the full pipeline broadly first, then go deep where they steer you. Don't spend 30 minutes perfecting ingestion and never reach serving. |
If you announce "one valid approach is a lakehouse here; a warehouse-only design would also work and would be simpler to operate — let me explain why I'd lean lakehouse," you've just demonstrated exactly the judgment they're testing for. Candidates who insist their first idea is the only idea look junior. Engineers compare options.
You will hit the edge of your knowledge — everyone does. "I haven't operated Kafka at that scale, but here's how I'd reason about it, and here's what I'd want to validate" is a great answer. Honesty plus a reasoning approach beats a confident bluff that unravels under one follow-up question.
Take-home assignments
Many data teams swap (or add) a take-home for the live design round: "Here's a messy dataset and a prompt — build a small pipeline or a few models and write up your approach." This format rewards exactly the habits you built in the capstone, so treat it as a home game.
What graders actually reward:
- Clean, readable code over clever code. Clear names, small functions, no dead commented-out blocks.
- Sensible data modeling. Did you stage raw data, then build clean models on top — or dump everything in one giant query? They're checking for the layered thinking from the storage course.
- Tests. Even a few not-null/unique checks signal you care about correctness. Untested take-homes read as careless.
- A README. How to run it, what assumptions you made, what you'd do with more time. This is often the single most-read file — your written communication on display.
- Reproducibility. It runs from a clean checkout with documented steps. If they can't run it, they can't reward it.
The most common take-home mistake isn't doing too little — it's doing too much. A four-hour task does not need Kafka, Kubernetes, and a custom framework. Graders read over-engineering as poor judgment about scope. Solve the problem cleanly, note in the README what you'd add for production, and stop. Knowing what not to build is a senior signal.
A staged model layout, a few dbt tests, a clear README explaining choices and tradeoffs — you already produced all of this. A strong take-home is essentially a miniature capstone done in a weekend. Reuse the structure and habits you already have.
Behavioral interviews
The behavioral round answers a quieter but decisive question: would we want to work with this person? Technical skill gets you here; collaboration, ownership, and communication get you the offer. Don't wing it — the questions are predictable, so prepare stories in advance.
The STAR method
Structure every story with STAR so it stays tight and lands the point:
| Letter | Means | Keep it… |
|---|---|---|
| S — Situation | The context: where, when, what was at stake. | Brief — one or two sentences. |
| T — Task | Your specific responsibility or the problem to solve. | Clear and personal — your task. |
| A — Action | What you did, step by step. The heart of it. | Detailed — say "I", not "we". |
| R — Result | The outcome, ideally measurable, plus what you learned. | Concrete — a number if you have one. |
Common prompts to prepare a STAR story for: "Tell me about a hard bug you debugged," "a time you disagreed with someone," "a project you're proud of," "a time you failed," "why data engineering?" You can source almost all of these from building the capstone and learning this curriculum.
Don't apologize for switching into data. Frame it as evidence: the motivation to retrain on your own time shows drive; pushing through a hard curriculum shows grit; and a prior career gives you a fresh perspective and domain knowledge a lifelong engineer lacks. "I taught myself this, built a working platform, and I bring [your old field] context to data problems" is a confident, memorable story — not a gap to explain away.
Example STAR answer — "Tell me about a hard bug"
S: "While building my capstone, a GPU-rental data platform, my nightly pipeline started producing daily revenue numbers that were roughly double what they should be."
T: "I needed to find why the gold revenue table was inflating before I could trust any dashboard on top of it."
A: "I worked backward through the layers. The gold numbers were wrong, so I checked the silver fact table — it had duplicate usage-meter rows. I traced those to the ingestion step, where a retry was re-loading events that had already landed. I made the load idempotent by deduplicating on the event id, then added a uniqueness test on that key so the same bug would fail loudly next time instead of silently double-counting."
R: "Revenue numbers reconciled, and the new test has caught a similar issue since. The bigger lesson was to put data-quality tests at the boundaries, not just trust that loads are clean — I now add a uniqueness check on every fact key by default."
Why it works: it follows a real debugging path (symptom → trace upstream → root cause → fix → prevention), says "I" throughout, and ends with a durable lesson.
Example STAR answer — "Why data engineering?"
S: "In my previous role I kept running into the same wall — decisions were stalled because nobody could trust or even find the right numbers."
T: "I wanted to be the person who fixes that: building the reliable plumbing that turns raw data into something people can actually use."
A: "So I committed to retraining properly. I worked through ingestion, modeling, transformation, and orchestration, and then built a full platform end to end — sources, a medallion lakehouse, dbt models with tests, orchestration, and dashboards on top."
R: "I came out of it certain this is the work I want. I like that it's equal parts engineering rigor and being genuinely useful to the business — and I bring a perspective from my old field about what decision-makers actually need from data."
Why it works: it gives a genuine motivation, shows the work to back it up, and ties the career change to value rather than treating it as a liability.
The questions you should ask them
Interviews end with "Do you have questions for us?" — and saying "no" is a quiet red flag. Good questions signal you're evaluating them too. A few that consistently land:
- "What does the data stack look like today, and what's the biggest pain point in it?"
- "How do data engineers work with analysts and the rest of the org here?"
- "What would success in this role look like in the first six months?"
- "How does the team handle data quality and on-call when a pipeline breaks?"
- "What's something about working here you wish you'd known before joining?"
✓ Check yourself
- Can you recite the eight steps of the design framework from memory, in order?
- For any choice in a design, can you name the tradeoff you're making?
- Do you have three STAR stories ready (a hard bug, a conflict, and "why data engineering")?
- Can you tell your career-change story as a strength in two sentences?
Exercise — Outline a design for a new prompt using the 8-step framework
New prompt: "Design the data platform for a food-delivery app — orders, drivers, restaurants — so ops can see live delivery performance and finance can reconcile payouts." Spend ten minutes writing a one-line answer for each of the eight steps. Say the tradeoffs out loud. A sample outline:
- 1. Clarify: Ops wants near-real-time delivery status; finance wants daily, exact payouts. Volume: high order/event throughput. Two freshness tiers.
- 2. Sources: Orders Postgres, driver GPS/event stream, restaurant menu service, payments API.
- 3. Ingest: CDC off the orders DB; streaming for driver location/status events; daily batch from the payments API.
- 4. Store & model: Lakehouse, medallion layers. Gold:
fact_order,fact_delivery_event,dim_driver,dim_restaurant,dim_date. - 5. Transform & orchestrate: dbt models bronze→silver→gold with tests; orchestrator runs the DAG — fast cadence for ops marts, daily for finance.
- 6. Serve: Live ops dashboard on the streaming-backed marts; semantic layer for "on-time rate"; finance reconciliation tables.
- 7. Quality & governance: Uniqueness on order id, freshness checks on the event stream, PII (driver/customer location) access-controlled.
- 8. Scale & tradeoffs: Event stream is the volume risk → partition and incremental models. Tradeoff: a true real-time ops path adds streaming complexity and cost, so I'd start with a few-minute micro-batch and only go fully streaming if ops genuinely needs sub-minute latency.
There's no single right answer — a strong outline names a specific choice at each step and at least one honest tradeoff at the end. If yours does that, you're ready for the room.
Next
Clear the design and behavioral rounds and the conversation turns to money and start dates — so let's talk about evaluating, negotiating, and ramping. → The Offer & First 90 Days