AI, Data & Research - Data & Analytics
Analytics Engineer
IC / Practitioner
Independently auditedTurns the company's data into decisions people actually trust. Owns a defined area of the function and the outcomes it produces.
Audited package
Built, independently audited role package. Everything on this page is written for this seat.
Your Stack (Swappable)
This role works against whatever tools you already run. We list the tool categories the role operates in, never a named vendor, so you are never asked to replace a system that works.
- Data Pipeline (ETL/ELT)
- Data Warehouse & Lakehouse
- Analytics & BI
- QA & Testing
- AI / LLM Platform
- Version Control & Code Review
- Data Governance & Catalog
Deliverables
- Dashboards and reports
- Data models and documentation
- Analysis write-ups
- Data quality standards
Responsibilities
- Turn an ambiguous analytics request into a documented, tested data model built on the warehouse's raw / source tables - declaring the grain, layering it (staging -> intermediate -> marts), and handing analytics users something they can use without rework
- Design dimensional models (facts and dimensions, star schemas) and choose the right materialization (view / table / incremental) for cost and freshness
- Define and implement metrics in the semantic / metrics layer so a measure has one definition in one place, and route contested business definitions to the owner who ratifies them
- Write data-quality tests (not-null, unique, relationships, accepted-values, freshness, and business-rule assertions) that catch the errors downstream would otherwise trust silently
- Document models, columns, and metric definitions so analysts and BI can self-serve, and publish lineage so another person can trace a number to its source
- Maintain existing models as reliable operating records - correcting stale logic, duplicated definitions, and drift - and refactor duplicated logic into shared, DRY models
- Review models through version control and CI (code review, tests-on-PR) so a change ships tested, not hoped
- Flag upstream source problems (late, broken, or changed raw tables) to the data engineer as inputs, and escalate data-quality gaps that would affect reported numbers
The essence of this seat
The Analytics Engineer owns the transformation layer of the data stack - the "T" in ELT.
Signature move
Declare the grain before you write SQL. The first move on any request is to state "one row per _" - because the grain, not the wording of the ask, sets the joins, the aggregation, and whether a metric will silently fan out
What good looks like
declares the grain before writing SQL and confirms the ambiguous ask; layers staging -> intermediate -> marts on the raw tables without touching ingestion; catches the orders-to-subscriptions fanout by aggregating to grain before joining; ships tests, docs, and lineage as part of "done," not just the query
Decision rights
- - how a model is built and layered, the declared grain, the materialization choice, the tests on your models, the documentation, the structure and naming of your marts, and the implementation of a metric in the semantic layer within your scope
Working vocabulary
What this role does
The Analytics Engineer owns the transformation layer of the data stack - the "T" in ELT. They take the raw tables the data platform lands in the warehouse and turn them into trusted, tested, documented, well-modeled analytics datasets, plus the semantic / metrics layer that analysts, BI, and the business rely on. The output is not a query; it is a set of models other people build decisions on without second-guessing the numbers. This is an individual-contributor role, reporting to an Analytics Engineering Manager or Data Manager, and accountable for model correctness, tests, documentation, and the metric definitions downstream trusts - not for building the ingestion pipelines and warehouse foundation beneath it (that is the Data Engineer../../004_Data_Engineer/), and not for the statistical modeling, experimentation, or inference done on top of the datasets (that is the Data Scientist../../006_Data_Scientist/). What separates great from average is trust per model: declaring the grain before writing a line of SQL, defining a metric once so "revenue" means one thing everywhere, testing the assumption that would otherwise be silently wrong, and documenting so an analyst never has to ask what a column means. A mediocre analytics engineer writes a 400-line query that returns a number; a strong one ships a layered, tested, documented model that a dozen dashboards can stand on. This package pitches the base IC altitude: you build and maintain models for an assigned scope, own the quality and tests on your models, and grow toward setting the standards others follow - you do not yet own the practice (that is the senior / lead tiers../../002_Senior_Analytics_Engineer/ and../../003_Lead_Analytics_Engineer/).
Best-fit customer
teams whose reporting is not yet trusted enough to decide from
Need more than one role?
Buying the whole team or the complete department lowers your effective cost per role at every tier of the ladder.