Articles
Research Engineer vs Research Scientist: Choose Your Interview Preparation
Compare research engineer and research scientist preparation through official role descriptions, project evidence, coding, experiments, and role fit.
Choose research engineer versus research scientist interview preparation from the work a role expects you to deliver. Research engineering often emphasizes making ideas executable, reliable, and scalable; research science often emphasizes choosing a worthwhile question and producing convincing evidence about it. Both can involve substantial coding, mathematical reasoning, and experimentation. The title alone cannot tell you the exact interview loop.
Read the job description, identify the deliverables, and match your strongest project evidence to those demands. This guide provides a role-evidence matrix and two ways to defend the same project, helping you choose preparation tasks rather than treating the titles as a prestige ranking.
What official role descriptions tell you
Official facts: Google DeepMind describes research engineers as combining software, mathematical, and research skills to build and scale systems that test ideas. It describes research scientists around research questions, hypotheses, novel methods, and evaluation, noting that they normally hold a PhD. These are that organization's role descriptions, not universal degree requirements. Google DeepMind careers.
Google Research also describes research engineers working on large-scale testing and deployment of promising ideas. This illustrates that engineering and research duties can overlap. Google Research careers.
Anthropic explicitly says its engineers perform research and its researchers perform engineering. Its current careers guidance also discusses varied educational backgrounds. That is another reason to inspect a specific vacancy rather than applying a rigid title rule. Anthropic careers.
Editorial inference: your preparation should follow the role's output and your evidence gaps. No candidate report here establishes a required interview round, question frequency, or hiring threshold. Ask the recruiter for the actual loop and relevant expectations; duties are evidence of job fit, not proof of an assessment format.
Translate the vacancy into an evidence matrix
Extract verbs from the job description. “Implement,” “profile,” “scale,” “evaluate,” “formulate,” and “investigate” imply different artifacts. Mark which demands are essential, which are desirable, and which you cannot interpret without more context.
Then map each demand to evidence you can discuss. For implementation, bring a clear interface, tests, and a known failure you diagnosed. For research judgment, bring a hypothesis, a baseline, a discriminating experiment, and a limitation. For scale, bring the measured workload and bottleneck, not simply the name of a distributed framework.
| Role demand | Evidence and a useful practice task |
|---|---|
| Turn a method into working code | Implement a small component, check shapes and edge cases, and compare it with a reference. |
| Make experiments trustworthy | Explain splits, leakage controls, baseline tuning, ablations, and uncertainty. |
| Improve training or inference efficiency | Profile a representative workload and distinguish a measured bottleneck from a guess. |
| Develop a research direction | Identify the question, competing explanations, and a result that would change your belief. |
| Collaborate across a research team | Explain your contribution, interfaces, disagreements, and how others could reproduce the work. |
| Assess practical value | Connect a method to resource limits, failure costs, and evaluation conditions. |
A matrix with several strong research artifacts and weak software evidence does not automatically mean you should avoid engineering roles. It identifies what you would need to demonstrate. Conversely, excellent infrastructure work without evidence of original research judgment may require a different preparation focus for a scientist vacancy.
Do not create a numerical fit score that pretends to reproduce an employer's hiring rubric. Use the matrix to select exercises and recruiter questions. The hiring team may weight evidence differently, and a vacancy may combine demands that this broad comparison separates.
One project, two defensible explanations
Consider an original hypothetical project: a retrieval method improves performance on a specialized document collection. The team compares it with a tuned baseline and investigates whether the benefit persists for longer documents. No metrics below are claimed as a real project result.
For a research scientist explanation, start with the question: does the proposed representation preserve useful information that the baseline loses? Explain the mechanism, why the baseline is a fair comparison, and which experiment distinguishes that mechanism from extra compute or different data. Present the most important limitation before suggesting a next study.
For a research engineer explanation, start with the executable experiment: how are documents transformed, how is the model invoked, and how are results evaluated? Explain input contracts, batching, artifact versions, validation checks, and the bottleneck that limits repeated experiments. Show how a teammate can rerun the comparison reliably.
The explanations share the same scientific evidence. The engineering version does not get to ignore whether the comparison is fair. The scientist version does not get to ignore whether the method was implemented correctly. They differ in emphasis and the depth of follow-up preparation.
If your actual contribution was only the evaluator, say that. You can explain how its correctness affected the research without claiming you invented the method. If you designed the method but another collaborator built the production pipeline, distinguish those responsibilities. Accurate ownership makes deeper questions easier to answer.
Prepare implementation evidence that survives probing
Choose a compact component relevant to the role: a loss function, data transform, evaluator, sampling routine, or batching interface. Implement it under the tool conditions the employer confirms. State shapes, units, boundary cases, and numerical assumptions before optimizing.
For a regression loss, verify behavior on a tiny known input and check the gradient against a numerical approximation where appropriate. For a retrieval evaluator, verify relevance labels, duplicate results, ranking cutoffs, and queries with no relevant documents. For a batching component, define how request boundaries and outputs remain aligned.
A runnable notebook can be useful evidence, but do not equate it with a robust software package. Explain what is reusable, what depends on local state, and how configuration or environment differences affect execution. If you have not handled a real distributed training failure, explain the failure modes you would investigate without claiming operational experience you do not have.
When profiling, report the workload and measurement method. “The model is slow” is too broad. Distinguish preprocessing, data transfer, model execution, and evaluation. A local measurement does not establish production tail latency or capacity under concurrent traffic.
A preparation exercise can still be strong without a large system. A small component with explicit contracts and meaningful checks gives the interviewer something concrete to inspect. Expanding a toy project into a claimed production platform usually makes the evidence less credible.
Prepare research evidence that survives alternative explanations
Choose one project you know deeply. Write the research question as a claim that an experiment could weaken or support. Identify the baseline, intervention, outcome, and plausible confounders. If the result is purely exploratory, say so rather than retroactively inventing a preregistered hypothesis.
Ask whether the comparison changes more than one variable. A new model, larger dataset, longer training run, and different evaluator make a headline improvement difficult to attribute. You may need several comparisons to isolate the contribution. Explain which are available and which remain untested.
An ablation is useful when it tests a meaningful alternative explanation. Removing a component and observing a drop does not alone show why it helped; the removal may also change compute, optimization, or information access. Discuss those dependencies and the next comparison that would separate them.
Prepare a negative result. Describe an idea that did not work, how you determined that, and how it changed the next decision. Do not present every failed run as hidden evidence for the successful theory. Scientific judgment includes knowing when the evidence is insufficient.
For theoretical work, connect assumptions to the proposed application. A guarantee under independent samples or a restricted objective may not transfer directly to a changing deployment distribution. Explain the boundary rather than reciting a theorem as a universal reliability promise.
Evaluation is shared ground between the roles
Both roles need to know what the metric measures and what it leaves out. In the retrieval example, aggregate quality may hide poor performance on long documents or rare query types. A fair evaluation defines the population, labels, query grouping, and relevant baselines before interpreting an average.
Documentation-supported example: scikit-learn warns that preprocessing can leak information when it is fitted using test data; its guidance recommends separating training from evaluation correctly. This is an evaluation principle to apply in a project discussion, not evidence that an employer asks one particular leakage question. scikit-learn common pitfalls.
If several runs use different seeds, describe the variation rather than selecting only the best one. If the labels are noisy or subjective, discuss agreement and failure inspection. If a public benchmark may overlap with training material, identify that uncertainty instead of treating a benchmark rank as a complete capability measure.
Practice answering “What would change your conclusion?” A useful answer names a specific finding: the gain disappears under a matched compute budget, a held-out population reverses the ranking, or the method fails a known constraint. This exposes the connection between scientific reasoning and engineering decisions.
Confirm the interview loop before allocating practice time
Ask the recruiter which tasks are expected: general coding, ML implementation, mathematical discussion, research presentation, systems design, or project deep dive. Ask whether a presentation should emphasize one paper, several projects, or a proposed direction. Confirm permitted tools and any confidentiality boundaries.
Avoid assigning a universal percentage of preparation time to each area. If your confirmed loop includes an implementation round and your code practice is weak, that gap deserves attention even for a scientist title. If the role requires independent research direction and your strongest evidence is infrastructure delivery, prepare a defensible scientific question and its evaluation plan.
Use a gap-to-exercise mapping. A weak gradient explanation suggests a derivation and finite-difference check. A weak project story suggests an ownership diagram and evidence review. A weak systems discussion suggests tracing one experiment through storage, execution, failure, and recovery. Each exercise should produce a reviewable artifact.
After practicing, ask what evidence the session added. Reading another paper may broaden context but not repair an inability to explain your own baseline. Solving another generic algorithm may improve coding while leaving the role's experimental demands untouched. Keep useful work aligned with the actual vacancy.