1 min lesson
Stage 3 - the paid work-trial (the real test)
Use "Stage 3 - the paid work-trial (the real test)" to explain each part and the role it plays.
Step 1 of 2
This is the round that decides. Over 8 hours, sometimes stretched to a day or two, you build something real on or around Cursor and present it. For DX, that almost always means two deliverables at once: the thing you built and the teaching artifact around it - the demo plus the post, the integration plus the tutorial.
Use this stage map to decide what evidence belongs in each round. Memorizing the order is the shallow version. For every stage, prepare one artifact, one story and one question that shows how you reason in the role.
- Kickoff
- An intro meeting to set the brief and confirm your read on it.
- Middle
- A midday check-in - a natural place to show progress and de-risk scope.
- End
- A final presentation: the story of what you built and why.
- Support
- Docs access plus a Slack channel for questions throughout.
Product imagination - did you pick something worth building?
Autonomy - can you ship without hand-holding?
Taste - is the build and the writing actually good?
Can you teach it so a developer learns something real?
Scope to one finished, narrated small thing.
Build the teaching artifact alongside the code.
Ask sharp questions in Slack - it's a positive signal.
Rehearse the presentation as its own deliverable.
Learn more
Full explanation
The 8-Hour Run
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
A workable shape for the trial - the ▲ gates are where the day is de-risked and decided.
- Trap
- Over-scoping
- Why it loses
- Half-built ambition has nothing to demo
- The fix
- Cut to one finished happy path early
- Trap
- Build with no teaching
- Why it loses
- It's a DX role - the artifact is half the job
- The fix
- Write the post alongside the code
- Trap
- Silent for 8 hours
- Why it loses
- Misses a graded autonomy + questions signal
- The fix
- Ask sharp questions in the Slack channel
- Trap
- Winging the demo
- Why it loses
- The story is graded with the build
- The fix
- Rehearse the presentation before time's up
| Trap | Why it loses | The fix |
|---|---|---|
| Over-scoping | Half-built ambition has nothing to demo | Cut to one finished happy path early |
| Build with no teaching | It's a DX role - the artifact is half the job | Write the post alongside the code |
| Silent for 8 hours | Misses a graded autonomy + questions signal | Ask sharp questions in the Slack channel |
| Winging the demo | The story is graded with the build | Rehearse the presentation before time's up |
The recoverable mistakes all have a fix you can apply mid-trial.
A small, polished, well-narrated thing beats an ambitious half-built thing every time. The team can see potential anywhere; what's rare is the discipline to ship something done on a clock and explain it cleanly. Scope ruthlessly in the first hour and protect the last two for polish and the writeup.
Use the Slack channel deliberately. Early, ask “I'm leaning toward an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server that does X over a CLI demo of Y - which would teach more?” Asking a sharp, scoped question is a positive signal, not a sign of weakness. Going silent for the whole trial reads as someone who can't collaborate or de-risk.