Interview prep
Cursor Research Scientist Interview: Questions & How to Prepare
Cursor's Research Scientist trains frontier coding agents by scaling reinforcement learning on real user data, owning hard problems end to end. Interviews probe deep RL, strong engineering, data judgment, and a truth-seeking bent. That depth only comes from doing the research, so prepare by running experiments rather than rereading papers.
On this page
What does a Cursor Research Scientist actually do?
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.
- Team
- Engineering.
- Locations
- San Francisco and New York, flagged on-site rather than remote.
- Employment
- Full-time.
- Setting
- A small-team setting inside a very flat, "small and talent dense" org.
- What you train
- Frontier coding agents, via RL on real user data.
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.
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.
This exact topic is a hands-on lesson: The Interview Loop — about 19 minutes, free to read.
What does the Research Scientist interview assess?
Start with the honest part: Cursor doesn't publish an interview loop for this role. The Research Scientist page carries no "how we hire" note: no stages, no take-home policy, just an application form. So treat any post claiming to know "the Cursor research loop" with skepticism, and read the posting's fit criteria as the real map of what gets assessed.
When a company won't publish its format, prepare what every format samples. The posting spells out the short list: deep RL, strong engineering, comfort with ambiguity, care for data, a truth-seeking temperament. That transfers to a screen, a paper deep-dive, or a practical exercise equally.
Map the posting's "you may be a fit if" lines onto assessment areas and you get five. Everything an interviewer probes maps back to one of them:
The first fit line asks for "a deep background in RL and strong machine learning fundamentals." Expect to be pushed past textbook level: reward design, credit assignment over long horizons, and where methods break at scale.
It wants "an excellent programmer and software engineer." Research here ships into the next model, so be ready to show you can build the training, eval, and data yourself rather than hand it off.
"Handle ambiguous research tasks with little guidance" is stated plainly. Expect to describe how you scope an open problem, choose the first experiment, and decide when a line of work is dead.
"You care a lot about data quality, and can dive into the data." Expect questions about catching a bad datapoint, raising a dataset's difficulty, or debugging a result that turns out to be a data artifact.
The posting values people "aiming to learn more about the science than proving your ideas are correct." Expect behavioral probes into a time your data killed your own hypothesis, and what you did next.
What interview questions should I expect?
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.
- From the posting
- "drive effective RL or mid-training research"
- Expect to be asked to...
- Walk through an RL or mid-training project you led: the reward, the setup, what you measured, and what you'd change to get the same signal with less compute. Signal: strong answers name a measured result and the compute trade-off; weak ones recite the method with no number that moved.
- From the posting
- Handle "longer horizon tasks"
- Expect to be asked to...
- Reason about credit assignment and stability over long trajectories: where the signal gets sparse, and how you'd keep training from drifting.
- From the posting
- "Train graders ... with non-verifiable reward"
- Expect to be asked to...
- Design a grader for a coding outcome you can't unit-test: how you'd approximate a reward, and how you'd notice the model gaming it. Signal: strong answers assume reward hacking and design a check against it; weak ones trust the grader's score.
- From the posting
- "Improve the quality and difficulty of datapoints"
- Expect to be asked to...
- Propose how you'd raise a training set's difficulty and quality, and how you'd tell a genuine gain from a leak or artifact.
- From the posting
- "Realtime RL for coding agents"
- Expect to be asked to...
- Talk through learning from live user interactions: the feedback signal, the latency and safety constraints, and the failure modes.
- From the posting
- Own problems "end-to-end" with high autonomy
- Expect to be asked to...
- Take an ambiguous goal and, out loud, form a hypothesis, pick the first experiment, and name the eval that would tell you it worked.
- From the posting
- "truth-seeking ... more about the science than proving your ideas"
- Expect to be asked to...
- Tell a story where the data contradicted you, and show what you changed rather than what you defended. Signal: strong answers let the data overturn the hypothesis; weak ones defend the original idea.
| From the posting | Expect to be asked to... |
|---|---|
| "drive effective RL or mid-training research" | Walk through an RL or mid-training project you led: the reward, the setup, what you measured, and what you'd change to get the same signal with less compute. Signal: strong answers name a measured result and the compute trade-off; weak ones recite the method with no number that moved. |
| Handle "longer horizon tasks" | Reason about credit assignment and stability over long trajectories: where the signal gets sparse, and how you'd keep training from drifting. |
| "Train graders ... with non-verifiable reward" | Design a grader for a coding outcome you can't unit-test: how you'd approximate a reward, and how you'd notice the model gaming it. Signal: strong answers assume reward hacking and design a check against it; weak ones trust the grader's score. |
| "Improve the quality and difficulty of datapoints" | Propose how you'd raise a training set's difficulty and quality, and how you'd tell a genuine gain from a leak or artifact. |
| "Realtime RL for coding agents" | Talk through learning from live user interactions: the feedback signal, the latency and safety constraints, and the failure modes. |
| Own problems "end-to-end" with high autonomy | Take an ambiguous goal and, out loud, form a hypothesis, pick the first experiment, and name the eval that would tell you it worked. |
| "truth-seeking ... more about the science than proving your ideas" | Tell a story where the data contradicted you, and show what you changed rather than what you defended. Signal: strong answers let the data overturn the hypothesis; weak ones defend the original idea. |
Question types derived from the posting's own words, not Cursor's verbatim questions.
If you can do each row on real research of your own, not a memorized script, you're prepared regardless of how an interviewer phrases it.
How do I prepare for the Cursor Research Scientist interview?
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:
- 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.
- 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.
- 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.
- 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.
- 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.
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.
Each day, take one hypothesis about your model or agent, build the smallest eval or grader that could disprove it, and log what the data actually said, not what you hoped. The free practice track turns these reps into a scheduled curriculum ending in a mock research loop.
What does the posting require, and what does it not?
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.
- Background
- A deep background in RL and strong machine-learning fundamentals.
- Engineering
- An excellent programmer and software engineer, not a theorist who hands off the code.
- Autonomy
- Comfort handling ambiguous research tasks with little guidance.
- Data
- Real care for data quality, and the instinct to dive into the data.
- Temperament
- Truth-seeking: learning the science over proving yourself right.
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.
Frequently asked questions
Does Cursor publish its Research Scientist interview questions?
No. The posting says what the role does and who fits, but it publishes no question bank, stage list, or scoring rubric, not even a short 'how we hire' note. Prepare the criteria it does state: deep RL, strong engineering, data judgment, and a truth-seeking bent.
Where is the Cursor Research Scientist role based?
The posting lists San Francisco and New York, full-time on the Engineering team, and it's flagged on-site rather than remote. Check the live posting for the current location policy.
What does the Research Scientist interview focus on?
Read from the posting: reinforcement learning for coding agents, training graders for non-verifiable reward, raising datapoint quality and difficulty, and realtime RL. Expect deep RL and ML fundamentals plus evidence you can build the training, eval, and data yourself.
How should I practice for the research deep-dive?
Bring one RL or mid-training result you can defend end to end: hypothesis, reward or eval, experiment, and what the data changed. The free interview-prep practice track runs a mock research deep-dive and graders and reward design for exactly this.
Sources & last verified
Cursor ships frequently. Facts verified against primary sources on July 22, 2026.