Most Databricks interview guides you will find were written for a platform that no longer ships. They ask about Delta Live Tables. They ask how you mount an S3 bucket to DBFS. They ask you to explain ZORDER BY and how to pick a partition column.
Those questions are not wrong, exactly. They are just answerable by someone who last touched Databricks in 2023 — which means they separate nobody. Every candidate clears them, and you end up choosing on charisma.
The platform moved underneath all three. The governance layer became mandatory, the pipeline framework was renamed and its API changed, and the recommended table layout was replaced outright. None of those changes broke old code, which is exactly why they are useful in an interview: an engineer who has been in the product this year talks about the work differently from one who has not, without either of them being obviously wrong.
The fastest way to date a Databricks candidate is not asking what they know. It is asking what they stopped doing.
Here are the questions we use when we screen Databricks engineers, what a current answer sounds like, and where the out-of-date ones give themselves away.
The three renames that date a candidate
Start by listening to vocabulary before you test anything. Ask a candidate to describe the last pipeline they shipped end to end, then say nothing for ninety seconds. The words they reach for tell you which version of the platform lives in their head.
| If a candidate says | The platform now calls it | Why it matters |
|---|---|---|
Delta Live Tables, DLT, import dlt | Lakeflow pipelines, from pyspark import pipelines as dp | Names the pipeline framework’s current API surface, not the one from two rebrands ago |
Hive metastore, DBFS mounts, /mnt/ | Unity Catalog, external locations, volumes | Governance moved from optional add-on to the thing that gates access, lineage and serverless |
PARTITIONED BY plus ZORDER | Liquid clustering | Table layout tuning is now a declared clustering key, not a hand-picked partition column |
One important caveat, and it is the thing most interviewers get wrong: old vocabulary is not disqualifying. Databricks kept the old paths working deliberately. A candidate who says “DLT” out of habit while describing current behaviour accurately is fine. A candidate who says “DLT” and then describes a workflow that only made sense three years ago is the one you are looking for.
So do not score the word. Score whether they know it changed.
Governance is the first round now, not the last
For years, Unity Catalog questions lived at the end of the loop — a nice-to-have after the Spark questions were done. That ordering is backwards on the current platform.
Databricks states that Unity Catalog is automatically enabled for all Databricks workspaces created after November 8, 2023. It is not an upgrade someone chooses. Meanwhile the older path is described plainly in Databricks’ own documentation: the per-workspace Hive metastore is a legacy feature, and Databricks recommends migrating those tables and the workloads that reference them to Unity Catalog and disabling direct access.
Questions that work:
- “How do you reference a table, and what changes when you move a workload off the Hive metastore?” A current answer walks through catalog, schema and table as three real levels of isolation, and mentions what breaks along the way — hard-coded two-part names, jobs that assumed a default database, and permissions that were previously handled somewhere else entirely.
- “You have inherited a workspace full of
/mnt/paths. What do you do?” The answer you want matches Databricks’ own guidance: migrate mounts on cloud storage locations to external locations in Unity Catalog, and do not leave a storage account mounted to DBFS if it is also being used as an external location. Someone who has done this will get specific about the sequencing, because the sequencing is where it goes wrong. - “Who owns access control on your current team?” This is a culture question wearing a technical costume. On a governed workspace, the data engineer usually ends up owning a meaningful slice of it. Candidates who have never been on that hook will say “the platform team” and move on quickly.
There is also a hard dependency worth testing directly, because it catches people out. Databricks notes that legacy workspaces that are not enabled for Unity Catalog do not have access to serverless compute. Governance is not a parallel workstream to performance work — it is upstream of it. An engineer who has lived through a migration knows that in their bones, because it is the argument they used to get the migration funded.
Pipelines: what actually changed under Lakeflow
This is the highest-yield section of a Databricks screen, because the change is precise enough to be unfakeable.
Databricks’ documentation is direct about it: the product formerly known as Delta Live Tables (DLT) has been updated to Lakeflow pipelines, and if you previously used DLT there is no migration required — your code will still work. What did change is the authoring surface:
| Old | Current |
|---|---|
import dlt | from pyspark import pipelines as dp |
@dlt decorator prefix | @dp |
@view | @temporary_view |
@table | @table creates streaming tables; @materialized_view added for materialized views |
Ask this one: “A teammate has a pipeline that starts with import dlt. Does it still run?”
The correct answer is yes, and the reason matters. Databricks preserved compatibility on purpose. A candidate who confidently says it breaks is pattern-matching on “renamed product means migration” rather than reporting something they have seen. A candidate who says “yes, but we moved the new pipelines over so the codebase stopped being half and half” has actually managed this.
Then go one level deeper: “Streaming table or materialized view — how do you choose?” You are listening for a cost and correctness answer, not a definitional one. Strong candidates talk about whether the source is append-only, how much of the table has to be recomputed, and what happens on a backfill. Weak candidates recite the docs.
If the role sits closer to the analytics side of the house, the same instinct applies when you are hiring across the wider data warehouse stack — the framework names change, the question of what gets recomputed and who pays for it does not.
Layout and cost: where the bill actually comes from
Ask a Databricks engineer about performance and most will reach for whatever they learned first. That is exactly what makes it diagnostic.
Databricks now describes liquid clustering as a data layout optimization technique that replaces table partitioning and ZORDER, and recommends liquid clustering for all new tables, including streaming tables and materialized views. Clustering keys can be redefined without rewriting the data — which is the whole point, because the partition column someone chose in year one is usually wrong by year three.
Questions that work:
- “What is your default table layout for a new table today?” “Liquid clustering unless there is a reason not to” is the current answer. “It depends on the partition column” is a 2022 answer.
- “Walk me through the last time you cut a compute bill. What was the number before and after?” Anyone who has genuinely owned spend has this number. Anyone who has not will talk about caching in the abstract.
- “Serverless or classic — which have you owned, and what changed about how you tune?” Databricks describes serverless compute as a managed service where you run workloads without provisioning any compute resources in your cloud account, which speeds start-up and scaling and minimizes idle time. Cost work on serverless is about job shape and idle time; on classic it is about cluster sizing, autoscaling and instance choice. Both are legitimate. Hiring someone who has only done one and expecting the other on day one is not.
The second question is the one to keep. Cost ownership is the cleanest available proxy for seniority on this platform, and it does not depend on which version of the docs someone read.
What the certification tells you — and what it doesn’t
Certification comes up on almost every Databricks req, usually as a hard filter. It is worth being precise about what it buys you.
The Databricks Certified Data Engineer Associate is 45 scored questions and is valid for two years. The blueprint is weighted like this:
| Section | Weight |
|---|---|
| Data Transformation and Modeling | 22% |
| Data Ingestion and Loading | 21% |
| Working with Lakeflow Jobs | 16% |
| Governance and Security | 15% |
| Implementing CI/CD | 10% |
| Troubleshooting, Monitoring, and Optimization | 10% |
| Databricks Intelligence Platform | 6% |
Two things follow. First, the two-year validity does real work for you: a current certification is evidence someone has studied this platform recently, which is precisely the thing that is hard to verify by conversation. A certification from four years ago has lapsed and tells you about a platform that has since been renamed twice.
Second, look at the weighting. Governance and Security at 15% and Lakeflow Jobs at 16% together outweigh either ingestion or transformation on their own. The exam has already moved where the current hiring bar sits. If your interview loop still spends forty minutes on Spark internals and five on access control, your loop is calibrated to an older platform than the certification is.
What certification does not tell you: whether someone has been paged at 2am for a pipeline that silently dropped rows, whether they can push back on a stakeholder asking for a real-time dashboard on a batch source, or whether they will document anything. Those are the things that decide whether the hire works out, and they only come out of a conversation about real incidents — which is why our technical recruiting screens are built around one, rather than around a quiz.
How to run the loop, and what it costs
Three conversations. That is the shape that closes.
- Platform screen (30 minutes). The vocabulary test above, plus one governance question. You are checking whether they run the current platform, not testing recall.
- One real problem (60 minutes). Bring an actual pipeline, table or cost problem from your environment, sanitized. Ask how they would approach it, then argue with them a little. You learn more from ten minutes of disagreement than from an hour of clean answers.
- Stakeholder conversation (30 minutes). Whoever consumes their output. This is where you find out if they can say no clearly.
Skip the take-home. The population you are competing for is employed, and a four-hour unpaid exercise is where good candidates quietly stop replying.
On money: the US average for a Databricks engineer sits at $125,361 a year across roughly 10,000 reported salaries, with entry-level around $99,500 and experienced engineers at $177,880. Treat the average as what you pay for someone who can operate the platform competently, and the experienced number as what you pay for someone who owns the pipelines and the bill attached to them. If the req is genuinely the second thing and the band is set to the first, the role will sit open — a pattern we see repeatedly across the Databricks and lakehouse market, where the platform’s growth keeps outrunning the size of the senior bench.
The other lever, when the band will not move, is geography rather than seniority. Nearshore hiring puts experienced platform engineers in overlapping time zones at a different cost basis — which works well for pipeline ownership and badly for a role that also needs to be in the room with executives twice a week. Know which one you are hiring before you open the search.
