Data engineer interview questions in English

Data engineer interviews test SQL, data modelling, pipeline design and how you handle failures, and in English you must explain each design choice out loud. Practise describing one pipeline end to end (source, ingestion, transformation, storage, consumers), know batch versus streaming trade-offs in plain words, and prepare a story about a pipeline that broke and how you fixed it.

What a data engineer interview looks like

1. Recruiter screen
Your stack (Spark, Airflow, dbt, Kafka, a cloud warehouse), scale of data and why you are moving.
English focus: Name the stack and the scale in one sentence: 'I run about 200 Airflow DAGs feeding Snowflake.'
2. SQL and coding
Complex SQL, Python data manipulation, sometimes an algorithm question.
English focus: Say the grain and the join before typing, and say how you would test the output.
3. Data modelling
Design tables for a business, such as a ride-sharing app: facts, dimensions, keys.
English focus: Ask about the questions the business wants to answer before you draw tables.
4. Pipeline or system design
Design an ingestion or transformation pipeline with scale, latency and failure handling.
English focus: Use a fixed spoken order: requirements, sources, ingestion, processing, storage, serving, monitoring.
5. Behavioural
Incidents, working with analysts and data scientists, prioritising platform work.
English focus: Clear ownership: what broke, what you did, what you changed so it doesn't happen again.

10 data engineer interview questions, with spoken answers

Each answer is written to be said out loud: short sentences, the main point first, and one concrete detail. Change the details to your own experience before you practise.

1. Walk me through a data pipeline you built.

Recruiter screen

What they listen for: End-to-end understanding and one number for scale or impact.

“I built the pipeline that feeds our finance reporting. Data comes from Postgres and Stripe, we land it in S3 every hour, transform it with dbt in Snowflake, and finance reads it in Looker. It handles about 50 million rows a day, and it cut month-end close from five days to two.”

2. When would you choose batch processing over streaming?

Pipeline or system design

What they listen for: That you choose from the latency requirement, not from what is fashionable.

“I'd start from how fresh the data needs to be. If the business looks at a report once a day, batch is cheaper, simpler and easier to backfill. I'd use streaming when a decision depends on data from the last few seconds or minutes, like fraud checks or live inventory.”

3. What does idempotent mean, and why does it matter for pipelines?

Pipeline or system design

What they listen for: A correct definition and a concrete technique.

“Idempotent means if I run the same job twice, I get the same result, not duplicated data. It matters because jobs fail and get retried. In practice I write each run to a partition for its date and overwrite that partition, or use a merge on a unique key instead of a plain insert.”

4. Design a data model for a ride-sharing company.

Data modelling

What they listen for: Clarifying questions, a clear fact table grain, and sensible dimensions.

“Before I draw anything: what questions does the business want to answer, for example revenue by city or driver utilisation? I'd start with a trips fact table, one row per completed trip, with fare, distance and timestamps. Around it, dimensions for driver, rider, city and date. I'd keep cancelled trips in a separate fact, because the grain is different.”

5. A daily job that usually takes 20 minutes took 3 hours today. What do you do?

Behavioural

What they listen for: Calm triage: impact first, then cause.

“First, who's affected? If a morning dashboard depends on it, I'd tell those people it's late. Then I'd compare today's run with a normal one: input volume, data skew, cluster size, and whether a query plan changed. Very often it's a spike in input or one huge key causing skew.”

6. How do you handle late-arriving data?

Pipeline or system design

What they listen for: Event time versus processing time, and a practical reprocessing strategy.

“I separate event time, when it happened, from processing time, when we received it. For batch, I reprocess the last few days' partitions on each run, so late records land in the right day. For streaming, I'd use a watermark that waits a set time for late events, and send anything later to a correction job.”

7. How do you make sure the data in the warehouse is correct?

Data modelling

What they listen for: Automated tests and monitoring, not manual checking.

