Data Engineer Interview: Pass Modeling and Pipeline Design

How data engineer interview loops work, what the SQL, modeling and pipeline design rounds test, two worked examples and a three-week prep plan.

Data engineer interview loops vary by company, and the three employers below publish quite different shapes, so this page focuses on two skills that data engineering job descriptions and guides keep returning to: designing a data model and designing a pipeline. Meta and Monzo each publish a behavioral-style conversation about ownership or collaboration, and roles built on Spark or Databricks may add a distributed processing round. Companies package these differently, so the useful preparation is to understand what each round tests and practise it out loud.

Below, we compare three employers that publish how they hire for data roles, explain each round, walk through an illustrative modeling problem and pipeline design, and end with a three-week plan.

What three employers publish about their loops

Meta publishes an interview guide for its Data Engineer, Product Analytics role, written by its data engineers. The guide's overview describes the full loop as three one-hour technical interviews and one 30-minute ownership interview (a later section of the same guide refers to "two" technical interviews), using CoderPad for SQL and Python and, optionally, Excalidraw for drawing schemas. Meta says all three technical interviews "will be case studies of typical product challenges that we solve with data", scored on product sense, data modeling, and ETL in SQL and Python. In the modeling portion, you brainstorm the data needs of a product, design a data mart for analytics and then write SQL against it. Our Meta data engineer interview guide covers that loop's Python side.

GitLab lists the hiring steps for its Data Engineer job family in its public handbook: a screening call with a recruiter, an assessment, an interview with the hiring manager, two interviews with peers from the data team, and a final interview with the Senior Director of Data. This job-family page does not say what each interview covers, but from the intermediate level up, GitLab asks for a "demonstrably deep understanding of SQL and analytical data warehouses (Snowflake preferred)", hands-on ETL or ELT experience at scale, pipeline tools such as Airflow or dbt, and "strong data modeling skills and familiarity with the Kimball methodology".

Monzo described its data hiring process in 2022 for analytics engineers, data scientists and analysts, not a role titled data engineer: a 30-minute recruiter call, an initial call with a project deep dive, a take-home task, then case studies and a collaboration interview. The take-home has no time limit, and Monzo leaves "some things intentionally vague because we want to see the decisions that you make".

Side by side, Meta's guide and GitLab's job description both name modeling and SQL as core skills, but the shapes differ sharply. Meta runs its technical interviews as product case studies that collectively assess modeling, SQL and Python, while GitLab spreads its evaluation across an assessment and several conversations. Monzo moves the hands-on work into a take-home and judges your decisions. None of the three lists a separate pipeline design interview, so ask your recruiter exactly which rounds your loop includes.

SQL, Python, modeling and design: the rounds in a data engineering loop

The seven rounds below are our grouping, drawn from the published material above and the skills these job descriptions ask for; no company above runs all seven as separate interviews.

Recruiter screen

The recruiter checks that your experience fits before engineers spend time on you. Be ready to name your warehouse, your orchestration tool, whether you have built streaming pipelines, and the largest data volumes you have handled, and match them to the tools in the job posting.

SQL

This is the round to over-prepare, because both Meta and GitLab name SQL explicitly. Meta lists the constructs it expects: all types of joins, aggregate functions, analytical (window) functions, set operators and subqueries. It also suggests practising how you would load raw logging data into the tables you designed, so the SQL and modeling rounds feed each other. Drill with our SQL interview questions for three years of experience, and talk through edge cases such as NULLs and duplicate rows as you write.

Python coding

In the published material, Python is framed around data structures and data processing, though Meta's prep links also include HackerRank, CodingBat and LeetCode. Meta's guide asks candidates to know how dictionaries, lists, loops, strings and set operations work in Python, and GitLab's junior requirement is Python, Java or Scala "for data processing (Python preferred)". Practise parsing records, grouping and counting with dictionaries, and handling malformed input without crashing.

Data modeling

You are given a product or business process and asked to design the tables that answer its questions, then often to query them. Following Kimball's method, a strong answer states the grain before drawing anything, separates facts from dimensions, and knows how to keep history in a dimension. The walkthrough below shows what that sounds like, and our data modeling interview questions give you material to practise on.

