Data engineers build the plumbing everyone else trusts, so the interview has to check more than tool names. These data engineer interview questions cover data modeling, SQL, batch and streaming pipelines, storage formats, and data quality, plus behavioral prompts about owning failures. They're meant for data leads and hiring managers running a technical round, and for candidates preparing for one. Each question comes with what a good answer includes and, where it helps, a red flag. Pick the sections that match your stack and the seniority of the role.
What a strong data engineer interview checks
- Data modeling: clear grain, sensible facts and dimensions, and history handled on purpose.
- SQL fluency: joins, window functions and query plans, with an eye on cost.
- Reliable pipelines: idempotent loads, safe backfills, retries and orchestration.
- Storage and scale: file formats, partitioning, table formats and streaming trade-offs.
- Data quality and trust: tests, contracts, lineage, and fast, honest incident handling.
- Collaboration: working with analysts, source-system owners and security.
Data engineer interview questions: modeling and SQL
1. What is the grain of a fact table, and why do you decide it first?
What good looks like: the grain is what one row represents, such as one order line or one user per day. Choosing it first prevents double counting, decides which dimensions can join, and keeps measures additive. They explain facts (numeric events) and dimensions (descriptive context) in a star schema.
Red flag: mixing order-level and line-level amounts in one table.
2. Compare slowly changing dimension Type 1 and Type 2.
What good looks like: Type 1 overwrites the old value and keeps no history. Type 2 adds a new row for each change with valid-from and valid-to dates and a current flag, so facts can join to the version true at that time. They choose based on whether the business needs history for that attribute.
3. A table has several rows per customer. Return only the latest row for each one.
What good looks like: ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) in a subquery or CTE, then filter to row number 1. They break ties with a second column, and may mention QUALIFY in warehouses that support it.
4. A warehouse query that used to take seconds now takes 20 minutes. Where do you look?
What good looks like: the query plan. Common causes are partitions no longer pruned (a function wrapped around the partition column), a join on a key that stopped being unique and now multiplies rows, selecting every column on a columnar store, or data skew. They check the bytes scanned, since that often drives cost too.
Pipelines and orchestration
5. What makes a pipeline idempotent, and why does it matter?
What good looks like: running it twice for the same input gives the same result as running it once. They achieve it by overwriting a whole partition or using MERGE on a key, rather than blind appends. Idempotency makes retries and backfills safe.
Red flag: "We append, and if it runs twice we delete the duplicates by hand."
6. Compare full loads, incremental loads and change data capture.
What good looks like: full loads are simple but costly at scale. Incremental loads using an updated-at column are cheaper but miss hard deletes and depend on that column being reliable. Change data capture reads the database's change log (with a tool like Debezium), capturing inserts, updates and deletes in order.
7. You need to backfill two years of data after a logic change. How do you do it safely?
What good looks like: run it partition by partition with an idempotent job, limit parallelism so the source and warehouse aren't overloaded, write to a staging table or new version first, compare row counts and key totals against the old output, then swap. They tell downstream users when numbers will change.
8. What should an orchestrator like Airflow or Dagster handle, and what shouldn't it?
What good looks like: scheduling, dependencies, retries, alerting and visibility. It should trigger work in a warehouse or compute engine, not process large data itself, and shouldn't pass big datasets between tasks through its metadata store. They mention keeping tasks small, idempotent and parameterized by run date.
9. How do you test data transformations?
What good looks like: schema tests such as unique, not null, accepted values and relationships (as in dbt), plus row-count and freshness checks, and unit tests on tricky logic with small fixed inputs. Critical tests block the pipeline. Others warn.
Storage, scale and streaming
10. Why do analytics teams prefer Parquet to CSV?
What good looks like: Parquet is columnar, so queries read only the columns they need. It compresses well, stores the schema and types, and keeps column statistics that let engines skip data. CSV has no types, no schema and must be read in full.
11. What is the small files problem, and how do you fix it?
What good looks like: thousands of tiny files slow queries and strain metadata, because every file has overhead to open and plan. Fixes include compaction jobs, batching writes, and aiming for files in the range of roughly 100 MB to 1 GB, depending on the engine.
12. What do open table formats like Apache Iceberg and Delta Lake add on top of files in object storage?
What good looks like: ACID transactions, so readers never see half-written data. Also schema evolution, time travel to earlier snapshots, and row-level updates and deletes. Iceberg adds hidden partitioning, so queries don't need to know the partition layout.
13. How do you choose a partition key?
What good looks like: match how the data is filtered, most often by event date. Avoid high-cardinality keys like user ID, which create too many tiny partitions. Watch for skew, where one partition is much bigger than the rest.
14. In a stream, events arrive up to an hour late. How do you produce correct hourly counts?
What good looks like: aggregate by event time, not processing time, and use a watermark that says how long to wait for late data before closing a window. Events later than that go to a correction path. They know Kafka keeps order only within a partition.
15. What does "exactly once" really mean in a streaming pipeline?
What good looks like: in practice it means effectively once. Messages may be delivered more than once, so the result is made correct through idempotent writes, deduplication on an event ID, or transactions that commit offsets and output together.
Red flag: believing the message broker alone guarantees no duplicates end to end.
Data quality and governance
16. It's Monday morning and the revenue dashboard is wrong. What do you do?
What good looks like: confirm the problem and tell users quickly so nobody acts on bad numbers. Check freshness, row counts and recent upstream schema changes, use lineage to find the failing step, fix and backfill, then add the test that would have caught it.
17. An upstream team keeps renaming columns without warning. How do you stop the breakage?
What good looks like: a data contract that defines the schema and the change process, schema checks at ingestion that fail loudly, and a direct working relationship with the source team. They'd rather solve it with the team than build fragile workarounds.
18. How do you handle personal data in a data platform?
What good looks like: collect only what's needed, mask or tokenize sensitive columns, limit access by role and column, and set retention periods. They plan for deletion requests, which is harder in append-only storage and easier with table formats that support row-level deletes.
Behavioral (STAR)
19. Tell me about a pipeline failure you owned from detection to fix.
What good looks like: how they found out (ideally an alert, not a user), what the impact was, how they communicated, the fix, and the lasting change, such as a new test or contract.
20. Describe a time you cut the cost of a data platform.
What good looks like: they measured where the money went, made targeted changes (partitioning, fewer full refreshes, right-sized compute), and report the saving as a number without breaking anyone's work.
A simple scoring rubric
Running this interview with AI
An adaptive AI interviewer can take on the first technical screen for data engineering roles, so your senior engineers only meet candidates who already cleared the basics. NTRVSTA lets you customize the questions per role, and its exam library covers Python. The interviewer raises or lowers difficulty with each answer, and system-design questions use an interactive whiteboard, which works well for "design a pipeline for late events" prompts. Behavioral questions follow STAR.
Results come back as a score breakdown with video snippets of key moments, ready to share with the hiring team. Learn how AI interviews are scored, or compare vendors in our AI interview software guide. Related question sets: SQL, data scientist, Python and DevOps.
Questions
Should SQL be tested separately in a data engineer interview?
Usually yes. A 30-minute SQL exercise with joins, window functions and a deduplication task shows fluency quickly, and it frees the main interview for design and judgment. Use a realistic schema with some messy data rather than textbook tables.
How do I interview fairly when candidates used different tools?
Ask about the problem each tool solved, not the brand. Someone who ran solid pipelines on one orchestrator or warehouse can learn yours. Score their reasoning about state, retries, partitions and testing, which carries across every stack.
What should a junior data engineer interview focus on?
SQL, basic Python, and the modeling and idempotency questions here. Juniors do not need to have run streaming systems, but they should explain why reruns must not create duplicates and how they would check that a load worked.
To see a data engineering screen run end to end by an adaptive AI interviewer, book a 20-minute demo. Prefer to explore alone? Start a sample interview.
