Last updated: August 1, 2026
By Mike Carter, Director of Partnership Success, KORE1
A strong analytics engineer job description names the warehouse, the transformation tool, the size of the existing dbt project, and a real salary band inside the first hundred words. Everything after that is filtering. The template below is copy-and-paste ready, and the notes in parentheses tell you what to change and why.
I read job descriptions the way I used to read landing pages. Same job, honestly. You have a headline, a value proposition, a proof section, and an ask, and you get about eleven seconds before the reader decides whether you are worth the scroll. Most analytics engineer postings fail at the headline. Some fail earlier.
They fail in a specific way, too. The title says analytics engineer. The body describes a data engineer. The requirements list belongs to a BI developer. And the salary band, when there is one, was copied off a role that closed in 2023, back when the market was a completely different shape and half the people you are competing with for this hire had not started their dbt projects yet.
Quick note on who is talking, because it should change how you weigh this. I run partnership success at KORE1, which means I spend most of my week with founders, VPs of data, and the occasional CFO who has just discovered that nobody can agree on what revenue means. We staff these roles through our analytics engineer staffing desk inside a data engineering and data science practice we have been running since 2005, and yes, we get paid when you hire somebody we sent. The template further down costs nothing and works fine without us. Take it. Post it. If it fills the seat on your own, that is a good outcome and I would rather you have it.

Four Different Jobs Wear This Title
Analytics engineer covers at least four distinct jobs: greenfield builder, maintainer of an existing dbt project, embedded analyst-engineer inside a business function, and platform owner who also handles orchestration and ingestion. Each one attracts a different candidate and prices differently.
Before you write anything, pick one. Just one. This is the step people skip, and skipping it is why a posting pulls ninety applicants and three interviews.
| Flavor | What the day looks like | Who you want |
|---|---|---|
| Greenfield builder | Stands up the dbt project, picks the modeling convention, wires CI, argues about naming | Someone who has done it before, start to finish, at least once. Opinions required. |
| Maintainer | Inherits 300 to 600 models, fixes tests, refactors the mart layer, keeps runs under an hour | Patience and a refactoring instinct. Very different personality from the builder. |
| Embedded | Sits with finance or growth, owns their metric layer, is in their standup, not yours | An analyst who learned engineering. Domain fluency beats SQL elegance here. |
| Platform owner | dbt plus Airflow or Dagster, plus ingestion, plus warehouse cost, plus access control | This is a data engineer. Pay accordingly, and consider retitling the req. |
That last row causes more grief than the other three combined. A client in Costa Mesa spent five weeks last spring interviewing for what they called an analytics engineer. Every finalist walked at the offer stage. When we finally read the actual req instead of the title, it wanted Airflow DAG ownership, Fivetran connector debugging, Snowflake role hierarchy design, and dbt on top of all of it. That is a senior data engineer with a modeling specialty. The band was set forty thousand dollars low because the title said analytics. We retitled it, moved the band, and it closed in nineteen days. Same pipeline. Same recruiters. Same market. The title and the number were the entire problem, and neither one of them had anything to do with the quality of the candidates we were sending in the five weeks before that.
If you want the longer treatment of where the line sits, we wrote one: data engineer vs analytics engineer. The short version is that analytics engineers own the transformation layer and the semantics on top of it. When ingestion and orchestration land on the same person, you have quietly written a different req.
Set the Band Before You Write a Word
Salary data for this title is a mess, and the mess tells you something. Glassdoor reads the U.S. average near $155,700 as of mid-2026. Middle of the market, roughly $128,800 to $190,900. ZipRecruiter, looking at the same two words in July 2026, lands at about $109,100.
Forty-six thousand dollars apart. Both defensible.
Glassdoor leans on self-reported total compensation, which skews toward venture-backed companies in expensive metros. ZipRecruiter reads posted base salaries across every ZIP code in the country, including the hybrid role at a mid-size insurer in Columbus that nobody blogs about. Neither number is your number. Your number depends on the flavor you picked above, your metro, and whether you are quoting base or base plus bonus plus equity, and if you post the wrong one you will find out at the offer stage, which is the most expensive place in the process to find anything out. We have eaten that one more than once.
| Level | Experience | Typical base (US) | What the band buys |
|---|---|---|---|
| Associate | 0 to 2 years | $95K to $120K | Writes models under review, learning the testing discipline |
| Mid | 2 to 5 years | $115K to $155K | Owns a domain end to end, reviews other people’s SQL |
| Senior | 5 to 8 years | $155K to $200K | Sets modeling standards, owns the semantic layer, mentors |
| Staff or Lead | 8 years and up | $195K to $245K plus | Architecture across teams, often the first analytics engineering hire |
These match the bands in our guide to hiring an analytics engineer, which goes deeper on metro adjustments and the premium for genuine dbt-at-scale experience. If you want a live read on your specific market before the req goes up, the salary benchmark assistant is faster than clicking through aggregator pages for an hour.