Pipeline or data system design

You design an end-to-end flow from sources to tables that people use, and defend each choice. A strong answer covers batch versus streaming, idempotency and backfills, late data, quality checks, orchestration and cost, as in the illustrative outline below. Our ETL interview questions cover the vocabulary this round assumes.

Spark and distributed processing

Roles built on Spark or Databricks may add a round on how distributed jobs behave. Be ready to discuss shuffles, partitioning and skew, and know the basics of Spark's optimiser. Adaptive Query Execution has been on by default since Spark 3.2.0; it can split skewed partitions in sort-merge joins and switch to a broadcast join when runtime statistics show one side is small, while the static broadcast threshold defaults to 10 MB. Drill with our PySpark coding interview questions and, for Databricks roles, our Databricks coding questions.

Behavioral: ownership, stakeholders and data quality

Meta's ownership interview assesses how you execute increasingly complex projects, collaborate, communicate and "use data and knowledge to influence decisions". For a data engineer, the story most worth preparing is a time your data was wrong, covered below. Our behavioral interview questions guide covers the general method.

How a senior data engineer loop differs

GitLab's handbook shows what changes at senior level: intermediate engineers build and maintain pipelines, while senior engineers "ship large features independently", "generate architecture recommendations and the ability to implement them", teach standards for code maintainability and performance, and "perform technical interviews". Meta's guide, which does not name a level, tells every candidate to prepare ownership examples around "Scope, Influence, and Leadership".

Neither GitLab nor Meta publishes a separate senior interview format, so this is our inference from the responsibilities above: expect more weight on judgement, such as design trade-offs, standards for a team and influencing others, and less on whether you can write the query. Our SQL query questions for five years of experience match the harder SQL you may still face.

An illustrative modeling round: ride-hailing trips

This walkthrough is illustrative: we wrote it to show the reasoning a strong answer makes visible, not from any company's question bank, and its terms follow the Kimball Group's published dimensional modeling techniques.

The prompt is to model trips for a ride-hailing app so analysts can track trips, revenue and cancellations by city and week. A strong candidate starts with Kimball's four steps: select the business process, declare the grain, identify the dimensions, then identify the facts.

Ask what the model must answer. The candidate asks who uses the data and which questions matter most, such as weekly completed trips by city, average wait time or revenue by ride type, because the answers decide the grain.

Declare the grain out loud. Kimball defines the grain as exactly what "a single fact table row represents", and warns that different grains must not be mixed in one fact table. A trip moves from requested to accepted to picked up, then to completed or cancelled, which fits an accumulating snapshot: Kimball uses it for processes with predictable steps, inserting each row when the process starts and updating it as it progresses. So the candidate declares one row per trip request in fact_trip, noting that a transaction fact with one row per status event would suit questions about every state change.

Separate dimensions from facts. Dimensions describe the context: dim_date, dim_rider, dim_driver, dim_ride_type and dim_location, joined twice, once for pickup and once for drop-off. The trip ID stays in the fact table as a degenerate dimension, a key with no dimension table of its own. Facts are the numbers measured at that grain: fare, distance, the wait from request to pickup, and a cancelled flag. As Kimball recommends for accumulating snapshots, it carries one date key per milestone.

Handle history in dimensions. Suppose a driver moves from a standard car to a premium one, and analysts want revenue split by the vehicle class at trip time. That calls for slowly changing dimension type 2, which adds a new row with its own surrogate key, plus effective date, expiration date and current-row columns. A change of phone number can be type 1, which overwrites the old value and keeps no history. Because each trip stores the driver surrogate key that was current when it loaded, queries return the vehicle class at trip time without any date logic.

Prove it with a query. The interviewer then asks for the weekly cancellation rate by pickup city:

SELECT
  d.week_start_date,
  l.city,
  AVG(CASE WHEN f.is_cancelled THEN 1.0 ELSE 0.0 END) AS cancellation_rate
FROM fact_trip f
JOIN dim_date d ON f.request_date_key = d.date_key
JOIN dim_location l ON f.pickup_location_key = l.location_key
GROUP BY d.week_start_date, l.city;

