Cursor Research Scientist Interview: Questions & How to Prepare

A Cursor Research Scientist trains the models behind Cursor's coding agents. The posting's charge is direct: Cursor "train[s] frontier coding agents and scale[s] RL on real user data to make them increasingly effective," and it's looking for scientists who can "drive effective RL or mid-training research in a small-team setting." The work is research, but it ships into the product.

The posting frames the day-to-day as owning "ambiguous, hard research problems end-to-end," and it promises "significantly more scope and autonomy than in other research labs" (its words, not a recruiter's). That ownership runs a full loop:

• Form hypotheses about what will make the agents better.
• Design experiments to test them.
• Build the training, eval, and data needed to run those experiments.
• Push results into the next model.

The loop is listed in an order, and I think the order is doing work. Hypothesis first, then the experiment, then the training and eval and data that particular experiment needs. Reverse it and you build a clean pipeline first, then go hunting for a question it happens to answer. The posting states that sequence without explaining it.

Four concrete workstreams are named on the posting. Read them closely, because the interview will sample the judgment behind each:

• Improve Cursor's understanding of RL: handling longer-horizon tasks, and training with less compute.
• Train graders to improve performance on coding tasks with non-verifiable reward.
• Improve the quality and difficulty of the datapoints used to train the models.
• Realtime RL for coding agents.

Two of those four lines are about where the reward and the data come from, and only one is squarely about the algorithm. Which is not where most RL prep goes. Budget yours the other way.

Cursor doesn't publish an interview loop for this role, so the posting's fit criteria are the only reliable map of what gets assessed. The Research Scientist page carries no "how we hire" note: no stages, no take-home policy, just an application form. Treat any post claiming to know "the Cursor research loop" with skepticism.

Map the posting's "you may be a fit if" lines onto assessment areas and you get five, and most of what an interviewer probes should trace back to one of them:

The failure I'd expect here is arriving as one half of the posting. Plenty of candidates bring deep RL reading with no system they built themselves, plenty of strong engineers have never designed a reward, and the missing half surfaces in the first follow-up question. Most of that cost is paid before the round even starts, because reading one more paper is the comfortable way to prepare and it leaves the gap where it was. Work the half you are weaker on.

No one outside Cursor can hand you its real questions, so this page derives the question types from the posting's own responsibilities and fit lines. Each row traces to something the JD asks of the role, and to what a strong answer has to show.

The first row asks for the same signal with less compute, which sounds like a budget question and mostly isn't. Cutting compute forces you to say which part of the run was producing the learning, and that is a claim about your experiment rather than about your cluster. If the cheaper version stops working, check the eval before you touch the algorithm, because a number that only moves at full scale is often measuring variance.

On the grader row, the answer that lands assumes the reward gets gamed. Coding rewards are cheap to hack. An agent can delete the failing test, or hard-code the expected output for the exact inputs the test uses, and the score goes green either way. Saying you would read the highest-reward trajectories by hand is probably the strongest single sentence you can offer there.

The realtime row is the least paper-shaped of the four. The hazard an interviewer will listen for is selection bias: you only see feedback on the suggestions the deployed model chose to show, so the log is not a random sample of what the model could have done. Exploration and off-policy correction are the standard fixes to name.

If you can answer each row from research you ran yourself, you're prepared regardless of how an interviewer phrases it.

Preparation for a research role is mostly evidence and reasoning: a body of work you can defend, and a habit of following the data. Concretely:

1. 1Bring one RL or mid-training result you can defend end to end: the hypothesis, the reward or eval you built, the experiment, and what the numbers made you change. The posting cares about the whole loop, not a single clever trick.
2. 2Rehearse the graders-and-rewards problem out loud. Pick a coding outcome with no clean unit test and design a grader for it, including how you'd catch the model gaming it. Non-verifiable reward is named on the posting.
3. 3Have a data-quality story ready: a time you found a bad datapoint, raised a set's difficulty, or traced a suspicious result back to the data rather than the method.
4. 4Use Cursor daily on real work so you understand the product your research would ship into. Know the current surfaces and model story. See what changed in Cursor in 2026, and start from Cursor basics if any surface is unfamiliar.
5. 5Practice reasoning in the open. Take an ambiguous goal and narrate forming a hypothesis, choosing the first experiment, and naming the eval that would settle it. That's the posting's "end-to-end" ownership in miniature.

The first step goes first because it carries most of the others. Rehearsing graders and having a data-quality story ready are both ways of defending a result you actually ran, and so is narrating an ambiguous goal out loud. My instinct used to be to bring the biggest result I had. That's the wrong filter. Bring the one where you built the eval yourself, even when the headline number was smaller, because the follow-ups dig into how you knew it worked.

Which evidence travels depends on where you did the work. If the eval harness or the training data on your best project belonged to another team, name that boundary and say what you built on your side of it.

For a structured version, the free interview-prep practice track runs RL-for-coding-agents work, graders and reward design, and a mock research deep-dive so you rehearse under realistic constraints. Treat it as structured practice for the bar this posting sets, not as Cursor's official process.

The requirements are short and specific, and what's missing is as informative as what's there. There's no stated degree, publication count, or years-of-experience bar. The fit lines are about capability and temperament.

Just as telling is what the posting does not state. Don't assume any of these:

• A required degree, PhD, or publication record. None is mentioned.
• A specific framework or stack, or a minimum years of experience.
• A remote option. The posting lists San Francisco and New York and is flagged on-site.
• An interview format, timeline, or number of rounds. The posting states none, so don't assume one.
• A salary range or equity band. Compensation is not specified on the page.

The absence of a degree line cuts both ways. Nothing in the posting screens you out for lacking a PhD, and nothing in it tells an interviewer how to believe "a deep background in RL" either, so the burden moves onto experiments you can walk through. A publication record carries that. So does a run you can narrate start to finish, and given how the fit lines are written I'd weight the second more heavily.

Pay isn't on the page either, so any figure you have seen quoted for this role came from somewhere other than Cursor. Ask the recruiter.