Research Engineer
What the work looks like, the stacks behind the title, what each level means and the training that helps, then how interviews run and how to prepare for each step.
What a research engineer actually does
An engineer who builds and scales the code behind research models, from large training runs to benchmarks that others can reproduce.
A research engineer works with research scientists to turn new ideas into working code and to train models at large scale. They write the training code, run experiments on GPU clusters and make sure the results are correct and reproducible.
A large part of the role is about performance. Research engineers make training faster and cheaper with distributed training, mixed precision and better use of GPUs, sometimes down to CUDA kernels.
They also build the large datasets, the tokenization and the benchmarks that research depends on, and they often turn papers into code that others can use.
- Launching and watching a large training run
- Making a training job faster on the GPU cluster
- Turning a new paper into working code
- Running benchmarks and checking results
- Code reviews and documentation for the research team
In AI labs and research teams, research engineers and research scientists often work on the same projects. Scientists usually lead on new ideas and papers, while engineers lead on the code, the scale and the reliability of experiments.
The line between the two roles differs from one company to the next. The job ad, and the weight it gives to publications versus engineering at scale, show where the role really sits.
The same title, very different stacks
Most research engineering searches are defined first by the part of the research stack the team owns, then by the ground every research engineer shares.
What each level means in practice
Titles vary from one company to the next. What changes from one level to the next is the scope you own and the decisions you take.
- Works on experiments designed by senior researchers
- Learns the codebase, the cluster and the methods
- Writes tested code with code review
- Runs experiments and training jobs on their own
- Fixes problems in training and data
- Works directly with research scientists
- Leads the engineering of a research project
- Takes choices on scale, performance and tools
- Mentors other engineers and leads code reviews
- Sets the training infrastructure across teams
- Leads choices on frameworks, clusters and standards
- Shapes the work of several research teams
The paths into the role, and what really counts
Research engineering values a strong engineering base and research experience. Companies still look first at the training runs you led and the code you released.
- Master's in computer science or machine learningA common path, often with research experience during the degree.
- PhD in machine learning or a related fieldA common path in AI labs, where strong engineers also join after a master's.
- ML engineering firstML engineers who like scale and performance also move into the role.
- Strong systems engineering backgroundEngineers from high performance computing or distributed systems also move into the role.
Our view: for this role, a training run you led or a paper you reproduced, with code others can use, often says more than any certificate.
A conversation with a senior tech recruiter
Your first interview is with one of our senior tech recruiters, who knows the role, the stacks and the levels in this guide. The conversation covers your own work through real examples, and the technical exercises come later, with the company. Before the call, we send you the six themes we will cover so you can prepare your examples.
- What you owned yourselfThe training runs, research code or benchmarks you were responsible for, and your own part in the team's work.
- Your environment and its constraintsCompute budget, cluster size, deadlines or research goals: what shaped your technical choices.
- The decisions you madeWhich framework, which parallelism and which trade‑offs on speed and cost, the options you compared and the reasons for your choice.
- The impact of your workWhat changed thanks to your work, with numbers when you have them: training speed, GPU usage, costs or benchmark results.
- How you work with other teamsYour work with research scientists, platform teams and other engineers, and how you settle a disagreement.
- What you want nextThe kind of research, scale and scope you are looking for in your next role.
- Training at scale
- Reproducibility
- Publications or open source
The same ground for every candidate. For a given role, every candidate answers the same final questions, built with the hiring manager around what the role really needs.
Ready for the next steps. After our call, we tell you how the company runs its interviews, who you will meet at each step and what each step is meant to assess.
What the company will assess, step by step
Each company runs its own process, and we walk you through its steps before you start. Research engineering processes often combine the steps below, and the depth expected at each step grows with your level.
- A coding exerciseLive coding in Python, often on a piece of ML from scratch, such as an attention layer or a training loop.
- An ML knowledge interviewQuestions on models, training, optimisation and the recent research of the field.
- A performance and scale interviewA slow or unstable training run to diagnose, and how you would scale it across many GPUs.
- A research discussionA paper or a past project discussed in depth with researchers, from the idea to the results.
- ConfirmedYou write clean ML code, test it and explain each choice in simple words.
- SeniorYou lead the discussion on scale, weigh speed, cost and stability, and point out risks before you are asked.
- Staff and PrincipalYou run most of the interview as a peer, think about the whole training stack and connect it to the goals of several research teams.
How to prepare as a research engineer
Practical advice for each step of a research engineering process, from the way you introduce yourself to the questions you ask at the end of each interview.
Start with the training runs and research projects you worked on, their scale and your part in them. Mention your stack in one sentence, then close with what you want next.
For each one, prepare the goal, the scale, your decision, the options you set aside, the result and what you would change today. Say "we" for the team and "I" for your own part.
Practise writing core pieces such as attention, a training loop or a loss function in PyTorch, and explain each line.
Prepare the number of GPUs, the training time, the costs and the speed gains of the runs you worked on.
In a performance interview, explain each check you make, from the data to the GPUs, before you propose a fix.
Rules on AI coding assistants differ from one company to the next, and sometimes from one step to the next. Ask before each step, and when they are allowed, explain what you ask the tool and how you check its output.
- Walk us through the largest training run you worked on.
- Your training loss suddenly jumps. What do you check?
- How would you train this model across many GPUs?
- Tell us about a paper you reproduced, and what you learned.
- How do research engineers and scientists share the work?
- Which compute can the team use, and how is it shared?
- Does the team publish papers or release code?
- Which frameworks and tools does the team use for training?
- How are research projects chosen and reviewed?
- How does the team use AI coding tools day to day?
Where research engineers come from, and where they go
The roles people most often hold before this one, and the ones they most often move to.
Some research engineers also move to research scientist roles.