Capstone: Full Mock Loop

Discovery is the stage interviewers use to find out whether you can actually run an enterprise deal or just talk about one. In the Cursor loop it is a live role-play with a technical buyer and most candidates fail it by pitching when they should be qualifying.

Treat this section as a timed drill, not a read. Set 15 minutes, speak the questions out loud and record yourself. You are selling into a buying committee that runs from individual developers up to the CTO, so the muscle you are training is diagnosis under pressure with a buyer who knows the product better than most reps do.

The scenario to run againstBuild the persona before you start the clock

The trap is built into the setup. Scattered usage and a pending security review look like a deal that wants to close itself and that is exactly the situation where reps coast on developer love instead of quantifying pain and finding the economic buyer.

Run the 15 minutes in five moves

1. 1Frame and earn the time (1 min). State the agenda, confirm the time box and ask permission to dig. “I would rather understand how your org builds software than pitch you something you already use.”
2. 2Quantify the pain (5 min). Move from “usage is scattered” to numbers: how many devs are active, what onboarding costs in weeks, what a slow PR cycle costs the org. A pain you can put a number on is a pain you can defend to a CFO later.
3. 3Map the committee (3 min). Name the economic buyer who owns the budget, the Platform/Security veto and your day-to-day champion. Ask directly who has to say yes and who can say no.
4. 4Surface the decision process (3 min). What the security review actually requires, what budget cycle they are in, how they evaluate dev tools and what killed or stalled the last one.
5. 5Lock a mutual next step (2 min). Propose a concrete next action with a date and an owner, including a thread to the absent security architect. No next step, no qualified deal.

The rubric - score each line 1 to 5MEDDPICC mapped to what discovery must surface

Self-check after the recording

• Count your questions versus your statements; healthy discovery skews heavily toward questions.
• Listen for follow-ups: did you take a vague answer and push it to a number or accept it and move on?
• Confirm you exited with a dated next step that pulls the absent security and budget owners into the deal.

A feature tour loses this stage. The panel - often including Sales Engineering - wants to see whether you can sell a technical product as a story that ends in a number a buyer cares about.

You are not demoing to prove the product works; developers already know it does. You are demoing to connect codebase-wide context, an agent task and Tab completions to a measurable engineering outcome, then to hold your structure when the hard questions land.

The day-in-the-life arcOne engineer, one real task, one outcome

1. 1Set the scene (30 sec). A new engineer at the 2,000-person org is shipping their first change in a large unfamiliar monorepo. Name the cost: onboarding usually takes weeks.
2. 2Context retrieval (1 min). Cursor pulls in the relevant files across the codebase so the engineer understands the change without spelunking. Tie it to faster ramp, not “it indexes your repo.”
3. 3Agent task (1.5 min). Hand the agent a scoped task - refactor, write the test, wire the endpoint - and show the human reviewing and steering. The story is impact with a human in the loop, not autopilot.
4. 4Tab in the flow (30 sec). Inline completions keep the experienced dev fast on the work they already know. Small moment, real daily time saved.
5. 5Land the outcome (30 sec). Close on the quantified claim: ramp from six weeks toward two or X more reviewed PRs per engineer per month - framed as a hypothesis to validate in a pilot, not a guarantee.

The four objections you will get

The demo rubric

This exercise mirrors the panel-presentation stage. You get a named target and limited time and the panel is reading for whether you think like an owner of a patch or a rep waiting for leads.

The output is one page, presentable in under ten minutes. Pick a real company you can speak to, ideally one with visible Cursor usage signals and build the plan around converting bottom-up adoption into an enterprise contract while taking security seriously from the start.

The one-page plan, five blocks

1. 1Account snapshot. Company size, engineering org shape, tech stack and the adoption signal you can point to (active Cursor users, public job posts mentioning AI tooling, a champion you know).
2. 2Stakeholder map. Economic buyer (likely VP Eng or CTO), Platform/DevEx and Security as the technical gate, day-to-day champions in dev teams and Procurement/Legal as the path, not the prize.
3. 3Pain hypothesis. Your best guess at the business cost they feel - slow onboarding, inconsistent velocity or audit risk from ungoverned AI usage - stated as a hypothesis to test in discovery.
4. 4Pipeline-generation plan. How you self-source: the champion you activate, the executive you multi-thread to and the outbound angle. Do not lean on inbound.
5. 5Deal thesis and close hypothesis. The path from current usage to a signed contract, the security/procurement steps and a realistic timeline with a named first milestone.

Prioritization logic - rank accounts on signalShow you allocate effort, not spray it

Make security part of the plan, not a surprise

The values round is where a skeptical founder or executive decides whether you are mission-driven or chasing a hot logo. Generic answers fail here harder than anywhere else in the loop.

Cursor screens for truth-seeking, builder mentality and bar-raising on a small flat team. Your job in this round is to prove those traits with real detail rather than describe them and to keep every claim quantified or concrete.

Run the four answers out loud

1. 1Why Cursor. Tie a specific personal reason to the product and the moment in software where AI changes how it gets built. Avoid the careers-page mission restated; land on why this product and this team, now.
2. 2A truth-seeking story. A time you said the uncomfortable true thing: cut a forecast you knew was soft, told a customer the ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. was thinner than they hoped or killed your own deal because it was not real. Show the cost you paid for honesty.
3. 3A built-from-scratch story. Something you created where none existed - a territory from zero, a playbook, an outbound motion, a process. This is the builder signal a flat early-stage team needs.
4. 4A lost-deal story. A real loss with your specific mistake named and the change you made after. The mistake should be diagnosable, not “budget got cut.”

Grade each answer on three axes

The curveball: your honest weakness

• Name a real weakness as a seller, not a humble-brag like “I care too much.” Something diagnosable: weaker at multi-quarter patience or at letting an SE drive when you want control.
• State what you do to manage it and one concrete change you have already made.
• Land it without spiraling; the test is self-awareness under pressure, which is exactly what the role-plays probe.

The loop is one integrated test of whether you can land and expand an AI code editor inside large engineering orgs. This final pass is where truth-seeking turns inward: grade yourself honestly, then fix the lowest score.

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.

Score each axis 1 to 5 from how the earlier drills actually went, not from how you hope you would do live. Your readiness is set by your weakest axis, because the loop will find it.

The five readiness axes

Close-the-gap actions by weakest axis

The basics checklist - verify, do not assume

• Numbers memorized cold: quota, attainment, rank, ACV, cycle length, self-sourced %.
• Cursor installed and genuinely used on a real codebase - you can describe a task you ran, not a feature you read about.
• Competitive positioning rehearsed against Copilot, Windsurf and the “devs use it free” objection.
• A story bank built: one complex won deal, one lost deal you own, a truth-seeking story and a built-from-scratch story.

Two final confirmations