Analytics Engineering: The Complete 2026 Guide (Role, Skills, Salary, Path)

Analytics engineering went from a niche title inside a few Silicon Valley data teams in 2018 to one of the most-searched career pivots in data by 2026. To research what the role actually looks like today, we read the three State of Analytics Engineering reports from 2023 to 2025, pulled compensation data from Levels.fyi and Glassdoor, worked through public job postings, and read what working AEs at GitLab, dbt Labs, and various independent Substacks were writing.

Woven through the guide, we’ve captured the perspective of Eric Provencio, founder of Analytics Engineering and a working analytics engineer with seven years of experience. What follows is what we found.

What Analytics Engineering Actually Is

An analytics engineer owns the transformation layer of a modern data stack. That is the layer sitting between raw data landing in a warehouse and the tools that analysts, product managers, and executives use to look at it.

Raw data arrives messy. Customer records from a CRM look different from customer records in a billing system. Product events fire with inconsistent naming. Two SaaS tools disagree about what a “trial” means. The analytics engineer’s job is to reconcile all of that into clean, tested, documented tables that everyone downstream can trust.

In practice, this means writing SQL transformations in tools like dbt, defining data models that reflect how the business actually thinks about itself, writing tests that catch broken data before a business user finds it in a dashboard, and documenting everything so a new analyst can find their way around without asking questions. For a shorter definitional overview, see what analytics engineering is.

The 30-second version:

• What they build: clean, modeled, tested tables in a data warehouse that downstream analysts and applications can query with confidence.

• What they use: SQL, dbt, one cloud warehouse (BigQuery, Snowflake, or Redshift), Git, and a BI tool.

• Who they work with: data analysts and BI teams downstream, data engineers upstream, and business stakeholders in every direction.

• What sets them apart: software engineering practices applied to analytics. Version control, code review, automated testing, and living documentation.

Claire Carroll, who was among the first to publicly define the role in 2019 while at dbt Labs, put it this way: analytics engineers spend their time transforming, testing, deploying, and documenting data so that analysts can spend their time answering questions.

The most common misread of the role, from inside the job:

From Eric

The biggest misconception is that people think it is a purely technical role. Analytics engineers typically sit alongside the business and serve as the intermediary between engineers and non-technical stakeholders.

The role requires soft skills just as much as it requires technical skills. In my experience, some of the best analytics engineers started as data analysts and then leveled up their technical abilities.

Whether you are already doing analytics engineering work under a different title is worth asking. If you spend most of your week writing SQL that other analysts will query, worrying about how to model a metric consistently, or reviewing another engineer’s pull request against a data warehouse, you are doing it. The title just has not caught up to the work yet.

Where The Role Came From

Between 2012 and 2018, three shifts changed data work. Cloud warehouses like Redshift, BigQuery, and Snowflake made storage and compute cheap. Managed ingestion tools like Fivetran and Stitch turned data extraction into a click. And BI tools like Looker and Mode put query-writing power in the hands of business stakeholders.

Getting data in became easy, and getting it out became easy, but the transformation layer in between was still hard and neither engineers nor analysts were quite the right fit for it. In 2018, dbt Labs and the Locally Optimistic community started calling that middle-layer role “analytics engineer.” The title stuck.

Analytics Engineer vs Data Analyst vs Data Engineer vs BI Developer

The clearest way to understand analytics engineering is to see it next to the roles it borders.

Analytics engineer vs data analyst. Analysts consume data to answer questions. AEs produce data so that other people can answer those questions faster. An analyst lives in Tableau or Looker; an AE lives in a code editor. Most AEs started as analysts. For a deeper breakdown of the boundary, see our comparison of analytics engineer vs data analyst.

Analytics engineer vs data engineer. Both write code, both use Git, both care about testing. Data engineers own the pipelines, orchestration, streaming infrastructure, and the platform. Analytics engineers own what happens once the data lands in the warehouse. In small teams these roles blur. At scale, they diverge sharply.

Analytics engineer vs BI developer. BI developers build the layer analytics engineers hand data to. In larger teams running Looker, BI owns the LookML layer while AEs own the underlying dbt models. If you are a BI developer who has started writing dbt models to fix what LookML alone cannot clean up, you have quietly become an analytics engineer.

