Anysphere hires every Cursor engineer and designer through a 2-day onsite where you build a real feature in the live codebase (Source: a16z). Candidates rate the Software Engineer loop “very difficult” — 4.5 out of 5 (Source: Glassdoor). The process-map guides list the rounds; this guide answers the questions.
In this article, we’ll cover the following 14 questions:
- How do you use Cursor today?
- What would you most like to build in Cursor?
- Why Cursor (Anysphere), and what would you build if left in a vacuum?
- Why did you accept that code? And why didn’t you accept this one?
- What’s your approach to generating code with AI?
- Can you explain what the first line of your solution is doing?
- How do you decide what to use versus reject from the AI’s output?
- When do you use Tab, Cmd+K, Composer/Agent, and Background Agents?
- How does Cursor index a large codebase, and what leaves your machine?
- What does .cursor/rules do, and how is it different from legacy .cursorrules?
- When would you turn on MAX mode, and what does it actually change?
- How would you chunk medical documents versus social-media posts for retrieval?
- An agent gives users wrong answers and there are no logs. What’s your debugging process?
- How do you know when your AI system is wrong?
How the Cursor (Anysphere) interview actually works in 2026
Cursor is the AI code editor built by Anysphere, and the two names point at the same company — Glassdoor splits candidate reports across “Cursor (CA)” and “Anysphere” entities. The reported software-engineering loop runs a recruiter call, then one or two HackerRank-style coding screens with an engineer on the line, then a 2-day onsite where you build a real feature in the actual codebase.
Expect a practical, comprehension-first bar — one candidate’s interviewer said repeatedly that syntax was not the point. Average time-to-hire sits near 7 days (Source: Glassdoor), and candidates report back-channel reference checks after the onsite (Source: Blind). Treat the whole loop as a judgment test, not a syntax test.
| Stage | Format | What it tests | Source |
|---|---|---|---|
| Recruiter call | Phone screen | Motivation, fit, whether you genuinely use Cursor | Glassdoor |
| Technical coding screen(s) | 1-2 HackerRank rounds with an engineer on the line | Practical problem-solving; “syntax is not the point” | Glassdoor |
| 2-day onsite | Build a real feature in the live codebase, plus 4-6 hour culture meals | End-to-end delivery, culture fit, a candidate preview of the company | a16z |
| Back-channel and offer | Reference checks, ~7-day cycle | Track record and reputation | Blind |
Two cautions before you prep. Reports differ on whether AI tools are allowed during the on-screen rounds — the accounts of keeping Cursor on for coding sit alongside one piece framing the onsite as “no AI” (Source: The Bridge Chronicle). And at least one candidate has publicly disputed the unpaid 2-day work trial as exploitative (Source: Blind); both threads are unpacked below.
Recruiter-screen and motivation questions
The Cursor (Anysphere) recruiter screen is a soft pass/fail on one thing: whether you are a real, daily Cursor user with a concrete reason to be in the room. Candidates report being asked about their personal technical interests rather than trivia, and prep notes from the loop stress recent hands-on use of Cursor, VS Code, or IntelliJ plus a GitHub profile that is “as green as possible” (Source: Glassdoor). The recruiter is screening for conviction and authentic usage, so vague enthusiasm reads as a red flag. Have a specific, recent build you can describe in two minutes.
How do you use Cursor today?
Concept: genuine-user signal | Difficulty: junior | Stage: recruiter
Direct answer: Describe your actual Cursor workflow in concrete primitives, not adjectives. Say what you reach for Tab on (fast in-line next edits), when you drop to Cmd+K for a targeted change, and when you hand a multi-file feature to the Agent.
Mention how you steer it — grounding prompts with @-mentions of files and docs, keeping a .cursor/rules file so the model respects your conventions, and reviewing every diff before you accept. Tie it to one recent thing you shipped this way: a migration, a refactor, a feature behind a flag. The recruiter is not grading the task; they are checking that the verbs are yours and the muscle memory is real.
What they’re really probing: Whether you installed Cursor last week to pass the screen, or you live in it.
This exact phrasing shows up mostly in competitor prep framing, but the underlying gate is real: reports describe the screen probing “personal technical interests” and recent editor use, not memorized features.
What would you most like to build in Cursor?
Concept: motivation and product taste | Difficulty: mid | Stage: recruiter
Direct answer: Cursor wants a candidate with product taste, so answer with something you would genuinely ship and could scope on the spot. Pick a real gap you have felt — say, a Background Agent that triages flaky tests overnight, or a .cursor/rules-driven guardrail that blocks an anti-pattern your team keeps reintroducing.
Then show the seams: what context the Agent needs via @-mentions, where you would keep a human in the loop on the diff, how you would know it worked. This question is reported verbatim from a candidate who accepted an offer (Source: Glassdoor), so treat it as a real signal, not small talk. Specific and shippable beats grand and vague.
What they’re really probing: Do you have opinions about the product, and would you be additive to a team building it?
The candidate who got this question rated the loop “very difficult” but had a positive experience and accepted. Conviction plus a buildable idea is what landed.
Why Cursor (Anysphere), and what would you build if left in a vacuum?
Concept: motivation and self-direction | Difficulty: mid | Stage: recruiter
Direct answer: Anysphere’s CEO Michael Truell frames the onsite around a deliberately open prompt — “what would they build if left in a vacuum without a team?” — so your “why” should connect the company’s direction to something you would chase unsupervised.
Cursor is betting on a “third era of software development” where fleets of agents ship changes autonomously, and the company crossed roughly 1 million daily active users on the way there (Source: Contrary Research). Name the part of that bet you care about, then describe one concrete thing you would build into it with no one assigning it. Show self-direction, not flattery.
What they’re really probing: Conviction about the mission, and whether you generate your own direction without a manager handing you tickets.
The “vacuum” framing is Truell’s own test for whether a candidate can drive work end-to-end. Treat it as the seed of the onsite, not a throwaway.
Defending your AI workflow with Cursor left on
Cursor-fluency roles increasingly run a coding round where you keep the AI assistant on and defend every line you take or leave. The vivid accounts here — a CTO telling a candidate to “leave Cursor on,” then grilling the accept/reject decisions — come from interviewer Brian Jenney at an unnamed AI startup and are not confirmed as Anysphere’s own stage.
Read them as the broader AI-allowed interview pattern that Cursor-fluency jobs exemplify. Companies including Meta, Rippling, and Google now let candidates use AI assistants in technical sessions, specifically to watch how you evaluate, modify, and trust generated answers. The bar moved from “can you produce code” to “can you justify it.”
Why did you accept that code? And why didn’t you accept this one?
Concept: judgment under AI | Difficulty: senior | Stage: technical
Direct answer: When you keep Cursor on, every suggestion you take is a decision you own, so narrate the decision as you make it. Pick one block you accepted and say why — it matched the codebase’s existing abstractions, it was the simplest thing that passed the test, you could read it at a glance.
Then pick one you rejected and name the failing criterion: it was clever but unmaintainable, it pulled in a dependency you did not need, it would be hard to test. The point is to show a critical layer sitting between the model’s output and the commit. Interviewers running this format care less about your final answer and more about how you reason over each diff in real time.
What they’re really probing: Whether there is any judgment between “AI suggests” and “you commit,” or you accept whatever looks plausible.
In the canonical account, a candidate instinctively switched from Cursor to a plain editor and was told to keep Cursor on — and the interview got harder, not easier, because every accepted line became a question (Source: Brian Jenney).
What’s your approach to generating code with AI?
Concept: AI workflow philosophy | Difficulty: mid | Stage: technical
Direct answer: Frame your approach the way the AI-allowed interviewers frame the job: treat AI output as a first draft, not a finished answer, and “optimize for trust, not completion” (Source: IEEE Spectrum). Say that you start from intent — what the change needs to do and which constraints matter — then let the model draft, then edit, refactor, or reject.
Make clear you read every line before it lands. As Jenney puts it, “your decision-making process is what separates prompt jockeys from software developers” (Source: Brian Jenney). Refusing to use AI at all reads as rigidity; using it without a critical layer reads as a prompt jockey. Land in the middle and say so out loud.
What they’re really probing: Prompt jockey or developer — do you drive the tool, or does it drive you?
Roughly 84% of developers now use or plan to use AI tools, so pretending you do not is a fast way to fail; silence when asked to reason is treated as a red flag.
Can you explain what the first line of your solution is doing?
Concept: comprehension check | Difficulty: junior | Stage: technical
Direct answer: Be able to explain every line you kept, starting with the first one. This is the cheapest comprehension check an AI-allowed interviewer has, and it is brutal precisely because correct code does not prove understanding — in one reported round, about 20% of candidates could not explain how their working solutions worked, only that they did (Source: IEEE Spectrum).
So before you accept a block, read it well enough to defend the opening line: what it imports, what it initializes, why it is there at all. If you cannot, you have not finished the task — you have only watched the model finish it. Treat explainability as part of “done,” not a bonus.
What they’re really probing: Did you actually read what you shipped, or did you accept-and-paste on faith?
One candidate claimed he used no AI, then went silent when asked to explain his first line — and was caught on exactly this question.
How do you decide what to use versus reject from the AI’s output?
Concept: accept/reject criteria | Difficulty: mid | Stage: technical
Direct answer: Give an explicit rubric instead of a vibe. Say you reject output when it fails on maintainability, simplicity, or testability — the three levers Jenney names — and that you lean on fundamentals like the Single Responsibility and Open-Closed principles to explain why.
Concrete beats abstract: would a map beat a sprawling object here, can this 60-line function be decomposed, does this regex-heavy path earn its complexity. Then accept the version that a teammate could read in six months. Showing you can articulate the why behind a reject is the whole game.
- Maintainability — could a teammate change this safely later?
- Simplicity — is this the least clever thing that works?
- Testability — can you write a test against it without contortions?
- Fit — does it match the codebase’s existing abstractions?
What they’re really probing: Can you justify a rejection with engineering fundamentals, not taste?
A candidate kept Cursor on for a full-stack Next.js challenge, rejected the model’s bloated, regex-heavy backend, defended the call on maintainability and simplicity, and got the offer — one of roughly 30 the team interviewed (Source: Brian Jenney).
Cursor product-knowledge questions you’re expected to nail
Cursor’s own coding rounds skew toward “how does the product work,” not abstract LeetCode — candidates report questions tied to “different parts of Cursor and how it works,” with one medium-hard problem per round plus a follow-up or two (Source: Blind). That makes product fluency double as interview prep: the same knowledge that gets you through the recruiter gate carries the technical screen.
The mental model to anchor on is Andrej Karpathy’s description of Cursor as an “autonomy slider” — Tab completion, Cmd+K for targeted edits, or full agentic autonomy (Source: Cursor). The four questions below are the ones a Cursor interviewer can reasonably expect you to answer cold.
When do you use Tab, Cmd+K, Composer/Agent, and Background Agents?
Concept: tool selection on the autonomy slider | Difficulty: mid | Stage: technical
Direct answer: Map each tool to a rung on Cursor’s autonomy slider. Tab is next-edit prediction — its custom model predicts edits near your cursor and the next place to jump, generating over a billion edited characters a day. Cmd+K is for a surgical, targeted edit in place.
The Agent (Cmd+I) completes multi-step tasks independently, running terminal commands and editing across files, and it connects to external tools and data sources through the Model Context Protocol. Composer is Cursor’s in-house agent model tuned for engineering speed at roughly 4x faster generation than peers (Source: Cursor). Background Agents push that work async and to the cloud for parallel jobs you do not babysit.
- Tab — fast, in-flow next edits and jumps
- Cmd+K — one targeted, in-place edit
- Agent / Composer — multi-file, multi-step tasks with tools
- Background Agents — async/cloud work running in parallel
What they’re really probing: Whether you reach for the lightest tool that fits, or fire the agent at everything.
The Agent can make an unlimited number of tool calls during a task (Source: Cursor), and Cursor 3 now surfaces every running agent, local and cloud, in one sidebar — 35% of merged PRs on Cursor’s own team are written by autonomous cloud agents (Source: InfoQ).
How does Cursor index a large codebase, and what leaves your machine?
Concept: RAG and indexing internals | Difficulty: senior | Stage: technical
Direct answer: Cursor builds a searchable index by first taking a Merkle tree of cryptographic file hashes, so only changed branches sync. Files are split into syntactic chunks — practitioner write-ups describe tree-sitter parsing into an AST along function and class boundaries — then embedded with a custom model.
The key security point for the interview: only embeddings and path-masked metadata go to the cloud vector store (Turbopuffer); raw source stays local and is fetched only at inference time (Source: Towards Data Science). Semantic search is “one of the biggest drivers of agent performance,” lifting response accuracy ~12.5% in Cursor’s own evaluation (Source: Cursor).
What they’re really probing: Do you understand retrieval over code and the privacy model, or just that “it searches files”?
Path masking splits each path component and obscures it with a secret key — src/payments/invoice_processor.py becomes something like a9f3/x72k/qp1m8d.f4 — and the index re-syncs about every 5-10 minutes against the Merkle tree (Source: Engineer’s Codex).
What does .cursor/rules do, and how is it different from legacy .cursorrules?
Concept: steering the agent with rules | Difficulty: junior | Stage: technical
Direct answer: A Cursor agent is built from three parts — Instructions (system prompt plus rules), Tools, and the Model you pick (Source: Cursor).
The .cursor/rules directory is how you supply the rules half: a set of .mdc files holding persistent, project-scoped instructions the agent honors on every task — coding conventions, preferred libraries, directory layout, and house style — so you are not re-typing the same context into each prompt. The single-file .cursorrules at the repo root is the legacy form and is now superseded by the .cursor/rules directory (Source: Medium). Knowing this distinction signals you actually configure Cursor deliberately rather than leaving it on defaults.
What they’re really probing: Can you steer the agent deterministically, or do you just hope the prompt sticks?
The recommended workflow pairs rules with a written PRD and an .cursorignore file to keep noise out of the index — start from intent, set .cursor/rules, then ground prompts with @-mentions (Source: Medium).
When would you turn on MAX mode, and what does it actually change?
Concept: context and cost tradeoff | Difficulty: mid | Stage: technical
Direct answer: MAX mode runs the same underlying model but lifts the limits Cursor normally imposes to control cost.
Regular mode prunes context to roughly 10k-15k tokens (about 2,000 lines) even when you attach more; MAX bypasses that pruning to restore the model’s full window, raises the tool-call ceiling from 25 to 200 per interaction, and pushes file reads toward 750 lines (Source: Medium). It shifts the agent from “context pushing” to “context pulling,” and it runs on token-based pricing rather than per-request (Source: Cursor forum). Turn it on for genuinely large-context reasoning — a sprawling refactor across many files — not for routine edits.
What they’re really probing: Do you grasp the context-versus-cost tradeoff, or do you flip toggles blindly?
Cost discipline matters: heavy MAX use runs about $8-10/day (Source: Medium), and one engineer reported spending “$2k a week” on premium Cursor models before moving the same workflow to Claude Code at roughly a tenth of the price (Source: InfoQ).
Applied-AI-systems and editor-primitive coding rounds
Cursor’s coding rounds lean practical and applied-AI rather than pure algorithm puzzles — candidates describe one medium-hard problem per round tied to how the product works, not LeetCode. The three questions below come from interviewer Brian Jenney’s design for an AI-engineering role at an unnamed startup, not from Anysphere’s own loop (Source: Brian Jenney); treat them as the applied-AI pattern any Cursor-fluency job exemplifies.
The throughline is that “off-script” follow-ups — chunking tradeoffs, debugging with no logs, knowing when the system is wrong — are where rehearsed answers fall apart. They reward reasoning from the data and the failure mode, not reciting a default.
How would you chunk medical documents versus social-media posts for retrieval?
Concept: RAG chunking strategy | Difficulty: senior | Stage: system-design
Direct answer: Chunking is the heart of any retrieval-augmented generation pipeline, so answer from the documents’ structure, not a default chunk size.
Medical documents are long, highly structured, and high-stakes: chunk along semantic boundaries (sections, findings, clinical notes), keep chunks large enough to preserve context, add deliberate overlap so a result is not orphaned from its qualifier, and carry rich metadata for filtering. Social-media posts are short, noisy, and self-contained: chunk near one post each, deduplicate aggressively, and handle slang and thread context. The interviewer wants to hear you tie granularity and overlap to stakes and structure — getting a wrong clinical chunk back is far costlier than a wrong meme.
What they’re really probing: Do you reason from the data’s characteristics, or recite one blog-post chunking recipe for everything?
This exact off-script question exposed a candidate who gave “two generic, blog-post answers with no nuance” (Source: Brian Jenney). It is worth knowing because Cursor’s own product is built on a RAG system over your codebase (Source: Contrary Research).
An agent gives users wrong answers and there are no logs. What’s your debugging process?
Concept: debugging agentic systems | Difficulty: senior | Stage: technical
Direct answer: Resist the generic “replicate the issue and dig through the logs” — that answer is exactly what fails this round. For agentic systems with no logs, your first move is to add the observability you wish you had: instrument each stage so you can see the prompt, the retrieved context, the tool calls, and the raw model output. Then give a specific, staged process:
- Reproduce with a fixed input so the run is deterministic enough to study.
- Isolate the failing stage — retrieval, prompt, tool call, or the model itself.
- Turn the failing cases into a small eval set you can re-run after each fix.
- Confirm the fix against that set before you call it resolved.
What they’re really probing: Can you go past the rehearsed line to an actual, specific method?
A candidate who kept repeating the generic logs answer disconnected the call when pushed for the specific process behind it.
How do you know when your AI system is wrong?
Concept: evals and observability | Difficulty: senior | Stage: system-design
Direct answer: This is really an AI engineer screen, and the strong answers name a quality discipline, not a feeling. Cite evaluation datasets, LLM-as-judge, and observability tooling such as LangSmith or Helicone; treat structured outputs as table stakes rather than a highlight.
Then show you know the failure modes that make this hard: exploding token costs, a RAG system returning confident nonsense, and agents that demo cleanly but collapse under real users. The job, framed honestly, is a full-stack developer who can integrate AI — so answer like someone who has shipped one and watched it break.
What they’re really probing: Do you have a production discipline for AI quality, or do you ship on vibes?
Most candidates failed this round, and the cited $200K-$300K range for these roles reflects how few engineers understand those failure modes (Source: Brian Jenney).
The AI-authenticity scorecard: real versus performative Cursor usage
Cursor interviewers running the AI-on format can separate authentic usage from performance within minutes, because faking it leaves tells that real fluency does not. The scorecard below synthesizes the cited interviewer postmortems into a single rubric: the performative tell, what it signals, and what genuine Cursor usage does instead.
It is the inverse of the model answers above — those showed you what to say, this shows you the behaviors that quietly sink candidates. Note the integrity caveat that runs through this whole guide: these tells were observed in AI-allowed interviews at AI-first companies, documented by interviewer Brian Jenney and IEEE Spectrum, not confirmed as Anysphere’s own stage. Read the table as a behavioral checklist, not a transcript of a Cursor interview.
| Performative tell | What it signals | What real Cursor usage does instead |
|---|---|---|
| The cursor turns into a crosshair and you go quiet with long reading pauses | You are reading from a hidden answer source | Narrate your intent aloud while you work the problem |
| “That’s a great question” before every answer — a verbal loading spinner | You are stalling to fetch a response | Answer directly, or think out loud in real time |
| Prompt, accept everything, paste, move on | No critical layer between AI output and the codebase | Review the diff and reject parts with stated reasons |
| Can’t explain the first line of your own correct solution | You did not read what you shipped | Be ready to defend every line you kept |
| “Tool or library X is just better,” with no nuance | Pattern-matching a blog post, not reasoning | Tie the choice to the task’s constraints and tradeoffs |
| “No, I don’t use AI,” then silence when probed | Rigidity, or a bluff about your workflow | Treat AI as a first draft and optimize for trust |
| Deflecting or dropping the call when pushed for specifics | You can’t reason past the generic answer | Give your actual step-by-step process |
This scorecard synthesizes patterns from Brian Jenney’s firsthand accounts of AI-assisted engineering interviews (the tells that expose AI-cheating, the post-Cursor interview bar); the “explain your own solution” row is corroborated by IEEE Spectrum.
The 2-day onsite: what “go end-to-end in the codebase” really tests
Anysphere puts every engineer and designer through the same 2-day onsite, and has kept it even past 200+ employees, because it tests what a coding screen cannot — “can they go end-to-end in the codebase?” (Source: a16z). You build a real feature in the actual codebase, often something already started or shipped, with full-time-style support.
It doubles as a culture interview — 4-6 hour meals — and as a candidate preview of the company. The stated bar is comprehension, inquisitiveness, and “a hunger to get it done,” with method valued over the final answer. Demand is high enough that the unusual time commitment has not thinned the pipeline.
Go in with two caveats. One candidate publicly disputed the unpaid 2-day trial, noting the agreement carried IP-ownership language and arguing that California’s DLSE permits unpaid “try-out time” only when “there is no productivity derived” (Source: Blind).
Reports also conflict on AI use. The “leave Cursor on” accounts describe AI-allowed coding, while one piece frames the onsite as “no AI in interviews, real projects with the team” (Source: The Bridge Chronicle). Ask which applies before you arrive.
Questions to ask your Cursor interviewer
The reverse questions you ask a Cursor interviewer are themselves a seniority signal, so aim them at the things only an insider could answer — model training, eval discipline, agent ownership, and how the company actually runs the onsite.
Anysphere’s CEO frames the loop around comprehension and self-direction, so questions that show you think about production reliability and cost land better than questions about perks. Asking nothing, or asking only about salary and time off, signals you have not thought about the work — and at a company growing this fast, the work is the pitch. A few that signal you would operate at depth:
- How does the team train and evaluate in-house models like Composer and Tab — what does Cursor Bench look like in practice?
- What does your eval and observability stack look like for agent reliability?
- How does Cursor dogfood Cursor — what share of merged PRs come from autonomous agents today?
- What exactly does the 2-day onsite cover, and is the work-trial portion paid?
- Who owns agent reliability and on-call when a Background Agent ships a bad change?
- How do you balance the agent-first direction of Cursor 3 with developers who still want IDE-level control?
- With Composer running on Background Agents infrastructure and local-to-cloud handoff, how do you keep harness cost in check?
Your Cursor interview prep plan
Cursor interview prep is mostly about logging real hours, because the loop tests a kind of judgment that only accrues from daily use, not from cramming. The recruiter gate checks that you genuinely use the product; the coding round checks that you can defend every AI suggestion; the onsite checks whether you can drive a feature end-to-end.
None of that is fakeable the night before, so the plan is to build the decision-making muscle over weeks and make it visible. Treat the weeks before the loop as reps, not review, and let the decision log become the story you tell in the room. The concrete actions, in order:
- Switch your daily editor to Cursor now and rack up real hours across Tab, Cmd+K, and the Agent.
- Ship real PRs with the Agent and keep a decision log of every accept and reject, with the reason for each.
- Study how Cursor indexes code — tree-sitter chunks to a Turbopuffer vector store, raw source kept local — so the product-knowledge round is free points.
- Rehearse narrating your accept and reject calls out loud until it is automatic.
- Prepare a “vacuum” project — what you would build with no team — and scope it in two minutes.
The single highest-leverage next step: run a timed mock. Leave Cursor on, build one small feature end-to-end, and record yourself defending every line you keep — the playback is where the gaps show up while they still cost you nothing.