A good follow-up shows you have thought about late information. If a rider's account details reach the warehouse after the trip, Kimball's approach is a placeholder dimension row that is overwritten when the real context arrives, so the trip can still load on time.

An illustrative pipeline design: ride metrics, daily and live

This outline is also illustrative, written to show the ground a strong answer covers, for a prompt to feed a daily revenue dashboard and a live view of trip requests by zone.

• Sources and volume. Before drawing boxes, the candidate asks where trips live (an operational database), how app events arrive (a Kafka topic), how much data arrives daily and who reads each output.
• Batch versus streaming. Revenue is reviewed daily, so a daily batch is enough; requests by zone matter within minutes, so that path streams. Streaming only what needs it keeps cost and on-call load down.
• Duplicates and idempotency. Kafka's documentation says it "guarantees at-least-once delivery by default", so the design deduplicates on an event ID. Airflow's best practices say a re-run should "produce the same outcome", using UPSERT instead of INSERT and reading a fixed partition rather than calling now().
• Late data and backfills. Spark watermarks aggregate data within the lateness threshold, but data beyond it may be dropped, so the live view is approximate and the daily batch is the source of truth. Idempotent tasks make an Airflow backfill, which creates runs for past dates, safe to repeat.
• Quality checks and orchestration. dbt's built-in tests check that trip IDs are unique and not null, that status values come from an accepted list and that every fact key exists in its dimension. The candidate decides which failures block publishing, and who is alerted when a run fails.

The candidate closes on cost, partitioning tables by date so queries scan less. In our view, the trade-off reasoning is what earns credit, such as why the live view can tolerate approximate numbers while the finance dashboard cannot, not the number of tools named. Our Apache Kafka interview questions cover the streaming follow-ups, and if the posting names Snowflake, our Snowflake interview questions cover the warehouse side. For the alerting and on-call side of the job, our DevOps engineer interview guide goes deeper.

How to tell a data quality incident story

Expect "Tell me about a time your data was wrong." Google's SRE book defines a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions, and that outline works well for a data story too.

• Start with how the problem was detected, and say so honestly if a stakeholder found it before your checks did.
• State the impact in business terms, such as which dashboards or decisions used bad numbers and for how long.
• Explain how you contained it, such as pausing downstream jobs and telling the people who rely on the affected reports.
• Give the root cause and contributing causes, such as an upstream schema change or duplicates after a retry, and keep the story about systems rather than people.
• Finish with what changed afterwards, such as a new test, a data contract with the source team or an alert, because that is the evidence that you learned from it.

Google describes a blameless postmortem as one that identifies contributing causes "without indicting any individual or team", and an answer that blames the upstream team signals the wrong habits. An illustrative answer, invented to show the shape, might run: "Revenue doubled overnight on our dashboard because a retried load inserted the same day twice; I rolled the partition back that morning, switched the load to overwrite by date and added a uniqueness test that blocks publishing."

A three-week preparation plan

This plan assumes you already work with data; reorder it once your recruiter confirms the rounds.

Week one: SQL and Python. Write SQL daily with a timer, covering joins, window functions, set operators and subqueries, and explain each query aloud as you write it. Add one small Python exercise a day that parses and aggregates messy records using dictionaries and lists.

Week two: modeling and pipeline design. On alternate days, model one product you use, declaring the grain first and deciding where history needs type 2, then write two queries against it. On the other days, design a pipeline for that model, covering duplicates, late data, backfills and quality checks.

Week three: the extras and the stories. If the posting names Spark, Kafka, Snowflake or Databricks, spend two days on that tool. Then write one data quality incident story and two ownership stories, rehearse each until it fits in about three minutes, and run two full mock loops.

Practise the rounds out loud with Verve AI

Explaining the grain of a fact table, or why a pipeline can be rerun safely, comes out clearer the second time you say it. With Verve AI's AI Mock Interview you can rehearse those explanations with an AI recruiter, using the Data & Analytics, Software Engineering or behavioral question banks, your own custom questions or a LinkedIn job description, and see "a detailed performance report with personalized feedback and scoring" afterwards. Meta's data engineer interview guide says "we ask that you not use any unauthorized outside assistance during interviews" and that outside assistance includes "using AI tools unless provided by Meta", so check the rules of the company you are interviewing with and keep practice tools for the weeks before.

