Palantir SQL & Data Engineering interview questions

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.

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 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.

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.

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.

The Databricks screen opener that decides whether the rest of the interview goes deep or stays remedial. Definitions are table stakes, the points are in explaining what a shuffle physically does and how to see one in the Spark UI.

The Databricks signature deep-dive. Everyone says 'salting', almost nobody can write the salt correctly or explain why AQE might make hand-salting unnecessary. The full playbook, in the order a senior engineer actually tries it.

The small-files problem is the #1 self-inflicted lakehouse wound FDEs find in the field. The causes are always the same three things, and the fix has a prevention half most candidates forget.

The dimensional-modeling staple. The trip fact table is the easy part, interviewers score grain declaration, the surrogate-key rationale, and how you handle the rider who changes cities. Here's the full shape.

Sounds like a definition question; it's actually a judgment question. The economics that flipped the industry to ELT, and the four cases (starting with PII) where transforming before load is still non-negotiable.

The pipeline-design question that exposes whether you've ever been paged. One property, idempotency, solves reruns, late data, and backfills at once, and there are exactly three patterns that deliver it.

Pure FDE territory: the customer's data is always dirtier than scoped. The layered defense, contracts, quarantine, drift handling, and the alert-severity matrix that keeps you from crying wolf.

Palantir's home turf: entity resolution disguised as a dedupe task. The naive O(n²) comparison is the trap, blocking, match scoring, transitive closure, and the golden-record question are where the interview actually happens.

The integration question that decides data-platform FDE offers. Log-based vs query-based capture, why deletes break naive designs, the apply-merge that keeps order, and the snapshot step everyone forgets.

The capstone triage scenario data-platform FDEs get role-played through. A 9x blowup with an obvious-looking suspect, the scoring is on your diagnostic order, the questions you ask, and not stopping at the first plausible cause.

The Deployment Strategist data-modeling case. It looks like schema design; it's graded as ontology thinking, entities with identity, events that link them in time, documents as evidence, plus privacy designed in, not bolted on.

The verbatim Deployment Strategist case. The trap is accepting the premise, 'best for whom?' is the first scored move, and the second is designing a natural experiment from public data instead of hand-waving at 'analytics.'

The regression with no smoking gun, no deploy to blame, no single bad night. Staff-level triage is about reading the trend, not the last run, and the four slow-burn causes that a one-night comparison can't see.

The aggregate-restatement problem that breaks naive backfills: events arrive days late and out of order, so any partition you already published may be wrong. The staff answer is event-time partitioning plus bounded restatement, not a bigger watermark.

SCD2 tracks when an attribute was true; bitemporal also tracks when you knew it. The question separates engineers who can audit a number from those who quietly overwrite history when a correction arrives.

Basic salting assumes one side is a small dimension you can explode. When both sides are huge and skewed, exploding either one blows up the cluster. The staff move is to split hot keys out and handle them on a different plan entirely.

CDC design questions usually stop at the happy-path MERGE. This one stress-tests it: an at-least-once stream that double-delivers, hard deletes, soft deletes for audit, and a GDPR erasure that must physically purge even the bronze change log. The guarantees have to compose.

Streaming interviews separate people who have run a job at 3am from people who have read the docs. The hard parts are not the windowed aggregate, they are bounding state so the job does not die, and choosing what a late event does to an already-emitted result.

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.

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.

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.

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.

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.

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.

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.