SQL Interview Questions and Answers for Data Engineers (2026)

SQL Interview Questions: the 2026 shortlist for data engineers

Most SQL prep goes wide and shallow — a hundred queries copied from a cheat sheet, none of them defended out loud. That is the opposite of how a real screen works. A data engineering SQL round reuses a small set of patterns, and inside each one the interviewer reaches for the same handful of follow-ups: what is the grain of this table, what happens to the row that has no match, is your count still right when a duplicate sneaks in.

This is the shortlist of SQL interview questions that actually repeats in 2026 — grouped the way a tech screen groups them, each with a one-line answer and the follow-up that decides whether you pass. It is written for the people who get these rounds most: data engineers facing timed SQL screens, so it leans into the patterns that separate a junior answer from a senior one, including the SQL window functions that show up in almost every mid-to-senior loop. Before the list, there is a five-step framework that answers a query you have never seen, because the method is worth more than any single solution. Read it as a map — the query is table stakes, and the round is won on what you say when someone asks "why that join, and not the other one?"

How a data engineering SQL screen is actually run

A SQL screen is not a written exam. It is a 30-to-60-minute working session where a schema and an expected output sit beside the editor, you write a query against sample rows, run it, and defend each clause while the interviewer digs. In most data engineering interview questions of this kind you get three to six prompts on one schema — the Meta-style tech screen, for example, runs three SQL and three Python questions in 60 minutes — so pace matters as much as correctness. The same five moves carry every prompt on this list, so learn the moves first.

The five-step framework that answers any SQL question

• Read the schema. Before writing anything, name the tables, the keys, and which column joins to which. Thirty seconds here saves a wrong join later.
• Clarify the grain. Say out loud what one row of your result means — "one row per customer per month." Half of all wrong answers are really the wrong grain.
• Build in layers. Filter first, aggregate second, window or join last. A CTE per step reads better than one nested query and is easier to defend.
• Verify on sample rows. Run it, then trace two or three rows by hand against the expected output. Catch the off-by-one before the interviewer does.
• Say the tradeoff. Name the cost — a full scan, a fan-out join, a window over an unpartitioned table — and what you'd change at a billion rows.

What the debrief measures

Whatever the prompt, the scorecard is the same four dimensions: Correctness (does the query return the expected rows?), Query reasoning (did you pick the right join and grain, not just one that runs?), Communication (do you narrate the plan before you type?), and Time management (do you finish three prompts, not one perfect one?). Keep these in mind as you work the list — every question below maps back to them.

The questions, by category

The shortlist splits into five groups. The warm-ups check that you can join and aggregate without fumbling the grain; window functions are the senior signal; deduplication and data-quality questions are the DE bread-and-butter; modeling questions test whether you think in facts and dimensions; and the concept questions show up as follow-ups inside every single one.

Group A — Joins & aggregation (the warm-ups)

These open almost every screen. Each is one primitive done cleanly, and each reappears as a step inside the harder window and modeling questions — so nailing them pays off twice. The trap is never the syntax; it is the grain and the join type.

The two answers people fumble are the NULL ones. "Customers who never ordered" is the classic:

SELECT c.customer_id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
WHERE o.customer_id IS NULL;

Say why out loud: a LEFT JOIN keeps every customer and leaves order columns NULL when there is no match, so the IS NULL filter is exactly the unmatched set. NOT IN looks equivalent until the subquery returns a single NULL, which silently drops every row — a favourite follow-up precisely because it separates people who memorised the pattern from people who understand three-valued logic.

Group B — Window functions (the senior signal)

If one topic decides a data engineering SQL screen, it is this one. SQL window functions let you rank, run totals, and compare a row to its neighbours without collapsing the result — and the interviewer uses them to tell a junior answer from a senior one. Expect at least one, usually two.

"Top N per group" is the one to have automatic:

SELECT category, product, sales
FROM (
  SELECT category, product, sales,
         ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
  FROM product_sales
) ranked
WHERE rn <= 3;

