---
title: Databricks Interview Questions and Answers (2026)
description: Real Databricks interview questions — Delta Lake, MERGE, the medallion architecture, Unity Catalog, cluster choices and OPTIMIZE — with answers and a prep plan.
url: https://usegreenroom.app/blog/databricks-interview-questions
last_updated: 2026-07-31
---
← Back to blog
Data Engineering
# Databricks interview questions and answers
July 31, 2026 · 12 min read
"So the bronze layer," the interviewer said, "what transformations do you do there?" The candidate, who had read a blog post on the flight, said confidently: "Clean the data, fix the schema, deduplicate, standardise the column names." And the interviewer wrote something down, because that is the bronze layer's entire job description turned inside out.
Databricks interview questions punish half-learned vocabulary harder than most topics, because the platform's concepts sound obvious and are not. Bronze is raw-and-append-only precisely so you can reprocess when your cleaning logic turns out to be wrong. This guide covers what gets asked — Delta Lake, the medallion architecture, Unity Catalog, clusters, and the performance questions — and the follow-up sitting behind each.
## What Databricks interviews actually test
Whether the role is at Databricks itself, at a consultancy staffed to a Databricks account, or at a company that runs its platform on it, the Databricks interview questions cluster into five areas:
- Delta Lake — ACID transactions, the transaction log, time travel, MERGE, schema evolution. The single most-asked area.
- Lakehouse and medallion architecture — bronze/silver/gold, and what genuinely belongs in each.
- Spark underneath — because Databricks is Spark, every PySpark performance question is fair game.
- Platform mechanics — job vs all-purpose clusters, Photon, autoscaling, Unity Catalog, workflows and Delta Live Tables.
- Cost and governance — the questions that separate someone who has run a platform from someone who has used a notebook.
Because Databricks runs on Spark, the PySpark interview questions guide is effectively half of this preparation — shuffles, skew and broadcast joins get asked here under a different heading.
The five areas Databricks interviews cover, with Delta Lake carrying the most weight.
## Delta Lake interview questions
Start with the question that opens most loops: what is Delta Lake and what does it give you over plain Parquet?
Delta Lake is a storage layer over Parquet files plus a transaction log — the _delta_log directory of ordered JSON commits. That log is the whole answer. It gives you ACID transactions on object storage, so a failed write does not leave half-written data visible; readers get a consistent snapshot while writers are appending; you get time travel because every version is a log entry; and you get schema enforcement and evolution because the schema lives in the log rather than being inferred from files.
The follow-up: how does Delta do ACID on S3, which has no locking? Optimistic concurrency. Writers read the current version, stage their files, then attempt to commit the next log entry atomically. If someone else committed first, the writer detects the conflict and either retries against the new snapshot or fails. Knowing that appends rarely conflict but two concurrent MERGEs on the same partition will is the detail that marks real experience.
### MERGE and upserts
MERGE is the most-asked Delta operation, because it is how change data capture and late-arriving records get handled:
```
-- Upsert payments, guarding against replayed older events
MERGE INTO silver.payments AS t
USING staged_updates AS s
ON t.payment_id = s.payment_id
AND t.event_date >= '2026-07-01' -- partition predicate limits the rewrite
WHEN MATCHED AND s.event_ts > t.event_ts THEN
UPDATE SET *
WHEN NOT MATCHED THEN
INSERT *;
```
Two things to volunteer. First, the AND s.event_ts > t.event_ts guard — without it a replayed older event overwrites newer state, which is the classic late-webhook bug. Second, MERGE rewrites whole files, so an unpartitioned merge against a huge table scans everything; adding a partition predicate to the ON clause is the standard optimisation, and deletion vectors reduce the rewrite cost on newer runtimes.
### Time travel and VACUUM
Time travel — SELECT * FROM tbl VERSION AS OF 12 or TIMESTAMP AS OF '2026-07-01' — is used for audits, reproducing a report, and rolling back a bad load with RESTORE. The follow-up is always VACUUM: it deletes files no longer referenced by the log older than a retention threshold (7 days by default), and running it with a short retention destroys your ability to time travel that far back. Candidates who mention that VACUUM and time travel are in direct tension have understood the system.
## The medallion architecture: bronze, silver, gold
Back to the question from the intro. The medallion architecture is Databricks' recommended layering, and each layer has a specific contract:
- Bronze — raw ingested data, appended, as close to the source as possible. Minimal or no transformation, plus ingestion metadata (source file, load timestamp). The point is reprocessability: when your silver logic is wrong, you replay from bronze rather than re-requesting from the source.
- Silver — cleaned, conformed, deduplicated, joined into meaningful entities. Types enforced, business keys resolved, one row per real-world thing. This is where most of the engineering lives.
- Gold — aggregated, business-facing tables and marts shaped for consumption: dashboards, reporting, features for ML. Denormalised on purpose.
The good follow-up answer: layers are a convention, not a law, and a small pipeline that jams silver and gold together is fine — what you must not collapse is bronze, because that is your recovery path. Say that and you sound like someone who has had to backfill.
## Clusters, Photon and cost questions
Platform questions separate notebook users from platform owners:
- Job clusters vs all-purpose clusters — job clusters spin up for a single run and terminate, and are billed at a lower rate; all-purpose clusters stay warm for interactive development and are more expensive. Running production jobs on an all-purpose cluster is the most common cost mistake, and a great thing to say unprompted.
- Photon — a vectorised C++ execution engine that accelerates SQL and DataFrame operations. It costs more per DBU but often reduces total cost by finishing faster. It helps most on scans, joins and aggregations; it does not accelerate Python UDF-heavy code.
- Autoscaling — useful for variable workloads, wasteful for steady ones, and it cannot rescue a job bottlenecked on one skewed task.
- Serverless SQL warehouses — fast startup for BI workloads, good when analysts need low-latency queries without managing a cluster.
- Spot / preemptible instances — cheaper workers, but the driver should stay on-demand. A useful, specific answer to "how would you cut this bill?"
Other cost answers worth having ready: turn off auto-termination never, cluster reuse across small jobs, and the fact that small-file problems inflate both compute and storage costs. Our AWS interview questions guide and Azure interview questions guide cover the cloud layer these clusters sit on.
## Unity Catalog, governance and Delta Live Tables
Unity Catalog comes up increasingly often. It is the centralised governance layer: a three-level namespace (catalog.schema.table), unified access control across workspaces, lineage tracking, and audit. The interview-relevant point is why it exists — before it, permissions were per-workspace and lineage was manual, so a company with several workspaces had no single answer to "who can read this table and where did it come from?"
Delta Live Tables (declarative pipelines) is the other platform feature worth knowing: you declare the transformations and expectations, and the platform handles orchestration, dependency resolution, incremental processing and data-quality enforcement. The honest comparison — and interviewers like this — is that DLT reduces boilerplate and gives you quality constraints for free, but it is Databricks-specific, so you trade portability for productivity. Compare with the Airflow interview questions guide on general-purpose orchestration.
Also expect Auto Loader (cloudFiles) for incremental file ingestion, since "how do you ingest new files landing in S3 without re-reading everything?" is a standard question. The answer is Auto Loader with checkpointing, and the reason it beats listing the directory yourself is that it scales to millions of files using notification-based discovery.
## Performance: OPTIMIZE, Z-ORDER and small files
The performance question is usually framed as "queries on this table are slow, what do you do?" The expected chain:
```
-- Compact many small files into fewer, larger ones
OPTIMIZE silver.payments
WHERE event_date >= '2026-07-01'
ZORDER BY (merchant_id);
-- Then reclaim storage from files the log no longer references
VACUUM silver.payments RETAIN 168 HOURS;
```
Explain what each does. OPTIMIZE solves the small-file problem — streaming and frequent merges produce thousands of tiny files, and query planning drowns in metadata. ZORDER BY co-locates related values in the same files so data skipping can eliminate whole files for a filtered query; it helps on high-cardinality columns you filter on, and it is not a substitute for partitioning on a low-cardinality column like date. On recent runtimes, liquid clustering replaces the partitioning-plus-Z-ordering decision with an adaptive scheme, and knowing it exists reads as current.
The over-partitioning trap is worth raising unprompted: partitioning by a high-cardinality column like customer_id creates millions of tiny directories and is far worse than not partitioning at all.
## The Databricks Academy, the docs, ChatGPT — where each fits
- The official Databricks documentation — genuinely excellent and the fastest-moving source. The Delta Lake and performance-tuning sections answer most interview questions directly.
- Databricks Academy and the certifications — the Data Engineer Associate/Professional paths map closely to what gets asked, and the certification is a real résumé signal in consultancies staffed to Databricks accounts.
- The Community Edition or a free trial — the highest-yield item here. Create a Delta table, run a MERGE, break it, time-travel back. The questions are about things you can only describe convincingly if you have seen them.
- Udemy courses — fine for coverage, usually a runtime version or two behind on features like liquid clustering and Unity Catalog.
- ChatGPT — useful for explaining a concept and reviewing SQL. It will not catch you confidently describing bronze as the cleaning layer and then ask why.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud and asks the follow-up your reading never does. Fair tradeoff: Ari will not provision a cluster for you.
> The core truth: Databricks questions reward people who can say why a feature exists, not what it is called. Delta's log explains ACID, time travel and VACUUM in one breath; bronze exists so you can be wrong later. Learn the reasons and the trivia answers itself.
## How to prepare for a Databricks interview
- Week 1: Delta Lake end to end on a free workspace — create a table, MERGE into it, evolve the schema, time travel, RESTORE, VACUUM. Narrate each aloud as you go.
- Week 2: Spark performance, because Databricks interviews are Spark interviews wearing a platform badge. Build a skewed job and fix it.
- Week 3: platform and governance — job vs all-purpose clusters, Photon, Auto Loader, Unity Catalog, DLT. Prepare one specific cost-reduction answer.
- Final week: design a medallion pipeline aloud for a domain you know, prepare two war stories in first person, and run two full spoken mocks with follow-ups.
Building the rest of the stack? The PySpark interview questions guide covers the engine underneath, the Airflow interview questions guide covers orchestration, the dbt interview questions guide covers warehouse transformation, and the data modeling interview questions guide covers the schema design behind silver and gold.
## Frequently asked questions
### What are the most common Databricks interview questions?
The most common questions cover what Delta Lake adds over plain Parquet and how its transaction log works, how MERGE handles upserts and late-arriving data, time travel and its tension with VACUUM, the medallion architecture and what belongs in bronze, silver and gold, job versus all-purpose clusters and cost control, Unity Catalog and governance, and OPTIMIZE, Z-ORDER and the small-file problem.
### What is Delta Lake and how is it different from Parquet?
Delta Lake is a storage layer built on Parquet files plus an ordered transaction log stored in a _delta_log directory. That log adds ACID transactions on object storage, consistent snapshot reads while writers append, time travel to any previous version, schema enforcement and evolution, and efficient upserts through MERGE. Plain Parquet is just files, with no transactional guarantees and no version history.
### What is the medallion architecture in Databricks?
The medallion architecture is a layering convention with bronze, silver and gold tables. Bronze holds raw ingested data appended with minimal transformation so it can be reprocessed. Silver holds cleaned, deduplicated and conformed entities with types enforced. Gold holds aggregated, denormalised business-facing tables for dashboards, reporting and machine learning features. Bronze is the layer you must not collapse, because it is your recovery path.
### What is the difference between a job cluster and an all-purpose cluster?
A job cluster is created for a single automated run and terminates when the job finishes, and it is billed at a lower rate. An all-purpose cluster stays running for interactive notebook development and shared use, at a higher rate. Running scheduled production workloads on an all-purpose cluster is one of the most common cost mistakes on the platform, and moving them to job clusters is a standard cost-reduction answer.
### What do OPTIMIZE and Z-ORDER do in Databricks?
OPTIMIZE compacts many small files into fewer larger ones, which fixes the small-file problem created by streaming ingestion and frequent merges. ZORDER BY co-locates related values in the same files so data skipping can eliminate entire files when a query filters on that column. Z-ordering suits high-cardinality filter columns and is not a replacement for partitioning on a low-cardinality column such as date.
### Do I need to know Spark for a Databricks interview?
Yes. Databricks runs on Spark, so shuffles, partitioning, broadcast joins, data skew and caching are all fair game and frequently decide the round. Platform knowledge about Delta Lake, clusters and Unity Catalog sits on top of that foundation rather than replacing it, so preparing Spark performance debugging is roughly half of preparing for a Databricks interview.
Databricks rounds reward explaining why a feature exists, out loud. Greenroom runs mock data engineering interviews with Ari — Delta and performance follow-ups included — and scores structure, clarity and depth. Free to start. Curious how it works? See how AI mock interviews work.