Databricks Engineer Job Description Template 2026

Last updated: September 3, 2026

By Tom Kenaley, President and Senior Partner, KORE1

A Databricks engineer job description should name the cloud, name the layer of the platform this person actually touches, state what condition Unity Catalog is in, and say who has authority over the compute bill. Leave those four out and the same posting fits a Spark developer, a workspace administrator, a BI analyst, and a machine learning engineer equally well. Our Databricks engineer staffing page covers how we pull those apart before a search opens. Published averages for the exact title sit around $111,000 to $114,000, roughly $50,000 under what senior Databricks offers actually close at, and that gap starts in the posting.

The candidate withdrew on a Thursday. The offer was going out Monday.

A regional insurance carrier had run a search that looked healthy from the outside. Around ninety applications, six screens, three finalists, and a clear front-runner with six years of Spark behind him and three of those on Databricks in production. Everyone liked him. He liked them.

In the last conversation, almost as an afterthought, he asked who owned cluster policies today.

Nobody did. The workspace had grown to something north of two hundred all-purpose clusters with no policy layer over any of them, no tagging discipline, and a monthly bill that had roughly tripled inside a year. That last part was the actual reason the req existed. What nobody had written down was that the seat came with the problem and not the authority. He would be measured on the spend. He would not be allowed to change a single team’s notebooks or kill a single scheduled job without that team signing off first.

He asked one follow-up question. Then he said no, politely, and took a smaller title somewhere else.

That posting had nineteen bullets under required skills. PySpark, Delta Lake, Airflow, Kafka, dbt, Terraform, and so on down the list. Not one line described the platform he would inherit or the authority he would have over it. Those nineteen bullets could not have told him less about the job if they had tried.

Where I sit, for the record. KORE1 has run technology desks since 2005, so the incentive is obvious. A data team that gets this right by itself never calls me. Discount accordingly. What follows is about writing a posting that works, which costs nothing and does not involve hiring anybody to help.

Name the Cloud Before You Name Anything Else

“Experience with Databricks required” is not a requirement. It is a category.

Databricks runs on AWS, Azure, and Google Cloud, and inside a notebook the three are close to indistinguishable. Everything around the notebook is not. Azure sells it as a first-party service, so you provision from the Azure portal, it lands on the Azure invoice, identity comes through Microsoft Entra ID, and the networking conversation is about VNet injection, Private Link, and in most large enterprises an ExpressRoute circuit that somebody’s network team guards like a family heirloom. On AWS the same platform sits behind IAM roles, instance profiles, and S3 bucket policies, plus an entirely separate set of arguments about who is allowed to assume what.

Take somebody with four solid years in Azure Databricks at a healthcare payer, orchestrating through Azure Data Factory and writing to ADLS Gen2. Genuinely strong engineer. Drop them into an AWS workspace carrying Glue catalog history, Airflow on MWAA, and a set of S3 permissions three teams have been arguing about since 2022, and the first month is not going to be productive. They will get there. Not in your first sprint, and the honest ones will tell you so on the screen.

So say it. “Databricks Engineer (Azure)” in the title filters harder than any bullet buried on page two, because board search leans on the title field and barely reads the body, and candidates behave the same way. If the cloud honestly does not matter to you, write that down as well. Said on purpose it reads as confidence. Left out it reads as nobody thought about it.

Say What This Person Touches on Day One

Databricks is not one job. It is a stack, and different people own different floors of it.

The confusion is not the candidates’ fault. Somebody who spends their week writing PySpark transformations, somebody who spends it managing metastores and cluster policies, and somebody who spends it building retrieval pipelines on Mosaic AI will all describe themselves as Databricks engineers, and all three of them are being accurate about it. They apply to the same postings. Then six weeks of screening go into sorting out which one you meant.

The fix is not a better title. It is one sentence about artifacts. What does this person open on a Tuesday morning, and what do they change?

Most real jobs are a blend, and a blend is fine as long as you publish the ratio. “Seventy percent pipeline build, thirty percent platform administration” is a job a person can picture themselves doing. “Databricks engineer” is not. Our guide to hiring Databricks engineers works through how we split those lanes at intake, and the splitting is most of the value in the first week of a search.

Unity Catalog Has Three States and You Are Hiring for One of Them

This is the single most useful sentence you can add to a Databricks posting, and almost nobody adds it.

Unity Catalog is the governance layer, and it changed the shape of the work when it arrived. Three-level namespace, so every object is catalog, then schema, then table. Storage credentials and external locations instead of a mess of mount points. Lineage, audit, and row-level and column-level controls a compliance team can actually read. New workspaces get it by default now.

Installed bases are not new workspaces. In the real world a given company sits in one of three places, and each one is a different job.