The Analytics Engineer Job Description Template
Copy the block below. Replace anything in brackets. Delete whole sections that do not apply, because a shorter posting that is entirely true beats a long one that is half aspirational. The italic lines in parentheses are notes to you, not to candidates. Pull them out before you publish.
Job Title
[Analytics Engineer / Senior Analytics Engineer / Staff Analytics Engineer / Analytics Engineer, Finance]
(Use the plain title. “Data Ninja” and “Insights Alchemist” do not get indexed by the job boards candidates actually search, and they signal that the rest of the posting will also be unserious. If the role is embedded with one function, put that function in the title. It raises quality and lowers volume, which is the trade you want.)
About the Role
(Two or three sentences. Who they report to, what data platform, what the work powers. No mission statement. Nobody has ever accepted an offer because of a mission statement.)
[Company] is hiring a [title] to own the transformation layer in [Snowflake / BigQuery / Databricks / Redshift] and the metrics that [executive reporting / product analytics / the finance close] runs on. You will work in [dbt Core / dbt Cloud] alongside [Fivetran / Airbyte / Airflow / Dagster] and report to [Analytics Manager / Head of Data / Director of Data Engineering]. This role is [remote within the U.S. / hybrid, two days a week in {city} / onsite in {city}].
Where the Project Stands Today
(This section is the one nobody includes and every serious candidate wants. Four lines. It is the single highest-signal thing you can add, and it costs you five minutes.)
(Be honest in that last bullet especially. The dbt Labs 2025 State of Analytics Engineering report surveyed 459 data practitioners and leaders, and 56% of them named poor data quality as their most frequently reported challenge. So your candidate is already assuming there is a mess. Naming yours out loud costs you nothing and buys you a little credibility.)
- Warehouse: [Snowflake, roughly {X} TB, {Y} monthly credits]
- dbt project: [greenfield / about {N} models, {M} sources, {P} tests / two projects being merged]
- Team: [{N} analytics engineers, {N} analysts, {N} data engineers, reporting into {org}]
- Known problems we would want you to fix: [the run takes 90 minutes, the mart layer has four definitions of active customer, nothing is tested downstream of staging]
What You Will Own
(Six to eight lines, each one a task rather than a virtue. “Ensure data quality” is a virtue. “Write dbt tests that fail the build on a null in the grain” is a task. Candidates can picture the second one.)
- Design and ship dbt models across staging, intermediate, and mart layers, owning naming conventions, incremental strategy, and materialization choices
- Write and maintain tests that gate the pipeline, including uniqueness, referential, and freshness checks on [the models finance and leadership depend on]
- Own the definitions behind [revenue, active user, churn, pipeline], including the boring part where you get three departments to agree on one of them
- Build and maintain the semantic layer in [dbt Semantic Layer / Looker / Cube / Power BI], keeping metric logic in one place instead of nine dashboards
- Review SQL from analysts and junior engineers, and raise the floor on the SQL that reaches production
- Document lineage and model intent so an analyst can answer their own question without pinging you on Slack
- Partner with [data engineering / platform] on ingestion contracts and schema changes upstream of your models
- Watch warehouse spend on the models you own, and fix the query that quietly costs $900 a month
What You Bring
(Split required from preferred, then move half of what you wrote under required down to preferred. Every honest cut widens the pool. Every fake requirement screens out somebody who would have been up to speed in a month.)
Required
- [2-4 / 4-7 / 7+] years writing SQL against a cloud warehouse in a production setting
- Hands-on production experience with dbt, meaning models you built and still maintain, not a tutorial project
- Dimensional or wide-table modeling experience, and an opinion about which one fits which problem
- Git-based workflow with pull requests and code review as normal practice
- The ability to sit with a stakeholder, hear “our numbers look wrong,” and turn that into a defined problem
Preferred
- Python for the parts SQL handles badly, plus orchestration exposure in [Airflow / Dagster / Prefect]
- Experience in [{your warehouse}] specifically, including its cost model
- Semantic layer or metrics layer work in [dbt / Looker / Cube]
- Data quality tooling beyond dbt tests ([Elementary / Monte Carlo / Great Expectations])
- Domain background in [fintech / healthcare / e-commerce / manufacturing]
(Notice what is missing. There is no computer science degree requirement, because a large share of the strongest analytics engineers came up through analytics and picked up the engineering practices on the job. Gate on the degree and you screen out a good chunk of your best applicants for a credential the work does not need.)
Compensation and Benefits
(Post a real range. In much of the country you are legally required to, and everywhere else the best candidates skip postings without one because they have options and no interest in guessing.)
- Base salary: $[X] to $[Y], set by level and depth rather than by negotiation stamina
- [Equity, bonus target, 401(k) match, remote stipend, learning budget, conference travel]
- [Anything genuinely unusual about how your team works: no-meeting Wednesdays, a real on-call rotation or none at all, four-day summer weeks]
About [Company]
(Three sentences. Product, stage, and data scale. “We process 40 million events a day across 900 enterprise accounts” tells this audience more than a paragraph about your values ever will.)
How to Apply
(Say what the process actually is and how long it takes. This is the cheapest trust signal in the entire posting, and almost nobody uses it.)
[Send a resume to {address} or apply at {link}. Our process is a 30-minute intro, a 60-minute SQL and modeling conversation using a sample of our real schema, a 45-minute stakeholder conversation, and a decision. We aim to go from first call to offer in under three weeks, and we tell you either way.]

