The data career, mapped

Job titles in this field are close to meaningless across companies. "Data Scientist" spans people who run SQL for a marketing team and people who train models on a research cluster. What is stable is the work: a chain running from raw source systems to a decision somebody makes. Roles are slices of that chain, and understanding the chain is more useful than memorising the titles.

The chain#

source systems → ingestion → storage → modelling → analysis → decision
                     ▲          ▲          ▲          ▲          ▲
              data engineer  platform  analytics   analyst   everyone
                                       engineer   scientist

Every role owns a stretch of that line. Where the boundaries fall differs by company; that the whole chain must exist somewhere does not.

What each role actually does#

Data engineer. Gets data from where it is produced to where it can be used. Pipelines, orchestration, schemas, the 3am page. The hard part is never the transformation — it is the late-arriving row, the timezone nobody agreed on, and the upstream team that changed a column type on a Friday. Strong on: Python, SQL, orchestration, distributed systems thinking.

Analytics engineer. Turns raw warehouse tables into models an analyst can trust without asking anyone. Dimensional modelling, tests, documentation. The newest of these titles and, in many companies, the highest-leverage. Strong on: SQL, data modelling, dbt-shaped tooling, and an unusual tolerance for caring whether a number is right.

Data analyst. Answers questions with the modelled data, and — the part that separates good from fast — decides which question is actually being asked. Strong on: SQL, visualization, stakeholder conversations, scepticism.

Data scientist. Questions that need statistics or modelling. Experimentation, causal inference, prediction. In practice the job is 60% the same work as an analyst plus a statistical toolkit for the other 40%. Strong on: statistics, experimental design, Python, communicating uncertainty.

Machine learning engineer. Models that run unattended in production. Serving, features, monitoring, retraining. Closer to software engineering than to data science. Strong on: software engineering, systems, ML fundamentals, on-call composure.

Data platform / infrastructure. The substrate everyone else stands on. Storage, compute, cost, access. Strong on: infrastructure, cost modelling, query internals.

What actually changes between levels#

Level frameworks are wordy. The compressed version:

Note what is not in that table: tool count. Nobody is promoted for knowing an eleventh framework. The progression is entirely about scope of judgement — from executing a decision, to making it, to deciding which decisions are worth making.

The most reliable signal of readiness for the next level is the one nobody writes down: whether you will tell a senior stakeholder something they do not want to hear, and make it land.

Moving sideways#

The transitions people actually make, and what each requires:

• Analyst → Analytics engineer. The shortest move. You already write SQL; add version control, testing, and dimensional modelling. Weeks, not years.
• Analyst → Data scientist. Add statistics and experimental design. The gap is smaller than job ads suggest and larger than bootcamps suggest.
• Analytics engineer → Data engineer. Add Python, orchestration, and comfort with systems that fail at night.
• Data scientist → ML engineer. Add software engineering. This is the transition most underestimated by the person making it — production is a different discipline, not a deployment step.
• Software engineer → any of these. Usually easy on the tooling and hard on the statistics and the stakeholder work. Both are learnable; only one is typically expected.

What to learn, in what order#

If you are starting: resist the pull toward the glamorous end. The chain runs left to right and so should you.

1. SQL, properly. Not "I can write a GROUP BY" — joins that do not fan out, window functions, and the ability to say what one row of your result represents. This single skill is load-bearing in every role above.
2. The shape of data. Grain, keys, long versus wide, what a null means. Module one is entirely this and it is the cheapest error-avoidance available.
3. Python for data. pandas or Polars, plus enough software engineering to put a function in a file and test it.
4. Statistics you will use. Distributions, uncertainty, sampling, and why the mean is usually the wrong summary. Not a full degree — four lessons' worth.
5. How data gets there. Pipelines, idempotency, schema change. Even if you never build one, knowing why the table was empty this morning makes you dramatically more effective.
6. Communication. The highest-return skill on this list and the one nobody schedules time for.

Then specialise, once you know which failure mode you want.

Reading a job posting#

Postings are written by committee under time pressure, usually by copying an old one. They are a poor description of the job and a surprisingly good description of the organisation.

• Ignore the title. Read the first three responsibility bullets. Those are usually written last-minute by the actual hiring manager and are the truest part of the document.
• The first two or three requirements are real; the rest are preferences. A posting listing eleven technologies is describing a stack, not a person.
• A disclosed salary band is a signal about the whole organisation — it means levelling work has been done, and the negotiation will be about where you land in a range rather than what you can extract.
• "Wear many hats" means there is no platform and you will build it. Good if you want that, miserable if you wanted to do analysis.
• "Modernise our data stack" means a migration is in progress or overdue. Ask how long it has been in progress. The answer is diagnostic.

Our data-job-postings dataset is built from these patterns — including the one where salary disclosure is not missing at random, so an average over disclosed bands runs high. It is synthetic, so treat it as a thing to practise the analysis on rather than as market data.

The five interview questions worth preparing#

We are sceptical of interview-optimised study, because material tuned to a hiring process teaches the tricks that process rewards rather than the job. But interviews are real and some questions genuinely predict performance. If you prepare for anything, prepare for these:

1. "Here is a number that looks wrong. Walk me through what you would check." The best answers start with is the data complete? before they start segmenting.
2. "Explain a technical concept as though I am a stakeholder." Understanding and communicating are different skills; the job needs both.
3. "Tell me about an analysis that turned out to be wrong." A specific mechanism and a specific habit change. "A stakeholder misunderstood" is a bad answer.
4. "What would you need to know before starting this work?" Given a deliberately vague request. This is the scoping skill, and almost nobody tests for it — which means preparing for it is unusually cheap leverage.
5. One SQL question with a grain trap. The signal is whether you ask what does one row of this table represent before writing anything.

The patterns library is organised for exactly this kind of lookup, and every dataset here is something you can practise on in a browser tab.

Questions to ask them#

The single best one, and it is diagnostic:

What is a decision that changed because of an analysis in the last quarter?

A specific, vivid answer means the work matters. A vague one means it does not. Every organisation says it is data-driven; only some can name the last time it was true.

Then: what did the last person in this role work on, walk me through what happens when a dashboard number looks wrong, how does a request reach the data team and how is it prioritised, and who is on call, and for what.