Data Engineer Interview Questions (2026)
Data engineering interviews center on SQL depth, pipeline design, and the modern warehouse stack — with AI-data topics (vector stores, LLM-ready data) appearing in 2026 loops. These questions mirror what shows up in real interviews at both startups and large companies.
1.Design a data pipeline that ingests events from a product into a warehouse for analytics.
What a strong answer covers: Cover the spine: event collection (SDK/webhook to Kafka/Kinesis or a tool like Segment), landing raw immutable data first, transformation in the warehouse (dbt pattern: staging → marts), orchestration (Airflow/Dagster), and data quality checks between layers. State the batch-vs-streaming decision explicitly based on freshness requirements — defaulting to streaming without a requirement is a red flag interviewers probe.
2.What's the difference between ETL and ELT, and why did the industry shift?
What a strong answer covers: ETL transforms before loading (constrained warehouses forced it); ELT lands raw data and transforms inside the warehouse. The shift came from cheap warehouse compute (Snowflake, BigQuery) making in-warehouse transformation practical, which enabled dbt, version-controlled SQL, and re-derivable models from preserved raw data. Mention the tradeoff: ELT can become a swamp without modeling discipline.
3.Write a query to find the top 3 products by revenue in each category. Explain your approach.
What a strong answer covers: Window functions are the point: RANK() or ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC), filtered to rank <= 3 in an outer query or QUALIFY clause. Discuss RANK vs DENSE_RANK vs ROW_NUMBER tie behavior — interviewers almost always follow up on ties. Fluency with window functions is the single most tested SQL skill in data engineering loops.
4.A dashboard number looks wrong and three teams are arguing about it. How do you debug data quality?
What a strong answer covers: Trace lineage backward: dashboard → mart → staging → raw, diffing counts and sample records at each hop to find where truth diverged. Common causes: silent schema change upstream, late-arriving data, timezone handling, duplicate events, a changed metric definition. Then the durable fix: tests at layer boundaries (dbt tests, freshness checks) and a single owned metric definition. The debugging process matters more than guessing the cause.
5.How do you handle late-arriving and duplicate events in a streaming pipeline?
What a strong answer covers: Duplicates: idempotent writes keyed on event ID, or dedupe windows downstream; understand at-least-once vs exactly-once semantics and what your tools actually guarantee. Late data: watermarks, allowed-lateness windows, and reprocessing strategy for data past the watermark. Mention that many 'streaming' requirements are really micro-batch requirements once you push on freshness SLAs.
6.Compare partitioning and clustering in a warehouse. How do you cut a $50k/month BigQuery bill?
What a strong answer covers: Partitioning physically segments by a column (usually date) so queries scan less; clustering sorts within partitions for further pruning. The bill answer: find the top queries by bytes scanned, add partition filters, kill SELECT *, materialize expensive repeated subqueries, check for dashboards refreshing hourly that nobody reads, and consider slot reservations vs on-demand. Cost fluency is a hiring signal in 2026.
7.What is a slowly changing dimension, and when do you use type 1 vs type 2?
What a strong answer covers: The classic modeling question. Type 1 overwrites (no history), type 2 adds versioned rows with validity ranges preserving history. Use type 2 when point-in-time truth matters (customer's plan at time of purchase). Explain the join implication: fact tables join on the surrogate key valid at event time. Bonus: mention snapshot-based alternatives common in modern ELT.
8.How would you design data infrastructure to support LLM/RAG applications?
What a strong answer covers: The 2026 question. Cover: document pipelines (extraction, cleaning, chunking) as first-class ETL, embedding generation and refresh on source changes, vector stores alongside the warehouse (pgvector vs dedicated stores and when each wins), metadata for filtering and access control, and evaluation datasets as maintained data assets. Frame it as: LLM apps make unstructured data a production data-engineering responsibility.
9.Your nightly pipeline that feeds executive dashboards failed at 3am. Walk me through your response and prevention.
What a strong answer covers: Response: assess blast radius, communicate before executives find stale numbers themselves, backfill after fixing. Prevention is what they're really asking: retries with backoff, idempotent re-runnable tasks, data-freshness SLAs with monitoring, dependency-aware orchestration so downstream tasks don't run on stale inputs, and runbooks. Idempotency is the key word — pipelines you can safely re-run turn incidents into non-events.
10.When would you use Spark vs doing everything in the warehouse?
What a strong answer covers: Honest 2026 answer: the warehouse handles more than people think, and dbt-style SQL is cheaper to operate. Spark earns its complexity for: data too large or too unstructured for warehouse pricing to make sense, heavy programmatic transformation (ML feature pipelines, complex parsing), and streaming with Structured Streaming. Answering 'I'd default to the warehouse until forced out' signals maturity, not weakness.
11.How do you manage schema evolution without breaking downstream consumers?
What a strong answer covers: Contracts and staged rollout: additive changes are safe (new nullable columns), destructive changes (renames, type changes, drops) require versioning — publish new alongside old, migrate consumers, deprecate with a timeline. Mention schema registries for streaming, data contracts between producing and consuming teams, and CI checks that catch breaking changes before merge.
12.Tell me about the most complex pipeline you've owned. What would you build differently now?
What a strong answer covers: The experience anchor. Structure: business purpose, scale (rows/day, latency SLA), architecture, and the operational pain — what paged you. The 'differently now' half tests growth: good answers name a specific decision (over-engineered streaming, under-invested testing, no idempotency) and the principle learned. Rehearse this one; it opens most senior data-engineering interviews.
Prepping for a specific job?
Use the prep engine on the homepage — describe your interview and get a tailored question set instantly. Missing a role page? Request it.
Want a human in your corner? 1-on-1 interview prep — $150
A 1-hour session where I use AI to build a prep plan for your exact interview — the role, the company, the round. Strongest for technical interviews (cloud, AI/ML, DevOps) and behavioral rounds: mock questions, answer structuring, and a follow-up question bank tailored to your job description.
Book a session