Lines to Cut From Whatever You Are Using Now
Some of these are in your current posting. I would bet on it.
The degree line goes first. Bachelor’s in computer science or a related field, stamped under required, usually by somebody who inherited the template from a software req in 2019 and never reopened the question. Analytics engineering grew out of analytics. Not out of CS programs.
“Passion for data.” Everyone writes it. Nobody has ever been screened out by it. Cut it and you lose nothing.
Then there is the responsibilities list that runs to fourteen bullets because three stakeholders each added their own. A candidate reads fourteen bullets and correctly concludes the role is undefined. Eight is the ceiling. If you cannot get under eight, the problem is not the job description.
“5+ years of dbt experience.” Do the arithmetic on this one. dbt was open-sourced in 2016 by the consultancy that later became dbt Labs, and production adoption outside a narrow circle of early companies did not really arrive until 2019 through 2021. Requiring seven or eight years of it in 2026 means you are fishing in a pond of maybe a few thousand people nationwide, most of whom are employed and content. I have watched a req sit open for four months on a requirement the hiring manager had never actually checked the math on, and when we finally walked through the dates together on a Tuesday afternoon call, the whole thing came down in about ninety seconds. Four months of open req, undone in a minute and a half of arithmetic.
Last one, and this is the subtle one. Anything phrased as “must be able to work in a fast-paced environment” reads to an experienced candidate as “we have no process and the on-call rotation is a group chat.” Maybe unfair. It is still how it lands, and the people you most want to hire have been burned by that sentence before.
The Salary Range Is Not Optional in Most of the Country
Eighteen states and Washington, D.C. regulate pay transparency, and roughly a dozen of them, California and Colorado and New York among them, require a good-faith salary range inside the posting itself.
The full posting-range list runs through Hawaii, Illinois, Maine, Maryland, Massachusetts, Minnesota, New Jersey, Vermont, and Washington as well. Connecticut, Nevada, and Rhode Island take a softer line and only require the number on request or before an offer. Delaware is next up, with a law signed in September 2025 that switches on in September 2027 for employers with 25 or more people, which means anybody building a hiring process this year should probably just plan for it now rather than doing this twice.
Penalties swing from a hundred dollars to a quarter of a million depending on where you are standing, and the details are genuinely fiddly, so check your own jurisdiction rather than trusting a summary in a staffing blog. Including this one. Go look at what the New York State Department of Labor publishes if you want a sense of how far into the weeds the wording rules go.
Here is the part that matters more than compliance anyway. If you post remote-friendly, you are almost certainly subject to the strictest state your candidate pool touches. And even in a state with no requirement at all, a posting without a range gets fewer strong applicants, because senior people triage. They have four tabs open. Yours is the one without a number.
Adapting the Template
Three variations come up constantly on intake calls.
Contract or contract-to-hire. Swap the compensation section for an hourly range and state the duration and extension likelihood honestly. Analytics engineering contracts land in a wide band depending on stack and market. Add a line about whether the contractor will have production merge rights, because that single detail changes who says yes. More on the models themselves in contract staffing.
First data hire. If this person is employee number one on data, say so in the second sentence and rewrite “What You Will Own” to include the unglamorous parts. Picking the warehouse. Setting up Fivetran. Explaining to the exec team why the dashboard was wrong for six months before they got here. This role attracts a specific kind of person and repels everyone else, which is exactly what you want.
Embedded in a function. Name the function in the title, name the stakeholders in “About the Role,” and cut the platform bullets entirely. An embedded analytics engineer in finance needs to know what a deferred revenue schedule is, needs to survive a close week without breaking anything, and needs to be the kind of person who enjoys being the only technical voice in a room full of accountants. Nobody in that role cares whether they can tune a warehouse. Different job.
What Hiring Managers Ask Us About These Postings
Should the title say analytics engineer or analytics developer?
Analytics engineer. It is the term candidates search, the term dbt Labs standardized, and the one that pulls the right resumes. Analytics developer reads like a title written by a company that has never hired one of these before, and while that is an unfair inference for a candidate to draw from two words on a job board, they draw it anyway and you never hear about the ones who scrolled past.
Is dbt actually required, or is that just the fashion?
If you run dbt, require it. If you do not, requiring it costs you good people. Strong analytics engineers using Dataform, SQLMesh, or a well-organized set of orchestrated SQL transformations pick up dbt in a couple of weeks. What you should actually screen for is whether they have worked in a tested, version-controlled transformation layer at all. Someone who has only written ad hoc queries in a BI tool is a different hire, and no amount of dbt training closes that gap quickly.
How specific should the tech stack be in the posting?
Name every tool the person will touch weekly. Vague postings pull volume, specific ones pull fit, and volume is not the goal. There is a real cost to specificity, which is that you will get fewer applicants and the pile will look thinner in your ATS. Sit with that. Twelve applicants who have run a tested dbt project on your warehouse make for a far better week than ninety who have written SQL somewhere.
We already posted and got nothing usable. What now?
Nine times out of ten the range is wrong, the title does not match the body, or the requirements quietly describe a data engineer. Go read your own posting the way a candidate would. On a phone. At eleven at night, next to three other tabs. Then fix the one thing that is broken and repost it, instead of layering a second req on top of the first one and splitting your own applicant pool in half. If two rewrites have not moved it, the market is telling you something about the band.
How long does it take to fill one of these once the posting is right?
Our average across IT roles is 17 days from intake to accepted offer, and analytics engineer searches land close to that when the req is scoped cleanly. Add two weeks if the stack is unusual, if the band sits below market, or if the interview loop has five rounds. Nearly every long search we have run traces back to one of those three, and every one of them is sitting right there in the job description weeks before a candidate ever reads it, which is a frustrating thing to notice in week seven and a cheap thing to fix on a Tuesday.
Do we interview differently for an analytics engineer than a data analyst?
Yes, and the difference is code review. Analysts get evaluated on the answer. Analytics engineers get evaluated on whether somebody else can maintain the thing that produced the answer. We pulled the loop apart question by question in our analytics engineer interview questions guide.
Next Steps
Take the template. Cut it to what is true, put a real number in it, and post it. That alone puts you ahead of most of what is on the job boards this week.
If the seat has been open a while, or if you would rather not run the search at all, that is what we do. KORE1 has been placing data and IT talent since 2005, we work across 30-plus U.S. metros, and our placements hold at a 92% twelve-month retention rate, which is the number I care about more than time-to-fill because it means we scoped the role right in the first place. Our recruiters on this desk average 15-plus years in the market. You can talk to a recruiter about an open analytics engineering req, or start with direct hire staffing if you already know what shape the role needs to take.
And if you post it yourself and it works, tell me. I collect those.