The State of Analytics Engineering 2025 report, which surveyed 459 practitioners, noted that a majority of AEs still do some analysis work and a growing minority take on light data engineering when their team is small. The role has a center of gravity more than a hard boundary.

A Day In The Life Of An Analytics Engineer

The best way to answer “what does the job actually feel like on a Tuesday” is to hear it from someone who has spent seven years doing it.

From Eric

A typical Tuesday might start with 30 minutes of standup on Zoom, followed by about three hours of heads-down modeling, one to two hours of meetings, and 45 minutes reviewing PRs. Then, all of a sudden, I am being tagged in four different Slack channels because our anomaly alerts are showing duplicates in production data and revenue suddenly looks like it has doubled.

We trace it back to engineering emitting a new event without the proper duplication guards, and now we have to fix the data while figuring out which downstream dashboards and reports were affected.

In another case, we had an internal disagreement over what “revenue” actually meant. Our centralized definition excluded tips, while another team included tips and used the higher number because it made their team’s performance look better. The disagreement eventually reached the CFO, and that team was later no longer part of the company.

Situations like that are why centralized metrics and clearly governed definitions matter so much. Analytics engineering is not just about writing SQL. Sometimes you are establishing the numbers the company uses to make decisions.

The pattern in that day, and this is what State of Analytics Engineering survey respondents consistently report, is that only a minority of an AE’s time gets spent writing production code. Most of it goes to reviewing others’ code, defining metrics, resolving disputes, and writing documentation. If that reads as a downside, this is not your role. If it reads as leverage, it might be.

For a more granular walkthrough of an analytics engineer’s role responsibilities, our linked article breaks the work into named categories.

The Skill Stack

We reviewed public analytics engineer job descriptions from companies including GitLab, Netflix, Airbnb, Peloton, Notion, Stripe, and Ramp. The skills below are ordered by how often they show up as hard requirements.

SQL Fluency

SQL is the floor. Every AE job description we saw required it, most at an advanced level. The bar is not “can you write a query.” The bar is “can you write a query that handles a slowly changing dimension, deduplicates a stream of events, and does it in a way that does not scan the entire warehouse.”

Suppose you have a stream of order updates and you need the most recent status per order. A junior analyst reaches for a subquery. An analytics engineer writes:

select
  order_id,
  customer_id,
  status,
  updated_at
from order_events
qualify row_number() over (
  partition by order_id
  order by updated_at desc
) = 1

The QUALIFY clause, supported in Snowflake, BigQuery, and Databricks, filters window function results without a subquery. It reads cleanly, runs efficiently, and tells the next person reading the code exactly what you meant. That is the level assumed when a job description says “advanced SQL.”

Data Modeling

Modeling is the part that separates senior AEs from mid ones. The core patterns come from dimensional modeling in the Kimball style: star schemas built from fact and dimension tables, and slowly changing dimensions for tracking history.

A simple customer dimension model looks like this:

select
  customer_id,
  first_name || ' ' || last_name as customer_name,
  email,
  signup_date,
  customer_segment,
  lifetime_orders,
  lifetime_revenue,
  _dbt_updated_at
from {{ ref('int_customers_enriched') }}

The corresponding orders fact model joins to it on customer_id. Modeling is not really about the SQL. The hard work is deciding what belongs in the fact table (measures, foreign keys) versus the dimension (attributes, descriptions), and getting that right so downstream queries stay fast and analysts can find what they need without reading source code.

dbt

dbt is the transformation framework analytics engineers ship every day. At minimum, you should know models, sources, refs, tests, snapshots, and macros. A production dbt model rarely looks like the getting-started tutorial. Here is closer to what you would actually write:

{{ config(
  materialized='incremental',
  unique_key='order_id',
  on_schema_change='append_new_columns',
  cluster_by=['order_date']
) }}

with source as (
  select * from {{ ref('stg_orders') }}
  {% if is_incremental() %}
  where updated_at > (select max(updated_at) from {{ this }})
  {% endif %}
),

customers as (
  select * from {{ ref('dim_customers') }}
)

