# FDE at Cursor: not demos, but merged PRs

> The most convincing preparation for this role is to run your own migration project with evals, tracing and cost per PR, then write it up as a playbook others can repeat.

Original: https://fdetimes.net/en/guides/cursor-forward-deployed-engineer-guide/

You open the Forward Deployed Engineer, EMEA job post that Cursor (the company Anysphere) published for a London role on 4 June 2026. It contains a fairly blunt sentence: this is not a demo role; you are responsible for systems that have to work in the real world.

Keep that sentence in mind as you read the rest. Many engineers read job posts as a list of keywords to stuff into a CV. For this role, the right way to read it is to treat each line as a task you will have to do at the customer in your first week, then ask yourself whether you have done it before and what evidence you have.

## The job post actually describes an engagement

Read all the requirements and you will see that Cursor's post describes a fairly complete cycle of work. You run discovery with the customer's engineers and build Cursor workflows for jobs such as refactors, migrations, PR review loops, or going from incident to fix.

You then own the evals, tracing and cost trade-offs yourself, and package what you have built into reusable patterns.

On skills, Cursor asks for experience building production-grade AI workflows, the ability to work end to end across frontend, backend, infrastructure and prompt iteration, operational reliability, and strong Python and TypeScript/JavaScript.

Exponent's job aggregation page lists the expected experience as five years or more, including at least two years working directly with customers.

How Cursor places the role within the organisation is also worth reading closely. The company describes FDEs as people who sit with enterprise engineering organisations, possibly remotely, and Exponent's page notes that Cursor is building a full FDE organisation rather than a support function.

This bears directly on how you tell your story in interviews: you are the person who gets the product running for real, not the person working through tickets.

## How is an FDE team at Cursor described?

The Forward Deployed Strategist job post that Cursor published on 24 July 2026 shows how a team is organised. Each pod consists of one Strategist and one or two FDEs; the FDEs sit with the customer's team and build deeper production systems. The post also restates the company's mission: automating coding.

At leadership level, Cursor is hiring a Regional Director of Forward Deployed Engineering, a role posted on 22 July 2026, to lead and grow a team of 6–8 FDEs working on strategic projects.

The person needs eight or more years of experience leading engineering teams that ship production systems, acting as an executive technical sponsor to customers, and building reusable playbooks so the whole FDE organisation gets better over time.

One preparation tip follows from this. When the leadership of an FDE organisation is tasked with building shared playbooks, an FDE who can turn work for one customer into something that applies to the next is likely to be valued highly.

Bring evidence for both levels: one customer running well, and one pattern others can reuse.

## Example: a migration project with real measurements

Imagine a hypothetical customer that wants to move hundreds of services from an old logging library to a new one. This is exactly the kind of work the job post mentions. A good discovery session with the customer's tech lead might go like this.

> **FDE:** What does a migration PR need to look like for your team to merge it without editing it by hand?
> **Tech lead:** Green CI, no change to the log format the alerting system reads, and each PR touches only one service.
> **FDE:** Who reviews, and how many hours a week do they have for this?
> **Tech lead:** Two people, a few hours each.

Those three answers define your evals: green CI, unchanged log format, one-service scope. The last answer defines the real constraint: human review capacity, not code-generation speed.

Now a hypothetical calculation. The workflow generates 200 PRs, 150 pass CI, and reviewers merge 120. The merge rate is 60%, not the 75% the CI figure suggests. If the total model cost for the whole batch is C, the real cost per merged PR is C divided by 120, not C divided by 200.

This is where tracing earns its keep. By storing a trace for each PR, you can see why the 30 PRs that passed CI were rejected: perhaps a changed log format, perhaps touching two services at once.

Each cause can become an automated check that runs before a PR reaches a reviewer. The two reviewers then only have to read PRs that have a real chance of being merged.

**Key point:** Measure a workflow by the number of PRs merged, not the number of PRs generated.

## Turning the project into an application

The table below maps each requirement in the job post to evidence you can create yourself from a project like the one above.

| Requirement in the post | Evidence to have |
|---|---|
| Discovery with customer engineers | A page recording the questions asked and the merge criteria derived from them |
| Building Cursor workflows (migration, PR review) | A repo with a real series of PRs, each with one scope |
| Evals, tracing, cost | A table of merge rate, rejection causes and cost per merged PR |
| End to end, Python and TypeScript | An orchestration script in Python, a small dashboard in TypeScript |
| Reusable patterns | A one-page playbook that someone else can follow |

In your CV, write in terms of outcomes: one line stating the workflow, the merge rate, and which check you added after reading the traces. If you have fewer than two years working with customers, describe the times you sat with another team to untangle a production problem, because that is the closest material to this job.

## Common mistakes in preparation

The most common mistake is bringing a demo to an interview for a role that explicitly says it is not about demos. A slick video of an agent fixing code does not answer the questions: how many times did it run on a real repo, how many times did it fail, and what did you do when it failed?

Another mistake is ignoring cost. The job post states plainly that FDEs own cost trade-offs, so if you cannot say what a PR costs, you are leaving blank a part of the job assigned directly to you. Do not talk only about code either: interviewers want to hear what you asked the customer before you wrote the first line.

The final mistake is stopping at one successful run. In an organisation whose leadership is tasked with building playbooks, the next question is almost certain to be: can someone else repeat this without you?

This week, pick an open-source repo and migrate 20 files with Cursor. Twenty PRs with an honest table of numbers will be more convincing than any demo.

**Try this week:**

- Pick an open-source repo with at least a few dozen files using an old API, then use Cursor to migrate 20 of those files, one PR per file
- Record for each PR: whether CI is green, whether you would merge it as a reviewer, and how many tokens it used, then calculate the merge rate and the cost per merged PR
- Write a one-page playbook for this workflow and put the link at the top of your CV

## Sources

- [Forward Deployed Engineer - EMEA (Anysphere, via Thrive Capital job board)](https://jobs.thrivecap.com/companies/anysphere-2/jobs/81567994-forward-deployed-engineer-emea)

- [Cursor Forward Deployed Engineer jobs (Exponent / aced.io)](https://www.aced.io/jobs/fde/cursor)

- [Regional Director, Forward Deployed Engineering (Anysphere)](https://jobs.thrivecap.com/companies/anysphere-2/jobs/87156999-regional-director-forward-deployed-engineering)

- [Forward Deployed Strategist (Anysphere)](https://jobs.thrivecap.com/companies/anysphere-2/jobs/87458891-forward-deployed-strategist)