Capstone: Mock Work-Trial
Run the loop on yourself before they do
The mock work-trial brief
After this you can After this you can execute a realistic 8-hour-style build-and-teach exercise.
Cursor's paid work-trial is the round that actually decides the role, so the most impactful prep is to run that exact shape on yourself before they hand you the real one. Give yourself a clock, a brief and no escape hatch.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
This capstone rehearses every stage; the paid work-trial is the one that decides it.
The DX Engineer trial is a maker-and-communicator exam in one sitting: you build something real on Cursor's developer surface and you ship the artifact that teaches it. A demo with no write-up fails the teaching half; a tutorial with no working code fails the maker half. Both have to land.
The brief, written like the real oneOne build, one teaching artifact
Pick one capability and ship a small, real thing plus the post that teaches it. The constraint is the point: scope to what one focused person can finish and polish in a working day.
A working artifact on Cursor's surface: an Agent SDK script, a CLI automation, 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 or a .cursor/rules setup that changes how the agent behaves.
It has to run on a fresh machine, not just on yours. A reviewer will clone it.
The write-up that makes a stranger able to rebuild it: a quickstart, a tutorial or a thread with the code inline.
Voice tuned to a working developer. Show the workflow, not adjectives about it.
Pick one clear whoa moment
Every memorable dev demo has a single beat where the viewer sits up. Design backward from that beat, then cut everything that doesn't serve it.
- Idea
- Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud. that triages your own GitHub issues
- The whoa moment
- It opens a labeled, reproduced issue with a suggested fix in one command
- Why it teaches
- Shows the SDK as a real automation primitive, not a chatbot
- Idea
- MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server exposing your team's internal docs to the agent
- The whoa moment
- Agent answers a repo question using a private runbook it couldn't have known
- Why it teaches
- Makes MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.'s value concrete: context the model didn't ship with
- Idea
- Rules + AGENTS.md that enforce a house migration pattern
- The whoa moment
- Agent writes a new migration in the team's exact style, unprompted
- Why it teaches
- Teaches that taste and conventions are configurable, not luck
| Idea | The whoa moment | Why it teaches |
|---|---|---|
| Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud. that triages your own GitHub issues | It opens a labeled, reproduced issue with a suggested fix in one command | Shows the SDK as a real automation primitive, not a chatbot |
| MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server exposing your team's internal docs to the agent | Agent answers a repo question using a private runbook it couldn't have known | Makes MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.'s value concrete: context the model didn't ship with |
| Rules + AGENTS.md that enforce a house migration pattern | Agent writes a new migration in the team's exact style, unprompted | Teaches that taste and conventions are configurable, not luck |
One sharp beat beats a feature tour every time.
Timebox it like the real thingPlan, build, check-in, polish, present
- 1Plan (45 min). Lock the whoa moment, the surface you'll use and a definition of done you can actually hit. Write the README's first paragraph now, before any code, so the teaching frame drives the build.
- 2Build the spine (3-4 hrs). Get the happy path working end to end before polishing anything. A runnable ugly version beats a beautiful half.
- 3Check-in (15 min). Cursor's trial gives you a Slack channel for questions. Use it: ask one sharp scoping question, the way you would on the job. Silence is not a virtue here.
- 4Polish and verify (1.5-2 hrs). Clean the code, write the teaching artifact and run it on a clean checkout. Verify every claim against the actual SDK or CLI behavior, not your memory of it.
- 5Prep the present (45 min). Build the five-minute story and stage a fallback in case the live run stalls.
Log every override of the agentYour judgment is the grade
Cursor expects you to use AI heavily in the room and grades your judgment over the output, so the override log is the most valuable thing you'll bring. Keep a running note of every place you rejected or rewrote what the agent produced.
- What the agent did
- Suggested a polling loop to watch for new issues
- What you did instead
- Switched to a webhook the SDK already supports
- Why
- Polling is the obvious answer that a reviewer would catch; the webhook is correct
- What the agent did
- Wrote a README that described the tool in marketing voice
- What you did instead
- Rewrote the quickstart to a copy-paste-able 3-command path
- Why
- A developer wants to run it, not read about it
- What the agent did
- Invented an SDK method that sounded right
- What you did instead
- Checked the SDK source, found the real method, fixed the call
- Why
- Publishing a hallucinated API is the cardinal DX sin
| What the agent did | What you did instead | Why |
|---|---|---|
| Suggested a polling loop to watch for new issues | Switched to a webhook the SDK already supports | Polling is the obvious answer that a reviewer would catch; the webhook is correct |
| Wrote a README that described the tool in marketing voice | Rewrote the quickstart to a copy-paste-able 3-command path | A developer wants to run it, not read about it |
| Invented an SDK method that sounded right | Checked the SDK source, found the real method, fixed the call | Publishing a hallucinated API is the cardinal DX sin |
Each row is a moment you can narrate in the presentation.
Ship the override log as a short "decisions" section in your README. Cursor's reviewers are power users who can see when AI ran unsupervised and a candidate who can name where they overruled the agent reads as the engineer they want: fast with the tool, faster to distrust it. The log turns your AI usage from a liability into the evidence.
The deliverable bar is "would this actually land on X or HN and teach a real developer something," not "did I complete the assignment." A scope that's technically finished but boring fails that bar. If your honest answer to "would I post this?" is no, you scoped the wrong thing and the fix is a smaller build with a sharper whoa moment, not a bigger one with none.
Takeaway. Ship one runnable build with a single whoa moment plus the teaching artifact, timebox the day and keep an override log because your judgment over the agent is what's graded.
Self-check
QYou're scoping the mock work-trial and have two ideas: a broad SDK wrapper that touches Agent, CLI and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. but barely works or a tiny MCP server that does one surprising thing flawlessly. Which fits Cursor's deliverable bar and why?
Presentation rehearsal
After this you can After this you can tell the story of what you built and why, to time, with a fallback ready.
The work-trial ends in a presentation and on a tiny, talent-dense team the people watching are engineers who use Cursor daily. They've seen a hundred demos. The story is what separates a build that impresses from one that just works.
A feature tour is the default failure: clicking through what you made while the panel waits for the point. Lead with the developer's problem, drive to the whoa moment and let the narrative carry the demo while your hands keep up.
The five-beat structureProblem to next step in 5-7 minutes
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Lead with the problem, hit the whoa moment early and let the key-decision beat prove you're an engineer.
- 1The problem (45s). Name the developer and the friction concretely: "Anyone running an OSS repo drowns in unlabeled issues and triage eats the first hour of every morning." No tool yet.
- 2What you built (1 min). The shape of the artifact in one breath, then run it. Show the whoa moment early; don't save it for the end.
- 3The key decision (1-2 min). Pull one row from your override log and walk it: what the agent suggested, what you chose and why. This is the part that proves you're an engineer, not a prompt typist.
- 4The developer outcome (1 min). What changed for the person you named. Be specific: "triage goes from an hour to one command," not "it boosts productivity."
- 5What you'd do next (45s). One honest limitation and the next build. It shows taste and that you know where the edges are.
Stage the demo and a fallbackLive runs stall; rehearse the pivot
Model latency, a cold network, an expired token: any of these can freeze a live run in front of the panel. Treat a recorded backup as part of the deliverable, not a confession of doubt.
- Recorded run
- A 60-second screen capture of the whoa moment, queued and ready to play if the live run hangs
- Pre-warmed state
- Tokens valid, repo cloned, dependencies installed, one dry run done minutes before
- Narration that survives a stall
- If a model is thinking, keep talking about the decision; dead air reads as a freeze
- The pivot line
- "Latency's spiking - here's the run I captured this morning," then carry on without apology
“I'm not going to walk every line. Watch this one command - the agent never opened a file to find context, it pulled the right runbook through the MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server I wired up. That's the difference between an autocomplete and something that knows your stack. Here's what that does to triage time.”
Anticipate the questions you'll get
The panel will probe your tradeoffs and your scoping and especially where the agent helped versus hurt. Have the answers staged, anchored to your override log.
- "Why this scope?" - Tie it to the whoa moment and the one-day clock, not to what you ran out of time for.
- "Where did the agent slow you down?" - Name a concrete case where you spent more time correcting it than writing it yourself and what you learned.
- "What's wrong with this?" - Volunteer the real limitation before they find it; honesty about edges is the taste signal.
- "Would you publish this?" - Have a yes with a reason or a clear "not yet, here's the one gap."
Clarity and taste are graded as hard as the artifact, so an over-long, meandering presentation undercuts the very craft the role needs. If your five minutes sprawl to twelve, you're signaling you can't edit your own thinking, which is the same skill as cutting a bloated tutorial. Record the rehearsal, watch it back with a stopwatch and cut until the story is the same tight shape every time.
Takeaway. Run the five beats - problem, build, the key decision, the developer outcome, next step - to time and stage a recorded fallback so a stalled live run costs ten seconds, not the round.
Self-check
Technical-screen drill
After this you can After this you can rehearse AI-assisted coding while narrating your judgment out loud.
Before the work-trial, Cursor runs one to three craft screens: about an hour each, on a real slice of an unfamiliar codebase, with AI tools openly allowed and expected. The thing being graded is your judgment over the output, not your typing speed.
This round inverts the usual interview taboo. Reaching for Cursor isn't cheating here; it's the job. What they're watching is whether you drive the agent with taste or just accept whatever it hands you.
Run the drill on yourselfUnfamiliar repo, clock, camera on
- 1Pick an unfamiliar codebase slice. Clone a mid-size OSS repo you've never touched and assign yourself a real task: fix a flaky test, add a small feature or trace a bug from a stack trace.
- 2Ask clarifying questions first. Out loud, state your assumptions and the one question you'd ask the interviewer before writing code. Early clarification is a positive signal, not a stall.
- 3Solve it with Cursor in the loop. Use Agent and Tab the way you actually would, on camera, talking the whole time.
- 4Narrate every accept, reject and correct. Say why you're keeping a suggestion, why you're throwing one out and what you're changing by hand.
- 5Review the tape. Watch it back and answer one question honestly: did you exercise judgment or did you trust the output?
Narrate accept, reject, correctThe running commentary is the signal
// Agent proposes a fix for the failing test:
ACCEPT -> "This matches the existing test helper pattern and it
actually addresses the race, not just the symptom. Keeping it."
REJECT -> "It's mocking the network call to make the test pass. That hides
the real bug. Throwing this out and fixing the timeout instead."
CORRECT -> "Right shape, wrong error type. This repo throws a typed
DomainError, not a bare Error - I'll fix that by hand."
VERIFY -> "Before I trust this, I'm opening the source for that method
to confirm the signature instead of assuming the agent's right."Asking a sharp question early reads as senior, not unsure. "Is this test flaky because of timing or because of shared state?" before you touch code shows you scope a problem before solving it, the same instinct that keeps an agent from running off in the wrong direction. Candidates who silently start typing and candidates who ask three vague questions both score lower than the one who asks the single question that changes the approach.
The trap: trusting the output
- Move
- Accepting a diff
- Judgment (what they want)
- You read it, name why it's right and verify the risky parts
- Autopilot (what sinks you)
- You accept a 40-line change without reading it because the tests went green
- Move
- An API you don't know
- Judgment (what they want)
- You open the source or docs to confirm the method exists
- Autopilot (what sinks you)
- You ship the agent's call and hope the method is real
- Move
- A failing test
- Judgment (what they want)
- You fix the underlying cause and say so
- Autopilot (what sinks you)
- You let the agent mock the failure away to get a green check
| Move | Judgment (what they want) | Autopilot (what sinks you) |
|---|---|---|
| Accepting a diff | You read it, name why it's right and verify the risky parts | You accept a 40-line change without reading it because the tests went green |
| An API you don't know | You open the source or docs to confirm the method exists | You ship the agent's call and hope the method is real |
| A failing test | You fix the underlying cause and say so | You let the agent mock the failure away to get a green check |
Green tests with unread diffs is the exact anti-pattern this round hunts for.
Going silent is the quiet killer. If you solve the problem correctly but never narrate a single accept-or-reject decision, the interviewer can't distinguish your judgment from luck and judgment is the entire rubric. Talk through the boring parts too, because a clean reasoning trace on an easy fix still proves you're driving the tool rather than being driven by it.
Takeaway. Solve a real task on an unfamiliar repo with Cursor in the loop, ask the one clarifying question early and narrate every accept, reject and correct - judgment, not output, is the grade.
Self-check
QIn the technical screen the agent proposes a fix that makes the failing test pass by mocking the network call. The tests go green. What's the strongest move and what does it signal?
Portfolio and writing-sample audit
After this you can After this you can make your public body of work interview-ready.
Cursor expects a visible body of work and strong, evidenced opinions about developer marketing. The screen and the craft rounds both reference your portfolio, so a sharp set of artifacts does work before you say a word.
More links is not better. Three artifacts that each prove something specific beat a dozen that blur together. Curate ruthlessly toward one claim: you are a maker and a communicator with taste.
Curate two or three proof artifactsEach carries one part of the claim
- Artifact type
- A shipped tool or OSS project
- What it proves
- Maker: you build real things that run
- The bar
- Someone other than you has used it or it has stars, issues or a clean repo a stranger could run
- Artifact type
- A piece of writing or a demo that spread
- What it proves
- Communicator: you can teach and you understand distribution
- The bar
- It landed somewhere real - X, HN, a dev blog - and taught a concrete thing
- Artifact type
- A reference automation of your own work
- What it proves
- Taste plus daily power use: you abuse coding agents creatively
- The bar
- It shows a workflow a developer would steal, not a toy
| Artifact type | What it proves | The bar |
|---|---|---|
| A shipped tool or OSS project | Maker: you build real things that run | Someone other than you has used it or it has stars, issues or a clean repo a stranger could run |
| A piece of writing or a demo that spread | Communicator: you can teach and you understand distribution | It landed somewhere real - X, HN, a dev blog - and taught a concrete thing |
| A reference automation of your own work | Taste plus daily power use: you abuse coding agents creatively | It shows a workflow a developer would steal, not a toy |
Maker, communicator, taste: cover all three, ideally with overlap.
Frame every artifact for a developerOne line of why-this-matters
Each link needs a single sentence that says what a developer gets from it. Without that framing, a reviewer has to reverse-engineer your point and most won't.
- Weak
- "A CLI tool I built in TypeScript with the Cursor Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud.."
- Strong
- "Turn any failing CI run into a labeled issue with a suggested fix, in one command - built on the Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud.."
- Weak
- "A blog post about MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers."
- Strong
- "How to give the agent your team's private runbooks so it stops guessing - a 10-minute MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. walkthrough."
Tighten one writing sample to publishableCorrectness first, then clarity
Pick your single best piece and bring it to the bar Cursor holds for docs: correct, clear and credible to a working engineer. The fastest wins are usually subtractive.
- Verify every technical claim against the real API, SDK or CLI behavior - not your memory of it. One wrong method poisons trust in the whole piece.
- Cut the hype adjectives. "Powerful," "integrated," and "easy" are the words developers skim past.
- Make the quickstart genuinely copy-paste-able: a reader should reach a result in under three commands.
- Read it aloud once. Anything you stumble over is a sentence a tired developer will bounce off.
- Show the workflow with real code or a real terminal, not a paragraph describing it.
On a clean machine or a fresh container, follow your own writing sample step by step without skipping. Every place you reach for knowledge that isn't on the page is a gap a reader will hit and every command that errors is a correctness bug in your teaching. This is the same verification discipline the work-trial demands and doing it on your portfolio first builds the muscle.
Run the surface-mastery self-audit from earlier in this track and fix the biggest gap before the loop, not during it. If you've never actually shipped 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 or written a real .cursor/rules file, that hole shows the instant a power-user panel probes it. Closing one real gap with a small hands-on project beats rereading the docs and it gives you a fresh artifact to point at.
Takeaway. Curate two or three artifacts that prove maker, communicator and taste, give each a one-line developer value frame and tighten one writing sample to publishable correctness by re-running it cold.
Self-check
Readiness scorecard
After this you can After this you can score yourself stage-by-stage and target the weak spots.
One honest scorecard beats another reread of the prep. Score yourself cold on the dimensions the loop actually tests, using evidence from your mock build, your recordings and your portfolio - not how you'd do on a good day.
Each dimension is 1-5. A 5 means a Cursor reviewer could see your artifact land on X or HN and trust your engineering judgment without a second look. Anything lower points at a specific section to revisit.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The bars rank how decisive each dimension is; the table below is where you score yourself on each.
- Dimension
- Screen story
- What a 5 looks like
- A specific, personal "why Cursor" and a confident take on the AI coding-agent space, said cold
- Your score
- __
- Dimension
- AI-assisted coding judgment
- What a 5 looks like
- You narrate accept/reject/correct fluently and verify risky output instead of trusting it
- Your score
- __
- Dimension
- Surface mastery
- What a 5 looks like
- You've shipped real things on Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud., CLI, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. and Rules/AGENTS.md, not just read about them
- Your score
- __
- Dimension
- Agent internals
- What a 5 looks like
- You can explain indexing/retrieval, context windows, the agent loop and concrete failure modes
- Your score
- __
- Dimension
- Writing / demo
- What a 5 looks like
- A teaching artifact a developer would actually share, correct and free of hype
- Your score
- __
- Dimension
- Values / why-Cursor
- What a 5 looks like
- Truth-seeking, taste and genuine love of the craft are visible in your stories and choices
- Your score
- __
| Dimension | What a 5 looks like | Your score |
|---|---|---|
| Screen story | A specific, personal "why Cursor" and a confident take on the AI coding-agent space, said cold | __ |
| AI-assisted coding judgment | You narrate accept/reject/correct fluently and verify risky output instead of trusting it | __ |
| Surface mastery | You've shipped real things on Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud., CLI, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. and Rules/AGENTS.md, not just read about them | __ |
| Agent internals | You can explain indexing/retrieval, context windows, the agent loop and concrete failure modes | __ |
| Writing / demo | A teaching artifact a developer would actually share, correct and free of hype | __ |
| Values / why-Cursor | Truth-seeking, taste and genuine love of the craft are visible in your stories and choices | __ |
A 5 = would-land-on-X-and-teach-someone. Score what you can show today.
Map each low score to a sectionNo gap without a named drill
- Screen story
- The role-and-charter and values modules; rehearse "why Cursor" and your space POV out loud
- AI-assisted coding judgment
- This module's technical-screen drill; re-run it on a new repo, camera on, narrating every decision
- Surface mastery
- The developer-surface deep dives; ship one small thing on the surface you've never actually used
- Agent internals
- The how-agents-work module; be able to explain retrieval and one failure mode from first-hand evidence
- Writing / demo
- This module's portfolio audit; tighten one sample to publishable and re-run its quickstart cold
- Values / why-Cursor
- The behavioral/values module; have a real changed-my-mind story and a sharp dev-marketing opinion
Check the greenlight criteriaFour non-negotiables
Scores tell you where you stand; the greenlight is the floor. Walk in only when all four of these are true, each backed by something you can show, not something you intend to build.
A runnable artifact on Cursor's surface and the write-up that teaches it.
It exists today and a stranger could clone and follow it.
An evidenced point of view on how to reach developers without sounding like marketing.
Specific enough to defend and revise under a fair challenge.
You can name where coding agents break - context limits, retrieval misses, confident wrong calls.
From first-hand use, not a blog summary.
Daily power use across Agent, Tab, CLI, Rules and at least one of SDK or MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. shipped for real.
A panel of power users will know within minutes if it's fake.
Your readiness is set by your weakest two dimensions, because the loop has a stage for each. Averaging a 5 in surface mastery against a 2 in agent internals doesn't make you a 3.5; it makes you the candidate who freezes when an engineer asks how retrieval actually works. Circle the two lowest scores, ignore the strong ones and spend the rest of your prep entirely there.
Look at your work-trial deliverable and ask the only question that matters: would this actually land on X or HN and teach a real developer something? If the honest answer is no, no rubric score saves you - the whole role is producing artifacts that meet that bar. Go only when the answer is a confident yes, all four greenlight criteria hold and every dimension is a self-scored 4 or higher against real evidence.
Takeaway. Score six dimensions 1-5 against real evidence, map each low score to a named section and go only when all four greenlight criteria hold and your deliverable would genuinely land on X or HN.