select
  o.order_id,
  o.customer_id,
  c.customer_segment,
  o.order_date,
  o.total_amount,
  o.updated_at
from source o
left join customers c on o.customer_id = c.customer_id

Paired with a schema.yml that tests it:

version: 2

models:
  - name: fct_orders
    description: "One row per order, joined to customer dimension."
    columns:
      - name: order_id
        tests: [unique, not_null]
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('dim_customers')
              field: customer_id

That is what “knows dbt” looks like on a resume screen.

One Warehouse, Deep

Job postings ask for BigQuery, Snowflake, or Redshift. Which one matters less than “you know one well enough to write efficient queries and reason about cost.” Depth in one beats shallow familiarity with all three. If you do not have a preference, pick BigQuery for the free sandbox.

Git, Pull Request Hygiene, And Documentation

Every AE job description we scanned mentioned Git as a hard requirement. Not “have you used it,” but “do you know how to branch, open a PR, resolve a merge conflict, and write a commit message someone else can read.” Documentation shows up less as a stated requirement and more as a hiring differentiator.

The AE whose PRs explain the why and whose Slack messages are readable at 6pm on a Friday is the one who gets referred internally when the next role opens.

The Tools And What It Costs To Start

Analytics engineering has a nearly free onramp, which most career-guidance content skips right past.

The full stack, from zero to a job-ready portfolio project, costs zero dollars. You can run a real dbt project against BigQuery, push it to a public GitHub repository, build a Looker Studio dashboard on top of it, and interview for analytics engineer roles without paying for anything. The claim that you need to spend thousands to become hireable does not hold up.

Analytics Engineer Salary In 2026

Compensation for analytics engineers has held up better than most data roles through the 2024 and 2025 hiring slowdown. Combining the State of Analytics Engineering 2025 report with Levels.fyi, Glassdoor, and public job postings, the US bands look like this. Figures are in USD and reflect total compensation (base plus bonus plus equity annualized) unless noted.

Ranges are wide because the delta between company types is wider than the delta between levels.

Company type matters more than seniority. A staff AE at a post-Series-C SaaS company with real equity commonly clears $260k total comp. Netflix analytics engineers report median total compensation of $375k on Levels.fyi. The same senior title at a healthcare, insurance, or industrial company will be closer to $180k with no equity worth mentioning.

From Eric

Tech-first companies generally pay more than traditional or mid-tier companies, and the difference is not always just base salary. Tech companies can offer larger bonuses, with around 10% being fairly common, along with equity on top of cash compensation. Stock at a successful public company can become a meaningful part of your total compensation.

Private-company equity is much more uncertain because you could get very lucky, or the shares could ultimately be illiquid or worth very little. Look at the entire package: base salary, bonus, equity, workload, expectations, and company stability, rather than comparing jobs based on base salary alone.

Remote does not mean pay cut. State of Analytics Engineering 2025 respondents working fully remote reported medians within a few percentage points of onsite peers at similar seniority. Remote-first companies like GitLab, Zapier, and Automattic typically pay at parity or close to it. Aggressive geo-adjustment is now a hiring disadvantage in this market.

International remote is different. European AE salaries at local companies run 30% to 50% below US bands. AEs employed by US companies through EOR providers often close about half that gap.

Where AE sits relative to adjacent roles. AEs came in above data analysts (typically $20k to $40k higher at the same seniority) and slightly below data engineers ($10k to $25k lower). Data scientists are roughly at parity in aggregate, but bimodal: ML-heavy DS roles at big tech pay materially more; product-analyst-style DS pays less than AEs.

If those numbers justify the effort for you, the full course is built as the fastest defensible path from where you are now to a job in one of the bands above.

How To Become An Analytics Engineer: The Three Paths

Before the tactical breakdown, one honest note on how long this actually takes.

From Eric

I wish I had understood how much time it takes to fully grasp and internalize all of the concepts involved in analytics engineering. Early in my career, I often felt discouraged because everything seemed so complicated, and I regularly felt like a fish out of water even though I was learning and working eight to ten hours a day.

