AI-native products
Cursor
An AI code editor whose users are engineers who spot a wrong suggestion instantly and remember it.
Overview
Cursor builds an AI code editor and the agent infrastructure behind it. Their own careers listings show how wide that surface has become: agent harness and agent evaluation, model routing and inference, pretraining and reinforcement-learning data, storage, client infrastructure, security. In August 2026 the company announced it had become part of SpaceX; the engineering described on their blog and careers page is still the thing to prepare against.
The defining constraint is the audience. Users are professional engineers reading every diff, so a wrong suggestion is not a slightly worse answer, it is a bug someone has to notice and undo. Correctness is visible immediately and trust is expensive to rebuild. Latency is felt the same way: inline completion has a budget measured in tens of milliseconds, while an agent that runs for minutes has to be obviously worth the wait.
The company says openly that it is built around self-directed individual contributors, and interviews reward people who ship whole features rather than a slice of one. Their engineering blog is unusually concrete for this industry — model routing, open-sourced mixture-of-experts kernels, cloud agent environments, build caching to make agents start faster — and reading it is the cheapest preparation available.
What Cursor visibly values
Inferred from public material, not from a leaked rubric. Treat these as the themes worth emphasising rather than as a scoring sheet.
- Editor-grade latency thinking. Completion and inline edit budgets are tens of milliseconds; speculative execution, caching and cancellation are the interesting part, not a faster model.
- Codebase retrieval at repository scale — indexing, incremental updates, and choosing what context to send when the repo is far larger than any context window.
- Evaluation on real repositories rather than benchmarks. They ship agent evaluation and quality as its own team, and vague talk about "measuring accuracy" does not survive contact with it.
- Inference economics: routing between models, when a cheap model is sufficient, and what an agent run costs per task when it may call a model dozens of times.
- Systems and client engineering. A lot of the product is an editor, so process management, IPC, filesystem watching and not blocking the UI thread all matter.
- Autonomous, wide-scope ownership. They are explicit about hiring self-motivated individual contributors, and candidates who need a tightly specified task read badly.
- Security instincts about agents that execute code — sandboxing, credential handling and blast radius when an agent is given a shell.
Roles this kind of team hires
- AI Engineer
- LLM Engineer
- Machine Learning Engineer
- MLOps Engineer
- AI Research Scientist
- AI Security Engineer / Red Teamer
- AI Product Manager
Linked titles have a full question bank with model answers. Unlinked ones are titles this employer uses that do not map onto one of our role guides.
How to prepare
Use it seriously on a real codebase first
Not a toy project. Run the agent on something large enough to hurt, note where it fails, and arrive with three specific complaints and a suggested fix for each — that conversation goes better than any rehearsed answer.
Design a context-selection strategy out loud
Given a million-line repository and a fixed context budget, explain what you would index, how you would rank candidate files for a given edit, and how you would keep the index fresh as the developer types.
Have a real answer for agent evaluation
Explain how you would tell whether a change to the agent made it better: what tasks, what harness, how you handle non-determinism, and why unit-test pass rate alone is a misleading signal for editing code.
Read the engineering blog and pick a fight
Their posts on model routing, agent swarms and cloud agent environments describe real tradeoffs. Understand one well enough to say which alternative you would have chosen and what it would have cost.
Know your inference cost per task
Be able to estimate what an agent run costs in tokens and seconds, where the waste is, and which of caching, routing, smaller models or fewer turns you would reach for first.
What to watch for
Common mistakes with this kind of employer
- Prompt-engineering answers to systems problems. "I would improve the prompt" is not a response to an agent that edited the wrong file; the interesting failure was in retrieval, tooling or the harness.
- Underrating the editor half. Candidates who only prepare model-side material get caught by ordinary client engineering questions about latency, concurrency and process lifecycle.
- Demo-quality standards. A pattern that works nine times in ten is unacceptable in a tool that touches source code, and treating the tenth case as an edge case reads as inexperience.
- No cost sense. Proposing to run a large model on every keystroke, or a multi-agent swarm on every request, without pricing it signals you have never shipped this at volume.
Sources
This guide is written from primary public material — Cursor's own engineering writing, research pages, published job descriptions, and public talks. Nothing here is taken from a competitor's interview guide, and no specific claim about the loop is made without a source that supports it.
Last reviewed . Interview processes change without notice and vary by team, level, and location. Cursor's own careers page is the authoritative description of how it hires; where this guide and that page disagree, that page is right.
Rehearse it before it counts.
Knowing what a company values is not the same as demonstrating it under time pressure. Book a 30-minute 1:1 and run the round you are least confident about.