Data Platform & Analytics
Analytics Engineer
Where one definition of a metric is won or lost. The most business-facing engineering role in this field.
Analytics engineering owns the layer between raw data and the numbers people act on. It is closer to product than to infrastructure, and its defining artefact is a model that everyone agrees represents the truth.
| Time | What you are actually doing |
|---|---|
| 09:00 | Two teams report different revenue. Neither is wrong; they are using different definitions and the fix is upstream of both. |
| 10:30 | Modelling. Building the conformed customer entity so that 'active' means one thing. |
| 13:00 | Tests. Not many — the four that matter, on the models people actually depend on. |
| 14:30 | Documentation, which for this role is product surface: a model nobody understands is a model nobody trusts. |
| 16:00 | Deprecating three old marts that duplicate the new one, which is harder than building it. |
The decisive round
“Two dashboards show different revenue. Fix it.”
Interviewer: “Finance and the growth team report different revenue numbers for the same month. What do you do?”
A weak answer. “I'd trace both back to source, find where the logic differs, and align them on the correct definition.” Fine as far as it goes, and it treats a structural problem as an incident. You will do this again next quarter with two different dashboards.
A strong answer. “First I would establish that neither is wrong, because they usually both correctly compute a different thing — and starting from 'which is correct' turns it into a fight between two teams.
The usual causes: refunds included or not, the date being order date versus recognition date, currency converted at transaction rate versus month-end, and test accounts filtered or not. I would diff the two definitions and put both in front of the teams rather than adjudicating privately.
Then the real question, which is not which number is right but who decides what revenue means. That is a business decision, not an engineering one, and my job is to make it once and then make it the only accessible implementation. So: one model in the core layer, owned, documented, tested — and then the harder half, which is deprecating the two existing paths so nobody can compute it a different way. If both remain, we will be back here.
I would also expect to find that one of them is used in something consequential — a board pack or a commission calculation — so I would find out before changing anything, and tell that owner personally rather than letting them discover a number moved.”
Recognising both are correct, escalating the definition to the business, and treating deprecation as the actual work. Candidates who just align the logic will be back next quarter.
- Build a conformed entity with a stated grain and a single definition, then point two different consumers at it.
- Have a deprecation story — something you turned off, and the team that resisted.
- Write documentation somebody used. For this role it is product, not overhead.
- Know slowly-changing dimensions properly, because 'can I reproduce last year's number' is the question that exposes whether you do.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $120k – $200k base | Below platform-side data engineering, above BI analysis |
| India | ₹12L – ₹40L total | Growing quickly as the modelling layer separates from pipeline work |
The book for this field
Analytics & BI Tools
The four layers of the analytics stack, then Power BI, Tableau, Looker and Alteryx each in practice — what they are genuinely good at, where they hurt, how to choose with real scenarios, the licensing models that bite, and making analytics actually get used.
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 17 Data questions → · Back to Data Platform & Analytics →