Capstone: Mock Loop
Run the full loop on yourself before they do
Timed decomposition drill
After this you can run a 45-minute decomposition on a fresh ambiguous brief.
The decomposition round is the role's core filter. They hand you an enterprise mess and watch whether you scope it like an FDE or lunge at it like a contractor who bills by the ticket.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Each drill in this capstone maps to a stage here. Click a stage to see what it tests and how to prep.
You can't cram this the night before. The only honest preparation is to run the round on yourself, under a clock, on a brief you haven't seen. Pick something with the texture of a real Cursor engagement and give yourself exactly 45 minutes.
Use a brief like: “A 200-engineer org wants Cursor to cut their PR-review time in half.” It looks like a feature request. It's actually a discovery problem wearing a metric. Your first move is never to design the workflow - it's to ask what's eating the review clock.
Run it the way the real round runs: out loud. Narrate every assumption and every branch or write as you go in a doc you can replay. Record the session. You will catch things on the playback that you were blind to in the moment, especially the exact second you stopped scoping and started solving.
The 45-minute clockDrill protocol
- 10–5 min · Clarify. Restate the brief in your own words and ask the questions that change the answer. Is review slow because of queue time, reviewer load or rework? Which repos? Who actually feels the pain - ICs, leads or the release manager? Resist designing anything.
- 25–12 min · Stakeholders & metrics. Name the human who owns the outcome and the metric that proves it. Cut PR-review time in half from what to what, measured how. Time-to-first-review, review cycles per PR, merge lead time - pick the one tied to money.
- 312–22 min · Map inputs. What data and surfaces exist: the VCS, the CI signals, the review tooling, the codebase index, existing
.cursorrules. What's missing or locked behind SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. and security review. - 422–35 min · Decompose. Break the problem into independently shippable slices. Automated reviewer that flags the boring stuff. Context-grounded summaries on each PR. A triage bot that routes by ownership. Sequence them by value over effort.
- 535–45 min · Walking skeleton. Propose the thinnest end-to-end version that touches every layer and proves the thesis on one real repo in days, not the full system.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Two gates decide the round: clarifying before you design and ending on a thin, shippable slice.
The single fastest way to fail this round is to skip the clarify phase and start architecting the solution to the stated problem. Halving review time might mean fixing a CI queue, not generating AI summaries. If you build the summary bot and the bottleneck was queue time, you shipped the wrong thing beautifully.
Score your own tapeSelf-rubric
- Dimension
- Clarified first
- Pass looks like
- Two-plus questions that change the design before any solution
- Red flag
- Jumped straight to “here's what I'd build”
- Dimension
- Named metrics
- Pass looks like
- A baseline, a target and the measurement method
- Red flag
- “Make it faster” with no number
- Dimension
- Mapped inputs
- Pass looks like
- Concrete data sources, surfaces and the gaps
- Red flag
- Assumed clean data and full access
- Dimension
- Decomposed
- Pass looks like
- Independently shippable slices, sequenced by value
- Red flag
- One monolithic “the system” with no seams
- Dimension
- Walking skeleton
- Pass looks like
- Thin end-to-end slice, demoable on one repo in days
- Red flag
- A six-month roadmap as the first answer
| Dimension | Pass looks like | Red flag |
|---|---|---|
| Clarified first | Two-plus questions that change the design before any solution | Jumped straight to “here's what I'd build” |
| Named metrics | A baseline, a target and the measurement method | “Make it faster” with no number |
| Mapped inputs | Concrete data sources, surfaces and the gaps | Assumed clean data and full access |
| Decomposed | Independently shippable slices, sequenced by value | One monolithic “the system” with no seams |
| Walking skeleton | Thin end-to-end slice, demoable on one repo in days | A six-month roadmap as the first answer |
Watch the recording with this open. Mark the timestamp of any red flag.
Then run it again. Same length, fresh brief, but this time apply the framework on purpose: clarify, stakeholders, metrics, inputs, decompose, skeleton. Compare the two recordings. The gap between your instinct and your deliberate pass is exactly the muscle this round grades.
Takeaway. Decomposition is a scoping test, not a solving test. Clarify before you design, anchor on a measurable outcome and end on a walking skeleton you could ship in days.
Self-check
QIn a timed decomposition on “cut PR-review time in half,” what is your single highest-value first move and why?
Applied-AI coding drill
After this you can solve an editor-primitive or LLM-systems problem with AI assistance, well.
Cursor lets you use GPT and Cursor itself during the technical screen. That isn't a gift. It inverts the test: they're no longer grading whether you can write the function, they're grading whether you can drive AI with judgment.
Pasting raw model output without reading it is the fastest documented path to rejection in this loop. So the drill isn't “can I get a working diff.” It's “can I defend every line I kept and catch the line I shouldn't have.”
Pick one representative taskDrill scope
Consume a token stream and render incrementally.
Handle partial chunks, backpressure and a clean cancel.
Tests: applied-AI plumbing under real failure modes.
Compare two directory snapshots, emit add / delete / modify.
Editor-primitive thinking: paths, renames, ordering.
Tests: data-structure taste on a Cursor-shaped problem.
Model proposes a tool call, you execute, feed the result back.
Add a retry and a stop condition so it can't spin.
Tests: tool-calling, context construction, guardrails.
Set a 45-minute timer and narrate as if an interviewer is on the call. Start with the clarifying questions you'd actually ask, then state two tradeoffs out loud before you write code.
async function* streamCompletion(
resp: Response,
signal: AbortSignal,
): AsyncGenerator<string> {
const reader = resp.body!.getReader();
const decoder = new TextDecoder();
let buffer = "";
try {
while (true) {
if (signal.aborted) throw new DOMException("cancelled", "AbortError");
const { done, value } = await reader.read();
if (done) break;
buffer += decoder.decode(value, { stream: true });
// SSE frames are newline-delimited; only emit complete lines.
let nl: number;
while ((nl = buffer.indexOf("\n")) !== -1) {
const line = buffer.slice(0, nl).trim();
buffer = buffer.slice(nl + 1);
if (line.startsWith("data: ")) {
const data = line.slice(6);
if (data === "[DONE]") return;
yield JSON.parse(data).choices[0].delta.content ?? "";
}
}
}
} finally {
reader.releaseLock(); // always free the stream, even on cancel
}
}The point of typing it isn't the code. It's that you can answer: why buffer before emitting, what happens on a half-received chunk, why releaseLock lives in finally. If the model wrote it and you can't, you don't keep it.
Score the AI-authenticity dimension
- Did you read the generated code before running it or paste-and-pray?
- Did you reject or rewrite at least one suggestion that was wrong or lazy?
- Can you defend every line you kept - and name what you'd test?
- Did you catch your own bug before the tests did?
When a suggestion is wrong, say so out loud and fix it on the spot: “That'll drop the last partial chunk on cancel - I'm moving the cleanup into a finally.” Catching the model is a stronger signal than never needing to. It's the exact judgment the round exists to measure.
Write the test you'd be embarrassed not to have: a cancel mid-stream, an empty stream, a malformed frame. If you can't quickly assert correctness, you don't actually know it works - and “how do you know it works” is the question that follows you through this entire loop.
Takeaway. With AI allowed, the test becomes judgment: read every line, reject the bad ones, defend the rest and prove it with a test. Pasting unread output is the fastest rejection.
Self-check
QCursor's technical screen lets you use GPT and Cursor. What does that change about what's being graded and what behavior fails the round?
Mini paid-onsite simulation
After this you can build a thin end-to-end feature on an unfamiliar codebase, then present it.
The real decision round is a paid 8–9 hour build inside a slice of the Cursor codebase, with a live Slack channel and a deliberately vague brief. You can't replicate the paycheck or the exact repo. You can replicate the shape of it.
Clone an OSS project you've never touched. Hand yourself a fuzzy feature brief and a 2–3 hour box. The constraint that matters: unfamiliar code, ambiguous ask, hard clock. That's the simulation.
The onsite grades the build and the defense. A clean feature presented as a shrug loses to a scrappier feature presented with sharp reasoning about tradeoffs and evals. Rehearse the presentation as seriously as the code.
The 2–3 hour protocolRun it like the real thing
- 1First 30 min · Orient and write your questions down. Build and run the repo. Read the entry point and the data model. List the sharp questions you'd post in the Slack channel - which surface should this live on, what's the auth model, is there an existing pattern I should follow - instead of guessing silently.
- 2Scope a walking skeleton. Choose the thinnest path that proves the feature end-to-end across every layer it touches. Write down what you're deliberately cutting and why.
- 3Build end-to-end first, then deepen. Get the unglamorous full slice working before polishing any one layer. A vertical slice you can demo beats a gorgeous half.
- 4Verify it actually works. Run it on a real input. Add at least one test or a reproducible check. Note the edge cases you didn't get to.
- 5Prepare a 5-minute demo + tradeoff narrative. Show it working in 60 seconds, then spend the rest defending decisions, naming what you'd do with more time and stating how you'd evaluate it in production.
The defense they're listening forPresentation
- Why this approach
- The tradeoff you made and the alternative you rejected, with the reason.
- What you cut
- The scope you deliberately dropped to ship the skeleton - naming it shows judgment, not gaps.
- With more time
- The next two slices in priority order, tied to value not polish.
- How you'd evaluate it
- The concrete metric or eval that would tell you it works on real usage, not just your demo input.
- How AI helped
- Where you drove the model, where you overrode it and why - the authenticity signal again.
Rehearse these answers out loud before you present. Vague answers here erase a strong build.
The trap on an unfamiliar repo is rabbit-holing for two hours on one layer and arriving with nothing to demo. Protect the walking skeleton above all else. A working thin slice with honest gaps beats a deep, broken vertical every time.
“I shipped the end-to-end path first and deliberately stubbed the retry logic. With more time I'd add it next, because that's where this fails under real load - and I'd prove the fix with a replayed trace of the failure case.”
Takeaway. The onsite is the job in miniature: unfamiliar code, vague brief, hard clock. Protect the walking skeleton, verify it and defend your tradeoffs as hard as you built them.
Self-check
Client simulation & values round
After this you can rehearse a hard customer conversation and a values answer cold.
An FDE lives at the seam between the customer's senior engineers and your own delivery. The behavioral round probes whether you can hold that seam under pressure: deliver bad news honestly, keep the relationship and own the outcome in the first person.
Two things get tested here. Your customer craft when the news is bad and your fit with a flat, truth-seeking, high-intensity culture. Both fail the same way - vague, rehearsed-sounding, “we” instead of “I.”
Role-play: the migration is going to slipBad-news drill
Set the scene: you promised a framework migration would land Friday and it won't. The customer's lead engineer is on the call. Don't soften it into mush and don't lead with excuses.
- 1Name it plainly, fast. “The migration won't land Friday.” Lead with the truth before the context. Truth-seeking means the bad news comes first, not buried.
- 2Own it in the first person. “I underestimated the legacy auth coupling.” Not “we hit unexpected complexity.” You own outcomes, not effort.
- 3Bring options, not just a slip. Partial migration of the unblocked modules now, the rest behind a flag next week; or hold for a clean cut in ten days. Give them a decision, not a verdict.
- 4Anchor on the metric. Tie the path back to what the customer actually cares about, so the conversation stays about outcomes instead of blame.
- 5Confirm and follow through. Restate the agreed path and the next checkpoint in writing. De-escalation is mostly the customer believing you'll do what you just said.
Over-promising to escape an uncomfortable moment is the cardinal FDE sin. Committing to a Friday you can't hit just relocates the same conversation to a worse day with less trust. Never buy comfort now with a promise you'll break later.
“Why Cursor” and a STAR story, coldValues drill
Say both out loud once, unscripted, then critique the recording. “Why Cursor” has to be specific to you and to this product - the AI-coding mission, working at the seam of elite customer delivery and product engineering, the intensity. Generic enthusiasm reads as a candidate who'd say it about any startup.
A concrete reason rooted in the AI-coding mission and the FDE seam.
Names something true about the product you'd be deploying.
Sounds like only you could have said it.
“I love AI and fast-growing startups.”
Interchangeable with any company.
No personal stake, no product specificity.
For the STAR story, pick a project you owned end to end and tell it in the first person. The non-negotiable beats: an ambiguous start, a real decision you made, a measurable result and a moment you delivered hard news or caught your own mistake.
Have a peer throw curveball follow-ups: “What would the customer say went wrong?” and “What did you personally get wrong?” The follow-ups are where “we” leaks back in and where polish cracks. Practicing the first answer is easy; practicing the third follow-up is what wins this round.
“What went wrong is mine to name: I committed to a date before I'd validated the legacy integration. The result was a one-week slip I caught early and a process I now run - I de-risk the scariest dependency in the first two days, every engagement.”
Takeaway. Deliver bad news first, own it as “I,” and arrive with options. Make “why Cursor” specific enough that only you could say it and never over-promise to dodge a hard moment.
Self-check
Readiness rubric & gap plan
After this you can score yourself across all stages and build a focused gap plan.
Run the whole loop on yourself before they do. The point of a mock loop isn't to feel ready - it's to find the dimension that will sink you, while there's still time to fix it.
Treat the rubric as a gap finder, not a score to admire. Mark the weakest proof, turn it into one practice rep and keep the artifact you would show an interviewer.
Rate yourself 1–5 on each dimension below, honestly, using the evidence from the four drills you just ran. Anything under 3 is a blocker, not a weakness to mention apologetically in the interview.
- Dimension
- Decomposition discipline
- What a 5 looks like
- Clarify → metrics → inputs → decompose → skeleton, every time, under a clock
- Source drill
- Section 1
- Dimension
- Applied-AI coding
- What a 5 looks like
- Clean, testable editor/LLM primitive built fast and correctly
- Source drill
- Section 2
- Dimension
- AI authenticity
- What a 5 looks like
- Drive AI hard, reject bad output, defend every kept line
- Source drill
- Sections 2 & 3
- Dimension
- Eval rigor
- What a 5 looks like
- Always answer “how do you know it works” with a concrete metric
- Source drill
- Sections 2, 3 & 5
- Dimension
- Customer craft
- What a 5 looks like
- Bad news first, options attached, relationship intact
- Source drill
- Section 4
- Dimension
- Ownership & values
- What a 5 looks like
- First-person “I,” specific “why Cursor,” honest on intensity
- Source drill
- Section 4
| Dimension | What a 5 looks like | Source drill |
|---|---|---|
| Decomposition discipline | Clarify → metrics → inputs → decompose → skeleton, every time, under a clock | Section 1 |
| Applied-AI coding | Clean, testable editor/LLM primitive built fast and correctly | Section 2 |
| AI authenticity | Drive AI hard, reject bad output, defend every kept line | Sections 2 & 3 |
| Eval rigor | Always answer “how do you know it works” with a concrete metric | Sections 2, 3 & 5 |
| Customer craft | Bad news first, options attached, relationship intact | Section 4 |
| Ownership & values | First-person “I,” specific “why Cursor,” honest on intensity | Section 4 |
Score from the recordings, not from memory. Memory inflates.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The loop is graded on the floor, not the ceiling - a 5 here can't offset a sub-3 there.
Before you apply, confirm you can tell all three cold: a production AI-workflow story (shipped, not a prototype), a real model- or agent-failure debug story (what broke, how you diagnosed it) and a result with a metric attached. Missing any one of these is a gap to close, not a story to fudge.
Turn scores into a one-week planGap plan
- 1Rank your two weakest dimensions. Front-load them - the loop is graded on the floor, not the ceiling. A 5 in coding can't rescue a 2 in customer craft.
- 2Assign concrete reps, not reading. A sub-3 in decomposition means three more timed drills on fresh briefs, recorded and scored, not another framework article.
- 3Build the missing story if a non-negotiable is absent. If you lack a metric-backed result, go mine your past work for the number before you invent prep around a story that has none.
- 4Re-run the weak drills mid-week and re-score. Movement from 2 to 3+ on the recording is the only proof the plan worked.
- 5End on the gut check below. If it's still a no, you have your next week's plan.
One question decides it: can you walk into ambiguity, drive AI with taste and ship something a senior engineer would actually adopt? If every drill points to yes and the recordings back it up, you're ready. If any dimension is faking a yes, that's where your reps go this week.
Takeaway. Score every dimension from the tape; any sub-3 is a blocker. Front-load your two weakest, confirm the three non-negotiable stories and re-test before you apply.
Self-check
QYour mock-loop scores are: coding 5, decomposition 2, customer craft 4, AI authenticity 4. How should you spend your prep week?