The Role & Your Charter

Cursor's stated goal is to automate coding. A Research Scientist exists for one reason inside that goal: make the next coding-agent model meaningfully better, primarily through reinforcement learning trained on real user data.

Read this section as the role contract. The diagram or table names the surface area, but the interview signal is whether you can turn it into a clear operating claim: what you own, what you do not own, what evidence proves the work is working and where judgment matters.

That is the whole job in a line. Everything else in the JD is a specialization of it. You are not hired to survey a field, write a position paper or maintain a benchmark. You are hired so that the model shipping to Cursor users a quarter from now is better than the one shipping today and so that you can say why it improved.

The center of gravity is RL, not pretraining and not prompt engineering. The named surface area is concrete.

• Extending RL to longer-horizon agent-assisted tasks - episodes that span many tool-calls, not single completions.
• Compute-efficient training - more capability per FLOP, training at lower cost.
• Graders for non-verifiable rewards - scoring code where unit tests can't fully judge quality.
• Datapoint quality and difficulty - what makes a training example good, hard and representative of real requests.
• Realtime / online RL - learning from live user interactions, as shipped behind Cursor TabCursor's original autocomplete: multi-line, edit-aware suggestions you accept with the Tab key..

The org placement is a tell. This role lives under Engineering, not in a separate research division that hands findings over a wall. Research and engineering are not different castes at Cursor: you are expected to build the training, eval and data systems your hypotheses need, then ship the win yourself.

“End-to-end ownership” is the phrase the JD leans on hardest and it is easy to nod past. Make it concrete: there is no PM handing you a spec and no separate data or infra team to absorb the unglamorous half of the work.

The loop you run, start to finish, looks like this.

1. 1Form a hypothesis. A specific, testable claim - e.g. a denser process reward over tool-calls will fix credit assignment on long episodes - not a vague theme.
2. 2Design the experiment. Decide what varies, what is held fixed, the baseline, the metric and what result would change your mind.
3. 3Build what the test needs. Write the eval harness, the sandboxed environment, the data pipeline, the grader - whatever doesn't exist yet.
4. 4Run it and read the metrics. Distinguish signal from noise, watch for reward hacking and contamination and decide whether the hypothesis held.
5. 5Push the win into the next model. Land it in the training recipe so the improvement actually ships, then verify it survives at production scale.

Step 3 is where the role diverges from most lab jobs. Build what you need is not a slogan; it means you personally write production-grade infra, not specs you hand to engineers.

The charter resolves into four concrete research bets. You should be able to define each, say why it's hard and connect it to a Cursor product. Treat these as the four topics most likely to surface in a research-reasoning screen.

Notice the through-line. Three of the four are about reward: where it comes from, how dense it is and whether it can be trusted. RL on coding agents is largely a reward-engineering problem and the JD's emphasis on graders and long horizons reflects that.

“state-of-the-art coding agent” is not an abstraction here. It maps to specific shipped systems and the team's published research describes how they were built. Showing fluency with the actual products is a real differentiator, because most candidates discuss RL in general terms.

Two product surfaces anchor the work and they pose different RL problems.

Base-model selection is itself a research decision. Picking a strong open MoE and applying continued pretraining plus RL is a compute-efficiency play: you spend FLOPs where they buy the most product quality instead of re-learning what a good base already knows.

Compile 2026 updates the model story: Composer 2.5The current Composer release, better at long-running tasks and at judging when a job needs a light touch versus deep work. is the available model step to study now, while Cursor says it is training a significantly larger model from scratch with SpaceX using 10x more total compute. In an interview, keep those two facts separate: shipped capability versus future training direction.

The fourth bet from the JD shows up physically as infrastructure. Research here owns the systems, not just the algorithms.

• Anyrun runs hundreds of thousands of sandboxed coding environments so RL can execute and grade real code at scale.
• The RL pipeline is fully asynchronous and multi-region, so rollout and training don't block each other across geographies.
• Low-precision MoE kernels on Blackwell GPUs are part of how training stays compute-efficient.

This role rewards a specific disposition and it punishes the opposite. A brilliant paper-first researcher can genuinely struggle here and naming the failure modes honestly is part of preparing - both to decide if you want it and to speak to it in the values round.

Four mismatches show up most often.

The deepest of these is truth-seeking. The team screens hard for caring more about learning what's true than about being right. In practice that means you celebrate a clean negative result that kills your favorite idea, because it saved the next month of wasted compute.

One more cultural signal is easy to underrate: AI-native authenticity. The onsite explicitly allows AI tools, including Cursor and you're expected to wield them with judgment rather than paste model output blindly. Daily hands-on fluency with Cursor is a genuine differentiator, not a checkbox.