Data Engineer Interview Questions for Hiring Managers
The most useful data engineer interview questions ask how a candidate knows the data is right. Tool questions have their place, but a pipeline can use the right warehouse, the right orchestrator and the right transformation framework and still double-count orders after a rerun, lose late events from a mobile app, or drop a column when an upstream team renames it. Those failures rarely raise an error. They show up weeks later as a number nobody trusts.
These 15 questions are built around that problem, and they share one example: a grocery delivery company with orders in a Postgres database, delivery events from a driver app, price changes from stores, and a warehouse that feeds operations and finance reporting. The notes on what good answers tend to include are a basis for the conversation; a candidate who reaches a different, well-argued design may be giving you the better answer.
What These Data Engineering Interview Questions Assess
They assess five things: SQL and modeling judgment, pipelines that are safe to rerun, handling of late and changing data, quality checks that catch silent failure, and care with storage, privacy and migrations. Weight them toward the work. A role that maintains dbt models on a stable warehouse needs depth in modeling and testing; a role building ingestion from a dozen vendor APIs needs more on retries, deduplication and contracts.
If you are still defining the role, the data engineer job description template helps you pin down what the engineer will own before you interview. And keep the limits of an interview in view: it gives you evidence about reasoning, while how someone performs on your pipelines is the real evidence.
SQL and Data Modeling Questions
1. What Is the Grain of This Table, and Why Does It Matter?
Show the candidate an orders fact table and ask what one row represents. A strong answer names the grain precisely, such as one row per order line per fulfillment attempt, and explains what goes wrong when grains are mixed. If a promotion discount is stored on the order but summed at the line level, every multi-item order overstates the discount.
The signal is whether the candidate asks about grain before writing any query. Engineers who have been burned by it tend to ask first.
2. Write a Query That Returns Each Store’s Current Price per Product
The input is a log of price changes with store, product, price and effective timestamp. Most candidates will use a window function, ranking rows by effective time within each store and product and keeping the latest. Follow up on the details that break real queries: two changes with the same timestamp, a future-dated price that should not be current yet, and a product that was delisted. How the candidate handles ties and nulls tells you more than whether they know the syntax.
3. How Would You Keep Price History When the Source Overwrites It?
The store system only holds the current price, but analysts need to know what a customer paid last March. A type 2 slowly changing dimension is the usual answer: keep a row per version with valid-from and valid-to timestamps. In dbt, snapshots implement this pattern over mutable source tables, using either an updated-at timestamp or a comparison of chosen columns to detect changes. Source: dbt documentation, snapshots
Then ask what the approach misses. A snapshot records the state it sees when it runs, so a price that changes twice between runs keeps only the second change. A candidate who suggests capturing change events from the source database when every intermediate value matters understands the limit.
4. Order Times Arrive in Local Time From Three Time Zones. What Do You Do?
Good answers store timestamps in UTC with the store’s time zone alongside, and derive the business date from local time, because “orders on Tuesday” means Tuesday for the store, not for the warehouse server. Probe daylight saving transitions: an hour that happens twice in autumn will make a naive conversion assign orders to the wrong hour or reject them. Candidates who have dealt with this usually have a specific story.
Pipeline and Orchestration Questions
5. How Do You Make a Daily Load Safe to Rerun?
Reruns happen after failures, fixes and backfills, so the load must produce the same result whether it runs once or three times. Strong answers replace the partition being loaded, or merge on a stable key, instead of appending. Ask about the case where the source itself changed between runs, such as an order cancelled after the first load. The candidate should decide, explicitly, whether a rerun reflects the source now or as it was.
6. The Job Computes “Yesterday” From the Current Clock. Why Is That a Problem?
When that job is rerun or backfilled for last month, it still processes yesterday. Orchestrators such as Airflow give each run a data interval, and the documentation advises turning catchup off for a pipeline that is not written to respect its interval and works from the current time instead. Source: Apache Airflow documentation, DAG runs
A strong candidate parameterizes every job by the interval it processes, so a backfill of 30 days runs 30 correct, independent loads. This is one of the clearest separators between engineers who have run backfills and those who have only scheduled jobs.
7. A Pipeline Run Shows Success but One Task Failed. How?
Airflow decides a run’s status from its leaf tasks, and the same documentation warns that a leaf task with an “all done” trigger rule will run whatever happened upstream; if it succeeds, the whole run can be marked successful even though something failed in the middle. A cleanup or notification task at the end of the graph is the typical culprit.
Ask how the candidate would prevent it: an explicit final check that depends on every critical task, alerting on task failures as well as run failures, and data-level checks that do not care what the orchestrator reported.
8. Delivery Events From the Driver App Arrive Hours Late. How Do You Handle Them?
Drivers lose signal in parking garages, and the app uploads events when it reconnects. Good answers separate event time from arrival time, reprocess a trailing window (for example, the last few days) on each run so late events land in the right day, and decide when a day’s numbers are final. In streaming systems, the same idea appears as watermarks with a stated allowed lateness.
The follow-up is the business rule: if finance closes the week on Monday, what happens to an event that arrives Tuesday? A candidate who turns that into a question for the data’s owners, instead of a silent technical choice, is thinking about consumers.
Data Quality and Contract Questions
9. How Would You Know a Pipeline Silently Dropped Rows?
Row counts compared with the source for the same interval, freshness checks on the newest record, volume checks against the usual range for that weekday, and uniqueness and not-null tests on keys are the usual layers. Strong candidates put checks at the boundaries, where data enters and where it is handed to consumers, and give each one an owner who is alerted. A failing check that alerts nobody gets noticed only when someone happens to read the logs, usually after a report has gone out.
10. An Upstream Team Renamed a Column Without Telling You. What Now?
The immediate response is to stop the bad data from reaching reports: fail the load or quarantine the batch, tell consumers, and fix the mapping. The more useful part of the answer is prevention. Look for schema contracts agreed with source owners, checks that run in the source team’s pipeline before their change ships, and alerts on schema drift at ingestion. Ask how the candidate would persuade an application team to accept a contract they did not ask for.
Storage, Performance and Privacy Questions
11. How Would You Partition and Cluster the Orders Table?
The answer should start from queries. If most reports filter by order date and region, partition by date and cluster or sort by region and store. Ask about the opposite failure too: partitions so fine that each holds a tiny file, which slows reads and inflates metadata. The candidate should know how to check whether a query is actually pruning partitions in your warehouse.
12. Should Duplicates From Overlapping API Batches Be Removed in the Pipeline or in Storage?
Vendor APIs often return overlapping windows, and retries repeat batches. Either layer can deduplicate, but what each one promises differs. ClickHouse’s ReplacingMergeTree, for example, removes duplicates with the same sorting key during background merges at an unscheduled time, so duplicates can remain until a merge happens; the documentation recommends query-time deduplication with FINAL for correct results. Source: ClickHouse documentation, ReplacingMergeTree
A strong candidate asks which consumers need exact answers and designs for them. Billing and payouts usually warrant a deduplicated, immutable record; an exploratory dashboard may tolerate eventual cleanup.
13. Should Inventory Updates Be Streamed or Batched?
Ask what the business does with the data. If store managers restock once a day, hourly batches are simpler and cheaper to run correctly. If the app must stop selling an item the moment it runs out, a stream of stock changes may be justified. Good candidates name the operational cost of streaming (ordering, replays, state, on-call) and do not choose it because it sounds more advanced.
14. How Do You Handle Customer Addresses and Phone Numbers in the Warehouse?
Collect only what analysis needs, mask or tokenize direct identifiers, restrict raw access to a small role, and log who queries sensitive columns. Then ask about a deletion request. The candidate should trace where a customer’s data has spread, including derived tables, extracts sent to vendors and backups, and explain how deletion reaches each, or why a given copy is exempt under the company’s policy.
15. How Would You Move a Pipeline to a New System Without Breaking Consumers?
Look for a parallel run in which old and new pipelines process the same inputs, automated comparisons of outputs at the grain consumers use, a defined tolerance for differences, and a cutover consumers agree to, with the old path kept available for rollback. Ask what they did the last time the outputs did not match. The answer usually reveals a definition one system had applied silently for years.
Practical Assessments for Data Engineers
| Format | Time | Best at revealing | Trade-off |
|---|---|---|---|
| SQL exercise on a small realistic dataset | 45 minutes | Grain awareness, window functions, edge cases | Narrow view of pipeline design |
| Pipeline code review with planted defects | 30 to 45 minutes | Rerun safety, interval handling, testing habits | Less signal on writing new code |
| Design discussion for one new source | 45 to 60 minutes | Late data, contracts, privacy and cost reasoning | Depends on interviewer preparation |
For the code review, give the candidate a short job that appends instead of replacing, reads the current date instead of its interval, and has no check on row counts. Ask them to rank the problems by consequence, and see whether they connect each one to a specific consumer who would be misled.
A Rubric for Data Engineering Interviews
Score each area from 1 to 4, where 1 means no usable evidence, the mid-level column describes a 2 or 3 and the senior column describes a 4, and have each interviewer write down the specific evidence before anyone compares notes. The scale organizes the conversation; it has not been validated as a predictor, and an average should never hide weakness in an area the person will own alone.
| Area | Mid-level evidence | Senior evidence |
|---|---|---|
| SQL and modeling | Writes correct queries and names the grain | Designs models and history for several consumers |
| Pipelines | Builds idempotent, interval-based jobs | Plans backfills and recovery across dependent pipelines |
| Late and changing data | Handles late events with a reprocessing window | Agrees finality rules and contracts with data owners |
| Quality | Adds tests at boundaries | Designs checks that catch silent loss and assigns ownership |
| Storage, privacy, migration | Partitions sensibly, restricts sensitive columns | Runs parallel migrations and traces data for deletion |
Red Flags in Data Engineer Answers
Probe further when a candidate appends by default, computes dates from the clock, treats a green run as proof of correct data, cannot say what a table’s grain is, or chooses streaming without a business reason. Vague answers about data quality (“we had tests”) deserve a request for one specific check and the failure it caught. One weak answer calls for another question; a pattern across the work the role owns is more telling.
How Gun.io Looks at Data Engineering Fit
At Gun.io, we want to hear how an engineer proved their data was right, and the stack they used comes second. On a venture firm’s user acquisition funding platform, that meant separating two kinds of data that are easy to mix: our engineer kept fast-moving analytics in ClickHouse and built a PostgreSQL billing portal that records approved spend and fees as fixed history, so invoices stay the same even as the formulas behind the analytics change. Two of the ad platform integrations also moved to month-based chunks so high-volume pulls stayed reliable.
We judge technical capability and professional fit in human interviews, then keep judging on delivered work, because that is the stronger evidence. Many data roles overlap with analytics or modeling, so it helps to be clear about where data engineering ends and data science begins before choosing between them. You can see how we work with SQL and data engineers and the wider set of engagement models and engineering areas we cover.
Frequently Asked Questions
What Is a Good First Data Engineer Interview Question?
Ask the candidate to describe a pipeline they owned end to end: the sources, the consumers, what broke and how they found out. It sets up every technical follow-up and shows quickly whether their experience is in building, operating or both.
Should Data Engineers Be Tested on Python or Only SQL?
Test both if the role uses both, which most do. SQL covers modeling and transformation; Python or another language covers ingestion, API clients, testing and orchestration code. Keep the programming exercise close to the work, such as parsing a paginated API response, rather than an abstract algorithm.
How Do You Interview a Data Engineer for a Small Company?
Lean toward breadth and judgment. A first or second data engineer often owns ingestion, modeling, quality and stakeholder conversations at once, so ask how they decided what not to build and how they explained trade-offs to people who only wanted the dashboard.
Do Data Engineers Need Cloud Certifications?
No. A certification can show familiarity with a platform’s services, but it does not show the candidate can design a rerunnable load or handle late data. Spend the interview on systems they have built and treat certifications as background.
How Is a Data Engineer Interview Different From a Data Scientist Interview?
A data engineer interview focuses on moving, modeling and protecting data reliably; a data scientist interview focuses on analysis, statistics and models built from that data. The overlap is SQL and an understanding of what consumers need, but the failure modes you probe are different.
How Should Nontechnical Managers Evaluate Data Engineer Answers?
Compare answers to written notes, listen for specific failures and fixes, and ask follow-ups when the answer stays at the level of tool names. For the final decision, combine your notes with an assessment from an engineer or analyst who can judge the SQL and the design.
Hire Data Engineers Who Can Prove the Numbers
The engineer worth hiring treats correctness as something to demonstrate with checks, reruns and comparisons, not something to assume from a green run. If you are planning a data hire, talk to us about the data you need to trust: the sources, the consumers, what breaks today and who will own the pipeline.
