Cursor Agent Harness Engineer Interview Questions

You build the part of Cursor that decides what an agent can do. The posting scopes it as the agent loop, the tools, the prompts, the execution environment and the capabilities sitting on top, all designed as a platform other Cursor engineers extend and depend on. That last clause is the one to sit with. Your users are largely colleagues shipping on your surface, so a change you make lands in several products at once.

That sounds like a scoping note. It is closer to a description of the job's hardest part. Actually, calling them users undersells it — a platform team's colleagues are also its constraint, because the interfaces you would most like to change are the ones three other teams already build on. Expect at least one conversation about that, rather than about the agent loop itself.

Two items in the responsibility list carry more weight than the others, I think. Multi-agent coordination is named as an experience the harness shapes. And Auto, the default model setting, is where the JD says users trust Cursor to make the right model choices under real-world constraints, which is a polite way of saying the default is a product decision made on behalf of everyone who never opens that setting.

Four responsibilities are listed, and they run wider than a typical backend seat:

• Advance the agent harness itself: the loop, tools, prompts, execution environment and capabilities used across Cursor products, shaping experiences like multi-agent coordination.
• Improve the default Cursor agent experience (the "Auto" model setting) by making model choices against user needs, model capabilities and cost appetite.
• Shape the default Cursor agent's personality.
• Launch new models on Cursor end to end, partnering with foundation model providers and Cursor's research team on integration, evaluation and rollout.

Cursor publishes no rubric and no question bank for this team, so treat any post claiming to have the exact loop with suspicion. What the posting does give you is a fit list, and it is unusually opinionated about judgment rather than credentials. Read each criterion as an assessment area.

Two more sit at the bottom of the list marked as a plus: building eval datasets or frameworks to measure and improve AI system performance, and building products or tools used by other engineers. Well — "a plus" on a platform team usually means something closer to "the people we hire tend to have this." If you have an evals story, lead with it rather than saving it for the end.

The line about staying current on emerging research reads like boilerplate until you connect it to the last responsibility. Someone launching new models end to end has to form a view on a provider's release within days of it landing, decide what it is actually better at, and then decide whether that difference is worth changing a default nobody else has to opt into. Reading papers is not the point. Having a defensible opinion fast is.

More than most of its postings, which is worth knowing before you over-prepare for a format nobody described. The JD states that if there appears to be a fit, Cursor schedules two to three short technicals, and after that an onsite in its office where you work on a small project, discuss ideas and meet the team. That is the entire published outline.

Notice what that outline implies about preparation. A short technical rewards being quick and correct on ordinary engineering, not on agent trivia. The onsite project rewards something different: taking an ambiguous brief to a working slice while explaining your reasoning out loud, which is exactly the gray-area criterion in a room. Prepare both separately. They fail for different reasons, and probably at different stages.

The table maps each published responsibility or fit criterion to the question shape it implies, and to what an interviewer is reading for. These are derived from the JD's own words, not Cursor's verbatim questions. Really, the third column is the part worth rehearsing; the first two are just how you get there.

If you can do each row on work you actually did, the phrasing an interviewer picks stops mattering much.

Preparation here is mostly building and running agents on real work, then having opinions about what they did. The fit list rewards judgment that comes from watching agent behavior closely, and that is hard to assemble the week before an onsite. Honestly, start with the product you would be building.

1. 1Run Cursor's agents daily on a real repo, including Auto, and keep notes on where the default model choice was wrong for your task. That note file is the raw material for the routing question. Start with Cursor Agents if any surface is unfamiliar.
2. 2Build one small agent loop yourself: tool schema, validation, failure handling, termination. You want to be able to draw it and defend the termination condition, not describe it in general terms.
3. 3Bring an evals story. What you measured, what the metric missed, and what you changed after it misled you. The JD lists eval frameworks as a plus, and this is where taste in model behavior becomes checkable.
4. 4Prepare one gray-area decision where data, user experience and cost disagreed: what you shipped, what you gave up, how you found out whether it was right.
5. 5Warm up timed coding for the short technicals, then rehearse an ambiguous brief to a demoable slice out loud for the onsite. The two stages fail for different reasons, so practice them separately.

The free interview-prep practice track runs applied coding screens and a mock onsite project on a schedule, which mostly solves the problem that daily practice is easy to agree with and easy to skip. Treat it as scaffolding for the bar this posting sets. It is not Cursor's official loop, and nothing here should be presented as though it were.