Machine Learning Engineer vs Applied Scientist vs Research Scientist: Choose the Work, Not the Title

AI job titles look more precise than they are.

At one company, a machine learning engineer trains models. At another, the same title means platform engineering. An applied scientist may publish original research, tune an existing model for a product or own an entire business problem. Research engineer and research scientist are sometimes separate career tracks and sometimes a single vacancy.

This creates a costly mistake: candidates choose a title before they understand the work.

The better comparison starts with four questions:

• What are you expected to produce?
• What uncertainty are you paid to reduce?
• How is success measured?
• What evidence proves you can do it?

The short comparison

This is a map, not a universal standard. Read the responsibilities before trusting the title.

Machine learning engineer: make the capability dependable

The machine learning engineer lives at the boundary between a model and an operating product.

Depending on the team, the role may involve preparing data, training or fine-tuning models, building inference services, designing evaluation pipelines, optimising GPU use, monitoring drift and failures, and improving latency or cost. The engineer is often the person asked to turn a successful experiment into something that works on Tuesday at 3 a.m.

The defining question is not “Can the model do this once?” It is “Can the system do it repeatedly, economically and safely under real conditions?”

The strongest evidence is therefore concrete:

• a system you deployed and operated
• a bottleneck you measured and removed
• a reliability problem you diagnosed
• an evaluation pipeline you designed
• a model or service you made faster, cheaper or more accurate
• a tradeoff you made between quality and system constraints

This path is a good fit if you enjoy building, debugging and making abstractions real. You should be comfortable with imperfect models and equally imperfect infrastructure.

Applied scientist: connect scientific method to a real outcome

Applied scientists begin with a practical problem whose solution is not obvious.

The work might be ranking products, forecasting demand, detecting fraud, improving recommendations, evaluating an assistant, optimising logistics or adapting a foundation model. You may need to translate an ambiguous business objective into a tractable scientific question, choose an experimental method, build a model and determine whether the improvement is real.

Amazon describes applied science as solving AI problems across logistics, language, vision, robotics and other domains at real operating scale. Its current roles often combine advanced modelling, programming and end-to-end ownership of a business problem. That combination—scientific depth plus practical consequence—is the important signal, not the company’s exact title. See Amazon’s applied science overview.

The strongest evidence includes:

• a well-designed experiment with a defensible baseline
• a model improvement connected to a product or business result
• rigorous error, statistical or causal analysis
• the ability to explain why a result is trustworthy
• code strong enough to collaborate with engineering
• publications or patents when the role values novelty

This path fits people who like ambiguity, quantitative reasoning and seeing research change a real system. Advanced degrees are common because they compress evidence of research training, but they are not the only possible evidence.

Research scientist: expand what is possible

Research scientists are paid to work where the answer is not yet known.

They formulate hypotheses, design new methods, run experiments that may fail, interpret unexpected results and communicate what the field should learn. In frontier labs, research can still be product-grounded. A current OpenAI research posting, for example, combines reinforcement learning, dataset creation and evaluation with close product collaboration; another describes work across the full lifecycle of training, evaluation and deployment. The boundary between research and engineering is porous because important ideas have to survive implementation. See OpenAI’s research engineer/scientist role.

The strongest evidence is usually:

• a record of novel, rigorous research
• publications or substantial open research
• deep command of a research area
• the ability to create and test useful hypotheses
• strong implementation, especially for research engineer hybrids
• evidence that other researchers can build on your work

This path fits people who enjoy long uncertainty, deep specialisation and problems where progress may be hard to measure for months. A PhD is common because it is training for exactly that environment, though exceptional independent work can sometimes substitute.

The roles overlap more than the org chart admits

A useful system may require all three forms of judgment.

Consider a recommendation model. A research scientist might develop a new method for learning preferences. An applied scientist might adapt it to the company’s catalogue, design an experiment and test its effect on user outcomes. A machine learning engineer might build the pipeline, deploy the model, monitor its behaviour and keep inference within latency and cost limits.

In a small company, one person may do all three. In a large company, each responsibility may belong to a separate team. Seniority also changes the mix: senior engineers influence research direction, and senior scientists often own delivery.

That is why title matching is unreliable. Output matching is much stronger.

Choose by your preferred form of progress

Ask which result gives you the most satisfaction.

If it is the system works reliably for thousands of users, lean toward machine learning engineering.

If it is the experiment proves a better decision or product outcome, lean toward applied science.

If it is we now understand or can do something that was not possible before, lean toward research science.

Then examine your tolerance for three kinds of work:

Engineering depth

Do you enjoy code quality, systems design, observability, performance and operational ownership? More of this points toward ML engineering or research engineering.

Statistical and experimental depth

Do you enjoy problem formulation, baselines, uncertainty, causal questions and interpreting noisy results? More of this points toward applied science.

Open-ended research

Do you want to spend significant time reading papers, creating methods and pursuing hypotheses without a guaranteed product outcome? More of this points toward research science.

No path is more intelligent or prestigious by definition. They reward different forms of excellence.

Search for responsibilities, not only titles

When reviewing a vacancy, highlight its verbs.

• Build, deploy, scale, optimise, monitor usually indicate engineering ownership.
• Formulate, experiment, analyse, validate, improve metrics usually indicate applied science.
• Research, invent, publish, advance, pursue an agenda usually indicate research science.

Next, find the nouns that define the environment: production service, customer metric, paper, training run, evaluation, platform, data pipeline or research programme.

Finally, inspect the proof requested. A role asking for distributed-systems experience sends a different signal from one asking for top-tier publications, even if both are called “machine learning engineer.”

Build a portfolio for the role you want

For machine learning engineering, show an end-to-end system with tests, deployment, evaluation, monitoring, latency and cost. Document operational failure.

For applied science, show the reasoning from problem formulation to baseline, experiment, error analysis and decision. Explain what would invalidate your conclusion.

For research science, show depth: a paper, reproduction with meaningful extension, open-source research tool or series of experiments answering an original question. Explain the idea, not only the implementation.

If you are unsure between two paths, build a project that crosses the boundary. Then notice which part you keep returning to after the requirement is satisfied.

Do not treat the three paths as a ladder

Research scientist is not the promotion above applied scientist, and applied scientist is not the theoretical version of an engineer. Strong careers move in several directions. An engineer can become a research engineer. A scientist can move closer to product. A technical leader may combine all three perspectives while managing people who specialise.

The durable decision is not which label sounds best today. It is which class of problem you want to become unusually good at solving.

Choose the work first. Then find the companies whose title happens to match it.