Data Engineer Interview Questions by Round

Most loops open with a recruiter call and a technical screen. The screen is usually SQL in a shared editor, sometimes with a short Python task, and it decides whether you reach the full loop. The full loop then runs 4 or 5 interviews of about an hour each, sometimes on 1 day and sometimes across a week. It covers SQL in more depth along with Python, data modeling and pipeline or system design, plus a behavioral round. Some companies replace the live coding with a take-home assignment and a review of it.

Each round has a different interviewer listening for a different thing. The coding rounds check correctness on the cases the prompt does not mention. In modeling, the interviewer wants tables that answer the business questions at the grain you claimed, and in design, a pipeline that survives failure. The behavioral interviewer wants to hear whether you've done this work before and what you learned from it. A strong round rarely rescues a weak one, so preparation spreads across all of them; the data engineer interview prep guide lays out the order the rounds run in and how to plan for each.

SQL interviewers choose data with the edge cases already in it, then wait to see whether your query handles them. The most common is a NULL in a list. The PostgreSQL documentation on subquery expressions states the rule: when no value in the list equals the left-hand value and at least 1 list value is NULL, NOT IN yields NULL, not true. A WHERE clause keeps only rows that are true, so the query returns nothing and raises no error.

The NOT IN demonstration runs on 3 customers and 2 orders, and 1 of the orders has no customer_id. NOT EXISTS finds the 2 customers who never ordered. NOT IN finds 0, because the NULL in the subquery makes every comparison unknown. Add WHERE customer_id IS NOT NULL to the subquery and the 2 methods agree again. The interview version of the question, users who never made a purchase, opens in the practice problem card, where your answer runs against hidden data.

The other traps follow the same pattern. COUNT(column) skips NULLs where COUNT(*) does not, so the 2 disagree on exactly the rows an interviewer seeded. Integer division truncates in PostgreSQL and SQL Server, so a ratio of 2 integer counts comes back as 0 unless 1 side is cast to a decimal. A filter on a timestamp column written as = '2026-01-31' matches only midnight. Say each assumption aloud as you write, then check it against the sample rows before you call the query done.

For more questions of this kind, all with answers, the SQL interview questions guide works through the round in full and the SQL practice problems run every query against a real database.

Ranking questions are where most window function answers go wrong, because the 3 ranking functions agree until 2 rows tie. Take 4 salaries in 1 department: 180, 150, 150, 120. ROW_NUMBER numbers them 1, 2, 3, 4 and breaks the tie by whatever order the engine reads the rows in. RANK gives 1, 2, 2, 4: the tied rows share 2 and the next rank skips to 4. DENSE_RANK gives 1, 2, 2, 3: the tied rows share 2 and the next rank is 3.

So the third highest salary depends on the function. A filter of = 3 returns 1 of the 150 rows with ROW_NUMBER, no row with RANK, and 120 with DENSE_RANK. A top 3 filter of <= 3 keeps 3 rows under the first function and 3 under the second, while the third keeps 4. Before writing the window, ask the interviewer whether tied people both count and whether "third highest" means the third distinct value.

When you need exactly 1 row per group, as in deduplication, ROW_NUMBER with a tie-breaking column keeps the choice stable. DENSE_RANK returns the Nth distinct value, and RANK fits a competition ranking where a tie for second means nobody is third.

Try it on a question from real interviews: the second highest latency for each API method, where several calls can tie.

The Python round for data engineers is about moving and reshaping records, not puzzles. Expect to parse a file or a JSON payload, deduplicate, group, sessionize events by a time gap, or pull every page of an API without losing or repeating a record. Most answers need nothing beyond the standard library, mainly dict, set, collections.Counter, heapq and itertools.groupby, plus generators.

Interviewers listen for 3 habits. A 50 GB file is read 1 line at a time, never into a list, and you can say how much state your solution keeps. A bad record is caught with a specific exception and set aside with its reason, and the job keeps a count, so 1 malformed line neither crashes the job nor disappears silently. A lookup inside a loop goes through a dictionary or a set, which turns an O(n²) answer into O(n).

Many companies allow pandas, and some expect it, but be ready to write the same logic without it, because the follow-up is often "now the data does not fit in memory". The Python interview questions guide has the full set of questions for this round.

The data modeling round names a business and asks for its tables. It might be a marketplace or a rideshare app, a payments ledger or a streaming service. Most good answers follow the 4 decisions of Kimball's dimensional design process in order: select the business process, declare the grain, identify the dimensions, identify the facts. The Kimball Group defines the grain as exactly what a single fact table row represents, and recommends the atomic grain, the lowest level the process captures, because it answers questions nobody has asked yet.

