Scale AI SQL & Data Engineering interview questions

The most common escalation in any data deployment, and the one that quietly ends trust in the platform. Four causes produce it, one of them means nobody is wrong, and you cannot tell them apart without running the ladder in order.

Four lines of SQL, and one of the three obvious ways to write it returns an empty result set instead of an answer. Not wrong rows. Zero rows, silently, on production data that looks fine.

Everyone writes the join and the ratio. Then the result comes back dominated by people who bought one thing and sent it back, and the list is useless to the person who asked for it.

The constraint is the question. It rules out the two approaches most candidates reach for, and the approach that survives has one failure mode that can take the customer's production database down.

A 40-year-old SQL classic that still filters out half of candidates, because of ties, NULLs, and departments with one employee. The interview-proof solution fits in six lines.

The classic SQL screener at Snowflake and Meta. Everyone can recite the definitions, interviewers are listening for the one scenario where picking the wrong function silently corrupts your results.

Every pipeline eventually double-loads data, so every FDE screen eventually asks this. There's one canonical idiom, plus a determinism detail that decides whether your dedupe is rerun-safe.

The single most-reported live-SQL question in data-platform FDE screens. The pattern is standard, the points are in tie handling, the QUALIFY shortcut, and one aggregation trap most candidates miss.

Sessionization is gaps-and-islands with a twist, and it shows up in both SQL screens and Spark rounds at Databricks. The LAG-plus-running-SUM pattern here solves a whole family of interview questions.

Join fan-out is the bug behind half of all 'the dashboard numbers are wrong' escalations an FDE will ever field. The mechanism, the 30-second detection query, and the three legitimate fixes.

The most common bug in analyst SQL, and a favorite warm-up in Retool's debugging-flavored screens. One word's placement, ON vs WHERE, silently deletes your unmatched rows.

The hardest 'standard' SQL interview pattern, asked everywhere from Meta to Palantir. There's a three-line trick that turns consecutive runs into a GROUP BY key, once you've seen it, you can't unsee it.

The product-analytics staple that quietly tests event ordering, conditional aggregation, and cohort logic at once. Most candidates compute a funnel that double-counts, here's the version that survives interviewer scrutiny.

The triangle-shaped retention table every PM asks for, and a two-join SQL pattern interviewers love because it exposes grain mistakes instantly. Includes the right-censoring caveat that separates analysts from engineers.

Asked constantly because it tests whether you understand aggregation rather than syntax. The CASE-inside-aggregate idiom works on every engine, plus when to reach for Snowflake's PIVOT and its dynamic variant.

Snowflake's signature semi-structured question. Dot-notation, LATERAL FLATTEN for nested arrays, the casting traps, and the schema-on-read vs flattened-model judgment call interviewers really want to hear.

The Databricks signature triage question. Strong candidates don't list optimizations, they run a diagnostic decision tree: plan first, then scan, shuffle, join strategy, files. Here's the tree.

Snowflake's signature internals question, and the trap is in the second half: most candidates can define micro-partitions, but the scoring is on knowing the four cases where scaling up burns credits for zero speedup.

A warm-up that quietly reveals whether you understand why analytical engines are fast at all. Compression, projection, predicate pushdown, and the one workload where columnar is the wrong choice.