• Fully on Unity Catalog. The governance model is settled and the work is building inside it. Cleanest version of the job, and it tends to pay slightly less, because it hurts less.
• Mid-migration, with the legacy Hive metastore still live alongside it. Half the tables have moved, half have not, plenty of notebooks still reference two-part names, and somebody has to decide what happens to the ones nobody will claim. Hardest of the three. Most in need of a senior person.
• Not started. Somebody writes the design, gets security and legal to sign off, then runs the migration while production keeps running. Do not hire an associate into this. It looks like a technical job and it is mostly a political one.

Two sentences in the posting handle it. “We are roughly sixty percent migrated to Unity Catalog with the legacy metastore still serving three teams. You would own finishing it.” A senior engineer reads that and knows exactly what their first two quarters look like. They also know you are being straight with them, which matters more than it sounds like it should.

The alternative is what usually happens. Candidate accepts, arrives, discovers the migration in week two, starts taking recruiter calls in week nine. We have picked up more than one Databricks search that began life as somebody else’s completed placement, and in every case the story from the candidate’s side was some version of the same thing, which is that the job they were sold and the job they found were both real and were not the same job.

Who Owns the Compute Bill

Compute cost is the fastest-growing topic in every Databricks conversation I have with a hiring manager, and it is nearly absent from the postings those same managers publish.

The mechanics are simple enough. Consumption is metered in Databricks Units, the rate varies by workload type, serverless SQL currently lists at $0.70 per DBU with the underlying infrastructure folded into that rate, cluster policies constrain what anybody can spin up, budget policies cap serverless spend at the account, workspace, or user level, and tagging is the only thing that makes a line on the invoice attributable to a team.

The configuration is not the hard part. Cost control on this platform is an organizational problem wearing a technical costume. Enforcing a cluster policy means telling a data science team their favorite sixteen-node cluster is not available anymore. Auto-termination on idle warehouses means somebody’s dashboard is slow for eight seconds after lunch. Neither change takes ten minutes to configure. Both need a person who is allowed to make the call and survive the meeting afterward.

The posting should say who that is. Three options, all legitimate.

1. This role owns the policy layer and has authority to set it. Say so, and say who backs them when a team escalates.
2. This role reports on cost and recommends. Platform or FinOps owns enforcement. Also fine. Say it.
3. Nobody owns it yet and part of this job is establishing that. Real job, interesting to the right person, completely different sell.

The insurance carrier from the top of this page was option three, described in the posting as option one, and discovered by the candidate as neither. That is the failure mode. Not the money, not the stack, not the interview process. A quiet mismatch between the mandate on paper and the authority in the building.

The Certification Lines That Are Quietly Wrong

Copy-paste has done real damage to this corner of the job market, and it is worth thirty seconds of your time to fix.

Go look at the current Databricks certification catalog before you write a requirements line. As of 2026 the certifications are Data Engineer Associate and Professional, Machine Learning Associate and Professional, Data Analyst Associate, Apache Spark Developer Associate, Generative AI Engineer Associate, and Context Engineer Associate. Platform Administrator and the three cloud-specific Platform Architect credentials are accreditations, which is a different track. The Hadoop Migration Architect certification was retired on August 1, 2024, and that has not stopped it appearing in postings written since.

Three things follow.

Requiring a credential that no longer exists is a small error with an outsized signal. Every qualified candidate who reads it concludes the posting was assembled from an older posting, which means nobody senior looked at it, which means the interview loop is probably improvised too. They are not always wrong about that.

Be careful what you make mandatory, too. The Data Engineer Professional exam is a real filter and the people who hold it are generally good. Plenty of the best Databricks engineers we place have never taken it, because their employer paid them to ship instead. Listing it under preferred costs you nothing. Listing it under required costs you a chunk of the pool for a signal you can get in twenty minutes of technical conversation.

And the vocabulary moved out from under your posting. Delta Live Tables is now Lakeflow Declarative Pipelines, part of a Lakeflow umbrella that also covers Connect for managed ingestion and Jobs for orchestration. Same product, same code, new name. Write both for a while. “Lakeflow Declarative Pipelines (formerly Delta Live Tables)” reads as current to people who follow the platform closely and stays searchable for everyone who does not.

The Title String Is a Budget Decision

Here is something odd, and it costs companies real money.

Search the exact phrase “Databricks engineer” on the salary aggregators and you get a soft number. ZipRecruiter had the average at $111,632 in February 2026. Middle of the distribution, $80,500 to $132,500. Ninetieth percentile, $162,000. Glassdoor lands close by at around $114,110. Set your band off those and you will feel like a responsible steward of the budget right up until the third finalist declines.

