Data Engineer Mock Interview Practice

Practice the way the interview actually works: you write code, it runs, and the feedback names what an interviewer would push on. Live problems from the catalog, a graded data modeling answer, and a 10-question calibration set across SQL, Python, and data modeling make a weak round obvious in practice instead of in a real loop.

Last updated: July 27, 2026Proudly published by: Jeff WahlVerified against 1,569 live problems

Mock interview prep only counts when the code actually runs. Interview-calibrated questions execute for real, in the browser, with nothing to install, and the AI review marks the exact lines an interviewer would push on. A 10-question calibration set (5 SQL, 3 Python, 2 data modeling) shows which round needs your prep hours; the full mock interview guide and timed simulator rounds go deeper from there.

1,569

Practice questions

Interview domains

2,817

Interview reports behind the calibration

281

Companies represented

One Real Problem From Each Round

Pulled straight from the live catalog, statement and all. Open one and it runs and submits exactly like the product, because it is the product.

1. 7-Check Rolling Average

Asked in a Data Engineer interview by Goldman SachsMedium~10 minGo to problem

Task

Our rolling latency average for a health check covers that check and the six checks before it on the same service, so one service's history never bleeds into another's. From svc_health, list every check alongside its latency and that rolling average, services alphabetically and each service's checks oldest to newest.

Show the solution