The follow-up is always about ties. Narrate the difference before you are asked: ROW_NUMBER gives every row a distinct number so you always get exactly three even if two tie; RANK leaves gaps after a tie (1, 2, 2, 4); DENSE_RANK does not (1, 2, 2, 3). Which you pick is a product decision — "do two equal sellers both count as top-3?" — and saying that out loud is the senior signal.

Group C — Deduplication & data quality

This group is why data engineers get their own SQL screen. Real tables have duplicate rows, late-arriving records, and nulls where you did not expect them, and the interviewer wants to see you find them and reason about whether your numbers can be trusted.

Deduplication is the one you will almost certainly write:

WITH ranked AS (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
  FROM orders_raw
)
SELECT * FROM ranked WHERE rn = 1;

The follow-up — "two rows with the same timestamp" — is the real test. There is no right answer, only a defended one: add a deterministic tiebreaker to the ORDER BY (a surrogate key, the ingestion file name) so the result is stable across re-runs. "Stable across re-runs" is the phrase that tells the interviewer you have actually run a pipeline, not just a query.

Group D — Data modeling & the warehouse

Past the query questions, most DE loops include a data modeling interview segment — sometimes on a canvas where you add tables, draw relationships, and export the SQL. These test whether you think in facts and dimensions, and they are where ETL interview questions live too.

There is rarely one query to write here; the signal is vocabulary and tradeoffs. The phrase that lands is grain: say "this fact is one row per order line, revenue is additive across time, product, and store, but a ratio like margin is not" and you have shown more modeling sense than a page of DDL. For SCD type 2, be ready to narrate the row history out loud — the old row gets its valid_to stamped and its current flag cleared, a new row opens with today's valid_from — because the interviewer will ask you to trace exactly that.

Group E — Concepts drilled in every screen

These are not "write a query" prompts — they are the tradeoffs an interviewer drills the instant you mention a table or an index. Expect at least two inside any screen above.

For SQL vs NoSQL, the answer that fails is "NoSQL is faster." The answer that passes ties it to the workload: a transactional system with multi-table joins and strict consistency wants a relational database; a high-volume lookup by a known key — a session store, a feature cache — is where a key-value or document store earns its place. Say the access pattern first and the technology second, and the follow-up disappears.

How to prepare: a two-week plan

You do not need a hundred queries memorized. You need the framework automatic, window functions fluent, and a handful of data-quality patterns you can defend under pressure. Here is a realistic two-week pass.

• Days 1–3: Drill Group A until grain and join type are reflexive. Write each answer, then say its grain out loud in one sentence.
• Days 4–8: Live in window functions. ROW_NUMBER for top-N and dedup, RANK / DENSE_RANK for ties, LAG / LEAD for period-over-period, and one running total. These are the highest-leverage days.
• Days 9–11: Deduplication and data quality, plus the Group D modeling vocabulary — grain, star schema, SCD type 2, idempotent backfill. Write two-sentence answers out loud.
• Days 12–14: Full timed screens — three to six prompts on one schema, clock running, no notes. The goal is to finish on pace while narrating each step.

The follow-ups that decide every SQL round

Scan the right-hand column of every table above and a pattern jumps out: the questions rhyme. Master these five cross-cutting follow-ups and you are ready for prompts that are not even on this list.

• "What's the grain of this result?" → One sentence: what one row means. Get this wrong and the whole query is wrong.
• "What happens to the row with no match / a NULL?" → LEFT JOIN plus IS NULL, COALESCE for defaults, and the NOT IN trap.
• "Ties — ROW_NUMBER, RANK, or DENSE_RANK?" → Tie it to the product question: do equal rows share a place or not?
• "Is your count still correct?" → COUNT(DISTINCT) vs COUNT, dedup with a deterministic tiebreaker, a row-count check around every join.
• "Now it's a billion rows — what breaks?" → Name the cost: a full scan, a window over an unpartitioned table, a fan-out join; then the fix: a partition key, an index, pre-aggregation.

Each of these maps straight to the debrief: do you pick the right grain and join (query reasoning), return the expected rows (correctness), narrate the plan (communication), and finish on pace (time management)? Reading this list teaches you the answers. It does not teach you to deliver them while someone pushes back — that only comes from saying them out loud.

Frequently asked questions

Practise it on Zynter