Data engineering interview prep is the process of practicing the 5 rounds the loop covers: SQL, Python, data modeling, system design, and behavioral. The loop runs 5 to 7 rounds across roughly 4 to 8 weeks of focused prep.
A data engineering loop runs 5 domains in some order: SQL, Python, data modeling, pipeline system design, behavioral. The domains are stable across companies and levels; what changes is how much judgment the room expects on top of the working answer. This is the 2026 read on the loop, drawn from verified interview reports across hundreds of companies and from how this community preps: which rounds members practice, how often they solve them, and where they get stuck. The questions below were asked in real loops, and you can solve them right here.
5 domains over 2 to 5 weeks. The design rounds are where senior candidates separate, and where most rejections land.
Background, level calibration, and which loop you'll get (DE vs analyst vs DS). Confirm the round list here.
Usually SQL, sometimes Python. Live coding. Rejections are about speed and clarity, not just correctness.
SQL, Python, data modeling, system design (L4+), behavioral. The modeling and design rounds decide it.
Interviewers compare notes and set level. Consistency across rounds matters as much as any single strong one.
Base, bonus, equity. Level sets the band; a written competing offer moves equity most.
Share of members who attempt a problem in each domain and go on to solve it. The rounds people fail are not the rounds they practice most.
The round interviewers say decides senior loops is the one the community solves least. Prep where the gap is.
The coding rounds are learnable to a high floor. 90.6% of members who attempt a SQL problem here go on to solve it, usually within a couple of tries. The design rounds are different: barely half of data modeling attempts convert, and pipeline design converts the least of any round. Those are graded on stated grain, named tradeoffs, and failure modes, so reading about them moves the rate little. Practicing the modeling round and the design round out loud is what moves it.
The mock interview sets a real bar. Most verdicts land below Hire, and only a small share reach Strong Hire. An interviewer with follow-ups and a clock is a different problem from a well-specified prompt, so rehearse the interview, not just the questions.
The domains are stable across companies. What shifts is how much judgment the room expects on top of the working answer. Each round below has a real question from that round embedded further down the page.
1 or 2 prompts that look like analytics questions but focus on window functions, anti-joins, and conditional aggregation. Rejections here are about speed and clarity, not correctness: most candidates eventually get to a right answer, but the ones who hire are done in 15 minutes with no dead ends. The trap is window-function ordering, because a ties-allowed ORDER BY inside an OVER clause changes the answer in ways that are hard to spot under time pressure. 928 SQL questions here come from reported loops.
Closer to a notebook than to LeetCode. Pandas groupby/merge/pivot, parsing semi-structured input (gzipped JSON, malformed CSV, fields-of-fields), small class design, and increasingly often a PySpark variant. The bar is not whether you can write Python; it is whether you can write the kind of Python a data engineer writes on the job. Spark-heavy stacks bias toward PySpark here. 415 Python questions here cover exactly this shape.
The round that decides most loops, and the one candidates underprepare for. You get a product (ride-share, streaming app, e-commerce) and are asked for the warehouse schema. Passing answers state the grain before drawing tables, name the SCD type (Type 2 is common, Type 6 is the discriminator), defend star vs data vault, and call out at least one denormalization decision with a reason. The 2 losing patterns: skipping the grain statement, and over-normalizing.
Prompts cluster around 3 families: near-real-time fraud detection, daily reporting aggregations, and user-event sessionization. Passing answers choose batch or streaming explicitly, name the orchestrator, address late-arriving data, define a backfill strategy, and surface at least 2 failure modes (partial writes, schema drift, dedup, exactly-once). The senior-vs-mid signal is whether you raise the failure modes before the interviewer prompts you.
STAR format is table stakes. What separates strong answers is distinguishing what you did from what the team did, and naming the tradeoff you made rather than the outcome you got. Senior loops add scope-under-uncertainty prompts; staff loops add decisions that played out over quarters. Most common failure is rambling; second is burying the result.
5 real questions, each shown with the employer that reportedly asked it, one per round. Solve them right here: the editors run your code and the canvases check your design against the same grader the practice problems use.
Asked in a Data Engineer interview by Meta
> We run a content platform with a built-in team chat, and we want to recommend pages a person has not opened yet. Treat two people as connected when they have both posted in the same chat channel, and for each person surface the pages that at least two different connections have viewed but the person themselves never has.
Asked in a Data Engineer interview by Amazon
> You're rolling up a stream of metric events, each carrying a numeric `timestamp` and a numeric `value`, into fixed-width time windows of size `bucket_width`, where a window spans `[bucket_start, bucket_start + bucket_width)`. The events arrive unsorted, so collapse every window holding at least one of them into its event `count`, the `total` of its values, and the `bucket_start` it begins at, dropping any window that caught nothing. Return the windows in chronological order, earliest `bucket_start` first.
[
{"value":10,"timestamp":100},
{"value":20,"timestamp":250},
{"value":15,"timestamp":150},
{"value":5,"timestamp":310}
][
{"count":2,"total":25,"bucket_start":100},
{"count":1,"total":20,"bucket_start":200},
{"count":1,"total":5,"bucket_start":300}
]
Asked in a Data Engineer interview by Netflix
> Design a data model for a global subscription business with hundreds of millions of subscribers on several plan tiers across regions, where every upgrade, downgrade, pause, cancel and re-subscribe is kept with the moment it took effect, so a subscriber who comes back still has their earlier cancel on record. Finance and product analytics will use it for churn analysis, plan mix by tier, and the monthly recurring revenue each subscriber was paying, by region, at any point in time.
Click + Table in the toolbar, or right-click the canvas to add one.
Drag from a key column's edge dot to another column to draw a foreign key.
Asked in a Data Engineer interview by Shopify
> Our transformation layer has grown to over 200 models, and we're seeing silent data quality failures slip into production reports. The data team wants a pipeline design that enforces quality gates, prevents bad models from promoting downstream, and gives analysts confidence in the output. Design the pipeline.
Click or drag a node from the toolbar above. Right-click the canvas for the full menu.
Drag from a node's right port to another node's left port to wire data flow.
Asked in a Data Engineer interview by Databricks
> The nightly match of `transactions` against `users` on `user_id` has crept to 90 minutes against a 30-minute SLA, and the on-call engineer traced it to one merge task reading 8x the median rows on a Spark 3.4 cluster whose job config switched adaptive execution off. Salting the key would ripple into three downstream jobs, so she wants a configuration-only fix that splits the hot slice at runtime while the match keeps its current merge strategy and still returns each matched transaction's `user_id`, `transaction_date` and `total_amount`.
The single round most likely to decide a senior loop. Here is what a passing answer sounds like versus the one that gets a polite rejection.
States the grain first ("one row per completed trip"), builds a fact_trip around it with conformed dim_driver, dim_rider, dim_city.
Handles the move as an SCD Type 2 on dim_driver with effective/expiry dates, joins facts on the surrogate key so historical trips keep the city that was true at trip time, and defends the denormalization as a deliberate cost.
Starts drawing tables before stating the grain, joins facts to the driver dimension on the natural key, so changing a driver's city retroactively rewrites every past trip's city.
Over-normalizes every entity into its own dimension (an OLTP schema in dimensional clothing) and can't answer "trips per city last quarter" cleanly.
One check per round. If any of these is false 2 weeks out, that round is where your prep hours go.
Every round broken down: the questions candidates reported, the passing-answer patterns, and the traps. Plus the formats: take-homes, live coding, whiteboard design.
SQL round prep guide
Window functions, gap-and-island, and the patterns interviewers focus on in 95% of Data Engineer loops.
Python round prep guide
JSON flattening, sessionization, and vanilla-Python data wrangling in the Data Engineer coding round.
data modeling round prep guide
Star schema, SCD Type 2, fact-table grain, and how to defend a model against pushback.
system design round prep guide
Pipeline architecture, exactly-once semantics, and the framing that gets you to L5.
behavioral round prep guide
STAR-D answers tailored to data engineering, with example responses for impact and conflict.
take-home assignment guide
What a reviewer opens first in a 4 to 8 hour Data Engineer take-home, and what sinks a submission.
live coding round guide
How to think out loud, handle silence, and avoid the traps that sink fluent coders.
whiteboard design round guide
Drawing data architectures live, with the framing interviewers want.
Same 5 rounds. Different bar for what counts as a passing answer. The shift from working answer to reasoned answer is sharp between L4 and L5. Comp bands are the typical company 25th to 75th percentile from the salary data behind this site's company pages, some totals modelled from base pay.
| Level | What they assess | Round emphasis | Common failure | US total comp (2026) |
|---|---|---|---|---|
| Junior / L3 | Working answer to a scoped problem | SQL heavy, modeling light, no design round | Schema vocabulary gaps | $110K to $150K |
| Mid / L4 | Fluency across all 5 domains | Even weights, modeling and design at conceptual depth | Skipping the grain statement in modeling | $133K to $182K |
| Senior / L5 | Judgment and tradeoff articulation | Modeling and design carry the loop | Not leading the design conversation | $163K to $208K |
| Staff / L6 | Scope of impact and decision documentation | 2 design rounds, 1 cross-org behavioral | Treating design like an L5 deep dive instead of a roadmap | $178K to $216K+ |
The questions split the same way. Among the ones asked in junior loops, 100% are SQL or Python and the design domains barely appear. By the senior band, 37% are modeling, pipeline design, or Spark, and at Staff Data Engineer level 68% are pipeline design alone. The subject of the interview shifts as you go up: juniors are hired on execution, staff engineers on architecture.
Role-specific bars sit on top of these. Analytics engineering loops add dbt and modeling depth at the expense of pipeline design. ML data engineering loops push feature-store design and online/offline parity. Cloud specializations (AWS, GCP, Azure) substitute one of the design rounds for a cloud-native pipeline build using that provider's primitives.
The 5 tiers this site's company data uses, what the loop leans on at each, and how much practice material we have for companies at that tier.
| Tier | Who that is | How the loop shifts | Practice coverage |
|---|---|---|---|
| Elite | Top-tier public tech, household names | The full 5-round template at its deepest: committee calibration, window-heavy SQL, and modeling plus design carrying every senior decision | Solid |
| Top Tech | Well-funded private tech, unicorns | The most design-forward loops we see reported: pipeline architecture and modeling dominate what these companies ask | Extensive |
| Enterprise | Series B to D startups, public tech companies | Practical over theoretical: Python and pipeline questions shaped like the job, take-homes more common, fewer rounds | Broad |
| Growth | Seed to Series A, regional firms | 2 or 3 longer sessions instead of a 5-round loop; breadth over depth, often a take-home in place of a screen | Emerging |
| Staffing | First data role, career switch | SQL fluency and fundamentals decide it; screens are the whole loop and speed matters more than architecture | Growing |
Most loops follow the standard 5-round template. 5 companies bend it enough to be worth knowing in advance. Netflix and Airbnb skew streaming and large-scale event processing; expect a Spark or Flink question where most other companies would ask SQL. Stripe pushes system design depth, with a second design round in place of a Python round for senior candidates. Databricks digs into modeling on Delta Lake and PySpark specifics that no other loop covers. Uber runs the heaviest data modeling round in the industry, with 2-hour onsites that include a live schema critique. If you're interviewing at any of these 5, weight your prep accordingly.
For everyone else, the standard 5-round loop is the right mental model. Reference the U.S. Bureau of Labor Statistics data engineer occupation page for level definitions and median compensation by metro.
From the interview reports behind this site's per-company guides. 'Standard' means the 5-round template with no unusual weighting.
| Company | Loop shape | What it leans on |
|---|---|---|
| Stripe | Second design round replaces Python at senior | Idempotent pipelines, system design depth |
| Uber | Heaviest modeling round in the industry | 2-hour onsite with live schema critique |
| Airbnb | Standard + streaming emphasis | Spark, large-scale event processing |
| Databricks | Spark-native loop | Delta Lake modeling, PySpark internals |
| Snowflake | Standard, dialect-deep SQL | QUALIFY, FLATTEN, time travel, warehouse design |
| Netflix | Standard + streaming emphasis | Spark or Flink question replaces one SQL round |
| Lyft | Standard | Marketplace metrics SQL, geo event modeling |
| DoorDash | Standard | Logistics modeling, real-time dispatch design |
| Instacart | Standard | Catalog and inventory modeling, window functions |
| Robinhood | Standard + correctness emphasis | Exactly-once semantics, financial reconciliation |
| Standard | Engagement event sessionization | |
| Meta | SQL-heaviest FAANG loop | Window functions, gap-and-island, Presto dialect |
Round-by-round breakdowns with the questions reported by candidates, the stack they actually use, and where the loop deviates from the standard template.
Stripe data engineer interview guide
Stripe Data Engineer process, comp, financial-precision SQL, and the collaboration round.
Uber data engineer interview guide
Uber Data Engineer process, marketplace and surge data modeling, geospatial pipelines.
Airbnb data engineer interview guide
Airbnb Data Engineer process, experimentation platform questions, two-sided marketplace modeling.
Databricks data engineer interview guide
Databricks Data Engineer process, Spark internals, lakehouse architecture, Delta Lake questions.
Snowflake data engineer interview guide
Snowflake Data Engineer process, micro-partitions, query optimization, warehouse architecture.
Netflix data engineer interview guide
Netflix Data Engineer process, streaming pipelines, A/B test infra, and the keeper test.
Lyft data engineer interview guide
Lyft Data Engineer process, marketplace pricing pipelines, real-time matching data.
DoorDash data engineer interview guide
DoorDash Data Engineer process, three-sided marketplace data, dasher-merchant-consumer modeling.
Instacart data engineer interview guide
Instacart Data Engineer process, retailer catalog modeling, batch and real-time inventory.
Pinterest data engineer interview guide
Pinterest Data Engineer process, recommendation pipelines, ad attribution data, graph modeling.
The job description and the interview rarely match. dbt is on every JD; dbt rarely shows up in the loop unless the company is dbt-native (Wayfair, HubSpot, dbt Labs). Airflow is the same: conceptual questions about DAG design come up, code questions almost never do. Spark is the inverse: rarely on the JD as a requirement, frequently in the design round as a tradeoff conversation. See the dbt vs Airflow comparison for which one to spend time on.
On warehouses, the loop is dialect-agnostic at most companies: ANSI SQL with Postgres syntax for the edge cases. The exceptions are the warehouse vendors themselves and the companies built on a specific stack. Snowflake-native shops ask Snowflake-specific syntax (QUALIFY, FLATTEN, time travel); BigQuery shops do the same for ARRAY functions and partition decorators. Snowflake vs Databricks covers which dialect to invest in if you're choosing.
For streaming, Kafka comes up in design rounds at any company handling real-time data, but only Stripe, Netflix, Databricks, and the ad-tech mid-market ask Kafka questions deep enough to require API-level familiarity. Flink is asked at maybe 5 companies in the industry. If you're not interviewing at one of them, the time-to-payoff on learning Flink is negative. See Kafka vs Kinesis for the AWS-context version of the same call.
2 weeks out. SQL practice and one mock per day. A passing run takes about 3 min on an easy problem and 4 min on a medium, so a focused hour is 8 to 12 problems. Skip the take-home if it's not required, and don't start a new tool. Hit the top 100 questions for breadth, then do 4 to 6 full mock interviews out loud.
8 weeks out. Week 1 and 2: SQL and Python to fluency. Week 3 through 5: data modeling 10 problems deep, with the schemas drawn out and defended, since the community's 50.5% solve rate on modeling marks it as the shared weak spot. Week 6 and 7: system design, 15 prompts minimum, out loud. Week 8: mocks and behavioral rehearsal. Each round has its own detailed walkthrough in the per-round guides.
Switching from software engineering. Your algorithm prep is over-leveled for this loop. The deltas to close are dimensional modeling and pipeline design. See data engineer vs backend engineer for which of your existing skills carry over. SQL vs Python covers which to deepen first.
Switching from analytics or analytics engineering. Your SQL is already strong. The unfamiliar territory is pipeline orchestration, late-arriving data, and the failure modes that come from running schedules instead of writing queries. See data engineer vs analytics engineer for the specific gap to close.
2 per round, condensed to the passing shape. The full worked versions, with follow-ups and the common wrong answers, live in the per-round guides and the practice catalog.
DENSE_RANK() OVER (PARTITION BY customer_id ORDER BY order_total DESC) in a CTE, filter rank = 2 outside. Tie handling is where the interviewer is watching: ROW_NUMBER forces an arbitrary winner, RANK skips 2 entirely when 2 rows tie at 1, DENSE_RANK keeps a true second. Say which you chose and why before the interviewer asks.
Gap-and-island: activity_date minus ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY activity_date) * INTERVAL '1 day' is constant across a consecutive run. GROUP BY the user and that derived key, HAVING COUNT(*) >= 7. Dedup multiple events per day with DISTINCT first or the row numbers break; volunteering that dedup step is the senior signal.
Stream it: gzip.open in text mode, iterate line by line, json.loads each line, accumulate counts in a defaultdict(int). Memory holds the counter, never the file. Mention the malformed-line policy (count and skip to a dead-letter log, never crash) and you have covered what the hidden tests actually check.
Dict keyed on event_id; replace when the incoming updated_at is strictly newer, with a deterministic tiebreaker (say, larger sequence number) for equal timestamps. This is ROW_NUMBER dedup translated to Python, and the interviewer is checking the same 2 things: the tiebreaker and what happens on ties.
State the grain first: one row per delivered order in fact_orders. Type 2 dimensions for courier, customer, and restaurant; promo as an attribute on the order fact because reporting cares about promo state at order time. Courier utilization derives from the fact plus a shift snapshot table. Then name one tradeoff out loud: star over snowflake because the consumer is BI.
Type 2 when history must be reported as it was (a customer's segment at order time), Type 1 when only current state matters (a corrected email). The cost is row explosion, half-open effective_from/effective_to join logic on every fact join, and a merge pipeline that must be idempotent. Saying 'Type 2 everywhere to be safe' is a failing answer; it doubles storage and every join for history nobody asked for.
Choose streaming explicitly and say why batch loses (minutes matter). Kafka or Kinesis into a stateful consumer with sliding-window aggregates per account, alerts to a low-latency store, raw events landed in parallel to the warehouse for backfill and model training. Name the failure modes unprompted: late events versus watermark, duplicate delivery handled by idempotent alert keys, and what degrades when the consumer lags.
Make the job idempotent: MERGE on the natural key instead of INSERT, or write to a staging table and atomically swap the partition. The principle to say out loud: re-running yesterday today must produce the same result. Add a run_id for audit and alert on row-count drift rather than on job success alone.
Pick a failure with a real blast radius, and structure it: what broke, what you did in the first hour, what the permanent fix was, what monitoring exists now that did not before. Ownership is the line they are listening for: 'I missed the alert gap and here is the check I added' passes; 'the upstream team sent bad data' fails, even when true.
Senior loops ask this to gauge calibration, not humility theater. Name the decision, the information you had, why the call was reasonable then, when the evidence turned, and how fast you reversed. The failing patterns are picking a fake weakness or a decision that was someone else's. Reversal speed is the metric they write down.
4 to 8 weeks is the range that fits most working engineers. If you've shipped pipelines in the last year and your SQL is fluent, 4 weeks gets you back to interview pace. If you've been in one tech stack for 3 years, plan 8. The unavoidable time sink is system design, which doesn't compress: you need 15 or 20 design problems out loud before you stop sounding rehearsed.
Less than the job descriptions suggest. Most mid-market loops touch Spark at the conceptual level (partitioning, broadcast joins, skew) but rarely require you to write PySpark on a whiteboard. The exceptions are companies that genuinely run on Spark at scale: Databricks, Netflix, Airbnb, and most large adtech and ride-share shops. For everyone else, read the JD literally; if Spark is one bullet among many, conceptual is enough.
Data modeling and system design. Members here solve 90.6% of the SQL problems they attempt, but the rate falls to 50.5% on data modeling and 33.6% on pipeline design. SQL and Python rounds have unambiguous outcomes; the design rounds are where senior candidates separate, and rejections at L5 and above almost always cite 'did not lead the design conversation' or 'missed a tradeoff.' That gap only closes by practicing designs out loud.
Yes, if the company is one you want. Most take-homes are assessed as much on the README as on the code: assumptions stated, tradeoffs named, edge cases you chose to skip explicitly called out. A clean take-home moves you from 'maybe' to 'yes' in calibration meetings. The exception is if the prompt is poorly scoped and a senior recruiter can't tell you the expected time investment; that signals an unserious process.
L4 is assessed on whether you can do the work. L5 is assessed on whether you can decide what work is worth doing. The same SQL question at L4 expects a correct query; at L5 it expects a correct query plus 3 reasons the requirement might be wrong. The same pipeline prompt at L4 expects a working pipeline; at L5 it expects a working pipeline plus the migration story and the failure mode you'd alert on.
Data science loops lean on statistics, A/B testing, and modeling. Data engineering loops lean on production systems. Both share SQL and Python, but the data engineering SQL bar is higher (window functions, query optimization, the kind of joins that come up because someone partitioned wrong), and the system design round replaces the modeling case study. If a job description mentions both, ask the recruiter which loop you'll get; the difference is real.
A recruiter screen, 1 or 2 technical screens, then a 3-to-5 round onsite: SQL, Python or coding, data modeling, system design at L4 and above, and behavioral. 5 to 7 total touches over 2 to 5 weeks is the norm at mid-size and large companies. Startups compress the same domains into 2 or 3 longer sessions, often with a take-home replacing one screen.
Different, not harder. The algorithm bar is far lower: almost no dynamic programming or graph puzzles. The systems bar is different in kind: dimensional modeling and pipeline design have no LeetCode equivalent, so software engineers switching over routinely fail loops they expected to cruise, not on code but on grain statements and idempotency reasoning. If you are coming from SWE, the modeling round is the one to respect.
SQL alone passes nothing beyond an analyst-titled screen; every real DE loop also covers Python, modeling, and at L4+ system design. But you do not need LeetCode-style algorithm prep either: the Python rounds are pipeline-shaped (parsing, dedup, sessionization, retries), and about 4 percent of reported rounds resembled algorithm puzzles. Work SQL until it is reflex and Python until pipelines come out clean, then put the hours you saved on LeetCode into modeling.
No. DataDriven is community-run, and every feature is open to every member: the practice problems that run your code against real data, the mock interview, the schema canvas, all of it. The 'catch' is that we use anonymized solve patterns to improve how problems are picked for you, and to weight which problems we add next.
Reading a solution is not the same as writing one
Every engineer who has frozen on a query they had read a dozen times knows the gap. The only preparation that closes it is producing the answer yourself, under time, before the interview does it for you
76% of hiring managers reject on the coding task, not the resume
From HackerRank's 2024 Developer Skills Report. Candidates who look strong on paper still fail the live screen if they haven't done timed, executable practice
System design comes down to the calls you defend out loud
Ingestion, batch vs streaming, the bronze/silver/gold layers, idempotency, backfill and replay. Sketching the pipeline and naming the failure modes is the signal, not the boxes
Data engineer interview questions
The questions each round asks, answered with the traps that cost points
SQL round walkthrough
Window functions, anti-joins, the patterns interviewers focus on.
Data modeling round
Grain, SCDs, and the tradeoffs that separate senior from mid.
System design round
Pipelines not services. Batch vs streaming, late data, failure modes.
Data engineer roadmap
The 6 stages to learn in order before the loop, with a timeline for your background
FAANG data engineer interview questions
How the Meta, Amazon, Apple, Netflix and Google loops differ, with answers
The data engineering challenge
Dirty, production-shaped data, scored blind each week.
50+ guides covering every round, company, and role