The Role & Your Charter
What you'd actually own as a User Researcher at Cursor
The role in one paragraph
After this you can explain what this job is and is not, in Cursor's own words.
You design and run studies that tell Cursor what developers want, need and love in an AI coding tool and you turn that into insight the roadmap actually moves on.
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.
Cursor is the AI code editor built by Anysphere, used daily by millions of professional developers. The JD frames the job around one outcome: learn what those users want, need and love and guide the company's tradeoffs with that knowledge. This is a senior individual-contributor craft role at the 5–8+ years mark. You are not a manager and you are not a junior research assistant who takes notes while someone else owns the question.
The other non-negotiable is method breadth. This is a mixed-methods seat, so interviews alone won't carry it. The expectation is qualitative work combined with product analytics, surveys and experiments, woven into one story rather than four separate reports.
- Company
- Anysphere - the AI code editor Cursor, moving extremely fast.
- Seat type
- Senior IC craft role, 5–8+ years; not a manager, not an assistant.
- Mandate
- Learn what developers want, need and love; shape the roadmap.
- Method
- Mixed-methods: qual + analytics + surveys + experiments combined.
- Function stage
- A growing research function - early, high-impact, you help build it.
- Location
- SF or NY, full-time, in a flat and talent-dense org.
The phrase growing research function is the part candidates skim past. You are joining early. There is no deep research org to absorb you, no standing ops team to recruit your participants and no template library waiting on a shared drive. Early means high use and it means you build the scaffolding while you do the work.
- Senior IC, not management. You own the craft and the calls, not a team of reports.
- Mixed-methods, not interviews-only. The bar is reaching for the right method, including a survey or the analytics, when talking to people isn't it.
- Roadmap-driving, not report-producing. Success is a decision Cursor made differently, not a deck you delivered.
- Early-function builder, not process inheritor. You bring the playbook; nobody hands you one.
When the recruiter or hiring manager asks you to describe the role, compress it before you elaborate: “I own end-to-end research that tells Cursor what developers want, need and love, across qual, analytics, surveys and experiments and I push that into roadmap decisions.” Then add the texture that you know it's an early function you help build. That framing shows you read the charter, not just the bullet list.
Takeaway. This is a senior, mixed-methods IC role in a growing research function: you run end-to-end studies that tell Cursor what developers want, need and love and you drive the roadmap with the result.
Self-check
QWhich framing best matches how the JD defines this role?
Your four pillars of responsibility
After this you can map the JD's responsibilities to day-to-day work and to the rounds that test each one.
The JD's responsibilities collapse into four pillars and each one is probed in a specific round. Knowing which pillar a round is testing lets you bring the right story instead of telling the same case study five times.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Step through each round to see which pillar it tests - then bring the story that fits the room.
Own end-to-end studies: interviews, usability testing, surveys, experiments.
From the question, to the design, to fieldwork, to the readout - you hold the whole arc.
Help PM, design and eng test hypotheses and gather feedback fast.
Scoped to the cycle: a read that lands before the decision is made, not after.
Connect findings to product decisions, tradeoffs and strategy.
Synthesis is the craft - a tight, decision-ready narrative, not a raw data dump.
Build the systems, templates, recruiting pipelines and rituals.
ResearchOps so the next study is faster - for you and for everyone else.
These aren't four separate jobs. They're one loop: a question comes in, you pick a method and run it fast, you synthesize into a decision and you leave behind a template or a repo entry so the next person reuses your work. The infrastructure pillar is what keeps a one-person function from being the bottleneck.
- Pillar
- Research leadership
- What it looks like day-to-day
- Designing a study and defending the method choice
- Round that tests it
- Research-challenge round; portfolio deep dive
- Pillar
- Product acceleration
- What it looks like day-to-day
- A scrappy 5-interview read inside one sprint
- Round that tests it
- Hiring-manager screen; cross-functional round
- Pillar
- Insights translation
- What it looks like day-to-day
- A one-page readout that changed a roadmap call
- Round that tests it
- Portfolio deep dive; mixed-methods craft round
- Pillar
- Research infrastructure
- What it looks like day-to-day
- A reusable interview guide or participant pipeline
- Round that tests it
- Hiring-manager screen; values conversation
| Pillar | What it looks like day-to-day | Round that tests it |
|---|---|---|
| Research leadership | Designing a study and defending the method choice | Research-challenge round; portfolio deep dive |
| Product acceleration | A scrappy 5-interview read inside one sprint | Hiring-manager screen; cross-functional round |
| Insights translation | A one-page readout that changed a roadmap call | Portfolio deep dive; mixed-methods craft round |
| Research infrastructure | A reusable interview guide or participant pipeline | Hiring-manager screen; values conversation |
Each pillar has a home round - bring the story that fits the room.
Plenty of candidates can run a clean interview. Far fewer can take messy qual, a survey cut and an analytics trend and compress them into one recommendation a PM acts on that week. The JD calls for “concise, compelling, actionable insight that connects to decisions.” Treat insights translation as the pillar that separates a senior hire from a competent one.
Don't let the infrastructure pillar read as process for its own sake. In a flat, fast org, templates and repositories exist to make research faster, not to add ceremony. If your ops story sounds like you built a governance layer, reframe it as the thing that let the team get to insight in days instead of weeks.
Takeaway. Four pillars - research leadership, product acceleration, insights translation, research infrastructure - are one loop and each maps to a specific round; translation is the pillar that marks you as senior.
Self-check
QWhich of the four pillars most directly separates a senior researcher from a competent one and why?
The user is a professional developer
After this you can adapt your research instincts to a sophisticated, technical, opinionated audience.
Cursor's user is an expert developer working in an AI-native code editor. Studying that person is a different craft from consumer UXR and the interview will read you for whether you know the difference.
Cursor is a VS Code fork wired around proprietary models, so the surface is familiar to any engineer but the behavior is new. The people using it are technical, opinionated and time-poor. They are skeptical of fluffy research and they will notice immediately if your questions reveal you've never actually written code in the tool.
- Expertise
- They know their craft deeply - surface usability is table stakes, not the story.
- Recruiting
- Hard to reach and protective of their time; a no-show costs you a week.
- Skepticism
- They sniff out fluff fast; credibility is earned by speaking their language.
- What they value
- Speed, control, trust in AI output and staying in flow.
Translate “want, need and love” into this user's terms and it stops being abstract. Love here is rarely about a cleaner button. It's whether Tab predicts the edit they were about to make, whether they trust an agent's diff enough to accept it without reading every line and whether the tool keeps them in flow instead of pulling them out to babysit it.
Can they find the feature and complete the task?
First-run impressions and learnability dominate.
Does it fit a deep, idiosyncratic workflow under real pressure?
Edge cases, trust in AI output and long-run flow dominate.
Knowing the product surface is what lets you ask sharp questions instead of generic ones. If you can name the real workflows, you can probe where the experience actually frays.
“For a developer, ‘love’ isn't a delight moment - it's trust. I'd want to study where someone accepts an agent's multi-file diff without reading every line and where they don't, because that trust boundary is the real adoption curve for an AI editor. That's a question you can only ask well if you've felt that hesitation yourself in 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..”
The fastest way to lose the product round is to answer with a playbook that could apply to any app. “I'd run usability tests to see if users can complete the task” is a red flag for this user, because task completion is the floor for an expert. Ground every method in a real Cursor workflow and a real developer tension or you'll read as someone who studied the JD but not the tool.
Takeaway. Cursor's user is an expert, skeptical, time-poor developer; “want, need and love” means speed, control, trust in AI output and flow - and only real product familiarity lets you ask questions sharp enough to clear the bar.
Self-check
QWhy does studying Cursor's developer user differ from consumer UXR and how should that change your research focus?
What 'no narrow job descriptions' means for research
After this you can calibrate to Cursor's flat, scrappy operating model.
Cursor is a small, talent-dense, flat team where engineers write copy and answer support tickets. “No narrow job descriptions” is not a slogan, it's how the work gets done and research won't be siloed from it.
Practically, that means you do the whole job yourself. You recruit your own participants, write your own screeners, build your own templates and ship the insight without an ops team handing you a clean panel. The flip side is real autonomy: nobody is gating your questions or your methods.
- Self-recruiting
- You source and screen developer participants yourself - no ops backstop.
- Self-tooling
- You build the guides, surveys and repos as you go, then reuse them.
- Self-direction
- You set the agenda; there's no handed-down playbook to follow.
- Opinionated
- A strong point of view is expected - you propose the question, not just answer it.
The operating principle that follows is speed over perfection. A fast read on five developers that changes a decision this week beats a rigorous twelve-week study that lands after the feature shipped. The skill being tested is not whether you can run the perfect study - it's whether you can scope a good-enough one fast and name the tradeoff out loud.
- 1Start from the decision. What call is the team about to make and by when?
- 2Pick the lightest method that informs it. Five interviews, a quick survey or an existing analytics cut - whatever clears the bar in the time you have.
- 3Name the tradeoff. State what the speed costs you in confidence, so the team reads the result correctly.
- 4Leave a reusable artifact. A screener or guide that makes the next fast read even faster.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Naming the tradeoff is the gate that turns scrappy into rigorous - skip it and a thin study reads as definitive.
Frame yourself as the thing that makes a tiny team move faster and decide better, not the process owner everyone has to route through. In a flat org, a researcher who adds steps is friction; a researcher who removes uncertainty fast is impact. Every story should land on “this let the team move,” not “I made sure research was done properly.”
Don't confuse scrappy with sloppy. Speed over perfection is not permission to drop rigor silently - it's permission to make a deliberate, stated tradeoff. The senior move is “I ran five interviews instead of fifteen because the deadline was Friday and here's the confidence cost.” The junior move is presenting a thin study as if it were definitive.
Takeaway. In a flat org you do the whole job yourself and optimize for speed over perfection - scope a good-enough study fast, name the confidence tradeoff out loud and frame yourself as a force multiplier, never a gatekeeper.
Self-check
Signals you can't fake
After this you can identify the credibility markers an interviewer is listening for and how to demonstrate each.
Cursor's loop is built to read authenticity. The panel is listening for a handful of signals that a generic UXR candidate can't manufacture and most of them surface in how you tell a story rather than in a claim you make.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Two signals carry the most weight - and they're the two you can't manufacture in the room.
- Signal
- Mixed-methods fluency
- Faked version (red flag)
- “I'd run some interviews to understand it.”
- Real version (what to say)
- “Interviews were wrong here, so I pulled the analytics first, then surveyed to size it.”
- Signal
- Impact orientation
- Faked version (red flag)
- “I delivered a 40-page report.”
- Real version (what to say)
- “The team killed the feature based on what we found.”
- Signal
- Speed without sloppiness
- Faked version (red flag)
- “We ran a thorough 12-week study.”
- Real version (what to say)
- “Five interviews in three days and here's the confidence tradeoff I named.”
- Signal
- Product literacy
- Faked version (red flag)
- “Cursor is an AI coding tool.”
- Real version (what to say)
- “In 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., I noticed people hesitate before accepting a multi-file diff.”
- Signal
- Truth-seeking
- Faked version (red flag)
- “The research confirmed our direction.”
- Real version (what to say)
- “The data contradicted the VP's bet and I said so with the evidence.”
| Signal | Faked version (red flag) | Real version (what to say) |
|---|---|---|
| Mixed-methods fluency | “I'd run some interviews to understand it.” | “Interviews were wrong here, so I pulled the analytics first, then surveyed to size it.” |
| Impact orientation | “I delivered a 40-page report.” | “The team killed the feature based on what we found.” |
| Speed without sloppiness | “We ran a thorough 12-week study.” | “Five interviews in three days and here's the confidence tradeoff I named.” |
| Product literacy | “Cursor is an AI coding tool.” | “In 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., I noticed people hesitate before accepting a multi-file diff.” |
| Truth-seeking | “The research confirmed our direction.” | “The data contradicted the VP's bet and I said so with the evidence.” |
The real versions are concrete and end in a decision or a tension; the faked versions are abstract.
Two of these deserve extra weight because they're the ones Cursor screens hardest for. Product literacy is binary in the room: either you've actually written code in Cursor and can talk about a real workflow or you haven't and it shows in seconds. Truth-seeking is cultural: the org prizes following the data over the loudest opinion, including up the chain.
Use Cursor for real work before the loop, not a demo poke.
Have one specific observation about a real workflow ready to share unprompted.
Bring a story where your data contradicted leadership.
Show you surfaced the uncomfortable finding and what changed because you did.
Pre-load one concrete story for each signal so you're never reaching in the moment. The strongest are the ones that double up: a mixed-methods study that contradicted leadership, was run fast and changed a decision hits four signals in a single narrative. Specificity is the proof - a real workflow, a real number, a real decision.
Cursor runs a paid, project-heavy onsite partly to see whether you truly know the tool and the developer. Polished UXR vocabulary won't clear it on its own. If you haven't used Cursor on real code by the time you interview, fix that first - it's the cheapest, most impactful prep you can do.
Takeaway. Five signals carry the loop - mixed-methods fluency, impact orientation, speed without sloppiness, product literacy, truth-seeking - and they're proven by concrete stories ending in a decision, not by claims; using Cursor on real code is the cheapest way to pass the authenticity read.
Self-check
QWhich two signals does Cursor screen hardest for and why are they the hardest to fake?