What data engineering interviews test
A data engineering loop usually spans four areas. The mix varies by company — analytics-heavy shops lean on SQL and modeling, platform-heavy teams lean on pipeline and systems design — but you should be ready for all four.
- SQL — non-trivial queries with joins, window functions, and aggregation, written correctly under time.
- Data modeling — dimensional modeling, normalization vs. denormalization, and schema design for analytics.
- Pipeline & system design — batch vs. streaming, orchestration, idempotency, and handling late or bad data.
- Coding & fundamentals — a general coding round plus distributed-data concepts (partitioning, shuffles, file formats).
SQL: the round you cannot fake
SQL is the single most reliable filter in a data engineering loop, and it is where under-prepared candidates get cut. Expect problems that require window functions (running totals, rank, deduplication), multi-table joins, and careful handling of NULLs and duplicates.
Practice writing queries that are both correct and readable, and be ready to explain what the query planner does — why an index helps, why a particular join order matters, how you would speed up a slow query. Talking through the execution, not just the syntax, is what separates a data engineer from an analyst.
- Master window functions cold — they appear constantly and trip people up.
- Handle NULLs and duplicates deliberately; interviewers plant them on purpose.
- Be able to reason about query performance and indexing, not just get the right rows.
- Say your approach out loud before writing the query.
Data modeling: design for how data is read
Modeling questions test whether you can design schemas that are correct, efficient, and understandable to the analysts who will use them. Know the difference between normalized (OLTP) and dimensional (OLAP) modeling, and when each is appropriate.
Be fluent in star schemas — facts and dimensions — and able to justify denormalization for analytical workloads where read performance and simplicity matter more than storage. Interviewers will push on slowly-changing dimensions, grain, and how your model handles a new requirement without a painful migration.
- Explain star schema (facts vs. dimensions) and when to denormalize.
- Define the grain of a fact table explicitly — ambiguous grain is a classic mistake.
- Handle slowly-changing dimensions and know the trade-offs of each type.
- Design so a likely new requirement does not force a rewrite.
Pipeline and system design
This is where senior data engineers stand out. Given a prompt like "design a pipeline to ingest and aggregate event data," drive it with a clear frame: sources and volume, batch vs. streaming, the processing and storage layers, orchestration and scheduling, and — critically — data quality and failure handling.
The details that signal experience are the ones beginners skip: idempotency so a retried job does not double-count, handling late-arriving and malformed data, backfills, schema evolution, and monitoring for data quality (not just pipeline uptime). Name the trade-off between latency and cost, and between exactly-once and at-least-once processing.
- Choose batch vs. streaming from the latency requirement, and justify it.
- Make pipelines idempotent so retries and backfills are safe.
- Plan for late, duplicate, and malformed data explicitly.
- Monitor data quality and freshness, not only whether the job ran.
Distributed-data fundamentals
Even if you will not write low-level distributed code, interviewers probe whether you understand what happens under the hood of the tools you use. These concepts explain why pipelines are slow or expensive and how to fix them.
- Partitioning and how a bad partition key creates skew and hot spots.
- Shuffles — why they are expensive and how to minimize them.
- Columnar file formats (Parquet, ORC) and why they matter for analytics.
- Batch vs. streaming engines and the delivery guarantees each provides.
How to prepare
Prioritize SQL and modeling first — they are the highest-frequency, highest-signal rounds — then build a repeatable pipeline-design frame. As always, practice out loud and under time; explaining your query plan or your pipeline's failure modes aloud is a different skill from knowing them.
- Daily: one non-trivial SQL problem involving window functions or dedup.
- Two or three data-modeling exercises (design a schema for X analytics use case).
- Rehearse a pipeline-design walk-through until the frame is automatic.
- Do full mock interviews and review where a follow-up exposed a gap.