“I test at a few levels: schema tests like not-null and unique keys, row-count checks against the source, and business rules, like revenue never being negative. They run in the pipeline, so a failed test stops bad data reaching dashboards, and the on-call person gets an alert.”

8. Explain the difference between a data warehouse and a data lake.

SQL and coding

What they listen for: A clear, current answer that mentions how the line has blurred.

“A warehouse stores structured, cleaned data in tables designed for analysis. A data lake stores raw files of any type, cheaply, and you apply the structure when you read it. Today many teams use a lakehouse, with table formats like Iceberg or Delta, to get warehouse features on lake storage.”

9. Tell me about a time you disagreed with an analyst or data scientist.

Behavioural

What they listen for: Respect for the other side and a solution that served the business.

“A data scientist wanted raw event data copied into their own schema every hour. I was worried about cost and having two versions of the truth. I asked what they actually needed, and it was three fields with low latency. We built a small incremental model for that, which was cheaper and kept one source.”

10. How do you handle schema changes from an upstream team?

Pipeline or system design

What they listen for: Both technical safeguards and communication with the other team.

“Technically, I validate the schema on ingestion and fail loudly on breaking changes rather than load bad data silently. But the better fix is agreement: a data contract with the upstream team, so they tell us before renaming or removing a field.”

Phrases to have ready

Clarifying scale: “Roughly how much data are we talking about per day, and how fresh does it need to be?”
Describing a pipeline: “Data lands in S3, gets transformed in Spark, and is served from the warehouse.”
Explaining a trade-off: “Streaming would give us fresher data, but it's harder to backfill and costs more to run.”
Talking about an incident: “The root cause was a schema change upstream. The fix was a contract test on ingestion.”
Owning a mistake: “That one was on me. I hadn't added a uniqueness test on that key.”
Checking requirements: “Who reads this table, and what decision do they make with it?”

Data Engineer vocabulary in plain English

Idempotent: Safe to run twice: you get the same result, not duplicates.
Backfill: Re-running a pipeline for past dates to fill in or fix data.
Data skew: A few keys have far more data than the rest, so one worker does most of the work.
Fact table: A table of events or transactions, like one row per order.
Dimension: A table that describes things, like customers or products.
Data contract: An agreement about a dataset's schema and meaning between the team that produces it and the team that uses it.

English mistakes that cost points

Avoid: Listing tools instead of explaining design: 'We used Kafka, Spark, Airflow, Snowflake.'
Instead: Explain why each piece is there: 'Kafka because three teams consume the same events.'
Avoid: Jumping into the design before asking about latency and volume.
Instead: Ask two or three clarifying questions first. In English panels, this is scored as seniority.
Avoid: Pronouncing 'data' two different ways in one answer, or stressing 'ar-CHI-tecture'.
Instead: Pick 'DAY-ta' or 'DAH-ta' and stay consistent. It's 'AR-ki-tek-cher', with stress on the first syllable.
Avoid: Saying 'we had a problem with the data' with no detail.
Instead: Name the failure: 'duplicates in the orders table after a retry.' Specific language sounds senior.

FAQ

What are the most common data engineer interview questions?

SQL with joins and window functions, Python data manipulation, batch versus streaming, idempotency, late-arriving data, data modelling with facts and dimensions, pipeline design and stories about incidents. Most English-speaking panels also ask you to walk through a pipeline you built.

How do I prepare for a data engineering system design interview in English?

Rehearse one fixed spoken order: requirements, sources, ingestion, processing, storage, serving, monitoring. Practise it out loud on two or three designs, such as clickstream analytics and a finance reporting pipeline, until the order is automatic.

Are Mockly's coaches data engineers?

Yes. Both Mockly coaches work as data engineers in the UK and have run these interviews, so practice sessions use real pipeline and modelling questions.

Ready to practise?

Turn interview English into a repeatable skill

Work through the Interview English Course, then book live coaching with engineers who give feedback on both your technical answers and how you deliver them in English.