Cursor Model Routing & Inference Engineer Interview Questions

The posting describes the team's scope in one sentence that is worth taking literally: it owns the full inference path, making Cursor's AI faster, more reliable and more cost-effective at a scale few teams in the world get to operate at. Every agent session, every tab completion and every chat message flows through this stack. As an engineer on it, you build the inference platform that powers every AI interaction in the product.

That is a backend-platform job, not a modeling one, and the distinction shapes everything below. The JD never mentions training a model or writing a prompt. It talks about provider API semantics, outages, traffic spikes and GPU utilization. If the word inference made you think of research, re-read the example projects, because they read like a traffic-engineering team that happens to be moving tokens.

Cursor lists three example projects, and each one is a system rather than a feature. Read them as the three failure classes the team is paid to prevent: a new model that takes weeks to onboard, a provider outage that users can see, and a traffic spike that takes a provider down with it.

• Building and evolving the inference gateway, a single abstraction over every provider's API semantics, so model onboarding becomes a config change.
• Designing intelligent cross-provider failover so no single provider outage causes user-visible degradation.
• Designing routing backpressure and admission control so traffic spikes do not cascade into providers.

The posting does not publish a you-will-not-own list the way some Cursor engineering JDs do, so the boundary has to be read from what it names. It names the gateway, failover and admission control. It does not name model quality, prompting, the agent harness or the client. Those live with other teams, including the Agent Harness seat that owns Auto's routing preferences and model launches on the product side.

The gray-area line is the one to prepare against. The fourth fit bullet says you make good calls when there is not a single right answer, weighing reliability, cost, latency and user experience, and the phrasing is a tell: the team has argued about exactly this, probably recently. A system that fails over instantly is also a system that can thunder-herd onto the backup provider. A system that admits every request is also the one that cascades. Every example project has a version of that tension inside it.

Where does Cursor Router sit in this? The public product, which routes a request to a model based on task, is a product surface; the platform this team runs is what that choice executes on, along with every other model call. I would not assume the interview expects you to know the product's routing rules. I would assume it expects you to know what happens to a request after the routing decision is made.

Unlike most Cursor postings, this one publishes a process. If there appears to be a fit, Cursor reaches out to schedule two to three short technicals, then an onsite in the office where you work on a small project, discuss ideas and meet the team. That is the whole published statement, and this page does not extend it: no stage content, no take-home policy, no language list is given.

Two of the three are standard senior-backend criteria. The middle one is the unusual one, and I think it is where candidates with strong systems backgrounds and no inference exposure get caught. Provider economics means knowing that a token has a price that varies by provider, by cache hit, and by whether the request was fast or standard tier, and that a routing decision is therefore also a spend decision. You do not need Cursor's numbers. You need to show you have thought in those units before.

Each row takes one thing the posting states and turns it into the question shape it implies, plus what an interviewer would be listening for. Derived from the JD's example projects and fit bullets, not Cursor's verbatim questions.

The last row is the one to rehearse out loud. It depends is a true answer and an empty one; the useful version names what it depends on and what you would do under each branch.

Build a small version of the system the posting describes. A gateway that fronts two model providers, streams tokens, fails over when one returns errors, and sheds load when a queue grows is a weekend project, and having built one changes every answer you give from theory into something you watched happen. That is also, as it happens, roughly the shape of an onsite small project.

1. 1Write a two-provider gateway that normalizes streaming and error semantics behind one interface, and keep a list of every place the two providers refused to look the same.
2. 2Add failover with a budget. Detect provider failure from a rolling error rate, fail over with a ramp rather than a cliff, and write down the condition that moves traffic back.
3. 3Add admission control with priorities. Decide which request class you would reject first under a spike and why; Cursor's own surfaces (tab completion, chat, agent sessions) are a good set to reason about.
4. 4Do the economics on paper. Price a day of traffic through your gateway under two routing policies, using public provider list prices, and be ready to explain the assumptions.
5. 5Prepare one incident story from a system you ran at scale, told as detection, decision, fix and the measurement that proved the fix.

The part most candidates skip is the capacity-planning bullet, because it sounds like a manager's job. It is not, on this team. The JD lists it alongside GPU utilization and provider economics as something you reason about, which means a launch that doubles agent traffic is your problem before it is anyone else's. Have an answer for how much headroom you would reserve for a model launch and what you would do when you were wrong.

For structure, the free interview-prep practice track schedules applied work and a mock loop so the reps happen on a calendar. It is scaffolding for the bar this posting sets, not Cursor's process, and the only process facts on this page are the ones the posting states.