Data Engineering System Design Interview: Complete Prep Guide
Data engineering system design interviews follow a 45-minute framework: requirements clarification → capacity estimation → architecture sketch → component deep dive → tradeoff summary. The differentiator at senior and staff level is not knowing the right tools — it is knowing how to justify every choice against your specific requirements.
The 45-Minute Interview Framework
Requirements Clarification
Ask questions before touching the whiteboard. Establish data volume, latency SLO, read/write patterns, consistency requirements, and retention.
→How many events per second at peak?
→What is the acceptable end-to-end latency? (seconds? minutes? hours?)
→Is this read-heavy or write-heavy?
→Do we need exactly-once guarantees?
→What is the data retention requirement?
Capacity Estimation
Back-of-envelope math. Show your work. Interviewers at senior level expect throughput in GB/s and storage growth in TB/day.
→events/sec × bytes/event = throughput in MB/s
→throughput × 86,400 = daily raw storage
→daily × compression ratio = compressed TB/day
→Peak: assume 3–5× average for burst headroom
High-Level Architecture
Sketch the 6 layers: ingest → store → process → format → serve → observe. Name specific tools and justify each choice relative to your requirements.
→Why Kafka over Kinesis for this volume?
→Why Iceberg over Delta Lake for this use case?
→Why Flink over Spark Streaming for this latency SLO?
→Where does the serving layer live — warehouse or feature store?
Deep Dive
The interviewer picks the hardest component. Common targets: exactly-once guarantees, schema evolution strategy, backfill mechanism, or partition skew handling.
→How do you handle late-arriving events in a streaming window?
→What happens when the upstream schema changes without notice?
→How do you backfill 3 years of historical data without disrupting production?
→How do you handle a hot partition in Kafka?
Tradeoff Summary
Close by summarizing the 2–3 most important tradeoffs you made. Show you understand what you sacrificed to get what you needed.
→We chose kappa over lambda — simpler ops but no separate batch correctness layer
→We chose Iceberg over Delta Lake — vendor-neutral, but less mature Spark integration
→We chose Flink over Spark — lower latency but higher operational complexity
Most Common Interview Questions
Design a real-time event analytics system
Kafka + Flink + Iceberg · exactly-once · windowing · late data
Design a data warehouse for a ride-sharing company
dbt medallion · Redshift/Snowflake · Airflow orchestration · star schema
Design a feature store for ML serving
Feast · offline Parquet · online Redis · training-serving skew
Design a data lakehouse migration from Hive to Iceberg
Table format migration · time-travel · schema evolution · backward compatibility
Design a data observability platform
OpenLineage · Prometheus · SLO framework · incident routing
What Interviewers Look For
- → Requirements discipline — asking clarifying questions before drawing anything
- → Capacity math — throughput in GB/s, storage in TB/day, peak multipliers
- → Component justification — every tool choice defended against requirements
- → Failure mode awareness — what breaks and how you recover
- → Tradeoff articulation — explicit statement of what you gave up
Common Interview Mistakes
Starting with tools, not requirements
Never say "I would use Kafka and Spark" before asking about volume, latency, and consistency. Interviewers mark you down immediately for jumping to solutions.
Skipping capacity estimation
Back-of-envelope math is expected at senior level. If you cannot estimate throughput in GB/s and storage growth in TB/day, you signal that you design by intuition, not rigor.
No failure modes discussed
Every senior DE interview tests at least one failure scenario. Prepare for: hot partition, late-arriving events, upstream schema change, disk full on the processing node.
FAQ
- What does a data engineering system design interview look like?
- 45–60 minutes. Vague problem → requirements clarification → capacity estimates → architecture → deep dive → tradeoff summary. DE interviews emphasize storage selection, streaming vs batch, schema evolution, and data quality more than pure software system design.
- What do interviewers look for at the senior level?
- Requirements discipline, capacity math, component justification against requirements, failure mode awareness, and explicit tradeoff articulation. Knowing the tools is not enough — you must defend why each tool over its alternatives.
- What are the most common questions?
- Real-time event analytics (Kafka + Flink + Iceberg), data warehouse design (dbt + Airflow + Snowflake), feature store (Feast + Redis + Parquet), lakehouse migration (Hive to Iceberg), data observability platform (OpenLineage + Prometheus).