Data engineer interview questions
Thirteen interview questions for data engineer roles — pipelines and reliability, AI, behavioral, and situational — each with what to listen for, an example answer, and red flags. Pick five or six per round; a good data engineer talks about the people who use the data, not just the systems that move it.
All 13 questions
Role-specific data engineer interview questions
- 01The overnight run finished green, but this morning the revenue dashboard shows numbers nobody believes. Where do you start?
- 02Where do data-quality checks belong in a pipeline, and what should happen when one fails at 3 a.m.?
- 03A product team wants a dashboard 'in real time'. The data arrives in a nightly batch today. How do you decide what to build?
- 04You're building a table other teams will depend on. How do you find out what 'correct' means, and where do you write it down?
AI questions for data engineer candidates
- 05AI assistants will now write a working SQL query for almost anything you ask. What does your review catch before that query feeds a dashboard?
- 06An AI monitoring tool now flags anomalies across your tables — dozens a week. How do you decide which ones matter?
- 07Your tables start feeding an AI feature, not just dashboards. What changes about how you think about data quality?
Behavioral data engineer interview questions
- 08Tell me about a schema change you shipped that broke something downstream. Who found it, and what changed afterwards?
- 09Tell me about a pipeline or warehouse whose cost you cut significantly. Where was the waste hiding?
- 10Tell me about handing a dataset or data model you built over to people who had to run it without you. What did they struggle with?
Situational data engineer interview questions
- 11You discover a bug has been corrupting one column of a heavily used table for six weeks. Walk me through the fix — history included.
- 12A source team announces a breaking change to their data feed, shipping in two weeks. Five of your pipelines consume it. What do you do?
- 13Two dashboards show different numbers for the same metric, and executives have noticed. Both teams insist theirs is right. How do you settle it?
Questions 1–4
Role-specific data engineer interview questions
The overnight run finished green, but this morning the revenue dashboard shows numbers nobody believes. Where do you start?
A strong answer distrusts the green status first — checks row counts, freshness, and source deliveries before touching transformation logic — and identifies which upstream change landed yesterday. Silent failures, not crashed jobs, are where to look first.
What to look for
- Doesn't trust a green run status; checks row counts and freshness first.
- Looks upstream before downstream: late or partial source deliveries, a changed export.
- Posts a 'don't trust this dashboard yet' notice before the fix, not after.
Example answerRed flags
Example answer
Green just means the job didn't crash. I'd check yesterday's row counts against the trailing average — a source that delivered 60% of its usual volume explains most 'impossible' numbers. Then partition freshness, then schema drift in the raw layer. And I'd post a warning in the analytics channel before diagnosing, so nobody makes a decision off that dashboard.
Red flags
- Starts rewriting transformation logic before checking whether the inputs arrived complete.
- Treats a green orchestrator run as proof the data is right.
Where do data-quality checks belong in a pipeline, and what should happen when one fails at 3 a.m.?
A strong answer layers checks at ingestion, after transformation, and before publication, with a severity policy set by consumer impact — deciding separately whether a failure blocks the publish and whether it pages — and honesty that unactioned checks are decoration.
What to look for
- Places checks at boundaries: on arrival, post-transform, pre-publication.
- Distinguishes blocking failures from warnings instead of paging for everything.
- Owns the follow-through: who gets woken, and what stops stale data reaching users.
Example answerRed flags
Example answer
Three layers. At ingestion: schema, volume, freshness — catch a broken source before compute is spent on it. After transformation: business invariants like 'no negative order totals'. Before publication: reconciliation against a trusted control total. A null-rate drift can wait until morning; a failed revenue reconciliation blocks the publish and pages whoever's on call.
Red flags
- One giant validation at the end of the pipeline, or none until a user complains.
- Every check pages someone — a guarantee the pages get ignored within a month.
A product team wants a dashboard 'in real time'. The data arrives in a nightly batch today. How do you decide what to build?
A strong answer questions the latency requirement before the architecture: what decision changes with fresher data, whether an hourly micro-batch suffices, and what streaming costs in infrastructure and on-call load — then prices both options honestly.
What to look for
- Asks what decision the fresher data would change before quoting an architecture.
- Knows the middle options: micro-batches, incremental loads, hourly refreshes.
- Prices the streaming path in operational burden, not just build time.
Example answerRed flags
Example answer
First question: what breaks at 24 hours old? Most 'real time' asks are satisfied by a 15-minute micro-batch at a tenth of the cost. If they're reacting to live incidents, that's genuine streaming — and I'd say plainly it means new infrastructure, replay handling, and someone on call for it. I've unsold more streaming than I've built.
Red flags
- Builds whatever was asked for without asking what it's for.
- Treats streaming as the default modern answer rather than a cost to justify.
You're building a table other teams will depend on. How do you find out what 'correct' means, and where do you write it down?
A strong answer treats correctness as a definition owned by the consumers — analysts, ML, product — pinned down with concrete edge cases, encoded as automated tests, and documented next to the table itself rather than in a wiki nobody reads.
What to look for
- Names the consumers and gets definitions from them, with edge cases: refunds, cancellations, timezones.
- Turns each agreed definition into an automated check, not just prose.
- Documents at the point of use: column descriptions, owned definitions, a named contact.
Example answerRed flags
Example answer
I ask the people who'll query it to define the tricky rows: does a refunded order count as revenue, whose timezone is 'today'? Those answers become column-level docs and tests — the definition lives with the table, versioned with the code. A metric defined three ways in three people's heads is an argument scheduled for next quarter.
Red flags
- Assumes the source system's values are the definition of correct.
- Documentation means a wiki page written once and never linked from the table.
Questions 5–7
AI questions for data engineer candidates
2026 · AIAI assistants will now write a working SQL query for almost anything you ask. What does your review catch before that query feeds a dashboard?
A strong answer names the failure class that matters: queries that run and return plausible numbers but are wrong — fan-out joins double-counting rows, silently dropped nulls, aggregation at the wrong grain — plus a habit of reconciling against a known total.
What to look for
- Names concrete bug classes: join fan-out, null handling, aggregation at the wrong grain.
- Verifies against a control number they already trust before shipping.
- Reads the join logic itself instead of judging the query by whether output looks sane.
Example answerRed flags
Example answer
The dangerous AI query isn't the one that errors — it's the one that returns numbers 8% high because a join fanned out on a many-to-many key. I check grain first: count distinct keys before and after each join. Then I reconcile one aggregate against a number I trust. AI writes my boilerplate; it doesn't get to define revenue.
Red flags
- Judges a query by whether the output 'looks reasonable'.
- Either refuses AI-written SQL entirely or ships it after a syntax-level skim.
An AI monitoring tool now flags anomalies across your tables — dozens a week. How do you decide which ones matter?
A strong answer calibrates trust deliberately: route flags by table criticality, track the tool's false-positive rate, retune or mute noisy detectors on the record — because an anomaly monitor the team has learned to ignore is worse than none.
What to look for
- Tiers tables by criticality so a flag on a revenue table outranks a staging table.
- Measures the tool's precision over time instead of trusting or dismissing it wholesale.
- Mutes or retunes noisy detectors deliberately, and says who decides that.
Example answerRed flags
Example answer
We turned one of these on and got forty flags the first week — two mattered. I'd tier the tables: anomalies on the dozen business-critical ones get a human look same-day, the rest batch into a weekly review. And I'd track its hit rate; when a detector cries wolf three times, it gets retuned or muted, on the record.
Red flags
- Plans to review every flag manually — that lasts about two weeks.
- Trusts the anomaly score as ground truth without asking how it was computed.
Your tables start feeding an AI feature, not just dashboards. What changes about how you think about data quality?
A strong answer recognizes the consumer changed: a model won't question a suspicious value the way an analyst would, so errors surface as bad user-facing behavior and quality gates, freshness contracts, and lineage must tighten before data ships.
What to look for
- Sees that a model consumes silently — no human eyebrow raised at a weird value.
- Traces the new failure path: bad rows become bad answers shown to users.
- Tightens contracts upstream: stricter gates, freshness guarantees, documented lineage.
Example answerRed flags
Example answer
An analyst who sees order value jump tenfold gets suspicious and pings me. A model just uses it. So checks that used to be advisory become blocking: no publish on failed validation, freshness contracts, and lineage so we can answer 'which outputs did the bad batch touch?' Garbage in used to mean a wrong chart; now it talks to customers.
Red flags
- Treats it as the same pipeline with a different consumer at the end.
- No answer for how they'd trace a bad batch to what it affected downstream.
Questions 8–10
Behavioral data engineer interview questions
Tell me about a schema change you shipped that broke something downstream. Who found it, and what changed afterwards?
A strong answer owns the break, is honest about the worst detail — the consumer found it, not the pipeline team — and ends with a structural fix: deprecation windows, contract checks, consumer notification, not just personal carefulness.
What to look for
- Owns it rather than blaming the consumer for depending on the column.
- Honest about detection — usually the downstream team, which is the painful part.
- The fix is structural: a deprecation process or contract check, not 'I'm more careful now'.
Example answerRed flags
Example answer
I renamed a column during a cleanup and shipped it with the usual review. Finance's month-end report broke — they found it, three days later, which was the worst part. Since then, anything consumed outside the team gets a deprecation window: new column added, consumers notified, old one removed a month later. Boring, and nothing's broken since.
Red flags
- Has never broken anything downstream — they haven't shipped much, or nobody used their tables.
- Frames the lesson as other teams needing to read release notes harder.
Tell me about a pipeline or warehouse whose cost you cut significantly. Where was the waste hiding?
A strong answer names real numbers and a specific waste pattern — full rebuilds of unchanged history, unpartitioned scans, orphaned tables still refreshing — and shows the habit of treating cost as an engineering metric, not finance's problem.
What to look for
- Specific mechanism and rough numbers, not 'we optimized some queries'.
- Found it by looking at cost per job or per table, unprompted.
- Checked who used the expensive thing before deleting or degrading it.
Example answerRed flags
Example answer
Our warehouse bill crept up 30% in six months. The biggest line was a job rebuilding three years of history nightly when only the last two days changed — nobody had revisited it since the table was small. Incremental loading cut that job's compute 95%. Then we found four dashboards refreshing hourly that no one had opened in a quarter.
Red flags
- Never looked at what their pipelines cost to run.
- Cut cost by silently degrading data someone depended on.
Tell me about handing a dataset or data model you built over to people who had to run it without you. What did they struggle with?
A strong answer names what the documentation missed — usually the why behind odd logic and the manual recovery steps — and shows the handoff was tested by watching someone else operate the pipeline, not by writing more pages.
What to look for
- Tested the handoff: someone else ran a failure drill or an on-call week before it counted.
- Documented the why — deliberate oddities, known quirks of sources — not just the how.
- Kept a feedback channel open after the handoff instead of declaring it done.
Example answerRed flags
Example answer
Before I changed teams I handed my ingestion jobs to two teammates. The docs covered the happy path; what they lacked was why the dedupe step existed — a vendor resends altered files. First failure, my successor nearly removed it. Now I write a 'weird on purpose' section and have the new owner run a simulated failure before I leave.
Red flags
- Believes the pipeline is self-documenting because the code is clean.
- Handoff was a single walkthrough meeting with no written trace.
Questions 11–13
Situational data engineer interview questions
You discover a bug has been corrupting one column of a heavily used table for six weeks. Walk me through the fix — history included.
A strong answer sequences the recovery: stop the ongoing corruption, size the blast radius, tell affected consumers before the backfill, then rebuild history into a staging copy validated against trusted totals, rather than rewriting a live table with no rollback.
What to look for
- Stops the bleeding and notifies consumers before starting the rebuild.
- Backfills into a staging copy or an equally reversible path, and validates before swapping.
- Identifies decisions or reports made off the bad six weeks, not just the rows.
Example answerRed flags
Example answer
Fix the transform so today stops adding damage. Then scope it: which partitions and downstream tables inherited the bad column. Consumers hear from me before the fix, with dates — someone may have shipped a board number off it. The backfill runs into a shadow table, I reconcile aggregates against source, then swap — keeping the old table until the numbers check out.
Red flags
- Starts the backfill before anyone downstream knows the data was wrong.
- No validation step between rebuilding history and swapping it in.
A source team announces a breaking change to their data feed, shipping in two weeks. Five of your pipelines consume it. What do you do?
A strong answer negotiates the seam, not just the date: sample payloads early, dual-format tolerance so cutover isn't a cliff, a staging test against the new feed, and a push for a data contract to prevent the next surprise.
What to look for
- Asks for sample data and a parallel-run period rather than just a date.
- Makes the pipelines tolerate both formats so the cutover isn't one risky night.
- Uses the incident to establish a data contract or change-notice policy.
Example answerRed flags
Example answer
First, get the new format now — samples or a staging feed — not on release day. I'd make ingestion accept both shapes, so their deploy date stops being my incident window, and run the new format through staging to see what breaks. And since this happened with two weeks' notice only by luck, I'd push for a change-notice contract.
Red flags
- Plans a single big-bang cutover the night their change ships.
- Accepts the two-week timeline as fixed without asking for samples or a delay.
Two dashboards show different numbers for the same metric, and executives have noticed. Both teams insist theirs is right. How do you settle it?
A strong answer traces both numbers to source to find the divergence — a definition fork, a query bug, or bad data — then drives to one owned definition and one certified table so the argument cannot recur next quarter.
What to look for
- Treats it as lineage work: traces both queries to source rather than voting.
- Names the likely suspects — definition forks, query bugs, source gaps — instead of guessing.
- Ends with one owned metric definition and one certified source, deprecating the other path.
Example answerRed flags
Example answer
Often both are 'right' for different definitions — but I rule out a plain bug first. I'd diff the two queries against source: one included cancelled orders, or counts in UTC versus local time. I bring both teams the fork, the business owner picks one definition, and both dashboards point at one certified table.
Red flags
- Picks the number from the more senior team to end the argument.
- Fixes this instance without creating a single defined source, guaranteeing a repeat.
Scoring rubric
| Score | Evidence anchor |
|---|---|
| 1 | Talks tools and job titles. No diagnostic order for a broken pipeline, no notion that data has consumers, treats a green run as success. |
| 2 | Can build a pipeline that works on the happy path, but quality checks, backfill safety, and downstream impact only come up when prompted. |
| 3 | Solid fundamentals: checks inputs before logic, layers validation deliberately, and has broken something downstream and changed a process because of it. |
| 4 | Strong across all four sections: prices cost and latency trade-offs honestly, treats consumers as part of the system, reviews AI-written transformations with named failure modes. |
| 5 | Teaches you something: their own frameworks for contracts, backfills, and trust calibration, numbers from real incidents, and a tested view on serving data to AI systems that didn't come from a blog post. |
Frequently asked questions
Which data engineer interview questions work best for a first-round interview?
The silent-failure diagnostic, the quality-check question, and the AI-written SQL question give a hard-to-bluff signal in 20 minutes. Kira can run this subset as a short voice interview with every applicant before you spend an engineer's hour.
What do strong data engineer interview questions and answers have in common?
They test judgment on running data systems, not syntax recall: diagnostic order for a bad load, where checks belong, who consumes the table. Trivia quizzes select for memorization; production stories select for engineers you can put on call.
How should senior data engineer interview questions differ from this set?
Keep the questions, raise the altitude: contracts between teams, cost and on-call policy they would set, mentoring engineers who lean on AI tools. The seniority notes below adjust each level; seniors should bring numbers from their own incidents.
Do interview questions for a data engineer need to match our exact stack?
No — this set is deliberately stack-neutral: the diagnostic principles transfer across vendors even where platform behavior differs. Judgment about failure, quality, and consumers is the hard part; tool syntax is the easy part. Screen for the first, train the second.
Should a data engineer interview include a live SQL exercise?
A short one helps if it tests judgment — reviewing a query with a fan-out bug beats writing one from scratch. Cap it at 30 minutes; fluent query writers often have never run a backfill.
Seniority notes
- Junior (0–2 years)
- Weight the role-specific section and expect textbook diagnostic order rather than incident stories; care is the signal — probe whether they check inputs unprompted when numbers look off in their own projects.
- Mid-level (2–5 years)
- The full set applies as written. Expect at least one owned production incident — a bad backfill, a broken consumer — and a real opinion on where quality checks belong.
- Senior (5+ years)
- Push toward platform ownership — data contracts across teams, the on-call and cost policies they'd set, mentoring engineers who ship AI-written transformations — and ask for the numbers from their biggest incident.