It was not until around year four or five, and after working with a few good mentors, that I felt like I had crossed the hill and started to see how everything fit together. If I could go back, I would focus less on trying to master every individual tool immediately and more on building strong fundamentals, finding good mentors earlier, and understanding that feeling uncomfortable is part of the process.

Most people arriving at analytics engineering come from one of three starting points.

Path A: No Technical Background

Realistic timeline: 9 to 12 months at 10 hours a week.

If you are starting from zero, sequence matters. Learn SQL first. Free sandboxes and graded exercises get you to intermediate SQL in about three months. Once you can write joins, window functions, and CTEs without looking things up, move to data modeling. Learn dimensional modeling from Ralph Kimball’s original book if you are patient, or a modern condensed version if not.

At month five or six, start dbt. Learn dbt Core, not dbt Cloud, since it is free and forces you to understand the fundamentals. Build against BigQuery’s free sandbox. By month eight, you should have a complete dbt project on GitHub that reads from raw source data, models it through staging and marts layers, has tests on every important table, and drives a small Looker Studio dashboard.

Milestone check: you can walk through your GitHub project on a screenshare and explain every design decision without notes. For a more detailed breakdown of this path, see our guide to becoming an analytics engineer without a CS degree.

Path B: Data Analyst Leveling Up

Realistic timeline: 3 to 6 months at 8 hours a week.

You already have SQL. What you need is dbt fluency, modeling discipline, and Git muscle memory. In practice: pick up your current job’s messy SQL files, move them into a dbt project, add tests, version them in Git. If your company does not yet use dbt, do it as a side project first, then propose it internally.

Resume framing matters as much as the work. “Wrote SQL for stakeholder reports” becomes “modeled six-domain data mart in dbt, added 40+ tests, migrated reporting to a versioned analytics repository.” Same work, AE language.

Milestone check: you can point to a dbt project (public or referenced) with more than 20 models, tests, and documentation, and explain why you made specific modeling choices when pressed.

Path C: Software Engineer Moving Over

Realistic timeline: 2 to 4 months at 10 hours a week.

You already have Git, code review instincts, and CI/CD muscle memory. What you likely do not have is deep SQL and dimensional modeling. Do not underestimate the modeling gap. Software engineering instincts often produce over-normalized data models that analysts hate to query.

Focus on modeling first. Then dbt. SQL will come as you use it. Your interview advantage: once you have built a small dbt project, you can talk about testing, CI, and maintainability in ways many career-changer AEs cannot.

Milestone check: you can describe a modeling tradeoff and explain your choice in terms an analyst would agree with. Not just a software engineer.

Which Path Succeeds Fastest

We asked Eric, who sees all three types of candidates in his course, which starting point reaches job-ready fastest. His answer reframes the question.

From Eric

The candidates who succeed fastest are usually the ones who are capable of learning across a lot of different disciplines. Analytics engineering is not a straightforward career path. I started in chemical engineering, and I know successful analytics engineers who previously worked as teachers, biologists, and history majors, and in fields that had nothing to do with analytics.

The key differentiator is being willing to learn constantly and go outside your comfort zone. Companies also use very different technology stacks, so long-term success depends less on memorizing individual tools and more on understanding the transferable concepts behind them.

Am I Ready To Start Applying?

Regardless of which path you took, you are ready to start applying when you can honestly check all of these off:

• ✓Public dbt project on GitHub with 15+ models across staging and marts layers

• ✓Tests on core tables (unique, not null, and relationships tests where they apply)

• ✓README with a two-sentence project summary and a lineage diagram

• ✓Walked through the project on a screenshare without notes

• ✓Can explain one modeling tradeoff you made and defend the choice

• ✓Resume rewritten with AE signal words (modeled, tested, documented, versioned)

If you can check five of six, start applying while you close the last one. If you can only check two or three, you have more work before applications will convert.

The Portfolio That Gets You Interviews

We looked at publicly-shared portfolios linked from analytics engineer job applications and community discussion. A clear pattern shows up. The ones that lead to interviews all look almost identical. The ones that do not look scattered.

The project that works is a public GitHub repository containing:

