Read twenty real 2026 postings back to back and you notice something useful: the databricks engineer job description has stopped improvising. The shape has settled. SQL first, then PySpark, then Delta Lake, then Unity Catalog, then orchestration, then CI/CD on one named cloud — and increasingly a paragraph about agents or RAG bolted onto the end. That consistency is good news for you, because it means a CV can be built against a known spine instead of a guess. It also means the scattergun CV — eighteen tools, no depth — now reads as a mismatch rather than as range. Hiring managers writing that same spine from scratch can start with how to hire Databricks developers.
What does a Databricks engineer do?
Strip the marketing language out of a posting and the job is usually four things: land data reliably, model it so analysts and ML teams can use it, govern who sees what, and keep the whole thing running on a schedule without anyone babysitting it.
What has changed is the weighting. Five years ago the bulk of the role was ingestion plumbing. In 2026 ingestion is largely a configuration problem — managed connectors, Auto Loader, Lakeflow Declarative Pipelines — and the time moves into modelling, cost control, governance and the awkward middle ground where data work meets AI work. Nearly half of data and analytics postings now mention AI at all, 45% as of December 2025 and the highest share of any sector analysed, which is why MLflow, vector search and evaluation loops keep showing up in postings that are otherwise entirely about pipelines.
The practical read: you are being hired to make data trustworthy enough that something else can be built on top of it. Everything in the requirements list is downstream of that.
What skills are required for Databricks roles in 2026?
Almost every posting leads with SQL, and the reason is not nostalgia. SQL is the second most used language among developers at 58.4%, ahead of Python — it is the shared language between you, the analysts, the BI layer and now the AI tooling that generates queries you have to review. A Databricks engineer who writes mediocre SQL is a Databricks engineer who cannot review anything.
Here is how the requirement lists actually sort once you separate the screening criteria from the wishlist:
| Requirement | Status in 2026 postings | What they are testing |
|---|---|---|
| SQL (windowing, CTEs, performance) | Must-have, near-universal | Can you reason about a query plan, not just write a query |
| PySpark / Spark SQL | Must-have | DataFrame API fluency, joins, skew, partitioning |
| Delta Lake | Must-have | MERGE, time travel, OPTIMIZE/Z-order or liquid clustering, schema evolution |
| Unity Catalog | Must-have (recent shift) | Catalog design, grants, lineage, migration from Hive metastore |
| Orchestration (Lakeflow Jobs, Airflow, ADF) | Must-have | Dependencies, retries, idempotency, alerting |
| One named cloud (Azure, AWS, GCP) | Must-have, named specifically | Storage, identity, networking on that cloud |
| CI/CD (Git, Asset Bundles, Terraform) | Must-have at senior level | Deploying workspaces and jobs as code |
| Python beyond PySpark | Strong nice-to-have | Testing, packaging, tooling |
| Streaming (Structured Streaming) | Nice-to-have, role-dependent | Watermarks, exactly-once, late data |
| MLflow, vector search, agent evaluation | Fast-growing extra | Can you support AI workloads, not build models |
| dbt, Iceberg, Snowflake | Context-dependent | Usually signals a migration or a hybrid estate |
| Scala | Narrow but well-paid | Legacy Spark codebases |
Two details worth reading closely. First, Unity Catalog has crossed from nice-to-have to screening criterion, and the commercial logic is visible in Databricks’ own customer data: companies that implemented AI governance pushed 12x more projects to production. Governance is no longer the compliance tax at the end of the project — it is the thing that decides whether the project ships at all, so hiring managers screen for it early.
Second, postings increasingly name runtime versions and specific features rather than asking for “3+ years Spark experience”. Spark 4.3 alone landed with more than 200 contributors addressing over 1,100 Jira tickets, and when the engine moves that fast, generic Spark experience stops being a differentiator. Naming what you have actually used — liquid clustering, Photon behaviour, declarative pipelines, serverless compute trade-offs — does more than another year on the timeline.
A job description is a priority list in disguise. The first three bullets are the job; the rest is the wishlist someone added in a meeting.
What does an Azure Databricks data engineer job description include?
The cloud named in the title changes roughly a third of the requirements, and candidates lose interviews by treating it as cosmetic. The platform skills transfer; the surrounding stack does not.
| Azure Databricks | AWS Databricks | GCP Databricks | |
|---|---|---|---|
| Storage | ADLS Gen2, abfss paths | S3, bucket policies | GCS |
| Identity | Entra ID, managed identities, service principals | IAM roles, instance profiles | IAM, service accounts |
| Orchestration often paired | Azure Data Factory, Lakeflow Jobs | Airflow/MWAA, Step Functions | Composer |
| Adjacent warehouse | Synapse, Fabric, SQL Server | Redshift, Glue Catalog | BigQuery |
| IaC expectation | Terraform or Bicep | Terraform or CDK | Terraform |
| Common extra ask | Power BI semantic models | QuickSight or Tableau | Looker |
Azure postings are the most numerous and the most prescriptive — they frequently assume you have migrated something off Synapse or Data Factory, and they often expect Power BI literacy because that is where the output lands. If your Databricks work has been on AWS, say so plainly and name the one or two Azure components you have touched; claiming cloud-agnosticism reads as never having debugged a storage credential at 2am.
Which Databricks certifications do job postings ask for?
Most postings list certification as preferred, not required. The two that appear by name are Data Engineer Associate and Data Engineer Professional, with Databricks Certified Associate Developer for Apache Spark turning up in Spark-heavy roles and the Machine Learning Associate appearing where the team supports AI workloads.
What a certification does and does not do:
- Does: get you past automated screens, satisfy a partner-status requirement at a consultancy, prove platform-current knowledge when your last two years were on another stack.
- Does not: substitute for a production story. Every interviewer’s follow-up to a certification is “what did you build with it”, and that is the actual question.
If you are deciding whether the exam is worth the weekend, the honest answer depends on whether you are applying to consultancies — where certifications are commercially load-bearing — or product teams, where they are a tiebreaker. We looked at where the premium actually lands in Databricks certifications worth the premium.
How should you structure a CV against the job description?
Stop listing tools. Start mirroring the spine.
Lead with the platform line. One sentence at the top: the clouds, the Databricks surface area, the scale. “Databricks on Azure, five years — Delta Lake medallion architecture, Unity Catalog migration across 40 schemas, Lakeflow Jobs orchestration, deployed via Asset Bundles.” A screener finds every must-have in that sentence.
Quantify the pipeline, not the tenure. Rows, tables, daily volume, job count, cost reduction, SLA. “Reduced nightly batch from 4.5 hours to 70 minutes by repartitioning and switching to liquid clustering” beats “experienced in Spark optimisation” every time.
Name the governance work explicitly. If you ran a Hive metastore to Unity Catalog migration, that is a headline, not a bullet point. Very few CVs say it clearly and a lot of hiring managers are looking for it.
Describe how you work with AI tooling, not whether you do. AI-assisted coding is now standard practice — 72% of analytics engineers work that way — so “writes PySpark by hand” is not a selling point. Judgement is. Show that you test generated transformations, that you review before merge, that you know where the model gets Delta semantics wrong.
Cut the long tail. Tools you touched once dilute the ones you own. If you want the day-rate version of this argument, Databricks skills that raise your day rate breaks down which specialisms actually move the number.
One more thing worth preparing for: the technical screen has got sharper because the market has got narrower. By the end of 2025, total tech postings were still 34% below pre-pandemic levels while AI-tagged postings grew. Fewer, more specific roles means screens that go deeper on fewer topics — know what a reviewer is likely to probe by reading how a Databricks engineer gets vetted in 90 minutes.
How do you become a Databricks engineer — and what should you expect to earn?
The realistic routes in are three: sideways from analytics engineering or BI (you already have the SQL, you need Spark and the deployment story), sideways from software engineering (you have the CI/CD and Python, you need dimensional modelling and the data instincts), or forward from a warehouse background on Synapse, Redshift or SQL Server (you have the modelling, you need the distributed-compute mental model).
All three work. What does not work is certification-first with no project, because the interview is a production conversation and you need a system you can describe end to end — ingestion, model, governance, orchestration, failure modes, cost.
On money: there is no official occupation code for lakehouse engineering, so the closest public benchmark is the data scientist category, where the US median was $120,230 in May 2025. Treat that as a floor rather than a target — specialist Databricks roles with Unity Catalog and platform responsibility sit well above it, and contract rates sit above that again. The same source projects the category to grow 35 percent from 2025 to 2035, which is the structural reason this skill set keeps clearing: the demand curve is not the thing under pressure, the generalist supply curve is.
Titles you will see, and what they actually mean
| Title | What the posting really wants |
|---|---|
| Data Engineer (Databricks) | Pipelines and modelling; broadest and most common |
| Platform / Lakehouse Platform Engineer | Workspace administration, Unity Catalog, Terraform, cost governance |
| Analytics Engineer | SQL and dbt-shaped modelling; lighter Spark |
| ML Platform Engineer | Feature pipelines, MLflow, serving — supports models, does not build them |
| Senior / Lead Data Engineer | The above plus design authority and code review |
| Databricks Consultant | Client-facing delivery, certifications matter more, travel likely |
The titles overlap enough that you should read the requirements before you read the headline. A “Senior Data Engineer” posting that lists Terraform, Entra ID and workspace provisioning is a platform role wearing a pipeline title — and if that is what you actually do, it is the posting you want. Specialists who want their experience matched to briefs rather than scraped from a title can get listed anonymously in the data engineering network.