Two teams can use the same title for different work. Compare responsibilities, artifacts, decision rights and success criteria before choosing a role or preparation path.
Problem
Consider these fictional teams. The candidate prefers systems debugging:
| Team/title | Actual responsibility | Artifact |
|---|---|---|
| A / Research Engineer | Data, experiments and model evaluation | Experiment report |
| B / Applied Scientist | Distributed-training reliability and on-call | Incident diagnosis and reliability changes |
Which team deserves closer investigation? Can the title identify its interview format?
Picture: Compare Work on Common Axes
The bars are invented allocations, not industry averages or measurements of teams A and B. For this illustration, each activity gets one primary time category; real activities can overlap.
Fictional activity allocations
The same scale exposes different time budgets in these fictional roles
Derivation
Applied Scientist example
This invented allocation gives modeling the largest share.
Research Engineer example
This invented allocation gives engineering the largest share.
ML Engineer example
This invented allocation gives engineering half the time.
Does the lead example have more total time, or a different allocation?
Work the Team Comparison
Team B better matches the stated systems interest for further investigation. Ask about reliability ownership, on-call load, research expectations and learning support before deciding. If B’s current work instead becomes model evaluation, update the fit assessment. Neither title establishes salary, degree requirements or interview format. Confirm the round constraints separately.
The basic decomposition
- Research: hypotheses, experiments and scientific reports; success depends on supported findings.
- Modeling: data, training and evaluation; inspect quality against the task’s requirements.
- Engineering: training/serving systems and operations; inspect reliability and resource constraints.
- Product: user needs and outcomes; inspect measurement, guardrails and adoption.
These activities overlap. Ask how the team assigns ownership and measures success, not just time percentages.
The decision tree
Build an editable team profile:
| Field | Record |
|---|---|
| Task | Current recurring work |
| Artifact | Expected deliverable |
| Success criterion | Observable standard |
| Decision rights | What you own or must escalate |
| Collaborators | Who shares the work |
| Operating duties | Deployment, on-call or research obligations |
| Learning needs | Current gap and available support |
| Evidence | Source, scope, date and unknowns |
Change 1: Responsibilities Contradict the Archetype
New task. Current manager/team evidence conflicts with the title’s implied mix.
Picture and change. Replace the profile with current tasks, artifacts and operating duties.
Check. The title is not ground truth.
Use when. Role labels are ambiguous.
Change 2: A Private-Lab Offer Looks Higher
New task. Compensation affects the choice.
Picture and change. Compare dated base, bonus, equity valuation/liquidity, location, level, risk and work fit; state unknowns.
Check. A posted base range does not establish a total-compensation multiple.
Use when. Offers differ in pay structure.
Failure: A Prestige Ladder Instead of Team Evidence
Degree labels, invented averages and title equivalences do not establish the actual job.
Transfer Check
What should overturn a title-based preparation plan?
Reasoned Answer
Current tasks, artifacts, success criteria and ownership, confirmed with relevant people and dated sources. Then verify assessment constraints.
Role-by-role, in plain language
These are possible technical cores, not universal job descriptions or a prestige ranking. Researchers can ship products; engineers can lead scientific experiments.
Research Scientist
Possible core: question selection, research methods and supported findings. Ask about publication, deployment and collaboration obligations.
Applied Scientist
Possible core: product-to-ML framing, modeling and evaluation. Ask who owns serving, launch and product outcomes.
Research Engineer
Possible core: research implementations, experiments and training systems. Ask about scientific decisions versus infrastructure ownership.
ML Engineer
Possible core: data/training pipelines, serving, testing and monitoring. Ask about modeling depth and operating duties.
Software Engineer (ML adjacent)
Possible core: APIs, applications, integration and data systems. Ask which ML-specific behavior and failure modes require ownership.
Fictional Allocation Reference
These invented schedules are not measured industry averages. Each row assigns 100% to disjoint primary activity bins.
| Example label | Research | Modeling | Engineering | Product |
|---|---|---|---|---|
| RS | 60% | 30% | 5% | 5% |
| AS | 20% | 40% | 20% | 20% |
| RE | 25% | 30% | 40% | 5% |
| MLE | 5% | 30% | 50% | 15% |
| ML-adjacent SWE | 0% | 10% | 80% | 10% |
Compensation patterns (US, mid-2026)
No verified pay comparison is established here. Use sourced offer terms; do not infer liquid equity value from a headline valuation.
What changes between levels
Compare scope, uncertainty, authority, influence and time horizon using that employer’s definitions. Level names are not fixed cross-company equivalents.
How to interview for each
Use confirmed work samples and the role paths, not title-based round assumptions.
A note on title inflation
Ask about shipped users, team track record, day-to-day mix and the work you would actually own. Qualifications vary; verify the real requirements rather than impose a universal degree-to-role route.
Related: The 5 things every applied scientist interview is testing for, senior through senior-principal ML scope.