Backend interviews ask how you would build something. Data engineering interviews ask what happens when it breaks — and they ask it about five different things.

There's a reason for the difference. A backend service fails in front of a user who retries. A pipeline fails at three in the morning, unattended, and the failure surfaces two days later as a number in a board deck that nobody can explain. Every experienced interviewer has lived that, and it shapes what they listen for.

So these questions are ordered the way data moves, and each section is really asking the same thing: what happens here when it goes wrong?

5
Places data breaks — the sections follow them in order
3am
When it breaks, with nobody watching
1
Question underneath all twenty: how would you know?

Ingestion

The opening round. Everything downstream inherits whatever you accept here.

  1. Batch or streaming — how do you decide, and what does streaming actually cost you?
  2. A source API rate-limits you halfway through a backfill. What happens next?
  3. A source changes its schema without telling you. What does your pipeline do?
  4. The same record arrives twice. What stops it being counted twice?

Saying it out loud: question 3 is the one that separates people who have operated a pipeline from people who have written one. The weak answer is validation; the strong answer is a policy: "It depends on the change. A new column I want to land and ignore, because failing the load over a field nobody uses is worse than the alternative. A removed or retyped column that something downstream depends on should fail loudly and early, at ingestion, rather than quietly producing nulls that reach a dashboard. So I'd rather have an explicit contract that says which fields are load-bearing than treat every schema change the same way."

Question 4 has a specific vocabulary attached — idempotency, natural keys, deduplication windows — and the mistake is producing the vocabulary without the trade. Say where the deduplication happens and what it costs you in state.

Storage and modelling

Where the shape you choose either helps or punishes every query for years.

  1. How would you model this for analytics — star schema, one wide table, or something else?
  2. Partitioning and file formats — what actually changes query cost?
  3. When is a data lake the wrong answer?
  4. How do you handle slowly changing dimensions — and does anyone really need type 2?

Saying it out loud: question 8 is a small trap. There's a textbook answer everyone can recite, and interviewers ask the second half precisely to see whether you apply it or just know it: "Type 2 is worth the complexity when someone will genuinely ask what a record looked like at a point in the past — sales territory at the time of the deal, price at the time of the order. When nobody asks that question, type 2 buys you a join condition on every query and a lot of rows for nothing. So I'd want the reporting question before I choose."

Transformation

The middle of the loop and the part most likely to include live SQL.

  1. What do you test in a transformation, and how?
  2. A metric changed and nobody knows why. How do you find out?
  3. Incremental or full refresh — how do you choose, and what breaks with incremental?
  4. Where should business logic live — in the pipeline, in the warehouse, or in the BI tool?

Saying it out loud: question 11 rewards naming the failure that incremental buys you. Full refresh is expensive and correct; incremental is cheap and drifts: "Incremental is the default once the table is big enough that a full rebuild stops fitting the window. What breaks is late-arriving data and updates to old rows — if I only process what arrived since the last run, anything backdated never lands. So I'd rather define a lookback window than a watermark, and I'd want a periodic full rebuild anyway, because that's the only thing that catches the drift."

This round often includes writing SQL while someone watches. The question list for that is here: SQL Interview Questions for Data Analysts, and there's a guide on doing it out loud: How to talk through a SQL query live.

The thread so far: every strong answer above answered a slightly different question than the one asked. Not “what is a slowly changing dimension” but “when is it worth the cost”. Not “how do you handle schema drift” but “which changes should fail loudly”. Interviewers for this role have all inherited someone else's pipeline. They are listening for whether you think about the person who inherits yours.

Orchestration

Senior weighting. Where the job stops being about data and starts being about operations.

  1. A job fails at 3am. What do you want to have already built?
  2. What makes a pipeline safe to re-run?
  3. Task A depends on B and C, and C is running late. What should happen?
  4. How do you run a large backfill without taking production down with it?

Saying it out loud: question 15 sounds like a scheduling question and it's really a design question about defaults. Interviewers want to hear you refuse the easy answer: "The wrong default is to run A anyway on partial data, because that produces a number that looks fine and is wrong, and wrong-but-plausible is the most expensive failure mode we have. So A waits and something alerts. But waiting forever isn't free either — if C is chronically late, that's a conversation about the SLA rather than a longer timeout."

Question 13 is an invitation to describe your ideal setup, and the strong answers are unglamorous: a runbook, alerting that says which downstream tables are now stale, retries that are safe because the job is idempotent, and enough logging to tell a transient failure from a real one without opening a laptop.

When someone downstream notices first

The last round, and often the one that decides seniority.

  1. A dashboard shows numbers that are obviously wrong. Walk me through the first hour.
  2. How would you know your data is fresh and correct before a human tells you?
  3. Who owns a data quality problem when the source system is the thing that's broken?
  4. What SLA do you give a stakeholder, and what do you do the week you can't meet it?

Saying it out loud: question 17 is graded on order, not on tools. Say what you'd establish first: "Before touching anything, I'd want to know whether the data is wrong or the dashboard is — those are different incidents. Then whether it's a new problem or has been wrong for a while, because that changes who needs to be told. Then I'd work backwards from the metric through the transformations to the source rather than guessing, and the first thing I'd communicate is not a diagnosis, it's that we know and roughly when we'll have an answer."

That last part matters more than candidates expect. Question 19 is checking the same instinct: the answer that scores is not "the source team owns it", it's that you own the pipeline's behaviour when the source is broken — detecting it, stopping bad data propagating, and telling people — even when you can't fix the cause.

The part that isn't about pipelines

Most of this role's visible moments are failures explained to people who don't share your vocabulary — a stakeholder who wants to know why the number moved, or why the dashboard was wrong for two days.

That's a specific skill, and it's the one that separates two candidates with identical technical answers. The failure mode is precision: an accurate explanation full of table names and job IDs that leaves the listener knowing less than when they started. We wrote about that pattern in Why your data science answers sound confusing in interviews — a different role, the same mechanism.

Practical target: take question 17 and answer it out loud twice — once to an interviewer, once as if to a non-technical stakeholder who is asking why their number was wrong. If the second version is much harder, that's the one the loop will actually test, because in this job it's the one you'd do more often.