What do data engineer interviews ask most?

Pipeline design, SQL and data modelling, batch against streaming, data quality, performance and cost, and for senior roles platform choices and leading engineers.

Is there a coding round?

Usually: SQL questions, and often a small Python task. Practise both, and explain your reasoning as you go.

Do I need to know Spark?

For large data, often yes. For teams on a cloud warehouse with dbt, strong SQL and modelling count for more.

Do certificates help?

A cloud data certificate helps at consultancies and some large companies. Pipelines you built and ran count for more.

How should I prepare in a week?

Say the two worked answers out loud, practise SQL joins and window functions, and prepare one story each about a failure, a speed-up and a cost saving.

Data engineer interview questions, with worked answers

Sixteen questions that data engineer interviews ask again and again, from first data job to lead and data architect. For each: what the interviewer is checking, a short answer, the full answer in plain words, a weak answer to avoid, and a likely follow-up.

The cvscored teamPublished 27 Oct 2026 · Updated 27 Oct 2026

Contents

How to use these questions
What a data engineer is expected to know
Pipeline design
Data modelling and SQL
Data quality and running pipelines
Big data, performance and cost
Platforms, standards and leading engineers
Your CV for these questions
Key takeaways
Frequently asked questions
More on the data engineer role

How to use these questions

Read the short answer and say it out loud. That is your first thirty seconds. Then read the full answer and pick two or three points to add, with an example from your own work: the size of the data, the tool, what broke and what you changed. Interviewers want reasons, not a list of tools.

What a data engineer is expected to know

Languages: SQL in depth, and Python for pipeline steps and small tools.
Processing: batch (large amounts on a schedule) and streaming (events as they happen), with tools such as Spark and Kafka.
Orchestration: running steps in order with retries and alerts, for example in Airflow.
Modelling: how to shape tables for the people who use them, often as dbt models in a warehouse such as Snowflake.
Cloud: the data services of AWS, Azure or Google Cloud, and what they cost.
Engineering habits: Git, tests, CI/CD and Docker, the same as software engineers.
Law and trust: personal data under GDPR (EU) and similar laws: what is kept, for how long, and who may see it.

Pipeline design

Design a pipeline that loads yesterday's orders from the shop database into the warehouse every night.

What they check: that you think about the whole journey: source, load, checks, failure and the people who use the result.

Short answer: "I copy only the changed rows from the source, land them raw in storage, then clean and model them in the warehouse. The steps run in an orchestrator with retries. Every run can be repeated safely, checks stop bad data reaching reports, and someone is alerted if it is late."

The full answer, in six steps:

