The Role & the Core Services Charter

The Engineering Manager, Core Services leads the team that owns Cursor's critical shared backend - the layer that sits between every product surface and the raw infrastructure. Four domains live under that charter and none of them is a back-office nicety: auth, webhooks, the backend systems powering agent workflows and source-control (SCM) integrations.

Read this section as the role contract. The diagram or table names the surface area, but the interview signal is whether you can turn it into a clear operating claim: what you own, what you do not own, what evidence proves the work is working and where judgment matters.

Think of this team as the load-bearing wall of a tool with over a million daily active users. Product teams build rooms on top of it. When the wall cracks, every room shakes at once. That is what people mean when they call this layer existential rather than incremental.

Two of these - webhooks and SCM - are how Cursor talks to systems it does not control. When GitHub throttles you or fires a duplicate event, your code is the thing that has to stay correct. The other two - auth and the agent backend - are the parts users feel on literally every action they take.

Because this is shared infrastructure, the metric that governs it is blast radiusHow much breaks if a change goes wrong; the scope of potential damage.. A bug in one product feature annoys the users of that feature. A bug in the auth path or the webhook dispatcher can take down everyone at once. That asymmetry is why clean contracts and reliability bars matter here more than raw feature velocity.

Cursor's culture line is blunt: no narrow job descriptions. Engineers - and managers - write copy, fix user issues, optimize infra and sit in hiring loops. An EM here is a player-coach who still ships, not a process owner who delegates the building.

The org is flat and lean with limited management hierarchy. Decisions happen through conversation and consensus, not approval chains. That structure only works if the manager in the room can argue the technical merits, not just facilitate the meeting.

This is the trap to avoid in prep: the role is failed from both ends. A brilliant builder who can't grow a team is wrong for it and so is a polished people-manager who hasn't touched production in years. The loop is engineered to screen against the second far harder than most companies do.

• The technical screens are hands-on coding and system design, medium-hard, with no AI allowed beyond autocomplete - your fundamentals must be sharp unaided.
• The signature onsite is a paid, multi-hour working session building a real project alongside the team, so credibility as a builder is tested directly, not inferred from a résumé.
• There is still a full people-management and behavioral panel, so coaching ability is graded too - you don't get to be only a builder.

The job description lists qualifications in the language of HR. Underneath each line is a specific thing you must be able to show in a room, usually with a concrete system you led. Decode the lines and the prep gets concrete.

The verb that matters in the first line is led. "I led the auth rewrite" and "I worked on the auth team" land completely differently. Leadership of a critical service means you owned the outcome - the SLO, the on-call rotation, the migration plan - not that you closed tickets inside someone else's design.

"It depends" is a fine opening, but it cannot be the whole answer. A senior backend leader is hired for judgment, which means committing to a position and naming the conditions that would change it. Neutral summaries of both sides read as someone who has read about the tradeoff but never had to own it at 3am.

Over a million daily active users changes which problems are real. At this scale, hot paths, caching and database scaling stop being optimizations you get to later and become the first thing you design around. Answers that ignore scale read as junior here.

Auth is the clearest example. If it sits on every request, then a 50ms regression there is a 50ms tax on the entire product and an availability dip is a full outage no matter how healthy the rest of the system is. That is why caching strategy and read-path design for auth are not afterthoughts at this scale.

The agent backend introduces a dimension most backend roles never touch: the dollar cost of a single request. LLM calls are expensive, so a reliability decision like "retry three times" is also a cost decision and a capacity decision like "keep warm headroom" burns money while idle.

The last stake is adversarial. A developer tool with repo access is a high-value target, so the security surface is large and someone is always probing it. Auth design here isn't just correctness, it's defense against an attacker who benefits from getting it wrong.

Somewhere in the loop - usually the hiring-manager conversation or the values round - you'll be asked some version of "what would you do first." A vague "learn the systems and build relationships" answer is forgettable. A specific, staged plan that ships something real by day 60 is the one they remember.

1. 1Week 0–30: earn trust and map the terrain. Learn the four systems hands-on, read the incident history and chart current SLOs. Meet every engineer and find the team's real strengths and gaps. Change as little as possible while you build the map.
2. 2Day 30–60: ship one credible win. Pick a single reliability or security improvement in auth or webhooks that you can land yourself. Shipping early as a player-coach buys you the credibility to make bigger calls later.
3. 3Day 60–90: set contracts and a hiring plan. Define the service contracts between Core Services and product surfaces and draft a hiring plan that raises talent density without bloating headcount or process.

The structure does the work: listen first, ship a concrete proof second, then institutionalize with contracts and hiring. It signals you won't barge in reorganizing on day one and that you also won't spend ninety days "observing" without delivering anything.

One more piece makes this answer land: a one-sentence "first change and why" for each of the four domains. You won't recite all four, but having them ready means whatever the interviewer pushes on, you have a specific, defensible move instead of a stall.