Most Delta Lake interview questions in circulation test recall, not judgment. A candidate can define ACID, recite the four properties, name the transaction log and still ship a MERGE that silently doubles a fact table on the second run. The skills worth testing are the ones that break production tables: upsert correctness, time travel and retention, file layout, schema evolution, concurrent writes, and how Delta and Apache Iceberg actually interoperate. Below are the questions to ask, the scenarios to put in front of a candidate, and what separates a strong answer from a confident one.
What Delta Lake interview questions should you ask?
Start from failure modes, not features. Every question below maps to a thing that goes wrong on real lakehouse teams, and each one has a version a junior can answer and a version only someone who has operated tables can.
| Skill area | The question | What a strong answer sounds like |
|---|---|---|
| MERGE / upserts | “Your nightly MERGE runs twice because of a retry. What happens to the target table?” | Walks through the match condition, whether the source has duplicate keys, and why whenMatchedUpdate plus a dedupe window on the source is the fix — not a DISTINCT bolted on at the end |
| Time travel | “A bad deploy overwrote a table at 02:00. Walk me through recovery.” | DESCRIBE HISTORY, pick the version, RESTORE or CREATE TABLE AS SELECT ... VERSION AS OF, then checks retention before promising anything |
| VACUUM / retention | “Why can’t you just set retention to zero?” | Ties it to in-flight readers and streaming checkpoints, and knows the default seven-day window exists to protect concurrent queries |
| File layout | “The table is 400 GB and queries take four minutes. Where do you look first?” | File count and file sizes before anything else — then partitioning scheme, then clustering, then the query itself |
| Schema evolution | “Upstream adds a column mid-sprint. What breaks?” | Distinguishes additive change, type widening and rename; knows mergeSchema is a convenience, not a contract |
| Concurrency | “Two jobs write to the same table at once. What happens?” | Optimistic concurrency control, conflict classes, and which operations can be made to not conflict at all |
| Interoperability | “Finance wants to read this table from a non-Databricks engine.” | Metadata-level interoperability via UniForm and a catalog conversation, not a copy job |
If a candidate has never had to explain to a stakeholder why yesterday’s number changed, they have never really operated a Delta table.
The pattern to look for across all seven rows is whether the candidate reaches for the table’s physical reality — files, versions, commits — or stays in SQL. Both matter. Only one of them tells you whether they can debug at 7am.
What are good scenario-based Delta Lake interview questions?
Scenarios beat definitions because they force sequencing. Give the candidate a situation, let them ask you questions back, and score the questions they ask as much as the answer.
The duplicate upsert
“A CDC feed lands every 15 minutes. Your MERGE keys on customer_id. Downstream reports a 3% revenue overstatement.” A strong candidate asks whether the source batch can contain multiple rows per key before touching the MERGE at all, then proposes a deterministic ranking by sequence number or commit timestamp. The reason this is now a correctness question and not a tidiness question: once you declare uniqueness and the optimizer trusts it, plans change. Databricks measured a case where RELY on a UNIQUE constraint let the engine eliminate a DISTINCT aggregation and cut median execution from 33.7 seconds to 2.8 — a 12.0x speedup. If the declared constraint is a lie, the fast plan returns wrong rows. Ask the candidate what happens when a constraint is declared RELY and the data violates it; the good ones get visibly uncomfortable, which is the right reaction.
The partition that was a mistake
“A predecessor partitioned an events table by event_date and country. Ingest is hourly. Queries are slow and the job that used to take 20 minutes now takes two hours.” You are testing whether they recognise over-partitioning and the small-file problem on sight. Databricks’ own data-layout analysis found Hive-style partitioning produces over-partitioning and small-file problems in more than 75% of cases — which means a candidate who treats partitioning as the default answer to “how do I make this fast” is reciting a 2017 playbook. Strong answers compare OPTIMIZE with Z-ORDER against liquid clustering, explain why clustering avoids the cardinality trap, and name the migration path rather than proposing a full rewrite on day one.
The VACUUM that never finishes
“Maintenance on one table takes most of a maintenance window. Nobody knows why — it isn’t the biggest table.” The insight you want is that cost tracks file count, not bytes: standard vacuuming has to list every file in the table directory, an operation Databricks documents as taking over 40 minutes for tables with 10 million files. A candidate who connects streaming micro-batches → small files → exploding file counts → unmanageable maintenance has shown you the whole causal chain in one breath. That is the answer worth hiring.
The concurrent write
“A backfill and a streaming job both write to the same table. The backfill fails with a concurrency exception.” Weak answers say “add a retry.” Strong answers explain optimistic concurrency control, identify which files each writer touched, and reduce the conflict surface — partition-scoped predicates, separating the backfill into a staging table, or sequencing the two jobs deliberately. Then they tell you retries are still needed.
Which Databricks Delta Lake interview questions separate seniors from juniors?
The separation is rarely about knowing more commands. It is about knowing what a command costs and who it blocks.
| Question | Junior answer | Senior answer |
|---|---|---|
| “What does OPTIMIZE do?” | Compacts small files into bigger ones | Names the target file size, explains the write amplification, and says when not to run it on a streaming sink |
| “How does time travel work?” | You can query old versions | Explains that history is a function of retained files, so retention policy and time travel are the same decision |
| “When do you Z-ORDER?” | For better performance | Picks columns by filter frequency and cardinality, and knows Z-ORDER is rewritten on every OPTIMIZE run |
| “How do you handle a schema change?” | Enable mergeSchema |
Asks who consumes the table, whether the change is additive, and what the contract with upstream is |
| “How do you know a table is healthy?” | Queries run fine | File count, average file size, commit frequency, last optimize, stale statistics |
The senior column has a tell: it answers with a trade-off rather than a verb. If you want a repeatable version of this, the 90-minute Databricks vetting structure covers how to run it as a single session, and the skills matrix covers what to record afterwards.
Is Iceberg better than Delta Lake, and should you test both?
It is the wrong question to ask a candidate, and a very good question to ask about a candidate. Anyone who answers “Iceberg is better” or “Delta is better” without asking about the engine, the catalog and the consumers has told you they think in brands rather than systems.
Test both, but weight them differently. Only 9% of teams report running Iceberg in production, with 6% planning and 12% in proof-of-concept — so screening for years of hands-on Iceberg will shrink your pool to almost nothing for no gain. What you are actually testing is transferable table-format reasoning: manifests and metadata trees, snapshot isolation, hidden partitioning, catalog dependency. A candidate who understands the Delta transaction log deeply can reason about Iceberg metadata in an interview; the reverse is also true.
The interoperability question is not hypothetical either. Among teams using Iceberg, Delta Lake shows meaningful overlap at 39.3% — multi-format estates are normal, so ask how they would expose one physical table to two ecosystems. UniForm-style metadata generation, catalog registration and the limits of each belong in that answer. A copy pipeline does not.
What Apache Iceberg interview questions matter for lakehouse roles?
Probe understanding directly instead of assuming it. Knowledge gaps are the joint most-cited barrier to Iceberg adoption at 27%, tied with unclear use cases — which means the gap in your team is likelier to be comprehension than tooling, and an interview is a cheap place to find out. That mirrors what we see more broadly: lakehouse adoption stalls on skills, not platform.
Four questions that earn their slot:
- “Explain hidden partitioning and why it matters.” Look for partition evolution without rewriting queries, and the contrast with Hive-style directory layouts that users have to know about to query efficiently.
- “Merge-on-read or copy-on-write for this table?” The best answer is conditional — write-heavy, update-heavy tables favour merge-on-read with deletion vectors; read-heavy tables with infrequent updates tolerate copy-on-write. Iceberg v3 deletion vectors are documented as delivering DML up to 10x faster than copy-on-write, and a senior candidate will immediately add that the cost moves to read time and compaction.
- “What breaks if the catalog is unavailable?” Tests whether they understand that the catalog holds the current snapshot pointer, and what that means for engines, permissions and migration planning.
- “How do you expire snapshots safely?” The Iceberg analogue of the VACUUM question. If they answered VACUUM well, see whether the reasoning transfers.
How do you score these answers without a take-home?
Stop grading on completeness. Grade on three signals, in this order.
Does the diagnosis come before the fix? Candidates who name a tool before asking what the symptom is will do the same thing in your incident channel.
Do they quantify? “It would be slow” is not an answer. “We’d be listing millions of files, so expect tens of minutes” is. Numbers in an answer mean they have watched a job run.
Can they say what they would not do? Rejecting the full repartition, the retention-to-zero shortcut, the unvalidated RELY constraint — negative knowledge is the clearest senior marker there is, and it almost never shows up on a CV.
Two follow-ups are usually enough to tell a practitioner from a reader: ask what went wrong the last time they ran that operation, and what they changed afterwards. People who have operated Delta or Iceberg tables answer in specifics without prompting. People who have read about them change the subject to architecture. Keep the whole thing to one scenario per skill area and you will get more signal in 60 minutes than a weekend take-home produces — and you can run the same script across every candidate in the data engineering pool for comparability.