Interview Roadmap¶

What a data engineering interview loop tests, which handbook guides cover each part, and a four-week plan to prepare.

Last reviewed 29 Sep 2026 · Download PDF

Overview¶

Challenge: Data engineering interviews cover a wide range: SQL, Python, data modelling, pipelines, distributed systems, cloud, and increasingly LLM tooling. Preparing "everything" is impossible, and reading without practising does not transfer to a live round.

Solution: Know the format of the loop, map each round to the topics that actually get asked, and practise the skill each round tests. Every guide in this handbook ends with Interview Questions, so this page tells you which ones to prioritise and in what order.

flowchart LR
    R["Recruiter screen<br/>fit, motivation, scope"] --> S["SQL round<br/>patterns, window functions"]
    S --> P["Python / coding<br/>data manipulation, clean code"]
    P --> D["Data modelling +<br/>pipeline design"]
    D --> A["System design<br/>end-to-end architecture"]
    A --> B["Behavioural<br/>ownership, incidents, trade-offs"]

Loops differ by company: some skip a round, add a take-home or a live debugging session, or add an AI/LLM round. Ask the recruiter for the format and the interview length.

On this page

Basic - The Rounds - Topic Map

Intermediate - A Four-Week Plan - How to Answer

Advanced - Behavioural Round - Take-Homes and Live Debugging - Questions to Ask Them

Reference - Common Pitfalls - Cheat Sheet - Interview Questions - Further Reading

The Rounds¶

Round	What it tests	Typical content	Prepare with
Recruiter / hiring manager	Fit, level, communication	Your projects, why this role, scale you have handled	A two-minute story for each project
SQL	Fluency and pattern recognition	Window functions, joins, dedup, cohorts, sessionisation	SQL Interview Patterns, Lab 01
Python / coding	Data wrangling and clean code	Parse and aggregate records, dictionaries and sets, generators, sometimes a small algorithm	Python for DE
Data modelling	Turning a business into tables	Star schema, slowly changing dimensions, grain, keys	Data Modeling
Pipeline design	Reliable ETL	Idempotency, incremental loads, backfills, late data, quality checks	DE Concepts, Ingestion & CDC, Airflow, Testing and CI/CD
System design	Architecture and trade-offs	Batch vs streaming, storage choices, scale, cost	System Design, Case Studies
Tool depth	Real experience with the stack on your CV	Spark tuning, dbt, Kafka semantics, warehouse internals	The guide for each tool
Behavioural	Ownership and judgement	An incident you handled, a disagreement, a mistake	Behavioural Round

Topic Map¶

Where the questions come from, ordered by how often they appear in practice.

Priority	Topic	Guides
Almost always	SQL and window functions	SQL, SQL Interview Patterns
	Data modelling (star schema, SCD)	Data Modeling
	ETL vs ELT, batch vs streaming, idempotency	DE Concepts
	Python data handling	Python for DE
Very often	Spark internals: shuffles, skew, partitioning	PySpark
	Orchestration and backfills	Airflow, Dagster
	Warehouse and lakehouse choices	Snowflake, BigQuery, Delta Lake, Iceberg
	Data quality and observability	Data Quality, Pipeline Observability
Often	Kafka and streaming semantics	Kafka, Flink
	dbt	dbt
	Testing and CI/CD for pipelines	Testing and CI/CD
	Cost and performance	Cost Optimization
	Serving fast analytics, query federation	Real-Time Analytics Databases, Trino
	Running data workloads on Kubernetes	Kubernetes
	Event time, windows and late data	Beam and Dataflow, Streaming SQL
	NoSQL modelling and CDC from operational stores	NoSQL and Operational Stores
	Serving data to the business	BI Tools
	Incidents, on-call and postmortems	DataOps
	Catalogs, ownership and lineage tooling	Data Catalogs in Practice
	Choosing and defending a stack	Choosing a Stack
	LLMs and data: safe SQL generation, MCP	MCP and Text-to-SQL
	Cloud platform specifics (Microsoft)	Azure and Fabric
	Security and privacy	Data Security & Privacy
Growing	LLMs, RAG, evals	LLM APIs, RAG, Evals
Situational	Terraform, Docker, CDC, lineage	Terraform, Docker, Governance

Go deep on the tools listed on your CV first. Interviewers ask about what you claim.

A Four-Week Plan¶

About 6–8 hours a week. Adjust the pace to your interview date.

Week	Focus	Do
1: Core skills	SQL and Python	Type out all 15 SQL patterns from memory. Solve five problems a day for a week. Do Lab 01. Refresh Python dictionaries, comprehensions, generators and `collections`
2: Modelling and pipelines	Data modelling, ETL design	Model an e-commerce and a ride-sharing business on paper, with grain, facts and dimensions. Explain idempotent loads, backfills and late-arriving data out loud. Do Lab 02 and Lab 05
3: Distributed systems	Spark, streaming, storage	Read the Spark shuffle, skew and join sections and explain them without notes. Kafka delivery guarantees and consumer groups. Lakehouse table formats. Do Lab 03 and Lab 04
4: Design and stories	System design, behavioural	Work through each case study aloud, timed at 45 minutes. Write five STAR stories. Do two full mock interviews with a friend or recorded

