Data Engineering Interview Prep

SQL round. 45 to 60 minutes, live coding, one or two prompts that look like analytics questions but test 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 fifteen minutes with no dead ends. The trap is window-function ordering: a ties-allowed ORDER BY inside an OVER clause changes the answer in ways that are hard to spot under time pressure. Full walkthrough in the SQL round prep guide.

Python round. 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. Companies with heavy Spark stacks bias toward PySpark on this round, covered in the Python round breakdown.

Data modeling round. The round that decides most loops, and the one candidates underprepare for. The interviewer gives you a product (ride-share, streaming app, e-commerce) and asks for the warehouse schema. Passing answers state the grain before drawing tables, name the slowly changing dimension type (Type 2 is the common one, Type 6 is the discriminator), defend a tradeoff between star and data vault, and call out at least one denormalization decision with a reason. The two losing patterns: skipping the grain statement and over-normalizing. Detail in the data modeling round guide.

System design round. Pipelines, not services. Prompts cluster around three families: near-real-time fraud detection, daily reporting aggregations, user event sessionization. Passing answers choose batch or streaming explicitly, name the orchestrator (Airflow if you don't have a stronger opinion), address late-arriving data, define a backfill strategy, and surface at least two failure modes (partial writes, schema drift, dedup, exactly-once semantics). The senior-vs-mid signal here is whether you bring up the failure modes before the interviewer prompts you. Walked through in the system design round guide.

Behavioral round. STAR format is table stakes. What separates strong answers is whether you distinguish what you did from what the team did, and whether you can name the tradeoff you made rather than the outcome you got. Senior loops add prompts about scope under uncertainty and outcomes you owned across teams; staff loops add prompts about decisions that played out over quarters. The most common failure is rambling, the second most common is burying the result. Stories worth practicing live in the behavioral round guide.

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.

Most loops follow the standard five-round template. Five 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 tests modeling on Delta Lake and PySpark specifics that no other loop covers. Uber runs the heaviest data modeling round in the industry, with two-hour onsites that include a live schema critique. If you're interviewing at any of these five, weight your prep accordingly.

For everyone else, the standard five-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.

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 five 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.

Two weeks out. SQL drills and one mock per day. Skip the take-home if it's not required. Don't start a new tool; you won't get to working fluency. Hit the top 100 questions for breadth, then do four to six full mock interviews out loud, alone or with a peer.

Eight weeks out. Week one and two: SQL and Python to fluency. Week three through five: data modeling ten problems deep, with the schemas drawn out and defended. Week six and seven: system design, fifteen prompts minimum, out loud. Week eight: 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.

Prompt. "Design the warehouse schema for a ride-share app. The product team wants daily reporting on completed rides, driver utilization, and surge pricing effectiveness."

The losing answer. A candidate draws three tables: rides, drivers, surge_events, normalizes each to 3NF, and answers the three reporting questions with joins. They never stated the grain. They built for the questions instead of the business. When the interviewer adds a question ("now report on rider lifetime value"), the schema cracks because it has no rider dimension.

The hire-signal answer. "I'm modeling a fact table at the completed-ride grain with one row per ride, and three Type 2 dimensions: dim_driver, dim_rider, dim_geo. Surge is an attribute on the ride fact, not its own table, because surge state at ride start is what reporting cares about. Driver utilization is a derived metric from the ride fact plus a snapshot of driver shifts. I'm choosing star over snowflake here because the reporting tool is BI and joins are cheap; if the consumer were operational, I'd reconsider." The candidate stated the grain, defended the SCD type, named the shape, and surfaced one tradeoff with a reason. That's the rubric.

The full walkthrough, with the follow-up questions the interviewer asks next and the variants that show up at Uber and DoorDash, is in the data modeling round guide. For the design-round version of this same exercise, see the system design walkthrough.