The README is more important than most candidates realize. A good one opens with a two-sentence explanation of what the project does, walks through the design decisions, and includes a lineage diagram or dbt DAG screenshot. It should read as a portfolio piece for someone deciding whether to interview you, not as documentation for someone deciding whether to run the code.

The most common mistake we saw is portfolios that lead with technical output (“here is my DAG”) instead of narrative (“here is the business problem I modeled, here is why I structured it this way”). Hiring managers scan portfolios in about 90 seconds. The candidates who get callbacks are the ones whose README could survive that scan.

What not to build: Kaggle-style notebook analyses, generic Titanic projects, or ML models with no analytics engineering scaffolding. These signal “I did the beginner tutorials” rather than “I can do the job.” We’ve also got a full analytics engineering job interview kit that’s worth checking out!

If you want a structured version of exactly this project built against BigQuery with dbt Cloud, that is the capstone of the course.

What The Analytics Engineer Interview Actually Looks Like

Before the four stages, one perspective from the other side of the table.

From Eric

Having interviewed candidates for more than 50 analytics engineering positions, I look first at their depth and speed with SQL, how quickly they recognize data quality issues, and whether they think about the foundation they are building rather than just getting code to run.

I was once on an interview panel where everyone but me wanted to hire a candidate who had barely met the technical bar, even after being given extra time during the interview. I warned the team that I thought we were lowering the bar too far. The first three code contributions that person made caused production issues, and because I was on-call, I ended up being the person responsible for fixing them.

That experience reinforced something I care about a lot when hiring: analytics engineers need a foundational mindset. If you repeatedly solve the immediate problem without thinking about architecture, testing, maintainability, and data quality, technical debt compounds quickly, and so do your data transformation and infrastructure costs.

The hiring loop for AE roles has converged on four stages, usually in this order.

The SQL Screen

Live or take-home SQL against a mock schema. Expect intermediate to advanced patterns rather than obscure trivia. At least one window function question, one on joins and null handling, and one that tests whether you can spot a correctness issue in someone else’s query.

A representative question: “Given a table of customer events with a customer_id, event_type, and event_timestamp, write a query that returns the average time between a customer’s first purchase and their second purchase, excluding customers who only made one purchase.”

The correct answer uses LEAD() or LAG() window functions. If you reached for a subquery, you passed. If you reached for a self-join, you also passed. If you could not get there in 30 minutes, that is the signal the interviewer is calibrating for.

The Take-Home dbt Project

Some, not all, companies still assign a take-home. Scope is typically small: 3 to 5 models, sample source data provided, deliverable is a GitHub repository. Time expectation is stated as 4 hours but 8 to 12 is common. The evaluation criteria are correctness of modeling decisions, code readability, testing coverage, and documentation. A clean 4-model project with tests and a thoughtful README beats an 11-model project without either.

The System Design Conversation

A 45 to 60 minute conversation about a modeling problem, usually presented as an ambiguous prompt. Example: “How would you model subscriptions for a SaaS product where customers can upgrade, downgrade, pause, and reactivate?” The interviewer is not looking for the right answer.

They are looking for how you think. Do you ask clarifying questions before designing? Do you consider the grain of the fact table? Do you name the tradeoffs? Strong candidates run this like a working session. Weak candidates present a rehearsed answer.

The Behavioral Round

Standard behavioral questions with a data-team accent. Expect at least one on stakeholder conflict, one on ambiguity, and one on tradeoffs between speed and correctness.

The course capstone produces the exact portfolio artifact hiring managers screen for in this interview loop, and the interview prep module walks through each of the four stages with sample questions and worked answers.

Common Mistakes People Make Trying To Become An Analytics Engineer

One broader pattern before the specifics.

From Eric

Candidates can over-index on being able to write technically perfect SQL while under-indexing on understanding what the data actually means to the business. I have interviewed candidates who could solve almost any SQL problem I gave them but had very little understanding of how the resulting metrics would influence business decisions.

The reverse can also be a problem: someone can understand the business extremely well but create a repository full of technical debt because they lack the engineering fundamentals to build maintainable models. The best analytics engineers can move between both worlds.

The specific mistakes we saw repeatedly:

• Learning dbt before SQL fundamentals: dbt is a wrapper around SQL. If your SQL is shaky, dbt just moves your confusion into a different tool. Fix the SQL first.

