Data Engineer Interview Questions, by Round

You may be preparing the same way you would for a software engineering loop and wondering what is different. This section maps the rounds these interviews reuse, so you can spend your time on the two that actually separate candidates. The technical filter is rarely where offers are lost.

• SQL. Window functions, deduplication, and query performance, usually live.
• Data modelling. Designing tables for a described business, and defending the grain you chose.
• Pipeline and ETL design. An open ended system design round scoped to data movement.
• Distributed processing. How a framework actually executes your job, and why it is slow.
• Coding. Python or Scala, often lighter than a software engineering round.
• Behavioral. On call incidents, broken dashboards, and stakeholders who wanted the number yesterday.

Titles overlap heavily with analytics engineering and platform roles, so the mix shifts. Related role banks sit on the interview questions by role hub.

SQL

• Deduplicate a table keeping only the most recent row per key.
• Write a query returning each user's session count using a 30 minute inactivity gap.
• Compute a running total and a month over month change in one query.
• Find rows present in yesterday's snapshot but missing from today's.
• What does QUALIFY do, and what would you write without it?
• This query scans a billion rows and takes twenty minutes. How do you diagnose it?
• Explain the difference between partitioning and clustering, and when each helps.

Data modelling

• Design the tables for an online marketplace's order history. What is the grain of your fact table?
• Explain a star schema, and when you would deliberately denormalise further.
• What is a slowly changing dimension, and how do you implement type two?
• A stakeholder wants historical reporting to reflect a customer's current region. What breaks?
• How would you model an event stream that arrives out of order?
• When would you choose a wide table over a normalised model?

The modelling round rewards committing to a grain and defending it. Candidates who describe three possible designs without choosing one score worse than candidates who pick a reasonable design and name its weakness.

Pipeline and ETL design

• Design a pipeline that loads daily transactions into a warehouse for reporting.
• The upstream source sends yesterday's data again. What happens to your job?
• How do you make a pipeline idempotent, and why does it matter for reruns?
• How would you backfill two years of history without disrupting the daily load?
• Late arriving data shows up three days after the partition closed. What do you do?
• How would you detect that a pipeline succeeded but produced wrong data?
• What do you monitor, and what pages someone at three in the morning?

Distributed processing and streaming

• What causes a shuffle, and why is it expensive?
• Your job is slow and one task takes far longer than the rest. What is happening?
• Explain data skew and two ways to handle it.
• When would you choose streaming over a scheduled batch job?
• What does exactly once processing actually guarantee, and where does it not hold?
• How do watermarks handle out of order events in a windowed aggregation?

Notice how few of these ask you to name a tool. Naming one is the start of the answer, not the answer. The follow up is always why, and what breaks.

Reading these lists builds recognition. The design rounds test something else: holding a system in your head while someone interrupts you with a failure case. That only comes from saying designs out loud.

• Draw and narrate a pipeline in fifteen minutes. Source, landing, transform, serve, plus how each stage fails.
• Attack your own design. After each practice run, ask what happens on a rerun, on late data, and on a schema change.
• Have a number ready for scale. Rows per day, size, latency budget. Stating your assumed scale first is scored.
• Write SQL by hand. Live rounds often use a plain editor with no autocomplete and no execution.
• Rehearse one incident story properly. What broke, how you found it, what you changed so it could not recur.

A data engineer with six years on batch pipelines prepared by reviewing framework internals, then stalled on "the upstream source resent yesterday's file" because she had only ever handled it by hand, never explained it. The knowledge was there; the spoken answer was not. Practising the design round with follow-ups is what the mock interview mode is built for.