Now look at where the neutral occupational data sits. O*NET puts database architects at a $139,500 median for 2025, with no stock in the number and every employer in the country blended into one figure. Data scientists sit at $120,230, with 23,400 job openings projected each year through 2034. Our own placed-base median on senior Databricks hires ran $168,000 over the two quarters before this was written, base only, no equity and no signing bonus.

The aggregator number is not wrong. It is measuring a population that includes a lot of people with Databricks listed as one skill among nine on a general data engineering résumé. The person you are actually competing for is being paid against a platform specialist band, and the title string you type decides which of those two markets your posting lands in.

Post the range. Pay transparency law now covers a growing share of the country, this pool trades numbers openly on forums nobody in your building reads, and a published band screens harder than any question you could write into a phone interview. The Databricks engineer salary guide splits the sources apart by level, city, and specialization. For a number priced against your specific scope, the salary benchmark assistant takes a couple of minutes and does not hand you to a salesperson.

Databricks Engineer Job Description Template

Brackets mark the decisions. Every one of them is a question a good candidate asks you eventually, so answering them now is the cheap version. Strip the bracketed notes out before the posting goes live.

Job Title

[Databricks Engineer (Azure) / Databricks Data Engineer / Senior Databricks Platform Engineer] [Cloud goes in the title. It filters harder than any bullet underneath, and it is how people search.]

About the Role

[Company] runs a lakehouse on [Azure / AWS / GCP] behind [what the data is actually for: claims analytics, supply chain forecasting, clinical reporting, customer 360], and we are adding a Databricks engineer to [team]. The platform is [N] workspaces on [Unity Catalog / a mix of Unity Catalog and the legacy Hive metastore], ingesting from [the two or three sources that matter] at roughly [volume]. This seat sits under [role], next to [analytics engineers, data scientists, the platform team, and the people whose priorities it will have to reconcile].

Where the Platform Stands Today

[This section is what separates your posting from everyone else’s. Four honest sentences.]

[Unity Catalog status: fully migrated, partially migrated with X teams still on the legacy metastore, or not started.] [Orchestration: Lakeflow Jobs, Airflow, Azure Data Factory, or a combination nobody planned.] [Deployment: bundles and CI, or notebooks promoted by hand.] [Streaming: in production, or batch only today.]

What You Will Build and Run

• [Ingestion and transformation across the medallion layers using PySpark and SQL, with [Lakeflow Declarative Pipelines (formerly Delta Live Tables) / Auto Loader / Structured Streaming] where it fits]
• Data quality and reliability for [the specific pipelines that matter], including what happens when an upstream source changes shape without telling anyone
• [Unity Catalog objects and permissions for [scope], including external locations and storage credentials]
• [Cost. Cluster and warehouse sizing, policy compliance, and tagging so spend lands against the right team.] [If this role does not own cost, cut the line rather than softening it.]
• Promotion and release. [Asset bundles defined in databricks.yml and deployed through [CI system], or today this is manual and improving it is part of the job]
• [If ML is in scope: feature tables, MLflow tracking, and model serving for [what]]
• Working with [analysts / scientists / product] on what the gold layer is supposed to mean, which is more of this job than the bullet above it suggests

Required Experience

• [3+] years shipping data pipelines other people depended on, [2+] of them on Databricks. Production, not a certification course and a weekend project
• PySpark and SQL at a level where you can explain why a job is slow. Partitioning, shuffles, skew, file sizing, and when Photon does and does not help
• Delta Lake in anger. Merges, time travel, OPTIMIZE and Z-ordering or liquid clustering, and an opinion about small files
• [Your cloud.] [Azure: Entra ID, ADLS Gen2, and networking you do not have to start from scratch on. AWS: IAM, S3, instance profiles.]
• Judgment about cost. [A candidate who asks what the monthly bill looks like before proposing an architecture has told you something useful.]
• [Unity Catalog experience, if you are mid-migration. Say migration experience explicitly. Using it and moving to it are different résumés.]

Things That Help

• Streaming in production. Kafka, Event Hubs, or Kinesis into Delta, running unattended, with a real answer about late-arriving data
• dbt on Databricks, but only if that is genuinely how your gold layer gets built today, because dbt is currently the most-listed skill on these postings that turns out on inspection to be something the team intends to adopt at some point rather than something anybody there has run
• [Your industry.] Regulated data carries its own rules, and a healthcare or financial services background shortens onboarding measurably
• Databricks Certified Data Engineer Professional [preferred, never required]
• A migration they have already survived. Hadoop, Synapse, on-premises Spark, or an earlier Databricks estate. Scar tissue is the qualification here

Compute, Cost, and On-Call

[Do not bury this in a benefits list.]