The most valuable habit: speak your reasoning out loud while you practise. Silent practice does not train the skill that the interview measures.

How to Answer¶

A repeatable structure works for almost any technical question:

Clarify. Ask about data volume, freshness, correctness needs, NULLs and duplicates, and who consumes the result.
State assumptions. "I'll assume orders are unique by order_id and time is UTC."
Outline the approach in one or two sentences before you write anything.
Solve simply first, then refine. A correct simple answer beats an unfinished clever one.
Test with a tiny example, including edge cases: empty input, ties, NULLs, one row.
Discuss trade-offs and scale: what changes with 1000× the data? What would you monitor?

For system design, use the sequence in System Design: requirements, capacity, architecture, deep dive on the risky parts, failure modes, cost. Draw as you talk.

If you get stuck, say what you are thinking. Interviewers give hints to candidates who communicate, and rarely to those who go silent.

Behavioural Round¶

Prepare five stories you can adapt to most questions. For each, use STAR: Situation, Task, Action, Result. Spend most of the time on your actions and a measurable result.

Story	Typical question it answers
A pipeline failure or data incident you handled	"Tell me about a time something broke in production"
A pipeline or query you made much faster or cheaper	"Tell me about an optimisation"
A disagreement about a technical decision	"How do you handle conflict?"
A project with unclear requirements	"How do you work with stakeholders?"
A mistake you made and what you changed after	"Tell me about a failure"

Good signals: you took ownership, you communicated early, you fixed the root cause and added a monitor or test, and you can name a number (hours saved, cost reduced, latency cut). Read Pipeline Observability for the incident vocabulary.

Take-Homes and Live Debugging¶

Take-homes are judged on engineering habits more than cleverness: - Make it runnable in one command, with a README that states assumptions and how to run it. - Idempotent loads, sensible schema, tests for the tricky logic, and data quality checks. - Keep it small and finished. Mention what you would do with more time (monitoring, incremental loads, scaling).

Live debugging gives you a broken query or pipeline. Read the error, form a hypothesis, check the smallest thing that confirms it, and narrate as you go. Common causes: fan-out joins, NULL handling, wrong grain, a timezone shift, a schema change, duplicates from a retry.

Questions to Ask Them¶

Good questions show judgement and help you decide whether to join.

What does the data stack look like, and what is painful about it today?
How do you find out when a pipeline is wrong, and how long does it take?
What is the on-call arrangement for data incidents?
How are schema changes in source systems communicated to the data team?
How do data engineers work with analysts, scientists and product?
What would success look like for this role in six months?

Common Pitfalls¶

Pitfall	Symptom	Fix
Memorising tool trivia	You can recite settings but not explain why	Learn the problem each tool solves and its trade-offs
Starting to code immediately	Solving the wrong problem	Clarify and state assumptions first
Ignoring `NULL`s, duplicates, ties and time zones	Correct on the happy path only	Ask about them, then handle them
Silent thinking	Interviewer cannot help or assess you	Narrate your reasoning
One-tool answers to design questions	"Just use Spark" for everything	Compare at least two options with trade-offs
No numbers in stories	Impact sounds vague	Quantify: rows, hours, dollars, latency
Claiming tools you have only read about	An easy follow-up exposes it	List what you have used, and be honest about depth

Cheat Sheet¶

Situation	Do this
Question is vague	Ask about scale, freshness, consumers, correctness
SQL problem	Name the pattern, write the simple version, test on a tiny table
Pipeline design	Sources → ingest → store → transform → serve, then idempotency, backfill, quality, monitoring
"How would it scale?"	Where is the bottleneck: shuffle, skew, single writer, hot partition?
"What could go wrong?"	Late data, duplicates, schema change, retries, source outage
Out of time	Summarise the design and list what you would do next
Stuck	Say what you tried, and ask a clarifying question

Interview Questions¶

Q: Walk me through a pipeline you built end to end. A: Give the context and scale, then follow the data: source, ingestion (batch or CDC), storage layers, transformations, orchestration, quality checks, monitoring, consumers. Highlight one hard problem you solved (late data, a slow join, cost) with a number for the result, and say what you would change now.

Q: How do you make a pipeline idempotent? A: Design each run so that running it twice for the same input gives the same result: overwrite a partition or MERGE on a business key instead of appending blindly, avoid side effects that cannot be repeated, and use deterministic keys. This makes retries and backfills safe.

Q: What would you check first when a dashboard number looks wrong? A: Whether the data is fresh and complete (freshness and row counts by layer), then whether the logic changed (recent deploys, schema changes), then grain and join issues such as fan-out or duplicates. Lineage tells me where to start, and I compare against a trusted source to confirm the fix.

Q: How do you decide between batch and streaming? A: By the freshness the business needs and the cost of being wrong or late. If hourly or daily is enough, batch is simpler and cheaper. Streaming is worth it for use cases with minutes or seconds of tolerance, such as fraud detection or operational alerts, and it adds state, ordering and exactly-once questions.