The Onsite Build & Product Craft

The prompt is vague on purpose. “Design a feature, product or service you think could be useful” is not the team running out of ideas. It's the test.

Cursor's paid onsite hands you a frozen copy of their codebase and a brief with almost no constraints. The founders have said publicly that what they want to see is what you'd build in a vacuum - given autonomy and a real codebase, where does your judgment take you. The choice of what to build is graded as heavily as the code.

So the first hour is not coding. It's scoping. Most candidates lose the day in the first thirty minutes by sprinting at the first idea, then discovering at hour six that it was too big, too generic or didn't touch a real user pain.

What a good pick looks likethree filters, applied fast

The intersection of those three is small and that's the point. A flashy idea that fails “shippable” leaves you presenting a broken stub. A safe idea that fails “real” leaves you presenting something competent and forgettable.

1. 1Pick the user moment. Name a specific person doing a specific task in Cursor - reviewing a big AI diff, hunting a bug, onboarding to an unfamiliar repo. Write the moment in one sentence.
2. 2Write the problem statement. One crisp line: who hurts, when and why the current product makes it annoying. This is what you'll open your presentation with.
3. 3List assumptions out loud. Scope, target user, what you're explicitly not building. Putting them on paper makes your judgment legible and lets the team correct you cheaply.
4. 4Define the demo. Decide the single end-to-end path you'll show before you write a line. The build exists to make that path real.
5. 5Send your clarifying questions. Slack the team the way you would on the job - share your plan, ask the two questions that actually change your design, then start.

You'll be dropped into a frozen snapshot of Cursor's own codebase - large, real and entirely unfamiliar. The question the founders ask afterward is blunt: can they go end-to-end in the codebase?

This is where authentic daily use of Cursor pays off and prep-cramming shows. Someone who lives in the tool reaches for codebase search, symbol jumps and an agent to explain a module by reflex. Someone who skimmed docs the night before reads files top to bottom and stalls.

A reading order that earns velocitymap before you edit

1. 1Get it running first. Build and launch the editor before changing anything. A known-good baseline is the thing you'll diff every later change against.
2. 2Find the seam. Use search and symbol navigation to locate where your feature plugs in - the command, the panel, the agent loop. Ask Cursor to explain that module before you touch it.
3. 3Inventory reusable primitives. Note the existing pieces you can stand on: the diff renderer, a context-retrieval helper, a streaming-edit applier, an existing command registration. Reuse beats reinvention under a clock.
4. 4Make one small, verifiable change. Wire the smallest possible version - a button that fires, a command that logs - and confirm it works end-to-end before building outward.
5. 5Keep it runnable at every step. Commit in small increments so you're never more than one undo from a working app.

Finding the seam is the whole game. The seam is the single point where your feature attaches to the existing system: which command surface, which event, which render path. Spend your spike hunting for it, because once you've found it the build collapses from “invent everything” to “extend one thing.”

Eight hours is enough to ship something real and not a minute more. The candidates who win plan the day like a project, not a hackathon and protect the last two hours for polish and the write-up.

Treat the schedule as a budget you commit to up front. The single most common mistake is building until the clock runs out, leaving no time to make it presentable or to prepare the tradeoffs story. An unpolished demo with no narrative undersells even good work.

Cut scope, don't blow the budgetthe recovery move when you're behind

You will fall behind. The skill is cutting scope the moment you notice, not at the end. A working narrow slice always beats a broad broken one, because the narrow slice demos and the broad one doesn't.

1. 1Set a checkpoint. At the end of the build block, ask: is the demo path working right now? If not, cut.
2. 2Drop the second feature first. Anything beyond the core demo path is the first to go. Park it in the write-up as “next.”
3. 3Fake the edges if needed. A hardcoded value or a stubbed model response that makes the demo real is fine, as long as you say so when you present.
4. 4Protect polish time. Never let the build eat the final hour. A rough-but-complete demo wins; a half-finished ambitious one loses.

Function gets you a pass. Craft gets you the offer. The JD asks for a taste for models and design and the onsite is where you prove you have it.

Cursor's whole bet is powerful tools that don't compromise on ease of use. The feature you choose should embody that tension. A raw capability bolted on with no thought to the moment of use signals an engineer; a capability wrapped in a moment that feels obvious and fast signals a product engineer.

Where taste actually showsthe details interviewers notice

The accept/reject moment deserves special attention because it's the defining interaction of an AI editor. Reviewing a PR of AI-generated code, accepting a multi-file edit, trusting a suggestion - these are exactly the new interfaces the role exists to invent. If your feature has a moment where the user decides whether to trust the AI, sweating that moment is the most direct way to show the taste they're hiring for.

• Tie the feature to a named user pain, not a generic capability - “reviewing a 30-file AI refactor is exhausting” beats “add a review tool.”
• Connect it to where Cursor is heading: agent loops, multi-file coordination, trust in AI output at scale.
• Make the happy path feel inevitable, then let depth live one layer down for power users.
• Polish one interaction completely instead of roughing out five - depth of craft reads louder than breadth.

The presentation is not a victory lap. It's the part of the day where they decide whether you'd be good to ship with - whether you can reason about your own system and hold an honest conversation about its limits.

The JD wants a functional understanding of the system design and someone well-prepared to discuss the trade-offs. That means you can explain how your feature works, why you built it that way and what you'd change - without getting defensive when they push.

The order that landsproblem before demo before design

1. 1Problem. Open with the user pain and why it matters. Thirty seconds. They should want the thing before they see it.
2. 2Demo. Show the one end-to-end path working. Live, not slides. This is the proof.
3. 3Design. Walk the architecture - the seam you found, the primitives you reused, the data flow. Functional, not exhaustive.
4. 4Tradeoffs. Say what you cut, what you'd do with more time and the risks you'd watch. This is the senior part.
5. 5Open the floor. Invite questions and disagreement. The debate is where they really evaluate you.

Being explicit about what you cut is counterintuitively the strongest move. Listing your own limitations shows you saw them, which is exactly the judgment a flat, fast team needs. The candidate who claims it's all done reads as someone who can't see their own gaps.

Especially for senior candidates, the final stage is building side-by-side with future teammates on a real problem, with culture conversations woven through, often over meals. They're answering one question: do we want to work with this person every day?

Talent density is a stated value, so they're not just checking competence - they're checking whether you raise the bar of the room. That shows up in small behaviors over two days far more than in any single answer.

What “good to ship with” looks likebehaviors they're watching for

• You communicate progress and blockers before being asked - “I'm stuck on the context plumbing, here's what I've tried” keeps the room moving.
• You treat Slack questions and teammate chats as real collaboration, not a crutch you're embarrassed to use or a place to hide.
• You're pleasant under pressure - calm, curious and generous when the build gets hard or a teammate disagrees.
• You make the people around you better: you ask sharp questions, share what you learn and credit others.

The flat, fast, in-person-leaning culture is something you demonstrate, not describe. Saying “I love moving fast” means nothing next to actually shipping a clean slice, flagging a blocker early and debating a design point without heat.