Capstone: The Mock Loop
Run the whole loop end-to-end and self-score
The Cursor research-challenge prompt
After this you can complete a realistic end-to-end research challenge.
The research-challenge round is the only part of the loop where the panel watches you think, not just hear you narrate the past. Treat it as a live audition for the job, not a quiz.
Cursor runs a paid, project-heavy onsite that mirrors the engineering loop. You will get a prompt about the developer and the product, then you design a study and defend the method choices to a panel of researchers. The bar is senior-IC: a plan that ships insight fast, holds up under pushback and connects to a roadmap decision someone actually has to make.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
This capstone mocks rounds 3–7. Step through each stage to see where the four mock rounds slot in.
Spend the first 90 seconds restating the question and naming the decision it informs before you touch method. "Before I design anything: who is going to act on this and what would they do differently depending on what we learn?" That single move separates a senior researcher from a methods technician.
A worked promptuse this as your rehearsal target
Work the same prompt every time you practice so you can feel yourself getting faster: Cursor wants to know whether developers trust the Agent to make multi-file changes unsupervised - design the research. It is a real Cursor tension, it mixes attitude with behavior and it forces a method choice between what people say and what they do.
- 1Frame the decision. Trust here is not one thing. Split it into the decision it drives: should the Agent default to auto-applying multi-file diffs or keep a review gate? Name that the moment you start.
- 2Sharpen the question. Turn the vague "do they trust it" into answerable sub-questions: where does trust break (which file types, which blast radiusHow much breaks if a change goes wrong; the scope of potential damage.), what recovers it (diff preview, undo, tests passing) and whether stated trust matches actual accept/revert behavior.
- 3Pick the method for the question. This is generative-into-evaluative. You need behavioral signal on what developers already do, plus moderated sessions to explain why the revert happened.
- 4Define participants and sampling. Segment by stakes, not by demographics: solo side-project users versus engineers shipping to a shared production repo. Trust thresholds differ enormously across that line.
- 5State analysis up front. Decide before fieldwork how you will code the qual and which behavioral metric (revert rate on multi-file Agent edits) anchors the quant. Pre-committing stops post-hoc storytelling.
- 6Map findings to decisions. For every plausible result, write the product move it triggers. A plan that cannot change a decision is a literature review.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The two ▲ GATE steps are where senior candidates separate from juniors - don't skip them under time pressure.
The 5–8 slide planwhat the panel expects on the page
Whether it is a whiteboard or a take-home deck, the skeleton is the same. Keep it to one idea per slide and lead with the question, not the method.
- Slide
- 1. Question + decision
- What goes on it
- The sharpened question and the roadmap call it informs
- What it proves to the panel
- You research toward a decision, not toward a report
- Slide
- 2. Method + rationale
- What goes on it
- The methods chosen and the alternatives you rejected
- What it proves to the panel
- You can defend a tradeoff, not just list techniques
- Slide
- 3. Participants + sampling
- What goes on it
- Segments, n, recruit source, screening criteria
- What it proves to the panel
- You can reach real professional developers, fast
- Slide
- 4. Timeline
- What goes on it
- Fieldwork, analysis, readout dates
- What it proves to the panel
- You ship on a startup clock
- Slide
- 5. Analysis plan
- What goes on it
- Coding scheme, key metric, triangulation logic
- What it proves to the panel
- You decided how to analyze before you collected
- Slide
- 6. Findings → decisions
- What goes on it
- Each possible finding mapped to a product move
- What it proves to the panel
- Your research changes what the team does
- Slide
- 7. Risks + mitigations
- What goes on it
- Sampling bias, small n, what could invalidate it
- What it proves to the panel
- You see your own study's failure modes
| Slide | What goes on it | What it proves to the panel |
|---|---|---|
| 1. Question + decision | The sharpened question and the roadmap call it informs | You research toward a decision, not toward a report |
| 2. Method + rationale | The methods chosen and the alternatives you rejected | You can defend a tradeoff, not just list techniques |
| 3. Participants + sampling | Segments, n, recruit source, screening criteria | You can reach real professional developers, fast |
| 4. Timeline | Fieldwork, analysis, readout dates | You ship on a startup clock |
| 5. Analysis plan | Coding scheme, key metric, triangulation logic | You decided how to analyze before you collected |
| 6. Findings → decisions | Each possible finding mapped to a product move | Your research changes what the team does |
| 7. Risks + mitigations | Sampling bias, small n, what could invalidate it | You see your own study's failure modes |
Slides 6 and 7 are where senior candidates win and juniors run out of time. Budget for them.
Two versions, alwaysthe speed read is part of the test
Cursor cares about running good-enough research fast. Show that you can dial rigor up and down on purpose by presenting the same question at two scopes.
Pull existing accept/revert telemetry on multi-file Agent edits today
5 moderated sessions with developers already in the funnel
One-page readout with a directional recommendation and a flagged confidence level
Goal: unblock a roadmap call this week, not settle the question forever
Behavioral analysis across both segments with a clean denominator
12–16 moderated sessions to saturation on the why
A short in-product survey to size how widespread the trust gap is
Triangulated readout: where the three signals agree and where they fight
The scrappy version is not the rigorous version with steps deleted. It is a deliberately different study with a different claim strength. Say out loud what you are choosing not to learn in 48 hours and name the risk you are accepting by skipping it.
Pre-write the defensethe panel will push; plan for it
Every method choice is a tradeoff and the researchers on the panel will probe each one. The classic gut-check is "do this in half the time" - they want to see you cut scope without losing the spine of the study.
- "Why not just a survey?" Surveys capture stated trust, not the moment someone reverts a diff. You need behavior plus the explanation behind it and a survey gives you neither cleanly.
- "Why moderated, not unmoderated?" Trust failures are emotional and contextual; you need to probe the hesitation in real time. Unmoderated would miss the pause before someone clicks reject.
- "Half the time - what goes?" Drop the survey, keep telemetry plus five sessions. You lose the ability to size the problem, but you keep the directional answer and the mechanism.
- "What if your sample is biased toward power users?" Acknowledge it, then show the mitigation: deliberately recruit from the at-risk segment (shared-repo engineers) and flag the readout's generalizability limit.
"I'd anchor on one behavioral metric - revert rate on multi-file Agent edits - and pair it with moderated sessions to explain the reverts. If you gave me 48 hours I'd ship telemetry plus five sessions with a confidence flag; with two weeks I'd add a survey to size it. Either way, every finding maps to one call: do we auto-apply or keep the review gate."
Takeaway. Lead the challenge with the decision and the sharpened question, then present a scrappy and a rigorous version of the same study with every finding mapped to a product move.
Self-check
QOn the research-challenge prompt about whether developers trust the Agent to make unsupervised multi-file changes, what should you establish before naming any method?
Mock portfolio walkthrough
After this you can rehearse a case study that survives probing.
The portfolio deep-dive is where most senior candidates quietly lose the loop. They give a tour of how clever the study was and never say what changed because of it.
Cursor's deep-dive runs about an hour on one or two case studies, with probing on tradeoffs, pushback and what you would do faster. Pick a single mixed-methods case you can run cold in under ten minutes, then leave the rest of the hour for the panel to dig. The case has to show qual and quant working together, because that is the practice they are hiring for.
The PAPAIL spineProblem · Approach · Process · Artifacts · Impact · Learnings
- 1Problem. One sentence on the decision at stake and why it was hard. Not the topic - the tension. "The team disagreed on whether to invest in X and we had no data."
- 2Approach. The method mix and why this mix for this question. Name the one tradeoff you made consciously.
- 3Process. Compress hard. The panel does not need your screener; they need the two or three moments where your judgment mattered.
- 4Artifacts. Show exactly one - the synthesis that drove the decision, not your raw notes. It should be readable on screen in five seconds.
- 5Impact. Lead with this, even though it comes late in the acronym. What decision changed, what shipped or got killed, what the measurable effect was.
- 6Learnings. One honest thing you would do differently, framed as a faster or sharper version, not a confession.
PAPAIL is the storage order, not the telling order. Open the walkthrough with Impact - "this study killed a feature the team had already half-built" - then rewind to how you got there. A senior audience grants you the rest of the ten minutes once they know it landed.
Pre-load the three probesthey will come; have crisp answers ready
Name the stakeholder and their real objection
Show how you changed their mind with evidence, not authority
If you lost the argument, say what you learned
Two methods you rejected and the one-line reason
Proves the choice was deliberate
Avoids looking like you only know one tool
The step that took too long for its value
How you'd scope it to ship in days
Directly answers Cursor's speed bar
One artifact, one vivid momentthe two things people actually remember
An hour of talk decays in memory to two images. Choose them on purpose: a single synthesis artifact that shows your thinking and one verbatim user moment that makes the finding undeniable.
- Element
- Artifact
- Weak version
- A 30-page report or a screenshot wall of quotes
- Strong version
- One synthesis frame: the insight, the evidence, the recommendation, on a single page
- Element
- User moment
- Weak version
- "Users were generally frustrated with the flow."
- Strong version
- "One engineer said 'I don't trust it because I can't see what it touched' while reverting a clean diff - that line settled the debate."
- Element
- Impact claim
- Weak version
- "It influenced the roadmap."
- Strong version
- "We cut the auto-apply default and shipped a diff preview; reverts on Agent edits dropped in the next release."
| Element | Weak version | Strong version |
|---|---|---|
| Artifact | A 30-page report or a screenshot wall of quotes | One synthesis frame: the insight, the evidence, the recommendation, on a single page |
| User moment | "Users were generally frustrated with the flow." | "One engineer said 'I don't trust it because I can't see what it touched' while reverting a clean diff - that line settled the debate." |
| Impact claim | "It influenced the roadmap." | "We cut the auto-apply default and shipped a diff preview; reverts on Agent edits dropped in the next release." |
The strong column is concrete and falsifiable. That is what reads as real experience.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Step through each dimension: the weak version reports, the strong version changes a decision.
Record yourself running the full ten minutes, then watch it once with a timer. Cut every sentence that is not decision-relevant. If a detail doesn't change what the listener now believes the team should do, it is padding - delete it.
The "method tour" is the dominant failure here: narrating sample sizes, guide design and analysis steps while the impact stays fuzzy. If you find yourself explaining how you did the research for more than three minutes before stating what changed, you have lost the room.
Takeaway. Run one mixed-methods case in under ten minutes, open with the decision that changed and pre-load crisp answers to who-pushed-back, what-else and what-you'd-do-faster.
Self-check
QWhat is the single most common way senior candidates lose the portfolio deep-dive and how do you avoid it?
Rapid-fire methods drill
After this you can answer method and quant questions under pressure.
The craft deep-dive moves fast and probes your reflexes. They are checking whether your method instincts are sound when you don't have time to hedge.
This round tests mixed-methods range: qual rigor, survey and sampling design, experiment and stats literacy and how you reconcile signals that disagree. The senior tell is that you name each method's blind spot as you reach for it. Confidence plus self-awareness reads better than confidence alone.
When the obvious method is wrongknowing what NOT to run is the senior signal
- Question type
- How many users hit this problem?
- Wrong tool
- Interviews
- Why and what to use
- Qual can't size prevalence; use telemetry or a survey to quantify, then qual to explain
- Question type
- Why do people revert Agent edits?
- Wrong tool
- Survey
- Why and what to use
- A survey gets rationalized recall, not the live hesitation; run moderated sessions
- Question type
- Which of two diff-preview designs is better?
- Wrong tool
- Open interviews
- Why and what to use
- Preference talk is noisy; run usability tests or an A/B with a task-completion metric
- Question type
- Is this new behavior growing over time?
- Wrong tool
- A one-shot study
- Why and what to use
- A snapshot can't show a trend; use longitudinal log analysis or a diary study
| Question type | Wrong tool | Why and what to use |
|---|---|---|
| How many users hit this problem? | Interviews | Qual can't size prevalence; use telemetry or a survey to quantify, then qual to explain |
| Why do people revert Agent edits? | Survey | A survey gets rationalized recall, not the live hesitation; run moderated sessions |
| Which of two diff-preview designs is better? | Open interviews | Preference talk is noisy; run usability tests or an A/B with a task-completion metric |
| Is this new behavior growing over time? | A one-shot study | A snapshot can't show a trend; use longitudinal log analysis or a diary study |
When asked "when would you NOT run interviews?", answer with the principle, then an example. "Interviews can't tell me how common something is, only what's possible. If the question is prevalence - how many developers do this - I reach for telemetry or a survey and use interviews to explain the number, not produce it."
Sizing a study, fasthave a defensible rule of thumb ready
For qual, you size to saturation, not to a magic number. For quant, you size to power. Be able to say both cleanly and to flex the number to the decision's stakes.
- Qual: roughly 5 sessions per distinct segment to surface major themes, extending until new sessions stop producing new codes (saturation). A higher-stakes decision buys more sessions, not a different rule.
- Survey / quant: size to detect the smallest effect that would change the decision (the minimum detectable effect) at a fixed confidence and power, then report the precision you actually achieved, not just the point estimate.
- The honest move: when the recruit is hard or the clock is short, run fewer and flag the confidence level rather than pretending small-n is conclusive.
When qual and quant disagreethe reconciliation question they love
Conflicting signals are a feature, not a failure. The disagreement usually means each method is measuring a slightly different thing and resolving it is where the real insight lives.
- 1Check they're measuring the same thing. Telemetry might show high feature usage while interviews report frustration - both can be true if usage is forced, not loved.
- 2Trust behavior for what, qual for why.* Logs tell you what happened at scale; sessions tell you the mechanism. Let each answer the question it's good at.
- 3Look for the segment hiding the average. A flat aggregate metric often masks one delighted segment and one struggling one that the qual surfaced.
- 4Resolve, then re-collect if needed. If the conflict is decision-critical and unresolved, name the targeted follow-up that would break the tie rather than averaging the two into mush.
Spot-the-bias on demandthey will hand you a flawed question and a flawed test
"How much do you love Cursor's powerful new Agent?" - leading and double-barreled
Fix: neutral stem, one construct, balanced scale: "How would you rate the Agent's multi-file edits?"
Also flag: vague quantifiers, assumed usage, agree/disagree acquiescence bias
Ships treatment to power users only, then claims a win for everyone
Selection bias plus no clean control; the effect is confounded with who got it
Fix: randomize at the user level, pre-register the metric, check for sample-ratio mismatch
Triangulate one Cursor question three waysthe design-a-mixed-method drill
A common live task: take one question and design three complementary methods, each covering another's blind spot. Use the same trust prompt from section one.
- Method
- Log / behavioral analysis
- What it answers
- How often developers revert multi-file Agent edits, at scale
- Its blind spot
- Silent on motivation; can't tell loved from tolerated
- Method
- Moderated sessions
- What it answers
- Why the revert happened, what would rebuild trust
- Its blind spot
- Small n; can't size how widespread it is
- Method
- In-product survey
- What it answers
- How widely the trust gap is felt across segments
- Its blind spot
- Stated attitude, prone to recall and acquiescence bias
| Method | What it answers | Its blind spot |
|---|---|---|
| Log / behavioral analysis | How often developers revert multi-file Agent edits, at scale | Silent on motivation; can't tell loved from tolerated |
| Moderated sessions | Why the revert happened, what would rebuild trust | Small n; can't size how widespread it is |
| In-product survey | How widely the trust gap is felt across segments | Stated attitude, prone to recall and acquiescence bias |
Three methods, three blind spots, each covered by another. That's triangulation, not just "more data."
Don't claim triangulation just because you used three methods. Triangulation means each method covers another's specific weakness and the answer is stronger where they converge. If all three share the same bias (e.g. all recruit from happy power users), you've stacked the same error three times.
Takeaway. Name each method's blind spot as you reach for it, size qual to saturation and quant to the MDE and treat qual/quant conflict as two measures of different things - behavior for what, qual for why.
Self-check
QTelemetry shows a Cursor feature has high usage, but your interviews surface strong frustration with it. How do you reconcile the conflict?
Values + why-Cursor mock round
After this you can deliver behavioral and motivation answers cleanly.
The values round reads for authenticity above all. Cursor is checking whether you actually use the tool and care about the developer or whether you're a strong generalist UXR reciting transferable answers.
Expect truth-seeking, ownership, pace and "why this team," sometimes folded into the onsite or a founder conversation for senior roles. Keep every story under two minutes and end each one on the outcome. The fastest way to fail this round is a polished answer that could have been told by someone who has never opened Cursor.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Authenticity is the gate; the behavioral themes are how you prove the rest. Step through each.
Four behavioral prompts, four themesrehearse one tight story per theme
"Tell me about a finding nobody wanted to hear."
Show you surfaced the uncomfortable result and followed the data over the loudest opinion
End on what the team did once they accepted it
"A study fell apart mid-flight - what did you do?"
Show self-direction with no one assigning you the fix
Flat org, no narrow job descriptions: prove you don't wait for permission
"You had 48 hours and no clean data. Go."
Show a good-enough study that still drove a decision
Bias to ship insight, not to perfect the method
"You disagreed with a PM's roadmap call. What happened?"
Change a cross-functional decision with evidence, not title
End on the decision that moved and the relationship intact
Run every behavioral story on a compressed STAR: ten seconds of situation, the bulk on the action and your specific judgment, a hard stop on the measurable result. If you're past ninety seconds and haven't reached the outcome, you over-built the setup. Land the plane.
The 2-minute why-Cursor narrativewhy this product, why this user, why now
- 1Why this product. Be specific and current: you use Cursor, here's the workflow it changed for you, here's what's still rough. Generic "AI is exciting" gets discounted instantly.
- 2Why this user. Professional developers are a sophisticated, opinionated, technical user - say why researching an expert user energizes you and where it's harder than researching a consumer.
- 3Why this team. A small, flat, talent-dense research function where you'd be roadmap-driving from day one. Name that you want the scope and the speed, not a big-co research org.
"I switched to Cursor as my daily editor about six months ago and the Agent changed how I scope multi-file refactors - but I still hesitate before letting it touch a shared repo, which is exactly the kind of trust friction I'd love to research. Studying professional developers is harder and more interesting than consumer work: they have strong priors and they'll tell you when you're wrong. And I want a function small enough that my research moves the roadmap, not a report that gets filed."
One Cursor friction you'd researchthis is the authenticity proof
Have a real friction you've personally hit, stated as a researchable hypothesis with a method. This single answer does more to prove you use Cursor than anything else in the loop.
- Friction
- Developers hesitate to let the Agent edit a shared production repo unsupervised
- Hypothesis
- Trust is gated by visibility of blast radiusHow much breaks if a change goes wrong; the scope of potential damage., not by raw model accuracy
- Quick test
- 5 moderated sessions on multi-file edits + revert-rate telemetry split by repo stakes
- Decision it informs
- Whether to invest in a richer diff-preview before pushing auto-apply
Specific, falsifiable, tied to a roadmap call. That's the answer that lands.
Three senior questions backasked questions reveal level
- "What research has actually changed a roadmap decision here in the last quarter and what made it land?"
- "Where does the team currently trust intuition over research and is that the right call?"
- "As the research function grows, what's the first ritual or piece of infrastructure you'd want built - and would I own that?"
The fatal tell is a why-Cursor answer with no first-hand product detail. "I love AI tools and your mission is inspiring" is what someone says who hasn't installed it. Anchor on a concrete moment of your own usage - a specific feature, a specific friction - or the authenticity read fails no matter how strong your craft is.
Takeaway. Keep every behavioral story under two minutes ending on the outcome and prove authenticity with one specific Cursor friction you've personally hit, framed as a hypothesis with a method.
Self-check
QWhat is the single most important thing the Cursor values round is reading for and how do you prove it?
Self-scoring rubric and gap plan
After this you can grade your loop and build a focused study plan.
A mock loop you don't score is just rehearsal theater. The point is to find your weakest dimension while it's still cheap to fix.
Treat the rubric as a gap finder, not a score to admire. Mark the weakest proof, turn it into one practice rep and keep the artifact you would show an interviewer.
Run all four mock rounds back to back, then grade each one against the same five dimensions a Cursor panel weighs. Score honestly - generous self-scoring is how people walk into the real loop blind. Anything under 4 is a gap and the plan below tells you which module to revisit for it.
The five-dimension rubricscore every round 1–5 on each
- Dimension
- Method fit
- What a 5 looks like
- Picks the right method for the question and says why; rejects the wrong one out loud
- What a 2 looks like
- Defaults to interviews for everything; can't say when not to run them
- Dimension
- Rigor under constraints
- What a 5 looks like
- Ships a good-enough study fast and names the confidence tradeoff
- What a 2 looks like
- Either over-engineers or cuts corners silently
- Dimension
- Synthesis & impact
- What a 5 looks like
- Every finding maps to a decision; leads with what changed
- What a 2 looks like
- Reports themes; impact stays vague or unmeasured
- Dimension
- Product credibility
- What a 5 looks like
- First-hand Cursor detail and a real developer-trust friction
- What a 2 looks like
- Generic UXR answers; no evidence of using the tool
- Dimension
- Communication
- What a 5 looks like
- Tight, under two minutes, leads with the answer
- What a 2 looks like
- Method tours, runs long, buries the point
| Dimension | What a 5 looks like | What a 2 looks like |
|---|---|---|
| Method fit | Picks the right method for the question and says why; rejects the wrong one out loud | Defaults to interviews for everything; can't say when not to run them |
| Rigor under constraints | Ships a good-enough study fast and names the confidence tradeoff | Either over-engineers or cuts corners silently |
| Synthesis & impact | Every finding maps to a decision; leads with what changed | Reports themes; impact stays vague or unmeasured |
| Product credibility | First-hand Cursor detail and a real developer-trust friction | Generic UXR answers; no evidence of using the tool |
| Communication | Tight, under two minutes, leads with the answer | Method tours, runs long, buries the point |
Score each of the four rounds on all five dimensions. The lowest cell across the grid is where to spend your week.
Common failure modes and their fixdiagnose your low scores fast
- Method tour over impact
- You narrated process and never said what changed → re-record the portfolio case, opening with the decision
- No quant depth
- You hedged on sizing, MDE or experiment bias → do a quant refresher; have power and SRM ready cold
- Generic, non-Cursor answers
- Your story could be told by anyone → add one first-hand Cursor friction with a hypothesis
- No clear tradeoff
- You presented one version of every study → always carry a 48-hour and a two-week version
The one-week gap planconcrete, daily, re-testable
- 1Daily Cursor use. Use it as your real editor every day this week and log frictions as you hit them. By Friday you have a stack of authentic, specific material for the values round.
- 2One re-recorded case study. Re-record your portfolio walkthrough opening with impact, cut to under ten minutes and re-watch with a timer until no sentence is padding.
- 3One quant refresher. Drill sizing-to-MDE, the qual/quant reconciliation move and spot-the-bias on a survey and an experiment until they're reflexive.
- 4Revisit your weakest module. Map your lowest rubric dimension to the track module that covers it and rework that one before re-running the mock.
Re-run the full mock at the end of the week and confirm every dimension scores 4 or higher across all four rounds. If one cell is still a 3, that's the only thing you work on next. Don't walk into the real loop with a known 2 anywhere on the grid.
Your overall "average" is meaningless to a panel - they remember the worst moment, not the mean. A loop with four 5s and one 2 reads as the 2. Spend your prep on raising the floor, not polishing what's already strong.
Takeaway. Score all four rounds on five dimensions, fix the single lowest cell with a one-week plan (daily Cursor use, a re-recorded case, a quant refresher) and re-run until every dimension clears 4+.
Self-check
QAfter scoring your mock loop you have mostly 4s and 5s but one 2 on "product credibility." How should you prioritize your prep week?