Say the grain out loud before drawing anything: "1 row per completed trip" or "1 row per order line". Every later choice follows from that sentence, and most modeling mistakes are a table whose rows mean 2 things. Then name the questions the model must answer and check each against your tables as you go.

Expect the interviewer to press on each choice you made. They will ask which attributes need SCD Type 2 and how a fact row joins to the version that was true at the time, why you chose a star schema with conformed dimensions over a normalized design or 1 wide table, and what happens to the model when the business adds a new product line or a second currency. The data modeling interview questions guide covers each of these with full answers.

A typical prompt: "Replicate the orders table from our production PostgreSQL database into the warehouse, with dashboards no more than 15 minutes behind." Start with the numbers the design depends on, rows changed per day and how fresh the data must be, then find out whether deletes matter and who reads the result. Ask for the ones the prompt leaves out.

Then walk the data from source to consumer. Capture changes from the database's write-ahead log with change data capture rather than polling an updated_at column, which misses hard deletes and any update that forgets to set it. Publish the changes to a Kafka topic keyed by order_id, so every change to 1 order lands in 1 partition and stays in order. A Spark job merges each batch into a lake table on order_id, applying a change only when its log position is newer than the stored one. Under that rule a replay or a duplicate leaves the table as it was. Records that fail to parse go to a dead letter queue with the reason attached, and a quality gate runs before the table reaches the dashboard.

The design is the easy half. The interviewer then asks what happens when things fail: the merge job dies halfway, the source adds a column, an event arrives 2 days late, the topic must be replayed from last week, or the table needs a backfill from a fresh snapshot. Answer each with the mechanism that handles it, and name the trade-off you accepted. The data pipeline interview questions guide and the system design round guide cover more prompts of this kind.

A Spark round checks whether you know where a job spends its time, and the answer is nearly always the shuffle. Narrow transformations like filter or select work inside each partition, and so does withColumn. Wide ones such as groupBy or join move rows across the cluster and cut the job into stages, and distinct does the same. Skew and disk spills show up in those stages, and that's where the slow tasks are.

Know the defaults, because the questions lean on them. Spark broadcasts the smaller side of a join automatically when it's under 10 MB, the default of spark.sql.autoBroadcastJoinThreshold, and a shuffle produces 200 partitions unless spark.sql.shuffle.partitions says otherwise. Adaptive query execution, on by default since Spark 3.2.0, coalesces small shuffle partitions and splits skewed ones while the job runs.

The skew rule has 2 conditions, and interviewers like to test the second. The Spark performance tuning guide treats a partition as skewed only when it's larger than 5 times the median partition and also larger than 256 MB. With a median of 40 MB, 5 times the median is 200 MB, but a partition still has to pass 256 MB before it's split. Below that, a slow task is either acceptable or a case for salting the hot key by hand. The PySpark interview questions guide goes deeper on joins and skew and on reading the Spark UI.

The behavioral round asks about work you have done, and for data engineers the questions cluster around a few themes: a pipeline that broke and how you found out, a time a number on a dashboard was wrong, a disagreement with a stakeholder about how a metric is defined, a project with unclear requirements, and a technical trade-off you made and would make differently now.

Describe the situation and what you did, then give the result in the units of the work. Count the hours data was late and the tables or consumers affected, or say how much a change saved in run time or cost. Then say what you changed so it couldn't happen again, such as a freshness check, a contract with the upstream team or a rerun procedure.

Prepare 5 or 6 stories that each cover several themes, and write down the numbers in each before the interview. The behavioral round guide has the full list of questions and how to structure each answer.

The topics stay much the same across levels; what the interviewer expects from your answer changes. At entry level, the bar is correct SQL and Python on the edge cases, a clean star schema and a clear account of a project you built. The design round, if there's one, asks for a simple batch pipeline. The entry-level data engineer interview questions focus on that loop.

At mid level, you're expected to own a pipeline end to end. That means choosing the grain and making the job idempotent, then testing the output and explaining how you would know it broke. At senior level, the design round carries the most weight. You're expected to ask for the numbers before drawing, name the failure modes of each component without being prompted, weigh cost against freshness, and adapt when the interviewer changes a requirement halfway through. The senior data engineer interview questions are pitched at that bar.

Practice under the conditions of the round. Give yourself about 20 minutes for a SQL or Python question and 45 for a modeling or design question, talk through your plan before you write, and check your answer against the edge cases before you run it. The habit the interview rewards is finding your own bug before the interviewer points at it.

Spend the most time on SQL, because it appears in nearly every loop and usually in the screen that decides whether you reach the rest. Then work through the rounds your target companies run, using the data engineer interview prep guide to plan the order. In the final week, run full rounds with a timer in a data engineer mock interview, where an answer that sounds right but would fail on the data gets the same follow-up a real interviewer would ask.