Cursor Software Engineer, Core Services Interview Questions

The posting places the team precisely: Core Services owns the critical shared services that sit between Cursor's product surfaces and the infrastructure layer, and it names three of them, auth, webhooks, and the backend systems that power agent workflows. You build the systems every product team depends on, and the stated goal is that they are reliable, well-abstracted and ready for whatever comes next.

Between is the operative word. This is not the team that runs the GPUs and it is not the team that ships the editor; it is the layer both of those call, which means its failures show up as everyone else's incidents. That is a good place to work if you like owning the thing nobody notices until it breaks, and a bad one if you need your work to be visible in the product.

Five example projects are listed. Each is an ownership statement about a system rather than a task, and the verbs are the tell: owning, powering, building, hardening, driving.

• Owning authentication: designing and implementing a scalable auth architecture that secures one of the most widely used developer tools in the world.
• Powering the agent backend: owning the infrastructure behind Cursor's agent workflows, optimizing for end-to-end performance and reliability as agents become central to the developer experience.
• Building a robust webhook server: high-throughput event delivery with proper retry semantics, dead-letter queues and observability so external integrations just work.
• Hardening SCM integrations: resilient abstractions over source control providers so Cursor stays solid regardless of third-party conditions.
• Driving end-to-end agent reliability: partnering with the client and inference teams to improve the full path from user action to agent response.

The posting is unusually concrete about ownership and says nothing about exclusions, so the edges have to be inferred from the neighbors it names. It says you partner with the client and inference teams on end-to-end agent reliability, which places the editor and the model-serving path outside this seat. What is inside is everything a product surface calls on the way to infrastructure: identity, event delivery, source-control access and the agent backend.

The fit bullet about abstractions deserves a closer read than it usually gets, because it is phrased as caring about something rather than having done it. Well-defined service contracts is the kind of thing every backend engineer claims to value; the posting is asking whether other teams could build on your services without talking to you. That is a measurable property. If your last platform had a contract other teams consumed without a meeting, lead with it.

Then there is the second bullet, which is the one that separates this from a generic backend posting: you have worked on agent products or infrastructure and have strong opinions on the reliability and performance of complex multi-step systems. An agent run is a chain of model calls, tool executions, SCM operations and client round-trips, any of which can fail halfway. Reliability there is not an uptime number. It is what happens to the run in progress when step six of nine times out.

This posting 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 entire published statement; no stage content, take-home policy or language list is given, and this page adds none.

A fifth bullet is marked as a plus rather than a requirement: experience with authentication and authorization frameworks (OAuth, JWTs, RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. Press Enter for the full definition.), event-driven architectures, or building developer-facing platform services. I would treat the auth half of that as closer to required than the wording suggests, given that owning authentication is the first example project on the list. You do not need to have built an identity provider. You need to be able to argue about token lifetimes and scope boundaries without looking them up.

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

Answer from systems you actually ran. The posting's own language is about owning and operating, and an interviewer who wrote it will notice the difference between a design you shipped and one you read about.

The most useful preparation is to build a small webhook server properly, because it is the one example project that fits in a weekend and exercises nearly everything the posting names: retries, a dead-letter queue, idempotency, observability and an external endpoint that misbehaves. Having run one changes the delivery-semantics question from a vocabulary test into a story about the bug you found at 2am.

1. 1Build a webhook server that delivers to a deliberately flaky endpoint, with idempotency keys, bounded exponential backoff, a dead-letter queue and a replay command. Keep the list of edge cases that surprised you.
2. 2Sketch auth for four surfaces (desktop client, web, CLI, cloud agent) acting as one user, and decide token lifetimes, scopes and how revocation reaches each surface.
3. 3Write the SCM interface on paper. List the operations an agent needs (clone, branch, push, open and update a PR, read checks) and mark which ones GitHub and GitLab disagree on.
4. 4Prepare the step-six-times-out answer. For a multi-step agent run, decide what state is checkpointed, what is safely replayable, and what the user sees while it recovers.
5. 5Bring one full-lifecycle story: a service you designed, ran, broke and fixed, with the number that proved the fix.

The bullet candidates most often skip is the partnership one, because it sounds like process. It is not. Driving end-to-end agent reliability with the client and inference teams means you own a latency or failure that originates in someone else's code, and the practical skill is cross-team instrumentation: a trace that survives the hop from the editor into your services and out to inference. If you can describe how you would get that trace in place in a week, you are answering the question most people treat as filler. See how Cursor's own cloud agent security and network docs describe that path for a sense of the hops involved.

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; the only process facts on this page are the ones the posting states.