The Interview Loop
Stages, format, who you meet, how to prep each
Loop overview and how Cursor differs
After this you can sequence the stages and identify the real decision round.
Cursor evaluates a Research Scientist across a handful of stages, but the offer is decided in one of them: a paid, multi-hour work simulation where they put you in the seat and watch how you actually operate. Everything before it is a filter; the onsite is the verdict.
Hold the whole shape in your head before you prep a single answer. Each stage tests a different slice of the same claim - that you can take an ambiguous RL-for-coding problem and drive it to a result that ships. The screens check fundamentals and signal. The deep-dive checks whether you own your own past work. The onsite checks whether you can do the job.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Step through each stage. Counts and order shift by candidate and seniority - the structure is reliable, the exact counts are not.
- 1Recruiter / hiring-manager screen (~30-45 min). Interest, research background, motivation and logistics. A real reason you want this research, not a generic love of LLMs.
- 2Technical phone screen(s) (1-3 rounds, ~60 min). ML/RL fundamentals plus a hands-on coding or research-reasoning exercise. Depth over trivia.
- 3Research deep-dive / past-work presentation. Present a prior project and defend every technical decision under adversarial questioning. Standard at top research labs; expect it layered in for this role.
- 4Paid practical onsite (one or two ~8-hour days). A real, project-shaped problem - Cursor's actual decision round - with open AI-tool usage allowed and expected.
- 5Team / culture + values conversation. Peers and research/eng leads, more common for senior hires. Whether you debate without ego and ship together.
- Stage
- Recruiter / HM screen
- Rough time
- 30-45 min
- What it decides
- Motivation, research fit, why product-impact research
- Stage
- Technical screen(s)
- Rough time
- ~60 min each (x1-3)
- What it decides
- RL/ML fundamentals; live reasoning under pressure
- Stage
- Research deep-dive
- Rough time
- ~45-60 min
- What it decides
- Ownership of past work; truth-seeking under probing
- Stage
- Paid practical onsite
- Rough time
- ~8 hrs (paid), 1-2 days
- What it decides
- Autonomy, judgment over AI output, end-to-end execution
- Stage
- Team / values
- Rough time
- ~45 min
- What it decides
- Flat-team collaboration, intellectual honesty
| Stage | Rough time | What it decides |
|---|---|---|
| Recruiter / HM screen | 30-45 min | Motivation, research fit, why product-impact research |
| Technical screen(s) | ~60 min each (x1-3) | RL/ML fundamentals; live reasoning under pressure |
| Research deep-dive | ~45-60 min | Ownership of past work; truth-seeking under probing |
| Paid practical onsite | ~8 hrs (paid), 1-2 days | Autonomy, judgment over AI output, end-to-end execution |
| Team / values | ~45 min | Flat-team collaboration, intellectual honesty |
Counts and order vary by candidate and seniority; treat these as a typical pattern, not a contract.
Cursor's onsite is a work simulation rather than a whiteboard. They hand you a project-shaped problem, pay you for the day and watch how you operate when no one is telling you what to do. Bias your prep toward operating well under ambiguity, not toward memorizing RL trivia, because the trivia gets checked in 60 minutes and the operating gets checked over 8 hours.
The number of technical screens, whether the deep-dive is a separate session or folded into a screen and whether you get one onsite day or two all shift by candidate and level. If a recruiter describes a different sequence than what you read here, believe the recruiter. The structure is reliable; the exact counts are not.
The single biggest differentiator for this role is showing that research at Cursor ships to millions and is validated on real user data and that you want exactly that. Name it early. The bar here is production impact, not papers and a candidate who frames their motivation around shipped models reads as already aligned with how the team works.
Takeaway. Several filter stages, then a paid multi-hour onsite work simulation that is the real decision; prep for operating under ambiguity, not for trivia.
Self-check
QWhich stage decides the offer in Cursor's Research Scientist loop and what makes its format distinctive?
Recruiter & hiring-manager screen
After this you can deliver a crisp research narrative and motivation on the first call.
The first call is short and easy to underestimate. It sorts for a specific reason you want Cursor's research, a research background that fits RL-for-coding and the basic logistics that make a hire possible. Generic enthusiasm fails here faster than anywhere else in the loop.
- Length & tone
- 30-45 min, conversational - background, motivation and logistics, not a quiz.
- Research fit
- Where your work sits relative to RL for LLMs, reward modeling and agent-assisted coding.
- Why Cursor
- A concrete bet you care about: RL on real sessions, graders for non-verifiable rewards, online RL.
- Logistics
- Location (SF / NY), visa and sponsorship status and timeline - surfaced early on purpose.
Your application already carries signal before this call. The job asks for a GitHub and a project description, so your prior work is screened before you ever talk to a human. Treat the recruiter call as the moment to turn that paper trail into a story.
Walk in with three things ready
One project where you owned an ambiguous problem end-to-end.
Hypothesis, what you built and the result you shipped or validated.
Name a research direction you find exciting and why.
RL for longer-horizon coding, graders or online RL behind Tab.
Location preference, work authorization and timeline.
Have clean answers so nothing stalls the loop later.
“I want to work on AI” and “I love language models” are the answers every candidate gives, so they carry no signal. Anchor instead to something only you could say: a reward-hacking failure you debugged, a credit-assignment problem in a long-horizon agent or a specific reason you think training on real user data beats a curated benchmark.
“I've spent the last year on RL post-training and the part I keep coming back to is graders for tasks unit tests can't score - partial credit on multi-file edits. Cursor is one of the only places where that research ships into a model millions of people use the next week and that loop from idea to shipped model is exactly what I want to be inside.”
Takeaway. Bring a 2-minute end-to-end ownership story, one concrete Cursor research bet and settled logistics - and never reach for “I love LLMs.”
Self-check
Technical phone screens
After this you can know what the 60-minute screens test and how to pass them.
The technical screens mix RL/ML fundamentals questioning with a hands-on coding or research-reasoning exercise. They are looking for depth, not trivia: can you derive the core math, reason about an experiment and stay coherent when you are wrong.
- What they probe
- RL fundamentals
- What good looks like
- Derive a policy gradient; explain advantage, KL control, on- vs off-policy and async RL.
- What they probe
- PPO / GRPO
- What good looks like
- State each objective, why the clip or group baseline exists and a failure mode of each.
- What they probe
- RLHF vs RLVR
- What good looks like
- Reward models from human preferences vs verifiable rewards from tests; tradeoffs and where each breaks.
- What they probe
- Transformer internals
- What good looks like
- Q/K/V and scaled dot-product attention, multi-head, KV cache, decoding and sampling.
- What they probe
- Coding exercise
- What good looks like
- Implement or debug a small component: a loss, a sampling loop or a KV cache.
| What they probe | What good looks like |
|---|---|
| RL fundamentals | Derive a policy gradient; explain advantage, KL control, on- vs off-policy and async RL. |
| PPO / GRPO | State each objective, why the clip or group baseline exists and a failure mode of each. |
| RLHF vs RLVR | Reward models from human preferences vs verifiable rewards from tests; tradeoffs and where each breaks. |
| Transformer internals | Q/K/V and scaled dot-product attention, multi-head, KV cache, decoding and sampling. |
| Coding exercise | Implement or debug a small component: a loss, a sampling loop or a KV cache. |
Expect a subset, not all of it, in any single 60-minute screen.
The coding portion is usually a focused component rather than a sprawling system. You might be asked to write the GRPO advantage from a batch of rewards or to find the bug in a decoding loop that silently breaks the KV cache.
import torch
def group_advantages(rewards, group_size, eps=1e-6):
# rewards: (B,) flat tensor of B = num_groups * group_size samples
r = rewards.view(-1, group_size) # (G, group_size)
baseline = r.mean(dim=1, keepdim=True) # per-prompt baseline
std = r.std(dim=1, keepdim=True)
adv = (r - baseline) / (std + eps) # normalize within group
return adv.view(-1) # back to (B,)Think out loud the entire time. Interviewers score your reasoning path and how you handle being corrected far more than a flawless first answer. When you hit a fork, say which option you are taking and why; when you are unsure, say what you would measure to find out. Silence reads as either stuck or hiding.
You can recite the PPO objective and still fail the next question: why does the clip exist and what happens to the gradient when the ratio leaves the clip range. Prep the second and third question deep on each topic, because that is where a memorized answer collapses and a real one holds.
Takeaway. Derive the core RL math live, debug a small training component and narrate your reasoning - the screen scores how you think, not a perfect first answer.
Self-check
QIn a 60-minute technical screen you blank on a derivation midway. What is the highest-signal way to handle it?
The research deep-dive
After this you can structure a past-work presentation that survives hard questioning.
The deep-dive is where you defend a real project under adversarial questioning. Pick one where you made the key decisions, because the whole round is built to find out whether the choices were yours and whether you understood them.
- 1Problem and hypothesis first. Open with the question you were answering and what you believed before you ran anything. Set the stakes in one or two sentences.
- 2Method, with the alternatives named. Walk the approach you took and, critically, the ones you rejected and why. Naming rejected alternatives is what separates an owner from a passenger.
- 3How you knew it worked. Quantify the result and the eval that proved it. State the metric, the baseline and the variance you had to rule out.
- 4The weakest part, volunteered. Close with the limitation you would attack next. Saying it before they find it is the single strongest move in the round.
Expect probing that is adversarial on purpose: “what would you do differently,” “how do you know it wasn't noise,” “what's the weakest part of this.” These are not traps to dodge. They are the test itself.
Cursor screens hard for caring more about what's true than about being right. In the deep-dive that means volunteering a real limitation scores higher than defending a flawed choice. If a reviewer finds a hole you knew about and hid, you fail the value, not just the question.
“The eval had a contamination risk I didn't fully close - here's how I'd test for it.”
“I'd rerun with more seeds; the effect was real but my n was small.”
“The result speaks for itself.”
“That edge case never came up, so it didn't matter.”
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The same probe, two answers. The round scores whether you care more about what's true than about being right.
A flashy team result you contributed one piece to will collapse on the third “why” because you can't defend decisions you didn't make. A smaller project you drove end-to-end is far stronger material, because you can answer every follow-up down to the choice of optimizer.
Takeaway. Pick a project you owned, lead with problem then method then proof, name your rejected alternatives and volunteer the weakest part before they find it.
Self-check
The paid practical onsite
After this you can operate like a Cursor scientist for a multi-hour real work simulation.
This is the round that decides the offer. One or two roughly 8-hour paid days on a real, project-shaped problem, with AI tools including Cursor explicitly allowed. They are not testing whether you can use the model. They are testing your judgment in using it.
- Judgment over AI
- Debugging, rejecting bad suggestions and knowing when not to trust the model.
- Autonomy
- Driving an ambiguous problem with little direction, the way the real job runs.
- Scope & time
- Stating assumptions, prioritizing and getting to a working, validated result.
- Narration
- Explaining your decisions as you go, so they can see how you think, not just what you shipped.
- 1Frame and assume. Restate the problem in your own words, write down the assumptions you're making and pick the smallest version that proves the idea.
- 2Use AI with a leash. Let Cursor draft and accelerate, then read every line, run it and verify the claim before you build on it.
- 3Get to a validated result. A working, measured outcome on a narrow slice beats an ambitious half-built system with nothing you can trust.
- 4Narrate the decisions. As you cut scope or reject a suggestion, say why out loud or in comments, so the reasoning is legible.
Pasting raw model output without verifying it is the clearest documented failure mode. The role is human-in-the-loop research; an AI-native scientist exercises judgment over raw output rather than shipping it blind. If the model hands you a grader and you wire it in without checking what it actually rewards, you've demonstrated the opposite of the trait they hire for.
“Cursor wrote this reward function in one shot, but before I trust it I want to see what it scores on three adversarial cases - a passing edit, a reward-hacked stub and a partial multi-file change. If it can't separate those, I'm not using it.”
Treat scope like the real job, not like a test you must finish. State up front what you're prioritizing and what you're explicitly cutting, then deliver a smaller validated result with the limitations named. A scientist who lands one trustworthy finding and is honest about its bounds outscores one who sprawls and ships something they can't stand behind.
Takeaway. The onsite tests judgment, not AI usage: frame and assume, use the model on a leash, land a validated result on a narrow slice and narrate every decision.
Self-check
QDuring the onsite, Cursor generates a plausible-looking training script that runs without errors. What's the right move?
Team & values conversation
After this you can prepare for the culture round with potential teammates.
The final conversation is with potential teammates and research or eng leads and it's more common for senior hires. It's a read on how you think and collaborate in a flat, talent-dense team where ideas get debated hard and decisions get made fast.
- They screen for spirited debate without ego: can you disagree, update when you're wrong and still ship together.
- They check that you've actually read their research and formed your own opinions about it.
- It's mutual - your questions about their open problems and how decisions get made signal how you'd operate as a peer.
Come having read the work, with opinions
Generic praise of Cursor reads as a candidate who skimmed the careers page. Showing you've read the ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. model reports and the Tab online-RL post and that you have a specific view on a tradeoff in them, reads as a future colleague who already thinks about this work.
Online RL on live Tab traffic: exploration, logging, off-policy correction.
Graders for non-verifiable rewards and the reward-hacking risk they carry.
“Where does offline eval still disagree most with shipped impact?”
“How do disagreements about a research bet actually get resolved here?”
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The behavioral signals a flat, talent-dense team screens hardest for - ranked by how much they move the decision.
When a teammate pushes back on something you said, treat it as a chance to demonstrate the value, not to win. Steelman their point, say what would change your mind and update visibly if they're right. In a flat team, the ability to lose an argument gracefully and converge on what's true is a hiring signal, not a weakness.
Name-dropping a paper you didn't read collapses on the first specific question. If you haven't gone deep on the ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. reports or the Tab-RL post, read them before this round - surface-level familiarity is worse than honest curiosity about where you'd start.
Takeaway. Show you can debate without ego and that you've actually read their research - and bring sharp questions about their open problems and how decisions get made.