What data engineer interviews actually test

Who's actually in the room

For a data engineer role, you're rarely being assessed by a generalist recruiter after the first call. The technical rounds are usually run by a senior data engineer or the data engineering lead, sometimes with an analytics engineer or a data scientist sitting in if the pipelines you'd build feed their models. That matters because the questions come from people who have been paged at 3am over a broken DAG, not from a rubric written by HR. They're listening for whether you've actually operated a pipeline in production, not whether you can define ETL.

Smaller companies often fold everything into two rounds: a live technical session and a conversation with whoever owns the data platform. Larger ones split it into a SQL/Python screen, a system or pipeline design round, and a values or stakeholder-handling round with someone from the team you'd feed data to — often an analyst or a product manager, and it's the round candidates most underprepare for because it looks like small talk and isn't.

The SQL and Python screen

This is rarely trivia. You'll get a schema — often something like orders, customers, events — and be asked to write a query using window functions: running totals, rank-within-partition, a self-join to find gaps or overlaps in date ranges. The point isn't the syntax, it's whether you reach for the right tool without being walked to it. A candidate who solves "find each customer's first and second purchase" with a correlated subquery when a LAG() would do it cleanly is telling the interviewer something about how they'll write production SQL under time pressure.

On the Python side, expect data manipulation with pandas or plain Python — deduplicating a messy dataset, parsing malformed JSON, handling nulls that mean different things in different columns. Increasingly you'll be asked to reason about a Spark job: why a transformation is slow, where a shuffle is happening, whether repartitioning before a join would help. If you've only ever run Spark through a managed platform like Databricks and never had to explain why a job spilled to disk, this is where it shows.

What a shallow answer sounds like here: reciting that indexes "speed up queries" without being able to say what happens to write performance, or explaining a window function's syntax correctly but being unable to say when you'd use ROW_NUMBER() over RANK() and what breaks if you get it wrong on a table with duplicate keys.

The pipeline or system design round

This is the round that separates people who've configured a tool from people who've owned a system. You'll typically be asked to design something like: ingest events from an application into a warehouse, keep a dimension table in sync with an upstream source that changes, or build a pipeline that has to backfill three years of history without doubling the compute bill.

The interviewer is listening for a small set of things, and they come up in almost every version of this question:

• Idempotency. Can your pipeline be re-run on the same data without producing duplicates or double-counted totals? If your answer doesn't mention how you'd handle a job that fails halfway through and gets retried, that's a gap they'll probe.
• Schema evolution. What happens when a source system adds a column, or changes a type from int to string? Do you fail loudly, or silently corrupt downstream tables? Mentioning a schema registry, or how dbt or Great Expectations tests would catch this, signals you've been burned by it before.
• Batch versus streaming, and why. Not "streaming is better" — that's the shallow answer. The real answer explains the trade-off: Kafka or Kinesis buys you low latency and complexity you now own, versus a scheduled batch job in Airflow or Dagster that's simpler to reason about and debug but means stale data for however long the schedule runs.
• Partitioning and cost. If you design a table without saying how you'd partition it — by date, usually, in a warehouse like BigQuery or Snowflake — and without acknowledging that a full table scan on a multi-terabyte fact table costs real money, the interviewer notices the omission even if they don't say so.
• Slowly changing dimensions. If the scenario involves a dimension that changes over time (a customer's address, a product's category), do you overwrite it, or do you version it with something like SCD Type 2? Getting this wrong doesn't fail you outright, but not knowing the term when the interviewer says "how would you handle a customer changing region" is a tell.

A shallow answer to a design question sounds fluent about tools and silent about failure. "I'd use Airflow to orchestrate it and land it in Snowflake" is a sentence with no engineering in it — it names the vendor and skips the decision. A strong answer says why: why this orchestrator handles backfills the way you need, why this warehouse's clustering keys matter for the query pattern the analysts actually run.

The questions that sound like small talk

"Walk me through a time a pipeline you built broke in production" is not an icebreaker. It's usually the most diagnostic question in the whole process, because a shallow answer gives you the symptom ("the dashboard was showing wrong numbers") and a real answer gives you the mechanism: what monitoring or lack of it meant you found out from a stakeholder rather than an alert, what the root cause turned out to be — a late-arriving file, a timezone bug, an upstream schema change nobody told you about — and what you changed afterwards so it couldn't happen the same way twice.

Similarly, "how do you decide what to test in a pipeline" is being asked to see whether you write data quality checks as a habit — row counts, null thresholds, referential integrity between a fact and its dimensions — or whether testing is something you do after an incident because someone told you to. Mentioning a specific practice, like asserting that a foreign key in a fact table always resolves to a row in the dimension, lands better than saying "I write tests for my pipelines," which could describe any job with the word pipeline in it.

"How would you explain to a stakeholder why their report is a day late" is testing something different again: whether you can translate a technical cause — a source API rate limit, a downstream dependency that didn't finish — into language a non-engineer can act on, without either dumbing it down to nothing or drowning them in DAG terminology they don't have.

What gives away someone who hasn't done the job

Interviewers in this field notice a specific pattern: fluency with tool names and no opinions about their limits. Someone who has actually run dbt in production can tell you where its testing framework falls short and what they layer on top. Someone who has actually operated Airflow can tell you what breaks when a DAG has too many dynamic tasks, or why they moved a heavy transformation out of a PythonOperator and into the warehouse itself. If every answer names a tool and stops there, that's the shallow answer, and people who hire data engineers have heard hundreds of them.

The other giveaway is talking about data volume without talking about cost or query pattern. "We had billions of rows" is not, on its own, an engineering fact. What did that mean for how the table was partitioned, clustered, or compacted, and what would have happened to the warehouse bill if you'd got it wrong? An interviewer who has owned a Snowflake or BigQuery cost dashboard will ask a follow-up and find out fast whether the billions of rows were something you dealt with or something you mentioned.

What to do next

Before your next interview, pick two pipelines you've actually built and be ready to describe, in specific terms: how you'd re-run them safely after a partial failure, what would happen if the source schema changed underneath you, and one incident where it broke and what you changed afterwards. Practise saying the trade-off, not just the tool — batch versus streaming, denormalised versus normalised, orchestrator A versus orchestrator B — because that's the sentence shape the interviewer is listening for.

If the harder problem right now is getting to that interview at all — adverts that ask for specific warehouse or orchestration experience you have in a different form, and applications that go quiet — jobmarket.pro reads the advert in full, matches it against your actual experience, and prepares the application from that rather than a generic template.