Cursor Software Engineer, ML & Inference Interview Questions

You build the training, inference, and data systems behind Cursor's frontier coding models, working directly with researchers to make progress repeatable and iteration fast. Cursor's careers site labels this posting "Software Engineer, ML Research" (the page header reads "Research Engineer"); the work centers on ML infrastructure, and inference is one of the three systems it names, which is why it maps to the ML & Inference role.

The job description lists three responsibilities, and every interview signal below traces back to one of them. Read them before the question list.

• Build Cursor's distributed training, inference, and RL infrastructure.
• Write libraries that simplify how researchers run large-scale data jobs.
• Architect the systems that turn Cursor user data into effective training data.

The second line is written from the researcher's side rather than yours. The posting has you working with researchers to "make progress repeatable and iteration fast," so a fair test of what you build is whether a researcher can run a bigger job than they could last month. A library only its author can operate hasn't simplified anything, which probably makes adoption the part an interviewer pushes on. The posting stops short of saying so.

Two of the three lines are data work, though the title says inference.

Cursor does not publish its interview stages, rounds, or timeline for this role, so treat any "the ML loop is X" claim with skepticism. What you can prepare for is the bar the job description sets. The three responsibilities and the four fit criteria point at a handful of things every format would sample, whatever the exact sequence turns out to be.

That silence is worth reading precisely, because a sibling posting on the same careers site does publish its process. Cursor's Software Engineer, Infrastructure listing carries an "Applying" section naming two to three short technicals, then an onsite in the office where you work on a small project, discuss ideas, and meet the team. This one has no such section. Borrowing that shape for this role would be a guess, and disclosure varies posting by posting, which the interview-process page works through in more detail.

One row asks you to reason about training and inference "at scale," and that phrase is where the difficulty hides. At scale the numbers you are improving pull against each other. Bigger batches keep the GPUs busy and raise throughput. The same batching, awkwardly, makes every request share the GPU with more neighbors, so tail latency gets worse. Prefill and decode pull apart the same way, one setting how long before the first token appears and the other the gap between tokens after that. Say which number you are protecting and what you traded for it.

These are question types the job description implies, the kind of prompt each responsibility naturally invites. Prepare a concrete story for each, and note what a strong answer proves versus a weak one, because interviewers read for the signal, not the script. Expect follow-ups that go a level deeper than your first answer.

The likeliest way to waste this prep is to work the wrong axis. "ML" in the title pulls people toward transformer internals and paper summaries, and then the hard follow-up turns out to be what happened when a node died mid-job. Infrastructure background sits first in the fit lines and model intuitions sit third, and that is the order worth putting your weeks into, though the posting never calls it a ranking. Get it backwards and you lose the study weeks, and the depth you skipped shows the moment someone asks you to design a system out loud.

If a design answer stalls, check the first thirty seconds of it. Answers that go wrong usually started with boxes on a whiteboard instead of a latency budget and a request volume.

Preparation for this role is mostly systems depth plus proof. The clearest proof is a distributed system you designed, shipped, and kept running yourself: the kind of depth an interviewer can probe for an hour and you never run dry. Reading about sharding layouts is the obvious way to build that, and I'd rank it second. The better hours go into failure behavior, like what one stalled worker does to a job that is already running. Work the steps below, then route the reps through daily practice.

1. 1Go deep on distributed systems: build or study one with sharding, scheduling, and fault tolerance, and be able to whiteboard training and inference throughput plus the failure modes under load.
2. 2Build in Cursor daily on a real repo (Tab, inline edit, Agent, and plan mode) and know what changed in Cursor in 2026 so you can speak to the product the models power.
3. 3Get concrete about LLM training and inference: be able to reason about RL on real usage, what makes training data effective, and the latency and cost tradeoffs of serving a model.
4. 4Rehearse one end-to-end ownership story: a system you designed, shipped, and kept running with high ownership. Name the tradeoff you made and what you'd change next time.
5. 5If you're newer to Cursor itself, ground yourself in the fundamentals first, then run structured reps.

The first step is first because it is the slow one. Systems depth takes months to build and tends to get probed on the second and third follow-up rather than the first, while the product familiarity in step two takes a weekend on a real repo and the ownership story in step four is rehearsal of work you already did. Take them out of order and you turn up fluent in Cursor and thin on what the first fit line asks for.

Team size changes which story to lead with. In a large platform org the training substrate and the data pipeline sit with different groups, and the pager sits with a third, so a candidate from that world can claim one layer in real depth. Smaller teams put all of it on a few people.

This posting asks for end-to-end ownership in those words, which points at the second case, so lead with the project you designed, shipped, and were still answering for when it broke.

For structured reps, the free ML & Inference practice track here runs the role and charter, an inference-fundamentals deep dive, routing, failover and backpressure, coding craft, a behavioral module, and a mock-loop capstone. It's scaffolding built around this job description, not Cursor's official process.

The fit criteria in the posting are short and specific, and they double as your prep checklist. Cursor lists four, weighted toward systems depth and ownership rather than an ML research record.

• A strong infrastructure and distributed-systems background.
• The ability to architect and ship end-to-end with high ownership.
• Strong intuitions about how language models work.
• Genuine excitement to learn more about ML.

The posting is explicit that you don't need to arrive as a researcher: "excited to learn more about ML" sits right next to "strong intuitions about how language models work." The hard requirement is distributed-systems depth and end-to-end ownership; curiosity about models is the complement, not a publication list. The role is based in San Francisco or New York per the posting.

The gap that takes longer, I think, runs the other way. An ML background with no production system behind it leaves the hard requirement unmet, and nothing in the four lines lets research depth substitute for distributed-systems depth. If that's you, spend the time on one system you can operate rather than on more model theory.

The four lines name no degree requirement and no publication record, so don't screen yourself out on either.