The Role & Your Charter

Cursor's framing for this role is blunt: you teach the future of software engineering. Strip the poetry and it's a working job - you make it legible, in code and in writing, what a developer can actually build with Cursor's agents, SDK, CLI and automations.

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.

Cursor sells a product whose ceiling almost nobody has found yet. Most developers use Agent mode and Tab and stop there. The API, the Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud., MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers, Background Agents, Rules and AGENTS.md, automations that wire all of it together - that surface is wide and the gap between what's possible and what people know is possible is exactly the gap this role closes.

That gap is where growth lives. A developer who discovers they can script a coding agent against their own repo or run a fleet of background agents overnight, becomes a power user and usually a loud one. You are the person who shows them the path.

Notice the bar. It is not "content shipped" or "assignment completed." It is whether a real developer is now able to do something they couldn't before, because of a thing you made. That standard reframes every deliverable: a tutorial that technically explains the SDK but leaves the reader unable to build with it has failed, even if it's grammatically perfect and on time.

A responsibility on a JD is abstract. An artifact is what you'd actually hand a developer. The skill of this role is the translation: read "gather market intelligence" and know it means a structured feedback doc that lands in a product channel, not a vague promise to "talk to users."

Here is each responsibility mapped to the concrete thing you'd ship and the signal an interviewer reads from it.

The responsibilities are not equally weighted. The first three - teach, explore, automate - are the maker core and they're where a portfolio either carries you or sinks you. The last group is the communicator and conduit work.

"Gather market intelligence" is the bullet candidates skip and it's a tell when they do. The role isn't a one-way broadcast. You sit closer to the developer community than almost anyone at the company, so what you hear - the confusion, the feature requests, the workarounds people invent - is a product input. The strongest candidates describe a loop, not a broadcast.

This is a hybrid maker-communicator role and the hybrid is the whole point. You build the SDK integration or the automation and you write the post that makes it spread. Either half alone fails the role.

The failure modes are symmetric and easy to picture. A brilliant engineer who can't write produces a clever demo that nobody understands or shares. A polished marketer who can't ship produces a thread about a thing they didn't actually build, which developers smell instantly. Cursor is hiring for the person who closes both gaps in one head.

The differentiator inside the maker half is subtle and worth naming precisely. You're expected to use coding agents heavily - Cursor builds them and the team lives in them. The skill graded is not how much you typed by hand. It's your judgment over AI output: knowing when the agent's answer is wrong, when a demo cuts a corner that would mislead a reader, when to throw away a generation and start again.

Cross-disciplinary creativity is called out explicitly and it's a real edge here. The demos that travel on X and HN often borrow a frame from outside engineering - a game, a piece of music tooling, a physical-world workflow rerouted through an agent. A demo that's technically sound but conceptually ordinary lands flat. The unusual angle is what makes a developer stop scrolling.

Four roles all sit near Cursor's developers and an interviewer will check whether you know which one you applied to. The cleanest cut is reach and direction: who you serve, how many at once and which way the work flows.

DX/DevRel is one-to-many and proactive. You teach at scale through public artifacts. Field Engineering is one-to-few and hands-on with named enterprise accounts. Support is reactive - it resolves the issue a user already hit. Product builds the surface itself.

The relationship to Product is the one worth getting right out loud. DX doesn't ship the surface, but it's the most credible external voice for it and the signal it gathers from the community flows back to Product as input. That two-way relationship - amplify outward, route signal inward - is what separates DX from a pure content function.

Cursor's team is small, flat and fast and the work-trial is the real hiring decision - so the question in the room is often "what would you ship in your first 90 days?" A strong answer is a sequence with visible output early, not a learning plan that ends in a deck.

The honest first job is becoming a power user of the whole surface, fast. You can't teach a developer to wire up the Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud. against an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server if you haven't done it yourself last week. So the plan front-loads depth, then converts that depth into artifacts that travel.

1. 1Weeks 1-2: get to top-1% power user. Drive the full surface hands-on - Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud., CLI agent, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers, Rules and AGENTS.md, Background/Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop.. Build something small with each so you've felt the rough edges, not just read the docs.
2. 2Weeks 2-5: ship one demo and one piece of writing that travel. A reference automation or sample app plus the post that makes it land on X or HN. The bar is that a real developer can run it and learn from it.
3. 3Weeks 4-8: stand up a feedback channel. Establish a credible public voice and a repeatable loop that pulls developer signal back to Product - a doc, a channel, a recurring digest.
4. 4Weeks 6-12: raise the bar on a docs slice. Find real correctness gaps in part of the developer surface, fix them and verify by reading the source or SDK internals - not by trusting the existing copy.

Two things make this plan land instead of sounding generic. First, the demo has a deadline measured in weeks, not a quarter - the culture rewards shipping early and iterating in public. Second, the docs work is specific: you're not promising to "improve documentation," you're committing to find gaps and verify against source.