Data Engineer Interview Questions
Data engineering interviews rarely test whether you can write a SELECT. They test whether you can make a pipeline correct: idempotent on retry, running its tasks in dependency order, joining at the right grain, and reconciling data that arrives late. Gronex lets you practice those exact failures in real Python repositories with failing tests — pandas, SQLite, and a scheduler you can run on a laptop, no Spark cluster required — so you rehearse the round, not a syntax quiz.
What data engineering interviews test
The hard part of a data role is not the query language — it is correctness under real-world messiness. A pipeline that runs twice must not double-count. A task must never read a table before its upstream has written it. A join must respect the grain of both sides or every downstream metric inflates. And an incremental load must handle records that show up hours after the window they belong to. These are the bugs that ship to production and surface as a wrong dashboard number, and they are exactly what a good interviewer probes.
Every challenge here is a real Python repository with a bundled verify step (pytest). You fix the pipeline until the data-quality assertions pass — row counts balance, keys stay unique, totals reconcile. The scenarios are CPU-only and run in seconds: a pandas DataFrame, a bundled SQLite database, or an in-repo scheduler stub, never a cluster you have to stand up.
Common patterns in data engineering rounds
Idempotent pipelines
Loads that produce the same result whether they run once or five times — the difference between a safe retry and a double-counted fact table.
Dependency & orchestration
Running tasks in true topological order so a step never reads a table its upstream has not written yet.
Join grain & cardinality
Knowing the grain of every table so a many-to-many join does not silently multiply rows and inflate every downstream metric.
Windowing & SQL analytics
Partitioning, ordering, and frame clauses that pick the right row and compute the right running aggregate.
Late & out-of-order data
Incremental and CDC merges that reconcile late-arriving records and keep the newest version of each key.
Data-quality assertions
Tests that catch a broken pipeline before it ships — row-count parity, uniqueness, and totals that must balance.
Problems to practice
Each is a real Python repository with a failing test suite. Open the brief and fix it — no signup required to read the full problem.
DAG Dependency Order & Idempotent Load
Fix a scheduler that reads before its upstream writes and appends instead of upserting on retry.
Open the challenge →Pandas Join Fan-out & Deduplication
A join grain error blows up cardinality; dedup on the wrong subset hides it. Restore row-count integrity.
Open the challenge →SQL Window Function Partitioning
ROW_NUMBER() with the wrong partition/order keeps the wrong row; the running-total frame is off.
Open the challenge →Incremental CDC Merge & Late Data
A watermark load that drops late-arriving records and keeps a stale version on merge.
Open the challenge →Guided walkthroughs
Airflow DAG Dependency & Idempotent Load
A scheduler that runs tasks out of dependency order and double-counts on retry — the two bugs that page on-call teams.
Read the walkthrough →Pandas Join Fan-out & Deduplication
A many-to-many join that silently inflates row counts — the classic data-quality regression.
Read the walkthrough →