Data Engineer Interview Questions
Data Engineer interviews test something narrower than "can you write SQL and build a pipeline." At any company running real production data, the job comes down to trust - can leadership make a decision off the number you produced at 3 AM after a job failed and you patched it under pressure. This guide covers the scenarios that separate engineers who ship dashboards from engineers who get trusted to own the data platform.
What Data Engineer Interviews Test
Incident judgment under time pressure - whether you patch the symptom or find the root cause before a reporting deadline forces your hand. System design trade-offs like batch versus streaming or cost versus latency, where the interviewer wants a defensible trade-off, not a textbook answer. Data quality ownership - catching silent breakage before it reaches a dashboard, not after someone else notices. Cross-team negotiation, since most pipeline breakage traces back to a decision another team made, and fixing it means influencing people who don't report to you. And compliance literacy - GDPR and data deletion aren't purely a legal team's problem.
Question 1: The 3 AM Pipeline Failure Before a Board Meeting
You're a Data Engineer at a Series C fintech. The nightly ETL pipeline feeding the executive revenue dashboard failed at 3 AM. Finance needs reconciled Q3 revenue numbers by 9 AM for a board meeting. Logs show a downstream table failed to load, but you don't yet know why. What do you do first, and what do you tell finance?
Why interviewers ask this
This tests whether a candidate treats a technical failure as a business incident. Weak candidates go quiet for hours while they debug. Strong candidates communicate immediately with a realistic timeline, separate "restore the data" from "explain what happened," and know when a manual stopgap is smarter than waiting for a full root-cause fix.
Example strong answer
The first move isn't the terminal, it's a message to finance within fifteen minutes: "Pipeline failed overnight, investigating now, will have a status update by 6 AM." Silence is worse than an honest "I don't know yet." In parallel, check whether the failure is isolated to one task in the DAG or cascading through downstream dependencies - that tells you the blast radius. Then triage the cause: a schema drift issue where an upstream team renamed or dropped a column, a resource issue like an out-of-memory error or timeout, or a data quality issue like unexpected nulls breaking a join. Each has a different fix and a different time estimate, which is exactly what finance needs to hear instead of "we're on it." If the board meeting genuinely can't move, use the last known-good snapshot with an explicit caveat rather than forcing a risky rerun under time pressure - a slightly stale number with a clear caveat is safer than a rushed fix that fails again at 8:45 AM. Once the immediate fire is out, the job isn't done. Write a blameless post-mortem and push for the fix that actually prevents recurrence - a schema contract with the upstream team so breaking changes are caught before they ship, or an alert that fires the moment the pipeline fails instead of when someone notices the dashboard looks wrong. The candidates who get promoted are the ones who treat the 3 AM page as a symptom of a process gap, not just a ticket to close.
Follow-up questions
- What do you do if finance already used a stale cached number in a slide before you had a chance to tell them?
- What if the root cause turns out to be a change your own team shipped last week?
Question 2: Two Teams, Two Different Numbers
Marketing and Finance are both reporting "monthly active users" for tomorrow's all-hands, and the numbers differ by 18%. Both pull from tables you maintain. The VP wants an answer before the meeting, not a debugging session.
Why interviewers ask this
This tests reconciliation skill and communication under executive scrutiny - not just SQL ability, but whether the candidate can explain a discrepancy clearly without technical jargon and without making either team look incompetent.
Example strong answer
Start with definitions, not queries: is "active" defined the same way for both teams - session-based versus login-based, a 28-day window versus a 30-day window? Discrepancies this size are usually a definitional mismatch, not a bug. Next, check whether one team queries a raw table and the other an aggregated or deduplicated view, and whether time zone or cutoff boundaries differ between the two pipelines. Once the source of the gap is found, the fix isn't just a quiet patch - document the discrepancy in a shared metrics definition doc, and propose that data engineering own a single canonical definition of MAU that both teams pull from going forward, rather than leaving each team to interpret it independently. Walking into the VP conversation with "here's exactly why they differ, and here's how we stop this from happening again" lands very differently than "we're still looking into it."
Follow-up questions
- What if the discrepancy turns out to be legitimate - marketing includes trial users, finance doesn't - rather than a bug?
- How do you prevent this exact conversation from happening again for the next metric?
Question 3: The Warehouse Bill That Quadrupled Overnight
Your data warehouse bill jumped 4x overnight after a teammate shipped a "small" pipeline change. Finance is asking questions. You need to find and fix the cost driver without breaking a pipeline that's currently running fine for everyone downstream.
Why interviewers ask this
This tests cost-awareness, which is often exactly what separates a mid-level data engineer from one trusted to own platform economics, and the ability to debug without introducing a new outage.
Example strong answer
Start with cost attribution - most warehouses expose query-level cost history, so isolate the specific job or query responsible rather than guessing. Likely culprits: a join that started returning far more rows than expected because of a schema change upstream, a query that used to be partition-pruned and now scans the full table, a clustering key that got dropped in the change, or a job frequency that quietly increased. Fix at the query level first - restore the partition filter, correct the join - rather than reverting the whole change blindly, since the teammate's change likely fixed something real too. Once stable, add a cost-anomaly alert so a 4x spike gets caught in an hour, not discovered by finance a day later. And give finance a real number, not a placeholder - "the fix ships today, and it caps the increase at roughly X" is a materially better answer than "we're looking into it."
Follow-up questions
- What if the fix requires temporarily pausing a pipeline other teams currently depend on?
- How would you build a guardrail so a single PR can't 4x spend again without anyone noticing?
Question 4: A GDPR Deletion Request Into 18 Months of History
A user requests full data deletion under GDPR. Their data has been denormalized into 18 months of historical snapshot tables, a feature store, and a few ad hoc CSV exports analysts made along the way. Legal wants confirmation of full deletion within the regulatory window.
Why interviewers ask this
This tests whether the candidate understands that compliance isn't a problem that resolves itself once legal asks for it - it's an architecture and process problem the data engineer actually owns.
Example strong answer
The first step is mapping every place the data could physically live - source tables, derived and aggregated tables, backups, feature stores, and any ad hoc exports - which requires either existing data lineage tooling or manual tracing if none exists. Rather than treating this as a one-off manual deletion job, the stronger move is building a reusable deletion pipeline, because this request will recur and a one-off script doesn't scale. The ad hoc CSV exports are usually the real finding here, not a footnote - they represent a governance gap where PII left the controlled environment entirely, and flagging that gap to leadership matters as much as completing this specific ticket. A senior answer treats the individual deletion request as the trigger for fixing the underlying process, not just closing the ticket.
Follow-up questions
- What if backups can't be selectively edited without restoring the entire backup?
- What do you tell legal when a full, immediate guarantee genuinely isn't technically possible within their timeline?
Question 5: Batch to Streaming - Make the Call
Product wants to migrate a core pipeline from nightly batch (6-hour latency) to streaming (90-second latency) to support a new real-time feature. The streaming architecture roughly doubles infrastructure cost. You're asked to make the recommendation, not just implement whatever gets decided.
Why interviewers ask this
This tests architectural judgment and business framing - whether the candidate can connect a technical decision to real product impact instead of defaulting to "streaming is the modern choice."
Example strong answer
The first move is pushing back on the requirement itself, respectfully: does the feature genuinely need 90-second freshness, or would 15-minute micro-batches solve the actual user problem at a fraction of the cost? Many "we need real-time" requests are really "we need faster than 6 hours," which streaming isn't the only way to solve. If the cost is going to double, quantify the actual business value of the latency improvement - does faster data change what a user does, or is it a vanity metric that looks impressive in a roadmap slide? Where streaming is genuinely justified, a middle path is often stronger than an all-or-nothing rebuild: stream only the specific hot-path tables the new feature actually touches, keep batch for everything else, rather than migrating the whole pipeline and taking on the full cost and migration risk at once.
Follow-up questions
- What if leadership already promised the real-time feature to a customer before checking technical feasibility?
- How do you stage the migration to avoid a risky big-bang rewrite?
Question 6: The Silent Schema Break From Another Team
An upstream team renamed a column without telling anyone. It didn't error - it just silently populated a downstream field with nulls, and 12 dashboards have been quietly wrong for four days before anyone noticed.
Why interviewers ask this
This tests whether the candidate designs for failure detection, not just failure handling - the most dangerous data bugs are the silent ones that never throw an error.
Example strong answer
Immediate triage means figuring out exactly which dashboards and decisions were affected over those four days and communicating the scope honestly, rather than downplaying it to avoid an uncomfortable conversation. Fix the immediate break by correcting the mapping. But the answer that actually matters here is systemic: propose schema validation or data contracts that fail loudly - an alert, a blocked deploy - the moment an unexpected null rate or type change appears, instead of a dashboard quietly going wrong for days. The deeper cultural shift is getting upstream teams to treat schema changes as an API contract with their downstream data consumers as real stakeholders, not an internal refactor they're free to make silently. That reframing, more than any single alert, is what prevents the next version of this exact incident.
Follow-up questions
- How do you get a team that doesn't report to you to actually adopt a data contract process?
- What if this exact failure mode has already happened twice before and nothing changed?
Question 7: A Slow Production Query Blocking a Launch
A dashboard query that used to run in 3 seconds now takes 4 minutes, and it's blocking a product launch tomorrow that depends on it loading fast during a live demo.
Why interviewers ask this
This tests query optimization depth under real time pressure, not in the abstract - and whether the candidate can distinguish a real fix from a Band-Aid, and say so honestly.
Example strong answer
Start with the query execution plan, not guesses: is it a missing index or partition prune, a join order problem, stale table statistics, or data volume that's simply outgrown the original design? Apply the targeted fix that matches the actual cause - restoring an index, rewriting a join, pre-aggregating a table - rather than a generic "add more compute" fix that masks the real problem. If a proper fix genuinely can't land before the deadline, a materialized view or cached result is a legitimate short-term mitigation, but it has to be labeled clearly as temporary, with a concrete follow-up plan, not quietly left in place as the permanent solution.
Follow-up questions
- What if the root cause is data volume that will keep growing, meaning today's fix breaks again in three months?
- How do you tell a demo-anxious product manager "I have a Band-Aid, not a cure" without sounding like you haven't solved anything?
Question 8: The Backfill That Won't Finish in Time
You need to backfill six months of historical data into a redesigned pipeline. At the current rate, it will take 11 days. Stakeholders want it done by Friday - in 3 days.
Why interviewers ask this
This tests practical orchestration knowledge and the ability to actually parallelize or optimize a real workload, not just do throughput math on a whiteboard.
Example strong answer
First identify the actual bottleneck: is the backfill serialized when it could run in parallel, hitting an external API's rate limit, or constrained by compute resources? Once the bottleneck is clear, options open up - partition the backfill by date range and run those partitions in parallel, temporarily scale up compute for the duration of the job, or reduce scope by backfilling the two most business-critical months first with the remainder following afterward. The honest move is presenting the real trade-off to stakeholders rather than quietly trying to force the original timeline and risking a rushed, error-prone job. "Here's what's achievable by Friday, and here's the plan for the rest" is a stronger answer than overpromising and delivering something broken.
Follow-up questions
- What if parallelizing the backfill risks overwhelming a downstream system that isn't built for concurrent writes?
- How do you decide what to descope if the full backfill genuinely can't finish by Friday?
Question 9: Cross-Team Negotiation Over a Breaking Change
Your team needs to change a core table's schema to unblock a new feature, but three other teams consume that table, and one says the change will break their pipeline and they can't prioritize a fix for two sprints.
Why interviewers ask this
This tests influence without authority, which is an underrated and enormous part of the role - most data engineering failures are organizational, not technical.
Example strong answer
The instinct to escalate immediately is usually premature. Start by understanding the other team's actual constraint - is it genuinely a capacity problem, or do they simply not understand the urgency and impact of the change? A strong path forward often reduces their cost directly: dual-write both the old and new schema for a defined deprecation window, provide a ready-made migration script, or offer to pair directly on their side of the change instead of just handing them a spec. If it's genuinely blocked after that, escalate with a clear, neutral framing of the trade-off for a decision-maker - not a complaint about the other team, but the actual business cost of each path forward. Preserving the working relationship matters as much as unblocking the feature, since this won't be the last time the two teams need to coordinate.
Follow-up questions
- What if the two-sprint delay genuinely blocks a committed launch date?
- How do you rebuild trust with that team if this negotiation gets contentious?
Question 10: Owning a Metric Nobody Trusts Anymore
Leadership has stopped trusting a core reporting metric because it's been wrong twice in the past quarter due to pipeline bugs. You're asked to fix the immediate bug, but the real problem is an organization-wide trust deficit in the data team's numbers.
Why interviewers ask this
This is a senior-level question that tests whether the candidate thinks past the ticket to the systemic reputational problem - exactly what separates a data engineer from someone trusted to eventually run the data platform.
Example strong answer
Fix the immediate bug transparently, but the answer that actually matters is the systemic proposal: automated data quality checks with a visible pass/fail status stakeholders can see for themselves, a documented metric definition with a named owner, a change log so people can see when and why a number moved, and proactive communication before numbers get used in a decision rather than after something breaks. Trust doesn't come back from a single announcement or an apology - it comes back from a visible pattern of reliability over weeks and months, and the strongest candidates describe that as a deliberate program of work, not a one-time fix.
Follow-up questions
- How do you actually measure whether trust is being rebuilt, rather than just assuming it is?
- What do you do if leadership wants a quick PR fix - a caveat footnote - rather than the deeper investment you're proposing?
Preparation tip
The through-line across all ten questions is the same: a Data Engineer who gets offers treats every technical incident as also a communication and trust problem, and every fix as an opportunity to prevent the next version of the same failure. Candidates who only talk about the SQL or the DAG configuration are describing the job at the level of a ticket. Candidates who also talk about who they told, when, and what changed afterward are describing the job at the level people actually get promoted for.