The Interview Loop, Stage by Stage

Cursor hires Software Engineer, Product through four phases and the middle one is unlike anything you've done at a normal company: a paid, full-day build inside a frozen copy of Cursor's own codebase. Hold the whole shape in your head before you prep a single answer, because each stage is testing a different slice of the same claim - that you can invent, ship and exercise real taste end-to-end.

The team is small, flat and talent-dense and the loop is calibrated to keep it that way. Difficulty runs high, around 8/10, because the bar is editor engineering and product judgment and genuine model taste in one person. Most loops span roughly three to six weeks.

1. 1Recruiter / hiring-manager screen (30-45 min). Genuine interest, a real “why Cursor,” your goals and an honest read on whether the intense pace fits you.
2. 2Technical phone screen(s) (1-3 rounds, ~60 min each). One medium-hard applied coding problem per round, often on a real slice of Cursor's codebase or an editor primitive. No AI beyond autocomplete in the first screens.
3. 38-hour paid onsite project (the decision round). A frozen copy of the codebase and a deliberately vague prompt: design and build something useful end-to-end, then present it. AI tools and Slack questions are allowed here.
4. 4Two-day onsite / team-fit (especially senior). Build side-by-side with future teammates on a real problem, plus culture conversations that often happen over meals.

The first call is short, informal and easy to underestimate. It sorts for two things: a real reason you want Cursor specifically and an honest readiness for how the team works. Generic enthusiasm fails here faster than anywhere else in the loop.

Expect the pace conversation to be direct. The healthy move is to be honest rather than to perform - say what kind of intensity you've thrived in and why this version of it appeals to you. Flinching reads as a mismatch and over-promising a lifestyle you'll resent reads as a future regret.

Walk in with three things ready

• A one-line fit statement: who you are as an engineer and why this exact role is the obvious next move.
• Two product stories you can tell in 60-90 seconds each, both grounded in shipping real user-facing software.
• A specific, current opinion from your own daily Cursor use - a workflow you run or an Agent behavior you'd change.

Cursor inverts the usual AI-tools convention twice in one loop and the technical screens are where the first inversion bites. The first screens disallow AI beyond autocomplete. You have to write fluent, correct code with no chat assistant in the loop.

The problems are applied and frequently editor-flavored - a text-buffer operation, a diff application, a small parsing task - not abstract puzzles chosen for their own sake. One medium-hard problem per round, usually around 60 minutes.

Train both modes deliberately

1. 1Clarify first. Ask two to four sharp questions about inputs, edge cases and what “done” means before you type.
2. 2Narrate as you go. Say what you're trying and why; silence reads as guessing, even when you're right.
3. 3When AI is allowed, interrogate it. Treat a completion as a draft from a fast junior engineer whose work you own.
4. 4Prove it works. A quick test or a manual check on a deliberately ugly input beats “it should be fine.”
5. 5Catch your own bug out loud. Spotting and fixing your own mistake is a positive signal, not an admission of weakness.

// Apply a single replace edit to a text buffer by character offset.
// Edge cases I'm watching: start > end, offsets past EOF, empty replacement.
function applyEdit(text: string, start: number, end: number, replacement: string): string {
  if (start < 0 || end < start || end > text.length) {
    throw new RangeError(`bad edit range [${start}, ${end}] for len ${text.length}`);
  }
  return text.slice(0, start) + replacement + text.slice(end);
}
// Quick check before I trust it: applyEdit("hello", 1, 4, "i") === "hio"

This is the round that decides it. You get limited, frozen access to Cursor's tech stack and a deliberately vague prompt: design and build a feature, product or service you think would be useful. Over about eight paid hours you figure out what to build, build it and then present design and tradeoffs.

Two questions sit behind the whole day. Can you go end-to-end in the codebase? And what would you build in a vacuum? The second one is the real test of taste - the brief is vague on purpose so that your choice of what to make becomes the signal.

The trap is starting to code in minute five. The candidates who win spend the opening stretch orienting and scoping so the thing they build is the thing that matters.

1. 1Orient (first hour-ish). Read the code, run it, map how it's wired. Ask sharp Slack questions about the goal and constraints before committing to a direction.
2. 2Pick something with taste. Choose a build that shows product judgment - a real user pain in an AI-native workflow - not the safest CRUD feature.
3. 3Scope a walking skeleton. Define the thinnest end-to-end path that proves the idea works and write it down before building wide.
4. 4Build with AI, verify relentlessly. Generate aggressively, read and test what comes back and redirect when it's wrong.
5. 5Protect the demo. Reserve the last 60-90 minutes to get a real, demonstrable path running and to rehearse the tradeoff story.

For more senior roles, the loop can extend into a two-day onsite where you build side-by-side with future teammates on a real, current problem, threaded with informal culture conversations that often happen over meals. This round answers a different question than the others: not “can you ship,” but “do we want to ship next to you.”

Talent density is a stated value, which means the implicit test is whether you raise the bar of the room. They're reading collaboration, taste and how you reason in real time - the meals aren't a break from the evaluation, they're part of it.

• How you collaborate live: do you make teammates better, share context and pick up the codebase's norms quickly?
• Whether your taste shows up in small decisions, not just the headline build.
• How you disagree - spirited and honest, then willing to change your mind when the evidence moves.
• Whether you can ship within the team's tools and conventions, not only as a solo operator.

Most candidates over-index on coding drills and under-index on the two things that actually decide this loop: authentic daily Cursor use and a rehearsed vague-prompt build. A three-to-four-week plan should weight toward those.

Use this stage map to decide what evidence belongs in each round. Memorizing the order is the shallow version. For every stage, prepare one artifact, one story and one question that shows how you reason in the role.

1. 1Weeks 1-4, every day: live in Cursor. Do real work in it - refactors, multi-file edits, debugging - and keep a running list of what delights you and what you'd change.
2. 2Weeks 1-2: drill applied coding both ways. Practice cold, no-AI coding on editor primitives and disciplined AI-assisted coding where you narrate and vet every suggestion.
3. 3Week 2: rebuild a couple of editor primitives from scratch. A gap buffer or rope, a diff applier, a streaming-edit consumer - by hand, until they're fluent.
4. 4Week 3: run a timed mock of the vague-prompt project. In one sitting, scope it, build a walking-skeleton slice and present the tradeoffs out loud.
5. 5Week 4: form and rehearse your product opinions. Sharpen your take on Cursor vs Copilot, Windsurf and Claude Code and on where the product should go next.

Hold an opinion on the landscape and make it specific. “Cursor is better” is not a take; “Cursor's tab model and multi-file edit review beat Copilot's inline-only flow for large refactors, but Claude Code's terminal-native loop is stronger for X” is.