[The platform runs roughly [$X] a month in Databricks spend today. This role [owns the policy layer / reports and recommends / helps establish ownership].] [On-call is [X] weeks in [Y] and covers [what breaks]. Last quarter it fired [honest number] times.] [Pipelines run [when], and the deploy window is [when].]

Compensation

Base range of [$XXX,000 to $XXX,000]. [Bonus target], [equity], [benefits]. [Onsite, hybrid at N days in the [city] office, or fully remote inside [region].] [Publish it. Where a mid-migration scope or real streaming depth pushes the top of the band, say so here rather than at offer stage.]

Before You Hit Post

We posted for a Databricks engineer and got two hundred résumés with no Databricks on them.

The word appeared in a bullet rather than in the title, and the rest of the requirements read as a generic data engineering list. Job boards match titles aggressively. Candidates filter the same way.

Check the second thing too. If your requirements say “Databricks, Snowflake, Redshift, or similar,” you have told everyone the platform is negotiable, and they believe you. If it genuinely is negotiable, that is a legitimate decision and you should own it. If it is not, cut the “or similar” and watch applicant quality change without the volume changing much.

Does naming the cloud in the title narrow the pool too far?

It narrows the pool and improves it at the same time, which is what filtering is supposed to do. In a deep market like Azure Databricks, the named-cloud posting usually draws fewer applicants and more finalists.

The exception is a genuinely small local market. If you are hiring on site in a metro without much Databricks density, naming the cloud on top of naming the platform can leave you with nobody. In that case keep the cloud out of the title, put it in the second paragraph, and be explicit that you will pay for the ramp. Decide which one you are doing rather than leaving it ambiguous and hoping.

Everyone lists Databricks now. What separates the line item from real production time?

Ask what broke. Anyone who has run Databricks in production has a story about a job that ran fine for four months and then did not, and they can tell you what the fix cost.

The tells come out fast. Real operators go to file sizes almost immediately. Or to a merge that got a little slower every week for two months until somebody finally opened the job history and found out why, which is a story with a date and a number in it. They will separate a cluster that was undersized from a query that was badly written without being prompted, and at least one candidate in your loop will tell you about the month autoscaling did exactly what it had been configured to do and the invoice arrived to prove it. Résumé Databricks describes the platform in the vocabulary of the marketing site. Neither group is lying. One of them has been on call.

Our band came from a “Databricks engineer” salary search and the good ones stopped replying.

That search returned a general population with Databricks as one listed skill. Platform specialists price against a different band, commonly $40,000 to $50,000 higher at the senior end.

Rebuild the number from the scope instead of the title. A mid-level engineer building batch pipelines inside a settled Unity Catalog estate is a different budget from a senior who will finish your migration while production keeps running. Both are Databricks engineers. Both apply to the same posting. Only one of them accepts a band set from an aggregator average.

We cut over off Hadoop in twelve weeks. Hire, or borrow?

Both, in that order. Cutover demand spikes and then falls away. Running the platform afterward does not. Treat them as one req and the second search starts two months behind.

Staff the cutover itself with contract Databricks engineers and open the permanent search alongside it for whoever owns the platform in year two. Your permanent engineer then starts while the cutover crew is still on site, learning the estate from the people who moved it rather than from a wiki page written on somebody’s last Friday. It also lets you scope that role against the platform as it actually lands, which is never quite the platform that was drawn in the plan.

The req has been open ninety days and the posting looks fine to us.

Read it as a candidate who already has a job. If nothing in the first two paragraphs tells them something they could not have guessed, there is no reason to keep reading, and they do not.

Postings that stall are rarely bad. They are usually generic in a way that is invisible from the inside, because everyone writing them already knows the context that got left out. Ninety days is also long enough that the band has drifted underneath you. Check it against a current source before assuming the problem is the words.

If You Only Change One Thing

Add the paragraph about your platform. Not the responsibilities, not the skills list. The four sentences that say what state Unity Catalog is in, how pipelines get deployed today, what the monthly compute spend looks like, and who is allowed to change it.

Every strong Databricks candidate is trying to work that out during your interview process anyway. Some of them ask. The ones who do not ask will guess instead, and a wrong guess in either direction costs you the hire, either at the offer stage where you can at least see it happening or in month four where you cannot. Putting it in the posting turns a screening problem into a self-selection problem. Self-selection is free.

Then look at the loop. A posting that scopes the seat correctly sends you candidates a generic Databricks interview cannot tell apart, and our Databricks interview question guide covers what to ask once they are in the room.

If the req has been open a while and you would rather hand it to somebody who has run this search before, our Databricks recruiters do this specific work, and you can start a conversation here. We also run Snowflake and general data engineering desks, which is the honest reason we can tell you when a Databricks title is the wrong one for what you just described. Twelve-month retention on our placements runs 92%. We fill the average req in 17 days.