FAQ

What rounds are in a data engineer interview?

There is no standard loop. Meta's guide overview lists three one-hour technical interviews (a later section of the same guide says "two"), run as product case studies that collectively assess product sense, data modeling, SQL and Python, plus a 30-minute ownership interview. GitLab lists a recruiter screen, an assessment, a hiring manager interview, two peer interviews and a final senior leadership interview, so ask your recruiter what yours includes.

What is a data engineer system design interview?

It is a round where you design a pipeline end to end, from sources to the tables people query. A strong answer explains batch versus streaming choices, how reruns avoid duplicates, how late data and backfills are handled, and which quality checks run. None of the three employers above lists it separately, so confirm whether your loop has one.

How should I prepare for a senior data engineer interview?

Prepare for more judgement and less syntax. GitLab expects senior data engineers to make architecture recommendations, ship large features independently and teach standards, and Meta's guide, which does not name a level, asks every candidate for ownership examples about scope, influence and leadership. Practise vague design prompts, and prepare stories about influencing decisions and raising data quality across a team.

Sources

• Meta Data Engineer, Product Analytics interview guide (PDF linked from this page; opened 2026-10-27): three one-hour technical interviews and a 30-minute ownership interview, CoderPad and Excalidraw, focus areas product sense, data modeling and ETL (SQL and Python), "case studies of typical product challenges that we solve with data", data mart design and SQL, SQL constructs, Python data structures, ownership criteria, "Scope, Influence, and Leadership", rule on outside assistance and AI tools: https://www.metacareers.com/DE-prep-onsite/
• GitLab Data Engineer job family: hiring stages, requirements by level (SQL, Snowflake, ETL/ELT, Airflow or dbt, Kimball modeling, Python for data processing), senior and staff responsibilities: https://handbook.gitlab.com/job-description-library/marketing/enterprise-data/data-engineer/
• Monzo data hiring process (2022; roles covered, recruiter call, initial call, take-home with no time limit, "intentionally vague", case studies and collaboration interview): https://monzo.com/blog/2022/03/21/data-hiring-at-monzo
• Kimball four-step dimensional design process: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/four-4-step-design-process/
• Kimball grain definition and no mixed grains: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/grain/
• Kimball accumulating snapshot fact tables (inserted, revisited and updated; a date key per milestone): https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/accumulating-snapshot-fact-table/
• Kimball transaction fact tables: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/transaction-fact-table/
• Kimball degenerate dimensions: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/degenerate-dimension/
• Kimball slowly changing dimension type 1: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-1/
• Kimball slowly changing dimension type 2 (new row, surrogate key, effective, expiration and current-row columns): https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-2/
• Kimball late arriving dimensions (placeholder rows overwritten later): https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/late-arriving-dimension/
• Airflow best practices on idempotent tasks, UPSERT instead of INSERT, fixed partitions, not using now(): https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html
• Airflow backfill (runs for past dates): https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/backfill.html
• Apache Kafka delivery semantics, at-least-once by default, idempotent producer: https://kafka.apache.org/42/design/design/
• Spark Structured Streaming watermarking and its one-directional guarantee on late data: https://spark.apache.org/docs/latest/streaming/apis-on-dataframes-and-datasets.html
• Spark Adaptive Query Execution on by default since 3.2.0, skew join handling, broadcast join conversion, 10 MB autoBroadcastJoinThreshold default: https://spark.apache.org/docs/latest/sql-performance-tuning.html
• dbt data tests (unique, not_null, accepted_values, relationships; pass on zero failing rows): https://docs.getdbt.com/docs/build/data-tests
• Google SRE book postmortem definition and blameless postmortems: https://sre.google/sre-book/postmortem-culture/
• Verve AI Mock Interview (AI recruiter, question banks including Data & Analytics and Software Engineering, custom questions, LinkedIn job descriptions, performance report with personalized feedback and scoring): https://docs.vervecopilot.com/features/mock-interview