Research Engineer vs. Applied Scientist: what the titles actually mean

Both titles live on ML teams. Both involve reading papers, running experiments, and writing Python. The confusion is real and sometimes intentional — companies use the names inconsistently. But there is a meaningful underlying distinction, and understanding it changes how you should be building your skills.

The one-line version

Research Engineer — you build the systems that make ML research possible.

Applied Scientist — you apply research techniques to solve a specific product or business problem.

A research engineer makes it fast and cheap to run experiments. An applied scientist decides which experiments to run.

What each role actually does day-to-day

Research Engineer

On any given week, a research engineer at a frontier lab might be:

Implementing a new architecture from a paper so it runs at scale on thousands of GPUs
Debugging a training instability that only appears at batch size 4096
Building the evaluation harness for a new capability benchmark
Writing the distributed training code that lets researchers iterate faster
Refactoring the data pipeline to handle a new modality
Profiling GPU utilization and shaving 15% off training time

The work is predominantly engineering. The output is reliable, reproducible, fast infrastructure that other people depend on. A research engineer's success is measured by how much faster the research team can iterate — not by the research ideas themselves.

Applied Scientist

On any given week, an applied scientist at a product company might be:

Designing an A/B test to validate whether a new ranking model improves click-through
Running ablations on a fine-tuned language model to understand what's driving quality
Pulling and analyzing offline metrics across model versions
Writing a research proposal for a new approach to a recommendation problem
Presenting experiment results to a product team and making a ship/don't-ship recommendation
Reviewing literature to find techniques applicable to the company's specific problem

The work is predominantly experimentation and analysis. The output is insights, models, and occasionally papers. An applied scientist's success is measured by offline and online metrics improving — business outcomes.

Where it gets blurry

At smaller companies, one person does both — you design the experiment AND build the pipeline. The title is mostly a function of seniority and org structure.

At large labs (OpenAI, Google DeepMind, Anthropic, Meta AI), the split sharpens considerably:

Research Engineers handle the infrastructure and implementation — training loops, eval frameworks, scale
Research Scientists (or Applied Scientists) design the experiments and push the ideas forward

The applied scientist title is especially common at product companies (Amazon, Apple, LinkedIn, Spotify) where the goal isn't advancing the field but applying existing techniques to recommendation, search, ads, or NLP problems. A research engineer at the same company may primarily support one or two applied scientists.

The skill matrix

	Research Engineer	Applied Scientist
Primary skill	Systems + ML	ML + analysis
Coding depth	High — owns the infrastructure	Medium-high — enough to execute
ML theory depth	Medium — enough to implement correctly	High — graduate-level expected
Statistics	Enough to validate results	Deep — designs experiments rigorously
Product sense	Optional	Often required
Paper writing	Rare	Common
Background	Strong SWE + ML	Often PhD or equivalent

Neither column is a strict requirement — the best people in both roles have deep skills in both dimensions. But the primary axis of mastery differs.

The traps to avoid

For Applied Scientists: shallow engineering skills. If you can't implement the experiment yourself, you're constantly blocked waiting for an RE to build your infra. At many companies, the applied scientist who can also build their own pipelines gets 5x more done than the one who can't.

For Research Engineers: insufficient ML intuition. You can build perfect infrastructure for the wrong experiments. If you don't understand why a regularization technique works, you can't tell when someone is about to waste three weeks on a dead end. The RE who can say "this architecture won't scale the way you think it will" is invaluable. The RE who just builds whatever is asked is more replaceable.

The skill overlap that actually matters

Both roles need to be able to:

Read a paper and understand what it actually claims (not what the abstract says)
Implement it from scratch, correctly
Get a working baseline result
Identify when the result is wrong and why

The practical test: given a new paper, how long does it take you to get a working implementation and a baseline result?

For a research engineer: fast because of strong code instincts. For an applied scientist: fast because of strong ML intuition. The best people in either role are fast for both reasons.

What frontier AI labs specifically look for

At Anthropic, OpenAI, Google DeepMind, and Meta AI, research engineer roles tend to require:

Genuine software engineering depth — not just ML scripts, but production-quality systems thinking
Ability to read and implement papers quickly and accurately
Experience with large-scale distributed training (or clear evidence you can learn it fast)
Understanding of evaluation methodology — you need to know when an eval is measuring what it claims to measure
Comfort working at the boundary between research and engineering — translating vague research ideas into concrete implementations

Applied scientist / research scientist roles tend to require:

Graduate-level ML background — PhD or equivalent demonstrated competence
Track record of original research contributions — papers, significant open-source work, or clear evidence of novel thinking
Domain depth in at least one area (NLP, RL, computer vision, multimodal, etc.)
Ability to communicate research clearly — written and verbal

The notable difference: at frontier labs, research engineers are expected to have serious research instincts, not just engineering skills. The bar is closer to "research scientist who codes extremely well" than "software engineer who knows ML."

Which path is right for you

Choose Research Engineer if:

You get more satisfaction from a system running correctly than from an experiment result being positive
You want to own the infrastructure and tooling layer
You have strong software engineering instincts and want to apply them to ML problems
You like making other people's work faster and more reliable
You want to be at the center of how frontier models are actually built

Choose Applied Scientist if:

You get more satisfaction from understanding why a model behaves a certain way
You want to own the modeling decision end-to-end
You have graduate-level ML background and want to apply it to concrete problems
You're comfortable with the slower feedback loop of experimentation
You want to connect ML technique directly to product or research outcomes

Neither is more prestigious. Both are genuinely hard. Both require the ability to read papers and implement them — the difference is which side of that skill you push further.

The honest hybrid position

The most effective people at frontier labs are hybrids who lean one direction. They can do both — implement complex systems AND reason about experimental design — but they're primarily measured on one axis.

If you're building toward a frontier lab research engineering role, the move is: develop serious ML intuition while maintaining engineering excellence. Be the person who can say "this experiment is designed wrong" AND fix the training pipeline that's causing the divergence. That combination is genuinely rare and genuinely valued.

The 300-day goal on this site is that combination. Research 50%, engineering 50%.