Data engineering interviews are not analytics interviews with some Python bolted on. The panel is working out whether you can be trusted with the pipeline that feeds every dashboard, model and finance report in the company, and whether you would notice it quietly producing wrong numbers. So the questions cluster around design, correctness and operations rather than clever algorithms. Here are the ones that actually come up, what each is probing, and how a strong answer is built.
These are the patterns for the role in general; if you want the shortlist for one specific interview, paste the actual job posting into the free Question Predictor and get the twenty questions most likely to come up in that particular loop.
What do data engineer interviews actually test?
Four things: whether you can design a pipeline that survives contact with messy upstream data, whether your SQL goes past a join and a GROUP BY, whether you model data so analysts do not have to reverse-engineer your intentions, and whether you treat correctness as an engineering problem rather than a hope. Tool knowledge matters far less than judgement.
Weightings shift by company: warehouse-heavy product teams lean on modelling and SQL, platform teams lean on throughput and cost, startups want to know whether you can stand the whole thing up alone and keep it cheap. Code generation has made writing a transformation trivial, so panels now spend their time on the decisions a generator cannot make: why this grain, why this partition key, what happens on a replay.
What does the data engineer interview process look like?
A typical loop runs four to six stages across two to three weeks: a recruiter screen, a SQL screen, a pipeline design round, a modelling round, and a behavioural conversation. Senior loops add a deeper systems round on throughput, cost and failure. Take-homes are less common than they were but still appear at smaller companies.
- Recruiter screen (20 to 30 minutes). Stack, scale, salary band. Describe your largest pipeline in two sentences: volume, latency, who consumes it.
- SQL screen (45 to 60 minutes). Live SQL on a shared editor, with window functions as the usual filter.
- Pipeline design round (60 minutes). You get a source, a consumer and a freshness expectation, then design the path between them and defend it.
- Data modelling round (45 to 60 minutes). Schema design for a described business, usually with a curveball about history or late data.
- Hiring manager or behavioural. Ownership and stakeholders. On-call questions often land here too.
If you already know the company, the company question banks are a faster read on house style than trawling forums.
What pipeline design questions come up in a data engineer interview?
Design questions hand you a source, a destination and a constraint, then watch how you reason. The panel wants you to ask about volume, freshness, schema stability and who screams when it breaks before you draw a single box. Strong candidates size the problem out loud, then design the simplest thing that meets the requirement and can be re-run safely.
Walk me through a pipeline you have built, end to end. What it probes: whether you have operated something, or only contributed a task to someone else's DAG. Give the shape in order (source, ingestion, storage, transformation, serving), then the numbers: rows per day, latency, cost, who depended on it. Finish with what went wrong once and what you changed, because specifics here buy credibility for the rest of the loop.
Design a pipeline that ingests around 500GB of clickstream events a day and has it ready for analysts by 9am. What it probes: sizing, partitioning, and the gap between arrival and readiness. Clarify the freshness requirement first, because daily by 9am is a batch problem rather than a streaming one. Land raw events in object storage partitioned by date and hour, transform into a modelled table, and keep the raw layer immutable so you can replay. Mention file sizes; thousands of tiny files are the classic self-inflicted wound.
How do you handle late-arriving or out-of-order events? What it probes: whether you understand that data does not arrive politely. Separate event time from ingestion time, define a lateness window you are willing to accept, and reprocess the affected partitions rather than patching individual rows.
Batch or streaming: how should you answer the architecture question?
Answer from requirements, not preference. Streaming earns its cost when something acts on the data within seconds: fraud checks, live inventory, alerting. Batch is correct for nearly everything feeding a dashboard or a monthly report. The trap here is enthusiasm, because a candidate who reaches for a streaming stack to power a daily report is optimising for interest rather than for the business.
When would you choose streaming over batch, and what does it cost you? What it probes: judgement about operational burden. Name the costs honestly: harder testing, harder backfills, state to manage, more on-call surface, a team that now has to understand watermarks. Then give the condition that justifies all of it, which is a consumer acting on the data faster than your batch cadence can deliver.
What is the difference between event time and processing time? What it probes: streaming fundamentals. Event time is when the thing happened; processing time is when your system saw it. Aggregates windowed on processing time drift and end up quietly disagreeing with the source of truth.
How would you get exactly-once semantics in a streaming pipeline? What it probes: whether you repeat marketing or explain mechanics. End to end you build at-least-once delivery plus idempotent writes, using a deterministic key so a replay overwrites rather than duplicates. Transactional sinks and offsets committed with the write make that real.
What data modelling questions should you expect?
Modelling rounds test whether you design for the questions the business will ask rather than for the data you happen to have. Expect a described business, a request for a schema, then a complication: history, hierarchy, or an attribute that changes. Dimensional modelling is still the common language, even in teams that call their layers something more fashionable.
Explain star schema versus one wide denormalised table. Which would you build? What it probes: reasoning about grain and change. Cover query simplicity and storage cost on one side, join cost and duplicated attributes on the other, then pick based on the engine and the consumers. Columnar warehouses have made wide tables cheaper than they were, but a star still wins when dimensions change independently.
How do you model a slowly changing dimension? What it probes: history. Type 1 overwrites and loses the past; type 2 adds a row per version with validity dates and a current flag, which is what most analytics teams need for point-in-time reporting.
How would you partition a large table, and what goes wrong? What it probes: physical design. Partition on the column consumers filter on, usually a date, watch partition size, and keep partitioning separate from clustering or sort keys. The classic failure is partitioning on something high-cardinality like user ID, producing millions of tiny files and queries slower than no partitioning at all.
How deep does the SQL round go for data engineers?
Deeper than analyst rounds. Joins and aggregation are assumed; the filter is window functions, deduplication and reasoning about a query plan. Most screens run three or four questions of increasing nastiness, and the last usually needs a window function or a self-join. Talk through the approach before typing, because the reasoning is scored more heavily than the syntax.
Find the second highest value per group, for example the second best paid person in each department. What it probes: window function fluency. Reach for DENSE_RANK or ROW_NUMBER in a subquery and filter on the rank outside, then say which you chose and why, because ties behave differently.
Deduplicate a table so only the latest row per key survives. What it probes: the single most common real task in the job. ROW_NUMBER partitioned by the key, ordered by timestamp descending, filtered to 1. Then ask what breaks the tie when two rows share a timestamp, because in real data they will.
A query over a partitioned table has become slow. How do you diagnose it? What it probes: evidence-led debugging. Read the plan, check whether partition pruning actually happened (a function wrapped around the partition column usually kills it), look for skew, check for stale statistics, check whether the file layout has degraded into many small files.
What orchestration questions do interviewers ask?
Orchestration questions test whether your pipelines can be re-run without fear. The word to have ready is idempotency: running the same task for the same logical date twice should produce the same result, not double it. Expect follow-ups on dependencies, retries, alerting, and backfilling a year of history without melting the cluster or the budget.
How do you make a scheduled job idempotent and safely backfillable? What it probes: operational maturity. Parameterise every task by a logical date rather than by "now", write to a partition keyed on that date, and replace that partition on re-run instead of appending.
How do you handle dependencies between pipelines owned by different teams? What it probes: whether you have worked in a real organisation. Prefer an explicit signal (a dataset marked complete, an event, a sensor with a timeout) over a hopeful schedule offset.
How do interviewers test data quality?
They describe a wrong number and watch you investigate. The signal they want is that you treat correctness as testable: row counts, null rates, uniqueness on keys, referential integrity, distribution checks against yesterday, freshness. Candidates who say they would eyeball the dashboard lose the round; candidates who describe assertions inside the pipeline that can block a bad publish win it.
How do you know a pipeline produced correct data? What it probes: whether quality is designed in or checked afterwards. Put tests in the pipeline itself: unique keys, non-null constraints, accepted ranges, row-count deltas against the previous run.
A stakeholder says yesterday's revenue number is wrong. Walk me through the investigation. What it probes: structured debugging plus communication. Define what wrong means (against which source, by how much), then work upstream layer by layer, comparing counts and totals at each boundary to isolate where the number diverges.
An upstream source changes a column type without warning. How do you handle it? What it probes: dealing with things outside your control. Fail fast at ingestion with a schema check rather than silently coercing, quarantine the bad batch, then fix forward with a replay.
What behavioural questions do data engineers get asked?
Behavioural rounds for data roles focus on trust and stakeholders. Expect a question about an incident where your data was wrong, and one about a request you pushed back on. Answer with a tight structure: the situation, what you decided, the trade-off you accepted, and the durable change that followed.
Tell me about a time your data was wrong and someone else noticed first. What it probes: ownership and honesty. Do not minimise it. Say what broke, how long it was wrong, who acted on it, how you communicated, and the check you added so it cannot recur silently.
Tell me about a request you refused, or negotiated down. What it probes: whether you can protect a platform from a hundred one-off requests. Show that you understood the underlying need, offered a cheaper path to it, and made the cost of the original request visible, rather than saying no and becoming the team everyone routes around.
What mistakes sink data engineer candidates?
Mostly judgement failures rather than knowledge gaps. Panels rarely reject someone for not knowing a specific tool; they reject people who design before asking, who cannot re-run their own pipeline, or who treat a wrong number as somebody else's problem. These are the patterns that end rounds.
- Designing before asking. Volume, freshness, schema stability and consumers should be established before you draw anything. Starting with a tool name loses the design round.
- Naming tools instead of mechanics. Saying you would use a particular engine explains nothing. Say what the job does, how it partitions, where the shuffle happens, what it costs.
- Ignoring replay and backfill. A design that cannot be safely re-run for a past date is not a production design, and senior interviewers check for this deliberately.
- Treating quality as someone else's job. If your answer to a wrong number is that the analyst should have caught it, the round is over.
- SQL that stops at joins. Window functions are the standard filter now, and missing them reads as insufficient depth however good your architecture answers were.
How should you prepare for a data engineer interview?
Rehearse one pipeline you know cold, with real numbers attached, because it will anchor half the loop. Drill window functions and deduplication until they are muscle memory. Practise a design out loud against a clock, since the format punishes people who can think it but cannot narrate it. Prepare two incident stories and one stakeholder story.
Before the loop itself, paste the actual job posting into the free Question Predictor and work through the twenty questions it flags for that specific role, since a lakehouse platform team and an analytics engineering team will ask you very different things.
For the live rounds, GhostPilot is a real-time interview copilot: a Chrome extension side panel and an optional Windows desktop app that transcribe the call, catch the question as it lands, and have a structured answer ready about two seconds later. It helps most on questions with a trap in them, such as a design prompt that quietly wants a replay strategy. It is a prompt rather than a script, and the specifics still come from your own work. The free tier gives you 10 minutes of live interview time a week, no card required.
Data engineer interview FAQ
How long should I prepare for a data engineer interview? Two to three weeks suits most mid-level candidates: a week on SQL and modelling, a week practising design out loud, a few days on stories. Analysts moving into engineering should plan for longer, mostly on pipeline design.
Do data engineer interviews still include algorithm questions? Some large companies keep one algorithm round, usually easy to medium. Most teams have replaced it with SQL and a practical Python exercise on parsing or transformation. Do not let algorithm grinding crowd out modelling.
Which round carries the most weight? Pipeline design, for mid and senior candidates, because it tests judgement, communication and depth at once. For junior roles the SQL screen is the real gate, and most rejections happen there.
Should I admit when I have not used a tool they mention? Yes. "I have not run that in production, but here is how I would reason about it and what I would check first" beats bluffing, and data interviewers are unusually good at spotting hand-waving because they spend their days finding wrong things.