Ask first. Who uses the data, by what time, and how fresh must it be? A report read at nine in the morning sets the deadline for the whole chain.
Extract gently. Read from a replica of the database, not the live one, and take only rows changed since the last run, using an updated-at column or change data capture (reading the database's own log of changes).
Land raw. Store the copy as it came, in a raw area of the data lake or warehouse, split by day. If later steps go wrong, you can rebuild from here without asking the source again.
Transform. Clean types, remove duplicates, join to customers and products, and build the tables the reports read, for example with dbt models.
Check. Row counts against the source, no empty keys, totals within the usual range. A failed check stops the run before the report updates.
Run and watch. An orchestrator such as Airflow runs the steps in order, retries short failures, and alerts the team if the data is not ready on time.

A weak answer: "I write a script that copies the whole table every night." It works until the table is large, and then it loads the source and breaks the deadline.

Follow-up: "The job failed at step four and ran again. Do you now have orders twice?" Not if each step is idempotent: running it twice gives the same result as running it once, for example by replacing a whole day's partition instead of adding rows.

When would you choose streaming instead of batch?

What they check: that you choose by what the business needs, not by what is exciting.

Short answer: "Batch, on a schedule, is simpler and cheaper, and right for most reports. Streaming is worth it when someone acts on the data within seconds or minutes: fraud checks, stock levels, live tracking. I ask how fresh the data must really be before I choose."

The full answer: Streaming means handling each event as it arrives, often from Kafka, a system that stores streams of events in order. It brings new problems: events arrive late or twice, the order can change, and the system runs all the time, so someone must be on call. Micro-batch, running small batches every few minutes, is a middle way that many teams use. If the answer to "how fresh?" is "by tomorrow morning", batch wins.

A weak answer: "Streaming is always better because the data is real-time." Follow-up: "An event arrives two hours late. What happens to yesterday's totals?" Use the time the event happened, not the time it arrived, allow a window for late events, and correct the totals when they come.

What do you do when a source system changes its schema without telling you?

What they check: that you expect change and protect the people downstream.

Short answer: "I detect it before it breaks reports: the load checks the columns and types it expects. A new column can be let through; a removed or renamed one stops the run and alerts us. Then I agree with the source team how changes are announced in future."

The full answer: A schema is the list of columns and their types. Landing data raw first helps, because nothing is lost when the shape changes. Formats such as Avro or Parquet carry their schema with them, and a schema registry keeps the agreed versions for streams. The lasting fix is a data contract: a written agreement with the source team on the fields, their meaning and how much notice a change needs.

A weak answer: "I fix the pipeline when it breaks." Follow-up: "The source team says they cannot give notice." Ask for a test copy of their changes, or read from an event they publish on purpose instead of their internal tables.

Data modelling and SQL

How would you model sales data so analysts can use it easily?

What they check: that you shape data for the questions people ask, and know the common patterns.

Short answer: "I would build a star schema: a fact table with one row per sale and the numbers, surrounded by dimension tables for customer, product, shop and date. Analysts join from the facts to whatever they want to slice by, and the rules live in one place."

The full answer: A data model is the way tables are shaped and linked. In a star schema, facts are events with numbers (a sale, a click) and dimensions describe them (who, what, where, when). It is easy to read and fast in a warehouse. Decide the grain first, meaning what one row means, because mixing grains causes double counting. For history, such as a customer who moves city, a slowly changing dimension keeps the old row with dates instead of overwriting it, so old sales still count for the old city.

A weak answer: "I would put everything into one big table." Follow-up: "Finance and sales count revenue differently." Agree one definition with both, write it down, and build it once in the model, with a separate measure if they really need two.

A query that used to take seconds now takes twenty minutes. How do you find out why?

What they check: a calm, ordered way of finding the slow part.

Short answer: "I read the query plan to see which step takes the time, then check what changed: more data, a new join, missing statistics, or a filter that stopped using the partition. I fix that one step and measure again."

The full answer: The query plan is the database's own description of how it will run the query. Common causes: a join that multiplies rows because a key is not unique; a filter wrapped in a function, so the database cannot skip partitions; scanning every column when a few are needed; and a table that grew tenfold. In a warehouse, partitioning or clustering large tables by date or customer lets a query read only the part it needs, which saves both time and money.

A weak answer: "I would ask for a bigger warehouse." Follow-up: "The plan shows a huge join." Check the join keys for duplicates, filter before joining, and pre-aggregate the large side if the detail is not needed.

Data quality and running pipelines

A manager says a number on the dashboard is wrong. How do you find the cause?

What they check: that you work backwards step by step, and fix the cause, not just the number.

Short answer: "First I find out what they expected and why, then I follow the number back through each step: the report, the model, the cleaned data, the raw data, the source. The step where it changes is where the problem sits. I fix it, correct past data, and add a check that would have caught it."

The full answer, in five steps:

Understand the claim. Which number, which day, compared with what? Often the report is right and the definition differs, for example orders placed against orders delivered.
Check freshness. Did last night's run finish? A late load looks like a wrong number.
Trace back. Recompute the number at each layer of the pipeline until two neighbouring layers disagree. That step holds the cause: a lost join, a duplicate, a changed filter, a time zone.
Fix and backfill. Correct the step, then re-run the affected days. A backfill is re-running a pipeline for past dates; it is safe only if the steps are idempotent.
Prevent. Add a data quality test at that point, tell the people who used the wrong number, and write a short note on what happened.

A weak answer: "I would change the number in the report."

Follow-up: "The source system itself has bad data." Flag or quarantine the bad rows, report them to the source owner with examples, and agree who fixes them; do not silently correct them in the warehouse.

How do you test data pipelines?

What they check: that you test both the code and the data, automatically.

Short answer: "I test the logic with small, made-up inputs before release, and I test the real data on every run: no missing keys, no duplicates, values in range, row counts that match the source. Tests run in CI before a change is merged, and data checks block a bad load."

The full answer: Unit tests check one transformation with a few rows whose result you know. Data tests, which tools such as dbt or Great Expectations run, check assumptions on real data every day. A staging copy with a sample of production data catches problems a made-up input misses. And every change goes through review in Git and through CI/CD, the automatic test and release line, like any other software.

A weak answer: "I check the output by eye after it runs." Follow-up: "Which test would you add first to an untested pipeline?" Uniqueness and not-empty checks on the main keys, because duplicates and missing keys cause most wrong numbers.

How do you set up orchestration so a team can trust the nightly runs?

What they check: retries, dependencies, alerts and the habits around them.

Short answer: "Each pipeline is a set of steps with clear dependencies in an orchestrator, with retries for short failures, timeouts, and alerts that go to the people who can act. Runs are safe to repeat, and each has an owner and a deadline the alerts are measured against."

The full answer: In Airflow or a similar tool, a pipeline is drawn as a graph of steps, so a step runs only when the steps before it succeeded. Retry a network error; do not retry a failed data check, which needs a person. Alert on lateness, not only on errors, because a job that hangs never fails. Keep secrets such as passwords in a secret store, not in the pipeline files. Write a short runbook per pipeline: what it does, who uses it, and what to do when it fails.

A weak answer: "We use cron and check the logs in the morning." Follow-up: "Alerts go off every night and people ignore them." Remove or fix the noisy ones; an alert nobody acts on is worse than none.

You need to backfill two years of data after a logic change. How do you do it safely?

What they check: that you can re-run history without breaking today's runs or the budget.

Short answer: "I run it in slices, a day or a month at a time, into a separate table, compare the new results with the old on a few slices, then swap the tables when the checks pass. It runs at quiet hours with a limit on resources, so the nightly pipeline is not slowed down."

The full answer: A backfill is only safe when each slice can be re-run alone and gives the same answer every time, so the steps must be idempotent and split by date partition. Estimate the cost first by running one slice. Tell the users that history will change, and why. Keep the old table for a while in case the new logic is wrong. Most orchestrators can run a backfill for a range of dates with a limit on how many run at once.

A weak answer: "I delete the table and run the whole history overnight." Follow-up: "Halfway through, the source system's old data is missing." Rebuild those months from the raw copies you landed, which is why raw data is kept.

How do you handle personal data in a pipeline?

What they check: that privacy is built into the design, not added at the end.

Short answer: "I take only the personal fields that are needed, mask or remove the rest early, limit who can see the raw area, and make sure data is deleted when the rules say so, including copies and backups. Under GDPR in the EU, a person can also ask for their data to be deleted, so the pipeline must be able to find it."

The full answer: Classify columns as personal or not when they enter the platform. Pseudonymise where you can: replace a name or email with a key, so analysts can count people without seeing who they are. Give access by role, and log who reads sensitive tables. Set retention per data set and delete automatically. In the EU, GDPR also limits moving personal data outside the EU, which affects where cloud storage sits. Work with the data protection officer early.

A weak answer: "Security is the IT department's job." Follow-up: "Analysts need the email address to join with a marketing tool." Join with a hashed or pseudonymised key in a controlled place, and pass on only what the tool needs.

Big data, performance and cost

A Spark job that processes a day of data has become very slow. Where do you look?

What they check: that you understand how Spark splits work, and its usual traps.

Short answer: "I open the Spark UI to find the slow stage, then look for the usual causes: a shuffle that moves too much data, skew where one partition is much bigger than the rest, too many tiny files, or reading far more data than needed."

The full answer: Spark splits data into partitions and works on them in parallel. A shuffle is when data must move between machines, for a join or a group by; it is the most expensive step. Skew happens when one key, such as one huge customer, holds most of the rows, so one worker does all the work; salting the key or treating that customer apart helps. Broadcast a small table to every worker instead of shuffling the big one. Filter and select columns early. Compact many small files into fewer large ones. Older platforms on Hadoop meet the same problems.

A weak answer: "I would add more machines." Follow-up: "One task runs for an hour while the others finish in a minute." That is skew: find the heavy key and split it.

The cloud bill for the data platform doubled in three months. What do you do?

What they check: that you treat cost as part of the job and find the big items first.

Short answer: "I find where the money goes, by service, warehouse, job and team, and start with the largest items. Typical savings: queries that scan whole tables, jobs nobody uses any more, warehouses that never pause, and data kept in expensive storage for years."

The full answer: Tag every resource with a team and a pipeline so costs can be shared out. Then look at the top ten jobs and queries: partition or cluster big tables so queries read less; schedule heavy jobs less often if the users do not need them hourly; let warehouses suspend when idle; move old raw data to cheaper storage with a retention rule. Agree a budget per team and an alert when it is passed, so a surprise like this is caught in a week, not three months.

A weak answer: "Cloud costs what it costs." Follow-up: "One team's dashboard refreshes every five minutes and costs the most." Ask how often they really look; a refresh per hour, or a small summary table, may cut most of the cost.

Platforms, standards and leading engineers

These questions come up for senior and lead data engineers and for data architect roles.

How would you choose between a data warehouse, a data lake and a lakehouse?

What they check: that you choose by needs and team, not by fashion.

Short answer: "A warehouse is best for clean, structured data and SQL reports. A lake stores any data cheaply, including files and logs, but needs more care to stay usable. A lakehouse adds warehouse features, such as tables and transactions, on top of lake storage. I choose by the data, the users, the skills of the team and the cost."

The full answer: If most users write SQL and the data comes from business systems, a managed warehouse such as Snowflake or BigQuery is simple and fast. If the company also has large files, events and machine learning, a lakehouse on open table formats such as Delta or Iceberg avoids keeping two copies. A data architect also asks: who runs it, how is access controlled, and how easy is it to leave the vendor? Write the decision and the reasons down, so the next team understands it.

A weak answer: "We should use whatever is newest." Follow-up: "Leadership wants one platform for everything." Show the cost and the risk of moving, and start with one domain to prove it before moving the rest.

How do you make other teams responsible for the quality of the data they send you?

What they check: that a senior data engineer fixes problems at the source, through agreements, not heroics.

Short answer: "With data contracts: the source team agrees which fields they send, what they mean, how good they must be and how changes are announced. Checks at the border show who broke what, and the quality figures are shared openly."

The full answer: Many data problems start where data is produced. A contract makes the promise visible; an automatic check on arrival enforces it. Data mesh is an approach where each business area owns its data as a product, with a team that answers for it, and the central platform team provides the tools. It needs mature teams; most companies take parts of it, such as named owners per data set, without the whole model.

A weak answer: "We clean everything in the warehouse." Follow-up: "A team refuses to sign a contract." Show them the cost of their bad data to people they care about, and start with the two or three fields that matter most.

As a lead data engineer, how do you set standards for a team of engineers?

What they check: for lead roles, leading through clear rules, reviews and coaching.

Short answer: "I agree a few standards with the team: how pipelines are named and tested, how changes are reviewed, what every pipeline must have before release, such as an owner, tests, alerts and a runbook. I make the right way the easy way with templates, and I coach through reviews and pairing."

The full answer: Standards nobody follows are worse than none, so keep them short and enforce them in CI/CD, not in meetings. A template for a new pipeline gives everyone the same start. Regular design reviews catch problems before they are built. A lead also plans the work with the business, protects time for fixing old pipelines, and helps each engineer grow: new responsibilities, honest feedback, and visible credit.

A weak answer: "I review every pull request myself." Follow-up: "A senior engineer keeps skipping the standards." Talk privately, understand why, and change the standard if it is wrong or hold the line if it is not.

How would you plan moving an old on-premise data platform to the cloud?

What they check: for senior and architect roles, planning a large change with low risk.

Short answer: "I list what exists and who uses it, drop what nobody uses, and move in waves, starting with one low-risk domain. Old and new run side by side, with checks that their numbers match, until users have moved. Then the old part is switched off."

The full answer: Most old platforms, for example on Hadoop, have many jobs nobody remembers; a list with owners and users often removes a third of the work. Decide per part: move as it is, rebuild, or retire. Run both platforms in parallel and compare outputs day by day. Plan the people side: training, new on-call rules, and a date for switching off the old system, because otherwise both run forever and cost twice.

A weak answer: "We copy everything over in one weekend." Follow-up: "The business wants it done in six months." Show what fits, what the risk of rushing is, and which waves deliver value first.

Your CV for these questions

Every answer above is easier when your CV already says it, because the interviewer asks about what is on it. Put one line under each job for each of these, in the words the ads use:

Skill	Weak line	Strong line, with proof
Pipelines	Built ETL pipelines.	Built incremental loads from 12 source systems; nightly run down from 5 hours to 50 minutes.
Data quality	Ensured data quality.	Added uniqueness and range tests to 80 tables; wrong figures reported by finance fell from monthly to none in a year.
Spark	Big data processing.	Fixed skew in the main Spark job by splitting the largest customer; run time down 70%.
Cost	Optimised cloud costs.	Partitioned the 3 largest tables and paused idle warehouses; platform bill down 30% in a quarter.
Leadership	Led a data team.	Led 4 data engineers through a move to the cloud in 3 waves; old platform switched off on schedule.

Then score your CV against a real job: you will see which of these the job needs and which your CV does not prove yet.

Key takeaways

Start every design from the users and their deadline; then make every step safe to run twice.
Choose batch unless someone acts on the data within minutes.
Find a wrong number by tracing it back layer by layer, then add the test that would have caught it.
Treat cost as part of the job: partition big tables, stop unused jobs, pause idle warehouses.
Senior roles add platform choices, data contracts with source teams, and standards the team follows.

Frequently asked questions

What do data engineer interviews ask most?: Pipeline design, SQL and data modelling, batch against streaming, data quality, performance and cost, and for senior roles platform choices and leading engineers.
Is there a coding round?: Usually: SQL questions, and often a small Python task. Practise both, and explain your reasoning as you go.
Do I need to know Spark?: For large data, often yes. For teams on a cloud warehouse with dbt, strong SQL and modelling count for more.
Do certificates help?: A cloud data certificate helps at consultancies and some large companies. Pipelines you built and ran count for more.
How should I prepare in a week?: Say the two worked answers out loud, practise SQL joins and window functions, and prepare one story each about a failure, a speed-up and a cost saving.

How to use these questions

What a data engineer is expected to know

Pipeline design

Design a pipeline that loads yesterday's orders from the shop database into the warehouse every night.

When would you choose streaming instead of batch?

What do you do when a source system changes its schema without telling you?

Data modelling and SQL

How would you model sales data so analysts can use it easily?

A query that used to take seconds now takes twenty minutes. How do you find out why?

Data quality and running pipelines

A manager says a number on the dashboard is wrong. How do you find the cause?

How do you test data pipelines?

How do you set up orchestration so a team can trust the nightly runs?

You need to backfill two years of data after a logic change. How do you do it safely?

How do you handle personal data in a pipeline?

Big data, performance and cost

A Spark job that processes a day of data has become very slow. Where do you look?

The cloud bill for the data platform doubled in three months. What do you do?

Platforms, standards and leading engineers

How would you choose between a data warehouse, a data lake and a lakehouse?

How do you make other teams responsible for the quality of the data they send you?

As a lead data engineer, how do you set standards for a team of engineers?

How would you plan moving an old on-premise data platform to the cloud?

Your CV for these questions

Key takeaways

Frequently asked questions

More on the data engineer role