Interview Insights · Data Engineer
What I Wish Every Data Engineer Candidate Knew Before Walking In
Quick summary — DE interview prep
If I could hand every data engineer candidate one page before the interview, it would cover the rounds, the SQL traps, the Spark basics and a few day-of habits. Data engineering interviews vary between companies, but the core is surprisingly stable. Almost every loop tests SQL beyond simple joins, asks how distributed processing works under the hood, and includes some kind of design conversation. Candidates who know this shape prepare for the right things. Candidates who do not often spend weeks on tool tutorials and then lose marks on NULL handling and shuffles.
In this guide you will learn:
- The typical shape of a data engineer interview loop
- The SQL traps that catch even experienced candidates
- Window function patterns you should be able to write from memory
- The Spark basics interviewers probe: partitions, shuffles, skew
- Day-of habits that make a strong first impression
SECTION 01The shape of a typical data engineer interview loop
Companies name their rounds differently, but most data engineer loops include the same building blocks. There is usually a screening call about your resume, a hands-on SQL round, a round on Python or Spark and a design round. Some companies combine them; some add a take-home assignment. Behavioural questions appear in every round, not only in HR.
Knowing this shape helps you plan. If you have two weeks, you should not spend all of it on Spark tuning while your SQL window functions are shaky. Ask the recruiter what the rounds are. It is a normal question, and the answer tells you where to spend your time.
| Round | What it usually looks like | What I am really checking | Common way to lose it |
|---|---|---|---|
| Screening | Resume walk-through and basic concepts | Can you explain your own work clearly? | Listing tools without saying what you built |
| SQL | Live queries on a sample schema | Joins, aggregation, windows and NULL logic | Correct syntax, wrong result due to NULLs |
| Python / Spark | Code a transformation and explain execution | Whether you understand what runs where | Using collect() on a large dataset |
| Design | Design a pipeline for a business need | Requirements, sizing and failure handling | Naming tools before asking about volume |
FIRST QUESTIONS I OFTEN USE IN EACH ROUND
Screening:
"Pick one pipeline on your resume. Where does the data
come from and who uses the output?"
SQL:
"Find each customer's second most recent order."
Spark:
"What happens when you call groupBy on a DataFrame?"
Design:
"Our app sends click events. Product wants a daily
active users report. Where do you start?"
None of these are tricks. Each opens a conversation.BEFORE THE INTERVIEW, IT IS FINE TO ASK:
- How many rounds are there, and what is each one?
- Is the SQL round live coding or on a shared document?
- Which SQL dialect or warehouse does the team use?
- Is there a take-home task? How long should it take?
- Will the design round use a whiteboard or a diagram tool?
- Is the team more batch or streaming focused?
These questions show organisation, not weakness.
If the recruiter tells you the team works on a specific warehouse, spend an evening on its SQL dialect. Small differences in date functions are exactly what slows people down during live coding.
SECTION 02The SQL traps that catch even experienced candidates
The SQL round is where I see the most avoidable rejections. Candidates prepare joins and GROUP BY, then lose marks on NULL behaviour, filtering a LEFT JOIN in the wrong place or confusing RANK with DENSE_RANK. These are not advanced topics. They are the details that separate someone who has written SQL against messy production data from someone who has only done tutorials.
Learn the traps below until you can explain them aloud. In the round, mention them before I ask: 'I am using NOT EXISTS because NOT IN behaves badly with NULLs.' That one sentence changes how the rest of the round goes.
| Trap | What goes wrong | Safer pattern | Sentence to say aloud |
|---|---|---|---|
| NOT IN with NULLs | Returns no rows if the subquery has a NULL | Use NOT EXISTS | NOT IN fails silently when NULLs exist |
| Filtering a LEFT JOIN in WHERE | Turns it into an inner join | Put the condition in the ON clause | WHERE on the right table drops unmatched rows |
| COUNT(col) vs COUNT(*) | COUNT(col) skips NULLs | Choose deliberately | COUNT(col) counts non-null values only |
| RANK vs DENSE_RANK | RANK leaves gaps after ties | DENSE_RANK for 'Nth highest' | Ties share a rank; DENSE_RANK has no gaps |
-- Second highest salary in each department (ties allowed)
WITH ranked AS (
SELECT department_id,
employee_id,
salary,
DENSE_RANK() OVER (
PARTITION BY department_id
ORDER BY salary DESC
) AS salary_rank
FROM employees
)
SELECT department_id, employee_id, salary
FROM ranked
WHERE salary_rank = 2;
-- Customers with no orders: NOT EXISTS is NULL-safe
SELECT c.customer_id
FROM customers AS c
WHERE NOT EXISTS (
SELECT 1 FROM orders AS o
WHERE o.customer_id = c.customer_id
);-- Daily revenue, change from previous day, and 7-day running total
WITH daily AS (
SELECT order_date, SUM(amount) AS revenue
FROM orders
GROUP BY order_date
)
SELECT order_date,
revenue,
revenue - LAG(revenue) OVER (ORDER BY order_date) AS change_vs_prev,
SUM(revenue) OVER (
ORDER BY order_date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS rolling_7_day
FROM daily
ORDER BY order_date;
-- Say aloud: "ROWS BETWEEN counts rows, not calendar days.
-- If some dates have no orders, I would join to a calendar
-- table first so missing days count as zero."
The comment about missing days is the kind of detail that marks real experience. Rolling windows over rows quietly become wrong when the data has gaps, and production data almost always has gaps.
SECTION 03The Spark basics interviewers keep coming back to
You do not need to be a Spark tuning expert for a junior or mid-level role. You do need to understand what happens when your code runs. Most Spark questions I ask are about the same few ideas: transformations are lazy, data is split into partitions, some operations shuffle data across the network, and uneven keys cause skew.
If you can explain those four ideas with a small code example, you will handle most Spark questions. If you can only describe Spark as 'fast big data processing', the round will be short.
| Concept | Plain explanation | Typical question | Good short answer |
|---|---|---|---|
| Lazy evaluation | Transformations build a plan; actions run it | When does Spark actually read the file? | On the first action, such as count or write |
| Narrow vs wide | Wide transformations shuffle data between partitions | Is groupBy narrow or wide? | Wide; rows with the same key must meet |
| Skew | One key has far more rows than others | One task runs for an hour. Why? | Likely a skewed key; salt it or broadcast |
| Small files | Too many tiny output files | Why is the next job slow to read? | Too many files; coalesce or compact |
from pyspark.sql import SparkSession, functions as F
spark = SparkSession.builder.appName("daily_sales").getOrCreate()
orders = spark.read.parquet("/lake/raw/orders/") # lazy
stores = spark.read.parquet("/lake/dim/stores/") # small table
daily = (orders
.filter(F.col("status") == "DELIVERED") # narrow
.join(F.broadcast(stores), "store_id") # no shuffle of orders
.groupBy("order_date", "city") # wide: shuffle
.agg(F.sum("amount").alias("revenue")))
(daily
.repartition("order_date")
.write.mode("overwrite")
.partitionBy("order_date")
.parquet("/lake/mart/daily_sales/")) # action: runs the plan"Nothing runs until the write at the end.
The filter is narrow, so each partition handles it alone.
The stores table is small, so I broadcast it to every
executor. That avoids shuffling the large orders table
for the join.
The groupBy is wide: all rows for the same date and city
must end up in the same partition, so Spark shuffles.
Before writing, I repartition by order_date so each date
folder gets fewer, larger files instead of many tiny ones.
If I wanted to confirm the plan, I would call
daily.explain() and look for BroadcastHashJoin."
Mentioning explain() is a small but useful habit. It shows that you check what Spark actually plans to do instead of assuming. Interviewers often follow up by asking what you would look for in the plan, so know that a broadcast join and an exchange step are the two things to spot.
SECTION 04A short preparation plan for the week before
Use this plan in the final week before a data engineer interview. It focuses on the gaps that cost the most marks, and it ends with a calm, light day before the interview.
SEVEN DAYS BEFORE THE INTERVIEW
Day 1 SQL traps: NULLs, LEFT JOIN filters, COUNT rules
Day 2 Window functions: ranking, LAG/LEAD, running totals
Day 3 Spark: lazy plans, shuffles, broadcast, skew
Day 4 Your projects: explain each one aloud, record it
Day 5 One full design case, timed, spoken aloud
Day 6 Mock interview with a friend or trainer
Day 7 Light review only, prepare questions to ask
Each day: 20 minutes of SQL practice regardless of topic.CAN YOU ANSWER THESE ALOUD IN UNDER A MINUTE EACH?
1. Why can NOT IN return zero rows unexpectedly?
2. RANK vs DENSE_RANK vs ROW_NUMBER: when to use each?
3. What makes a pipeline rerun safe?
4. What is a shuffle, and which operations cause one?
5. How would you deal with a skewed join key?
6. Parquet vs CSV: why does it matter for analytics?
7. Batch or streaming for a daily report? Why?
8. What data quality checks run on your pipeline?ON THE DAY
[ ] Laptop charged, IDE or SQL editor tested
[ ] Stable internet and a backup hotspot for online rounds
[ ] Notepad and pen for sizing and diagrams
[ ] Resume printed or open, every line explainable
[ ] Two or three questions for each interviewer
[ ] Arrive or log in ten minutes early
During each round:
Restate the question. Ask one clarifying question.
Think aloud. Test your answer on an edge case.
SECTION 05Day-of habits that change how you come across
These are small, but they shape the impression you leave in every round.
- Clarify before coding — Ask about NULLs, duplicates and expected output before writing SQL. It prevents rework and shows production thinking.
- Say the edge case out loud — After any answer, name one edge case and how your solution handles it.
- Admit unknown tools calmly — If you have not used a tool, say so and explain the closest thing you have used. Bluffing is easy to detect.
- Write readable SQL — Use CTEs with clear names and one clause per line. Interviewers read your query as you type it.
- Ask about the team's data — Questions like 'what is the biggest data quality problem you face?' show genuine interest in the work.
SECTION 06Interview Q&A — DE interview prep
Q1Why does NOT IN sometimes return no rows?
If the subquery returns even one NULL, the comparison with that NULL is unknown for every outer row, so NOT IN filters everything out. NOT EXISTS does not have this problem because it only checks whether a matching row exists.
Q2What is the difference between RANK, DENSE_RANK and ROW_NUMBER?
ROW_NUMBER gives every row a unique number, even for ties. RANK gives ties the same number and then skips, so you get 1, 1, 3. DENSE_RANK gives ties the same number without gaps, so you get 1, 1, 2. For 'second highest value' questions, DENSE_RANK is usually what you want.
Q3What is a shuffle in Spark and why does it matter?
A shuffle moves data between executors so that rows with the same key end up in the same partition. It happens in wide operations such as groupBy, join and distinct. It matters because it involves disk and network work, which is often the slowest part of a job.
Q4How would you handle a skewed join in Spark?
First confirm the skew by checking key counts. If the other table is small, broadcast it. Otherwise, options include salting the hot key by adding a random suffix and duplicating the matching rows on the other side, or enabling adaptive query execution's skew join handling in recent Spark versions.
Q5Why do data engineers prefer Parquet over CSV?
Parquet is columnar and compressed, so queries read only the columns they need and files are smaller. It also stores the schema and data types, which avoids parsing errors. CSV is useful for exchange but slow and fragile for analytics.
SECTION 07Test yourself — DE interview prep quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What rounds are there in a data engineer interview?
Many loops include a screening call, a SQL round, a Python or Spark round and a design round. Some add a take-home task or a separate behavioural round. Ask the recruiter for the exact structure.
How much SQL do I need for a data engineer interview?
More than basic joins. Expect window functions, aggregation with HAVING, NULL handling, deduplication, date logic and performance basics. Practise writing queries from memory, not only reading them.
Do freshers get Spark questions in data engineer interviews?
Often yes, especially for roles that use Spark. Focus on lazy evaluation, partitions, narrow and wide transformations, shuffles, broadcast joins and why collect() is risky.
What should I study one week before a data engineer interview?
Review SQL traps and window functions, Spark execution basics, your own projects explained aloud, and one timed design case. Keep the last day light.
What questions should I ask a data engineering interviewer?
Ask about the team's main data sources, batch versus streaming work, how data quality is monitored, what a typical week looks like, and the biggest data problem the team is solving now.
Where can I practise Data Engineer interview answers with expert feedback?
Yes. Uncodemy's Data Science Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise Data Engineer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Walk in knowing what to expect
Our Data Science Training Course covers SQL, Python, Spark, pipelines and cloud storage, with mock interview rounds that mirror the structure of real data engineer loops.
Talk to a counsellor for current fees- Advanced SQL practice
- Spark and Python labs
- Design case rounds
- Mock interview feedback