SELECT
    svc_name,
    checked,
    latency,
    AVG(latency) OVER (
    PARTITION BY svc_name
    ORDER BY checked
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS rolling_avg
FROM svc_health
ORDER BY    svc_name, checked

2. Single File

Asked in a Data Engineer interview by MetaEasy~10 minGo to problem

Task

You are given feed, a list of content entries. Each entry is either an item or a sub-list of entries, and sub-lists can nest to any depth. Any value that is not a list is a single item. Return all the items as one flat list.

Show the solution

def flatten(feed):
    result = []
    for item in feed:
        if isinstance(item, list):
            result.extend(flatten(item))
        else:
            result.append(item)
    return result

3. The Person They Were Then

Asked in a Data Engineer interview by SnapEasy~20 minGo to problem

Task

We run a messaging app where a user's subscription tier and country both drift over time, and the ad-revenue team needs every past impression to reflect the tier and country the user actually had the moment it fired. Design the schema that lets analysts slice historical ad revenue by the profile state as of each event.

Show the solution

SELECT
    u.subscription_tier,
    u.country,
    d.month,
    SUM(f.revenue_usd) AS revenue
FROM fact_ad_impression f
JOIN dim_user u ON u.user_sk = f.user_sk
JOIN dim_date d ON d.date_key = f.date_key
WHERE d.full_date >= DATE '2025-01-01'
GROUP BY u.subscription_tier, u.country, d.month
ORDER BY revenue DESC

The 10-Question Calibration Set

A deliberate diagnostic spread at real phone-screen difficulty. Where these 10 go cleanly, and where they do not, tells you exactly which round your prep hours belong in.

SQLMedium

Employee Salary Analysis

Find the top 3 earners in each department and their rank. Tests window functions (RANK or DENSE_RANK), PARTITION BY, and filtering windowed results. This is a phone-screen-level problem that appears in some form at every major tech company.

SQLMedium

User Retention Calculation

Calculate Day 1 and Day 7 retention for users who signed up in a specific month. Tests self-joins or window functions on date differences, cohort analysis logic, and handling users who never logged in again (they should show as 0% retention, not be excluded).

SQLMedium

Revenue Trend with Running Total

Compute daily revenue and a 7-day running total. Tests SUM() OVER (ORDER BY ... ROWS BETWEEN), date grouping, and the difference between ROWS and RANGE window frames, a subtle point that interviewers love to probe.

SQLHard

Finding Gaps in Sequential Data

Given a table of session events with sequential IDs, find the gaps where IDs are missing. Tests LAG/LEAD to detect discontinuities, the set-based approach with a generated series, and discussion of which approach scales better on a table with 500 million rows.

SQLMedium

Multi-Table Join with Aggregation

Find the top-selling product category for each user segment across 3 tables (users, orders, products). Tests multi-table JOINs, GROUP BY with aggregate functions, subquery vs. CTE style, and handling NULL values when a user has no orders.

PythonMedium

Log File Parser

Parse a server log file and return the count of ERROR entries per hour. Tests file I/O, string parsing, datetime handling, and dictionary-based aggregation. Interviewer follow-up: 'The file is now 10GB. How does your approach change?'

PythonMedium

JSON Flattener

Write a function that takes a nested JSON object of arbitrary depth and returns a flat dictionary with dot-notation keys. Tests recursion, type checking, and edge cases like empty objects, arrays, and None values. A common Meta and Google DE phone screen problem.

PythonHard

Deduplication with Conflict Resolution

Given a list of records with potential duplicates (same ID but different field values), deduplicate by keeping the most recent record for each ID. Tests dictionary-based grouping, timestamp comparison logic, and what happens when two records carry identical timestamps.

Data modelingMedium

E-Commerce Star Schema

Design a star schema for an e-commerce platform: the fact table plus at least 4 dimensions (users, products, dates, geography). Discuss the grain of the fact table, slowly changing dimensions for product price changes, and how the schema supports both 'revenue by category' and 'conversion rate by marketing channel'.

Data modelingHard

Event-Driven Data Model

Design the data model for a ride-sharing app's event stream (ride_requested, driver_assigned, ride_started, ride_completed, ride_cancelled, payment_processed). Discuss modeling the ride lifecycle as events, reconstructing current state from history, and the tradeoffs between event sourcing and a stateful rides table.

How a modeling answer is actually scored

Question 9 from the set, graded. The modeling round decides most senior loops, and the rubric is about what you defend, not what you draw.

Data modeling

Design the warehouse schema for an e-commerce platform. Reporting needs revenue by category and conversion by marketing channel.

✓What earns the signal

States the grain first ("one row per order line"), builds fact_order_line around it with conformed dim_product, dim_customer, dim_date, and dim_channel.

Handles price changes as SCD Type 2 on dim_product so historical orders keep the price that was true at order time, and defends line grain over order grain because category revenue is a line-level question.

grain stated firstType 2 price historyconformed dimensionsdefends line grain

✕What sinks it

Starts drawing tables with no grain statement, puts category directly on an order-grain fact, so a 3-category order has nowhere to land and revenue by category comes out wrong.

Overwrites product price in place, silently rewriting the history of every past order, and has no channel dimension, so the conversion question cannot be answered at all.

no graincategory on the factprice overwrittenchannel unanswerable

Passing correlates with defending the grain and the SCD choice before the interviewer asks. The diagram is secondary.Practice a data modeling problem →

Why running the code is the whole point

Reading solutions builds recognition. Interviews demand production. The gap between the two is exactly where candidates fail: you can know what ROW_NUMBER does and still not produce a windowed dedup with a composite tiebreaker in 12 minutes, out loud, under pressure. The only thing that closes that gap is writing code that actually executes and being told precisely what it got wrong.

Execution also catches the failure class that reading never can: code that looks right and runs, but is wrong. The LEFT JOIN that quietly became an INNER JOIN because of a WHERE filter on the right table. The retention query that excluded the users who never came back instead of counting them as zero. The review is built around these cases because interviewers are too.

When the untimed set goes cleanly, the same questions run in timed modes: single-round simulations, rapid-fire drills, and full loop simulations with an AI interviewer that asks follow-ups. How the grading works under the hood is covered in the AI grading guide, and the execution environment in the in-browser coding guide.

The Full Catalog, by Domain

Live counts from the practice catalog. Each domain page breaks down what interviewers ask and links into its problem set.

Domain	Questions	What interviewers probe	Where it shows up
SQL	928	Window functions, joins that multiply rows, NULL handling, gap detection	Nearly every loop; usually the first technical screen
Python	415	Parsing messy input, dedup by composite key, memory-constant processing	Most loops; notebook-shaped, not LeetCode
Data modeling	67	Grain statements, SCD types, star vs. snowflake tradeoffs	The round that decides most senior loops
Pipeline architecture	144	Batch vs. streaming, idempotency, late-arriving data, failure modes	System design rounds at L4 and above
Spark	943	Partitioning, broadcast joins, skew, plus every SQL problem in Spark SQL	Spark-native shops: Databricks, Netflix, Airbnb

What the Review Checks on Every Submission

Correctness across edge cases

Every question runs against fixtures built to break naive solutions: NULLs in join columns, empty tables, duplicate timestamps, single-row groups. A query that looks right on the happy path but drops the users who never returned gets caught, with the failing case shown to you.

Efficiency at scale

A self-join that scans n squared rows where a window function scans n once gets flagged. So does a DISTINCT papering over a join that multiplies rows. Interviewers at Google and Meta explicitly score performance awareness, so the review does too.

Line-level feedback, not pass/fail

The review points at specific lines: 'Line 14: this self-join produces duplicate rows when a user has multiple orders on the same day.' It reads like a senior engineer's code review, because that is the standard your interviewer will hold you to.

The habits production SQL demands

COALESCE instead of ignoring NULLs. NOT EXISTS instead of NOT IN when NULLs are possible. CTE structure instead of 4-level nesting. These are the patterns that separate a data engineer who ships production SQL from one who writes throwaway queries.

Find Your Starting Point

You are deciding whether to move into data engineering. Maybe you are a data analyst eyeing the switch, or a backend engineer who keeps landing on pipeline work. Solve 3 or 4 of the calibration questions. If the SQL feels comfortable, you are closer to interview-ready than you think; if it is a struggle, you have found where structured prep starts.
You have a phone screen on the calendar. Phone screens run 1 to 2 problems in 45 to 60 minutes. If you can solve 3 of the 5 SQL questions here in under 20 minutes each, with correct results and clean CTEs, you are in solid shape for most screens. The timed mock modes then build the pacing.
You are switching from software engineering. Your algorithm prep is over-leveled for this loop and your modeling prep is probably empty. The two modeling scenarios in the set are the fastest way to feel that gap: schema design under questioning has no LeetCode equivalent.
You want feedback, not just answers. Reading a model solution tells you what the author thought. The review tells you what your solution actually did: which edge case it dropped, which join multiplied rows, which line an interviewer would stop you on. That is the feedback loop that moves solve quality.

How to Work Through the Calibration Set

01
Start with the 5 SQL questions
SQL is the most-tested skill in DE interviews and the gate to every onsite. These 5 cover window functions, self-joins, retention analysis, running totals, and gap detection: the patterns behind 80%+ of real SQL rounds.
02
Move to the 3 Python questions
File parsing, JSON transformation, deduplication. Pipeline-shaped Python, not LeetCode. Each carries the scaling follow-up an interviewer would ask next, so practice answering it out loud.
03
Take on the 2 modeling scenarios
Data modeling is the most under-practiced round and the one that decides most senior loops. Design the schema, state the grain first, then defend the SCD choice and the denormalization tradeoffs out loud, the way you would with an interviewer pushing back.
04
Read the review line by line
The review is the product. If it flags a NULL bug you walked past or a join that silently duplicated rows, that is not a gotcha, that is the exact conversation a real interviewer would start. Retry the problem until the review comes back quiet.
05
Graduate to timed mock rounds
Untimed practice builds correctness; timed rounds build pacing and pressure management. When the calibration set goes cleanly, switch to the mock interview simulator: full rounds, a clock, and an AI interviewer that pushes back.

Go Deeper by Domain, Company, and Format

Round-by-round and company-by-company: what each loop actually tests, with worked answers and links into the matching problem sets.

SQL mock interview

Window functions, joins, and the topics behind most screens.

Python mock interview

Pipeline-shaped Python: parsing, dedup, transformation.

Data modeling mock interview

Grain, SCDs, and defending schema tradeoffs aloud.

System design mock interview

Pipelines, not services: batch vs. streaming, failure modes.

Pipeline architecture

Idempotency, late data, backfills, orchestration.

Spark mock interview

Partitioning, skew, broadcast joins, PySpark rounds.

FAANG mock interviews

How the big-tech loops differ and how to weight prep.

Google DE interview

The Google loop, round by round.

Meta DE interview

The SQL-heaviest FAANG loop, with Presto flavor.

Amazon DE interview

Leadership principles plus a heavy SQL screen.

Netflix DE interview

Streaming-leaning rounds and senior-level bars.

Senior DE mock interview

What changes at L5+: judgment over correctness.

Practice plan

Structuring practice across domains, week by week.

How AI grading works

What the reviewer checks and how scoring is built.

vs. LeetCode

Why DE interviews need different prep than SWE grinding.

Frequently Asked Questions

What does a practice session look like?+

Pick a domain (SQL, Python, data modeling, pipeline architecture, or Spark) and a difficulty. You get an interview-calibrated question with schema and sample data, a full editor, and the ability to run your code as many times as you want before submitting. On submit, the AI review checks correctness against edge-case fixtures and returns line-level feedback on efficiency and readability.

Does my code actually run?+

Yes. SQL executes against a real database loaded with realistic fixtures, and Python executes and produces real output. Real execution matters because the most common interview mistakes are subtle: a query that looks correct but mishandles NULLs, or a function that works on the sample input and crashes on the edge case.

How does the AI review work?+

It evaluates the actual output of your code, not a pattern match against one blessed solution. Any correct approach passes: window function, self-join, or CTE. It then scores efficiency and readability separately and points at specific lines, for example flagging a self-join that duplicates rows when a user has multiple orders on the same day.

Is the practice timed?+

Single-question practice is untimed so you can iterate until the review comes back clean. The mock interview modes are timed: single-round simulations, rapid-fire drills, and full loop simulations that mirror a real onsite's pacing. Most people start untimed and switch to timed rounds once accuracy is stable.

How is this different from practicing SQL on LeetCode?+

LeetCode's SQL problems are written for software engineers and lean algorithmic. Data engineering interviews test retention cohorts, running totals, gap detection, schema design, and pipeline-shaped Python, and they judge CTE structure and NULL handling, which an output-only auto-grader never sees. The review here checks those data engineering specifics on every submission.

Do I need to install or set anything up?+

No. Everything runs in the browser, including the editors, the database, and the review. An account (just an email) saves your attempt history and feedback so the platform can steer you toward the topics where your accuracy is weakest.

What should I practice first?+

SQL, specifically window functions. They are the single most frequently asked SQL topic in data engineering interviews and the fastest signal of interview readiness. Start with windowed ranking and rolling-average problems, then work through the calibration set in order: SQL, then Python, then modeling.

02 / Why practice

Run a Mock Interview Now

01
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
02
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
03
5 problem shapes cover 80% of data engineer loops
Dedup, sessionization, top-N-per-group, slowly-changing dimensions, partition tricks. Writing the shapes by hand turns the unfamiliar into pattern recognition

Start Practicing

Keep Going

DE Mock Interview Guide

The complete guide to mock interviews across all 5 domains

Interview Simulator

Timed rounds that push back the way an interviewer does

Interview Prep Pillar

Every round, every company, and the full prep plan

The weekly data challenge

Dirty, production-shaped data, scored blind each week.

Data Engineer Mock Interview Practice

One Real Problem From Each Round

1. 7-Check Rolling Average

2. Single File

3. The Person They Were Then

The 10-Question Calibration Set

Employee Salary Analysis

User Retention Calculation

Revenue Trend with Running Total

Finding Gaps in Sequential Data

Multi-Table Join with Aggregation

Log File Parser

JSON Flattener

Deduplication with Conflict Resolution

E-Commerce Star Schema

Event-Driven Data Model

How a modeling answer is actually scored

Design the warehouse schema for an e-commerce platform. Reporting needs revenue by category and conversion by marketing channel.

Why running the code is the whole point

The Full Catalog, by Domain

What the Review Checks on Every Submission

Correctness across edge cases

Efficiency at scale

Line-level feedback, not pass/fail

The habits production SQL demands

Find Your Starting Point

How to Work Through the Calibration Set

Start with the 5 SQL questions

Move to the 3 Python questions

Take on the 2 modeling scenarios

Read the review line by line

Graduate to timed mock rounds

Go Deeper by Domain, Company, and Format

Frequently Asked Questions

Run a Mock Interview Now

Keep Going