• Skipping modeling because it feels theoretical: it is not theoretical. Modeling is the difference between a mid AE and a senior one.

• Building a portfolio project nobody can clone and run: if a hiring manager cannot git clone your repo and see something work in ten minutes, you have a documentation problem, not a project problem.

• Certificate collecting instead of shipping: one good GitHub repo beats three certificates.

• Memorizing tool commands over understanding concepts: candidates over-focus on specific dbt commands or warehouse syntax when the more durable skills are modeling, debugging, metric design, and understanding the grain of a dataset.

• Applying only to senior roles: most companies hire mid AEs. Filtering yourself out of 70% of the market lengthens the search by months.

• Ignoring the “write clearly” part of the job: poor writing in cover letters, READMEs, and interview responses is a stronger negative signal than most candidates realize.

What AI Does To This Role In 2026

The question most people considering analytics engineering are actually asking is: is this a role AI is going to eat?

Our read is that analytics engineering is one of the more AI-resilient roles in data. Not because AI cannot help with the work, but because the parts AI helps with are not the parts that make an analytics engineer valuable.

From Eric

AI has transformed our industry for both better and worse. For people who are already deeply technical, it has allowed us to push past previous boundaries and dramatically increase the amount of code and analysis we can produce. I use it to draft SQL, troubleshoot errors, generate tests and documentation, review unfamiliar Python, and accelerate work that previously would have taken much longer.

My experience has also been that AI is enabling analytics engineers to take on more responsibilities that traditionally sat with data engineering, because many software and data engineering tasks can be automated more easily when they require less business context.

What AI accelerates:

• Writing dbt macros

• Generating boilerplate test coverage

• Refactoring long SQL queries

• Drafting model documentation

• Translating a business question into a SQL first draft

• Exploring an unfamiliar schema

All of this is much faster with a well-prompted AI assistant. A senior AE using Cursor or Claude Code is more productive than a senior AE without one.

What AI does not do well:

• Deciding what a metric should mean

• Root-causing why the source data from Stripe stopped matching the source data from HubSpot last Thursday

• Adjudicating a definitional dispute between marketing and finance

• Making the call between two modeling approaches when the tradeoffs are real and neither is obviously right

• Knowing which stakeholder actually needs to sign off on a schema change

• Recognizing that the model you were asked to build is not the model the company actually needs

Every one of those is what an analytics engineer actually gets paid for.

From Eric

Where I am much more cautious is allowing AI to define metrics, make modeling decisions, or implement business logic that I do not personally understand, because analytics engineering and data modeling in particular requires a tremendous amount of business knowledge, judgment, and organizational context that you cannot simply plug into an AI model.

In my opinion, analytics engineering is one of the safer data roles because of its multifaceted nature. The biggest advice I can give people using AI is to focus heavily on the quality of their prompts, plans, and reasoning rather than simply asking AI to write code.

dbt Labs published an essay in August 2026 arguing that the future of the role is what they call the “context engineer,” someone who provides the business context and modeling judgment that AI agents rely on to produce useful data work. Whether or not that framing sticks, the observation is real: as AI absorbs the mechanical parts of transformation code, the human parts become the entire job.

If you are evaluating a career move into AE with AI anxiety as the main headwind, the anxiety is probably misdirected. There are more AI-vulnerable data roles than this one.

Where To Go From Here

If you finished this guide and want to move forward, there are three practical paths depending on how much structure you want:

• Free practice: the analytics engineering practice library has 1,598 graded SQL and dbt exercises, no account required to start.

• A structured curriculum: the full course covers everything in this guide in depth, with a portfolio-ready BigQuery and dbt Cloud capstone at the end.

• Portfolio first: browse the project library and pick one to build against real datasets.

If you want the fastest defensible path from where you are now to a job-ready portfolio and an interview loop you can actually pass, that is what the course was built for. Six months of structured work, a real capstone project on your GitHub, and the same skill stack this guide walked through, sequenced so nothing is out of order.

Start with the free intro quiz to see where you would come in, or enroll in the full course if you have already made the decision.

Frequently Asked Questions