Data analyst vs. data scientist vs. analytics engineer: which loop are you in?
The title on the posting tells you very little. Two jobs called Data Scientist at two companies can share almost no interview rounds. Here is how to read a posting for the loop you will actually face.
By Lin S., founder and coach at Open Loop
A client came to me last year after failing two loops in a row, both for jobs called Data Scientist. The first was four rounds of SQL and product sense with no machine learning anywhere. The second opened with a coding screen and moved into model deployment. He had prepared thoroughly for the wrong one of those, twice, and both times the rejection said not a fit for the role which told him nothing.
Job titles in this field are close to noise. They were invented independently at a few dozen companies over about fifteen years, and there was never a standards body. What is not noise is the work, and the work determines the loop. If you can figure out the work from the posting, you can predict your rounds with reasonable accuracy, and that is most of the preparation problem solved.
Stop preparing for a title. Prepare for a loop.
The five archetypes
Underneath the titles there are roughly five jobs. Nearly every posting is one of these, or an explicit blend of two.
- Decision support. You partner with a business function, define how it measures itself, and answer questions that change what somebody does next quarter. Often titled Data Analyst, Business Analyst, Product Analyst, or Business Intelligence Engineer.
- Product data science. You own metrics for a product surface and you live in experimentation. Titled Data Scientist at most large consumer companies, sometimes Product Analyst, sometimes Data Scientist, Product Analytics.
- Applied machine learning. You build models that run in production and serve users. Titled Machine Learning Engineer, Applied Scientist, or Data Scientist at companies where the ML team was named early.
- Analytics engineering. You own the transformation layer: models, tests, documentation, and the semantics everybody else queries. Titled Analytics Engineer, sometimes Data Engineer, sometimes still Data Analyst at companies that have not renamed it.
- Research and inference. Causal inference where you cannot randomize, forecasting, survey and measurement work. Titled Research Scientist, Quantitative Analyst, Economist, or Data Scientist, Inference.
Titles drift, and specific naming conventions change, so treat any mapping you read as a snapshot rather than a rule. The useful and durable observation is that large companies split these into separate ladders with separate loops, while companies under roughly two hundred people hire one person to do three of them and interview accordingly.
What each loop actually contains
| Archetype | Rounds to expect | Where people underprepare |
|---|---|---|
| Decision support | SQL, a metrics or business case, a stakeholder conversation, behavioral | The stakeholder round. Most candidates over-prepare SQL and walk into the communication round cold. |
| Product data science | SQL, product sense, experimentation, behavioral, sometimes a take-home | Interpreting a flat or ambiguous test result, and defining a metric they can defend under pushback. |
| Applied ML | Python coding, ML system design, stats fundamentals, deep dive on a past model | Tradeoffs. They can recite how gradient boosting works and cannot say why they chose it over logistic regression. |
| Analytics engineering | SQL, dimensional modeling, pipeline design, code review, testing and orchestration | Modeling as a discipline. Grain, slowly changing dimensions, idempotency, and what happens on a backfill. |
| Research and inference | Stats depth, causal inference design, coding, research presentation | Explaining an identification strategy to a non-technical stakeholder in two minutes. |
Reading the posting
Job descriptions are written by hiring managers who are describing their actual week, then lightly sanitized by a recruiter. The signal survives that process better than you would expect. Here is a composite posting with what each line is telling you.
Partner with Product and Engineering to define success metrics for new features
Product data science. Expect a metric definition question and a product sense case. Define success metrics is the single most reliable tell for this archetype.
Design, run, and read out A/B tests across the onboarding funnel
A real experimentation round is coming. Not a stats quiz. Design, power, guardrails, and what you recommend when the result is ambiguous.
Build and maintain dbt models that power company reporting
Analytics engineering is part of this job. Expect questions on grain, testing, and what happens when an upstream schema changes. If this bullet is in the top three, the role is more AE than DS.
Deploy and monitor production models serving personalized recommendations
Applied ML. There will be a Python round that is closer to software engineering than to a notebook, and probably an ML system design round.
Proficiency in SQL and a BI tool such as Looker or Tableau. Python a plus.
Read the ordering. Python a plus in the requirements means the coding bar is low and the communication bar is high. If Python were load bearing it would not be a plus.
Reports to the Director of Business Operations
Where the role reports is the strongest single signal in the posting. Under a BizOps or Finance leader the job is decision support regardless of the title. Under an engineering leader it is technical regardless of the title.
Company size changes the answer more than industry
At a company with a thousand data people, these five jobs are five ladders with five rubrics, and the loops are narrow and deep. You will be asked product sense questions for ninety minutes and no machine learning at all, or the reverse, and being broad is not particularly rewarded.
At a fifty person company, one person is the analytics team. The loop compresses into two or three conversations that jump between writing SQL, sketching a warehouse, and arguing about which metric the founders should care about. Depth in one area matters less than being able to hold all of it and being visibly comfortable with the fact that nothing is built yet.
If you are targeting more than one archetype
Most people should, especially in this market. The mistake is running one generic preparation plan across all of them and being mediocre everywhere. Two things make a multi-track search work.
First, find the shared core and drill it once. SQL and behavioral stories appear in every loop on this page, so that work is never wasted. Metric definition shows up in four of the five. Start there regardless of your targets.
Second, keep separate resumes, and be honest that this is not the same as keeping separate lies. The same eighteen months of work genuinely supports different emphases. For an analytics engineering role the interesting part of your project was the modeling and the tests you added. For a product data science role the interesting part was the metric you defined and the decision it changed. Same project, two paragraphs, both true.
Framed for analytics engineering
Rebuilt the subscription reporting layer as 6 dbt models with tests on grain and referential integrity, cutting a nightly job from 50 minutes to 9 and eliminating the three-way disagreement between Finance, Growth, and the exec dashboard.
- Leads with the modeling and the tests
- Runtime and reliability as the headline outcome
Framed for product data science
Rebuilt subscription reporting so that Finance, Growth, and the exec dashboard finally agreed on one definition of active subscriber, then used it to show that our churn problem was concentrated in month two, which moved the retention roadmap.
- Leads with the definition and the decision
- Ends on what the business did differently
A note on leveling
One more reason the title is a bad guide: the same title spans an enormous range. A Data Scientist can be someone eight months out of a masters program and someone with twelve years who sets direction for a hundred-person org. The loop changes with level far more than most candidates expect, and in a specific direction.
Junior loops test whether you can do the work. Senior and staff loops test whether you can choose the work, and then whether you can get other people to do it with you. The technical rounds do not get much harder past a certain point. What changes is that what did you do becomes “why was that the right thing to do, who disagreed, and what happened to the ones who disagreed”. If you are interviewing a level up from your current one and your stories are all about execution, that is usually what is costing you the offer rather than anything technical.
So before your next application, do the boring thing. Read the posting again, decide which of the five archetypes it is, write down the four rounds you expect, and prepare those four. It takes fifteen minutes and it is the difference between the two loops my client failed and the one he passed a month later.