Capstone: Mock Loop & Self-Exam
Put it together under pressure
Take-home: cost-attribution model
After this you can produce a graded cost model and recommendation end-to-end.
Set a 4-hour timer and open a blank spreadsheet. The prompt: attribute Cursor's inference spend across features, then recommend where to cut 15% of COGS without wrecking the product. This is the round the whole loop is built around - Cursor explicitly wants the person who builds the model, not the person who schedules the meeting about the model.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
This capstone simulates the four hardest middle stages - take-home, systems, execution and values. Step through to see what each one is actually grading.
The deliverable is two artifacts that travel together: a cost model with every assumption visible and a one-page recommendation a founder could act on without a follow-up call. The model proves you can do the math. The page proves you can make a call.
The prompt, stated the way they'll state itVague on purpose - scoping is part of the test
You're handed a month of usage: tab completions, chat turns and agent runs, each with a model tier and rough token counts. Inference is the dominant COGS line. Leadership wants 15% out of it next quarter.
- Cost driver tree
- COGS decomposed to cost = volume × tokens-per-call × $/token, per feature and model tier - so every dollar has a named cause
- Stated assumptions
- $/token by tier, blended utilization, what you held fixed and where your numbers came from versus where you guessed
- Sensitivity table
- How the 15% target moves if token-per-call or tier-mix is off by ±20% - proves the recommendation survives being wrong
- One-page recommendation
- The two or three levers you'd pull, the expected savings, the product risk and what you would measure to confirm
A 4-hour timebox that ends with both artifactsPrioritize ruthlessly - finished beats elegant
- 10:00–0:30 · Frame and assume. Write the cost equation and list every assumption on one tab. State your unit: cost per active user is the metric leadership thinks in, so anchor there. Freeze scope - one month, three features, two model tiers - and push everything else to what I'd do with more time.
- 20:30–2:00 · Build the model. Attribute spend bottom-up: per feature, per tier, volume × tokens × $/token. Get the totals to reconcile against the stated COGS number. If they don't reconcile, find the gap before you go further; an unreconciled model is an untrustworthy model.
- 32:00–3:00 · Find the 15% and stress it. Identify where the cost concentrates, almost always a few high-volume or large-model paths. Build the sensitivity table. Pick the levers that survive the stress: model routing, prompt/context trimming, caching, tier downgrades for simple calls.
- 43:00–3:45 · Write the one-pager. Recommendation up top in two sentences, then the savings math, the product-risk line and the metric you'd watch. Write it for a CFO and an ML lead in the same page - neither should need a glossary.
- 53:45–4:00 · Reconcile and ship. Re-check that the model totals match, the assumptions tab is complete and the recommendation names a number. Submit the honest version, not the impressive-looking one.
# Bottom-up COGS attribution. Every term traces to an assumption on the
# assumptions tab - that traceability is what makes the model trusted.
feature_cost = sum(
calls[f, tier] # volume, from usage logs
* tokens_per_call[f, tier] # ASSUMPTION: measured median, not mean
* price_per_token[tier] # ASSUMPTION: blended in+out $/1M tokens
for f in features for tier in tiers
)
cost_per_active_user = feature_cost / monthly_active_users
# The 15% lever, modeled explicitly so the saving is auditable:
# route "simple" tab/chat calls from the large tier to a small model.
routed_share = 0.40 # ASSUMPTION: share of calls that are "simple"
small_tier_discount = 0.85 # small model ~15% the $/token of large
savings = (calls_large * routed_share
* tokens_per_call_large
* price_per_token_large * small_tier_discount)Three failure modes sink most submissions. No stated assumptions, so no one can trust or challenge the numbers. A fence-sitting recommendation that lists five options and ranks none, which reads as analysis avoiding a decision. And numbers that don't reconcile to the known COGS total, which makes a reviewer distrust everything above them. Fix all three before polish.
Put the assumptions tab first, not buried last. Open your walkthrough with “here's what I assumed and where I'm least confident,” then show the sensitivity table proving the recommendation holds even when those assumptions are wrong. Volunteering your own uncertainty is the truth-seeking signal Cursor screens for and it disarms the obvious challenge before it's asked.
Takeaway. Ship two artifacts in the box - a reconciled bottom-up model with every assumption visible and a one-page recommendation that names a number, a risk and a metric to confirm.
Self-check
QYour take-home model says routing simple calls to a small model saves 15% of inference COGS. What single addition most increases a reviewer's trust in that claim?
Whiteboard: GPU capacity plan
After this you can design a capacity framework live and defend the tradeoffs.
Whiteboard, 45 minutes, one senior leader watching. The prompt: a new feature is projected to double request volume in eight weeks - plan the GPU capacity. This is the systems-literacy round wearing a planning hat. They're checking whether you can reason about utilization, latency and the cost of guessing wrong in both directions.
Don't draw boxes first. Quantify the demand, then split it into a baseline you reserve and a peak you burst, then name the trigger that moves capacity. Every number you say buys you the right to the next design choice.
The four things a complete plan showsWalk them in order, out loud
- 1Demand model. Tie GPU need to usage, not vibes: requests/sec at peak = DAU × calls-per-user-day × peak-concentration ÷ seconds. Doubling request volume doesn't double GPUs if utilization has headroom - say that. Translate requests/sec into GPUs via throughput per GPU at your latency SLA.
- 2Reserve vs. burst split. Reserve the steady baseline where committed pricing wins, burst the spiky top on on-demand. The breakeven is sustained utilization: reserved capacity pays off above roughly 60–80% sustained use, so reserve only what you'll actually keep busy and let bursty demand ride on-demand even at a higher unit price.
- 3Utilization target. Name a target band and defend it. GPU fleets commonly run 15–30% utilized, which is money on the floor; you want the reserved tier pushed higher without starving latency headroom. State the latency SLA first - tab prediction needs tens-of-milliseconds responses - because that ceiling caps how hard you can pack a GPU before the tail blows out.
- 4Trigger points. Pre-commit the rules: scale up when sustained utilization crosses your high-water mark for N minutes, add reserved capacity when the burst bill exceeds reserved cost for a sustained stretch and set a hard latency-SLA breach alarm that scales out regardless of cost.
Name the cost of being wrong both waysThe clause that separates a planner from a forecaster
- Direction
- Over-provision
- What it costs
- Idle reserved GPUs burn committed spend at 15–30% utilization - the default failure of capacity teams
- How the plan hedges
- Reserve only the defensible baseline; let the uncertain top ride burst
- Direction
- Under-provision
- What it costs
- Latency SLA breaches, queueing, degraded tab/agent UX at launch - a product hit, not just a metric
- How the plan hedges
- Burst headroom + a latency-breach trigger that scales out regardless of cost
- Direction
- Wrong tier mix
- What it costs
- Large models serving simple calls inflates $/request even at good utilization
- How the plan hedges
- Model routing so small models take the simple share before you buy more GPUs
| Direction | What it costs | How the plan hedges |
|---|---|---|
| Over-provision | Idle reserved GPUs burn committed spend at 15–30% utilization - the default failure of capacity teams | Reserve only the defensible baseline; let the uncertain top ride burst |
| Under-provision | Latency SLA breaches, queueing, degraded tab/agent UX at launch - a product hit, not just a metric | Burst headroom + a latency-breach trigger that scales out regardless of cost |
| Wrong tier mix | Large models serving simple calls inflates $/request even at good utilization | Model routing so small models take the simple share before you buy more GPUs |
Saying both failure costs out loud is the judgment signal; picking a hedge for each is the plan.
“Doubling requests doesn't mean doubling GPUs if we're sitting at 25% utilization - first I'd model whether routing simple calls to a small model absorbs the increase. I'd reserve the baseline we keep busy above ~70% and burst the launch spike on-demand, because over-reserving leaves idle GPUs burning committed spend and under-reserving breaks the tab-latency SLA at launch. My trigger to add reserved capacity is the burst bill exceeding reserved cost for two sustained weeks.”
When the senior leader pushes back mid-answer - “why 70%, that seems low” - don't defend the number, defend the method. Say what 70% is protecting (latency headroom for the spiky tail) and what would move it (“if the workload were batchable and latency-loose, I'd pack to 85%”). Updating your number on a better fact while holding the reasoning is exactly the spirited-debate, truth-seeking behavior the round is built to test. Caving instantly reads as no conviction; refusing to move reads as no curiosity.
Watch the clock and finish. A complete, defensible plan with all four parts beats an elegant demand model you never connected to a reserve-vs-burst decision. If you're at minute 35 with no trigger points, stop refining the forecast and state the triggers - interviewers grade the whole framework and an unfinished plan signals you'd run a real program the same way.
Takeaway. Quantify demand, split reserve-vs-burst at the ~60–80% sustained-use breakeven, defend a utilization target against the latency SLA and name the cost of being wrong in both directions with a hedge for each.
Self-check
Execution drill: program in trouble
After this you can run a recovery scenario the way the execution round will probe.
The execution deep-dive doesn't ask if you can draw a Gantt chart. It hands you a fire: a migration is slipping and ML, Infra and Finance disagree on the path. They want to watch you re-baseline scope, triage risk, move people who don't report to you and force a decision - with an artifact at the end, not just a story.
The scenario: you're migrating inference serving to a new GPU pool to cut cost. It's two weeks behind. ML wants to pause for a model change, Infra wants to push through and Finance wants the savings this quarter. Run the recovery.
The recovery sequenceRe-baseline → triage → influence → escalate
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Run a slipping program in this order. The forcing escalation is the gate - nothing leaves the room without a dated decision.
- 1Re-baseline scope. Get the real critical path on the table, not the optimistic one. Cut or defer anything not load-bearing for the cost win - if the model change ML wants isn't on the path to savings, it ships after, not during. A re-scoped plan with a defensible date beats a heroic one nobody believes.
- 2Triage the risks. Rank by impact × likelihood, not by who's loudest. Separate the slip's cause (a dependency, a capacity gap, a disagreement) from its symptoms. Put each top risk on a single owner with a date.
- 3Influence without authority. You don't manage ML, Infra or Finance, so you earn the call: bring the numbers, frame the tradeoff in each partner's currency (ML hears latency/quality, Finance hears quarter timing) and propose a path that gives each a defensible win. Get verbal commitments in the room, then write them down.
- 4Force the decision. Where partners genuinely disagree, don't let it drift. Frame two options with their costs, recommend one and take it to the decision-maker with a deadline: “I need a call by Thursday or we lose the quarter's savings.” A decision-forcing escalation is the move; a status email hoping it resolves itself is not.
Show the artifact, don't narrate itA re-scoped plan plus an updated risk register
- Risk
- New GPU pool fails latency SLA under load
- Impact × likelihood
- High × Med
- Owner
- Infra lead
- Mitigation / trigger
- Shadow-traffic test before cutover; roll back if p99 breaches SLA
- Risk
- ML model change collides with migration
- Impact × likelihood
- Med × High
- Owner
- ML lead
- Mitigation / trigger
- Decouple: migrate current model first, ship model change in the next window
- Risk
- Savings slip past quarter end
- Impact × likelihood
- High × Med
- Owner
- You (TPM)
- Mitigation / trigger
- Re-baselined date + Thursday go/no-go to protect the quarter
- Risk
- Dual-running both pools inflates cost
- Impact × likelihood
- Med × Med
- Owner
- Finance partner
- Mitigation / trigger
- Cap the overlap window; daily cost watch during cutover
| Risk | Impact × likelihood | Owner | Mitigation / trigger |
|---|---|---|---|
| New GPU pool fails latency SLA under load | High × Med | Infra lead | Shadow-traffic test before cutover; roll back if p99 breaches SLA |
| ML model change collides with migration | Med × High | ML lead | Decouple: migrate current model first, ship model change in the next window |
| Savings slip past quarter end | High × Med | You (TPM) | Re-baselined date + Thursday go/no-go to protect the quarter |
| Dual-running both pools inflates cost | Med × Med | Finance partner | Cap the overlap window; daily cost watch during cutover |
This register - owners, triggers, a forcing date - is the deliverable the round wants to see.
Name the metric that tells you it's workingRecovery without a signal is hope
% of traffic cut over to the new pool, tracked daily against the re-baselined ramp.
If the curve flattens, the recovery is stalling before the date proves it.
$/request on the new pool versus the old, the whole point of the migration.
Paired with p99 latency, so you confirm the saving didn't come from a quality regression.
When the interviewer plays the disagreeing partner, resist arbitrating by opinion. Pull the conversation to the shared number - “both paths should be measured against $/request at the SLA; here's what each costs us” - and let the data carry the call. Influence without authority at Cursor is earned by being the most prepared person in the room with the cleanest framing, not by pulling rank you don't have.
Don't narrate a heroic all-nighter. The execution round rewards structured recovery, not effort - a re-baselined plan, a triaged register, a forcing escalation and a metric. If your answer is mostly “I worked the weekend and got everyone aligned,” you've shown stamina but not the program-management craft they're grading.
Takeaway. Run a slipping migration as re-baseline → triage → influence → force-the-decision, produce a risk register with owners and a forcing date and name a leading metric (% cut over) and an outcome metric ($/request at SLA).
Self-check
QML, Infra and Finance disagree on how to recover a slipping migration and none of them report to you. What's the most impactful move and why does it fit Cursor specifically?
Values round simulation
After this you can rehearse debate and why-Cursor against a tough interviewer.
Cursor's values round is a contact sport. The org screens for truth-seeking and spirited debate and you'll likely face a founder or senior leader who pushes back hard on purpose. The signal isn't whether you win the argument. It's whether you can update on a better fact without folding and hold a line when you're actually right.
Run this as a drill with a peer playing the antagonist. Three debate prompts, then a why-Cursor under fire. Record one round - tone and concision are part of what's measured.
Three spirited-debate prompts to rehearseHave your peer push back twice on each
- “Chargeback is bureaucratic overhead - just track total spend.” Defend showback-then-chargeback for AI workloads: you can't change behavior people can't see, but hard chargeback on experimental, bursty AI usage punishes the experimentation that drives the product. Hold the nuance under pressure.
- “Just over-provision GPUs - engineer time costs more than hardware.” Concede the kernel of truth (latency breaches at launch are expensive), then hold the line with the number: idle reserved GPUs at 15–30% utilization is a large, recurring COGS line and reserve-vs-burst captures the safety without the permanent waste.
- “Cost optimization slows the team down - that's not a TPM's job at a startup.” Reframe: the job is protecting gross margin so the company can fund more R&D, which speeds the team up. Tie it to outcomes, not process.
Update vs. hold - the two moves they gradeYou need to demonstrate both in the same round
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Two moves graded in the same conversation. Telling the situations apart is the truth-seeking signal.
When the interviewer surfaces real data you didn't have, change your view out loud and say why.
“You're right that this workload is batchable - that changes my utilization target, I'd pack higher here.”
This is the truth-seeking signal. Stubbornness reads as low curiosity.
When the pushback is rhetorical, not factual, stand your ground with evidence.
“I hear the concern and I still think reserve-vs-burst wins - here's the breakeven math.”
Folding under every challenge reads as no conviction. They want a thought partner.
The 90-second why-Cursor, then poke holes in itThree beats, specific to this charter
- 1The charter angle. You want to own the unit economics of running an AI product at 1M+ DAU - inference is the dominant COGS line, so this is one of the rare TPM roles that's genuinely quantitative and finance-adjacent, not Gantt-chart PM.
- 2The operator angle. You build the model and write the doc yourself. A flat, founder-engaged org with no thick management layer is where a hands-on operator who influences with prepared artifacts thrives and that's the work you actually want.
- 3The mission angle. Genuine belief that AI-assisted coding is where software is going, said plainly. The intensity only reads as real when the belief under it is real.
“Most TPM roles are process and ceremony. This one is essentially owning the unit economics of running an AI product at a million-plus DAU, where inference is the biggest COGS line - that's the quantitative, finance-adjacent work I'm best at and rarely get as a TPM. I want to build the cost models and capacity frameworks myself, in a flat org where the doc is the deliverable, not a deck someone else executes. And I believe AI-assisted coding is the future, so getting its unit economics right is work I'd find meaningful, not just billable.”
Have your peer attack the why-Cursor for genericness: “you could say that about any infra startup.” The fix is concreteness - name inference as the dominant COGS line, name 1M+ DAU, name a real Cursor session you ran and what you noticed about cost or latency. Authentic product usage is a screened signal here; “I've used it twice” is a quiet fail and a specific observation from real sessions is a quiet pass.
Takeaway. Rehearse three debate prompts until you can both update on a better fact and hold a line on the same call and deliver a 90-second why-Cursor concrete enough that a peer can't call it generic.
Self-check
Readiness scorecard & gaps
After this you can rate yourself across the loop and target the weak spots.
Prep drifts toward what's comfortable unless a scorecard points it somewhere else. Score each competency the loop tests, route every weak score to the module that fixes it, confirm your story bank is deep enough and build a one-week plan weighted to your lowest two scores.
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.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The five competencies, ranked by how decisive they are across this loop. Your two lowest self-scores against the heaviest bars set the week.
Score each competency against what the loop testsBe honest - a 3 you can defend beats a hopeful 5
- Competency
- FinOps / COGS attribution
- What the loop tests
- Showback vs. chargeback, unit economics, the take-home cost model
- Your 1-5
- __
- Competency
- GPU / capacity planning
- What the loop tests
- Reserve-vs-burst, utilization targets, demand modeling, cost-of-wrong both ways
- Your 1-5
- __
- Competency
- Program execution
- What the loop tests
- Re-baseline, risk triage, influence without authority, forcing escalations
- Your 1-5
- __
- Competency
- Systems literacy
- What the loop tests
- Inference serving, latency/SLA, batching, model routing, what drives cost
- Your 1-5
- __
- Competency
- Values / why-Cursor
- What the loop tests
- Spirited debate, update-vs-hold, concrete authentic motivation
- Your 1-5
- __
| Competency | What the loop tests | Your 1-5 |
|---|---|---|
| FinOps / COGS attribution | Showback vs. chargeback, unit economics, the take-home cost model | __ |
| GPU / capacity planning | Reserve-vs-burst, utilization targets, demand modeling, cost-of-wrong both ways | __ |
| Program execution | Re-baseline, risk triage, influence without authority, forcing escalations | __ |
| Systems literacy | Inference serving, latency/SLA, batching, model routing, what drives cost | __ |
| Values / why-Cursor | Spirited debate, update-vs-hold, concrete authentic motivation | __ |
Score before you study - your two lowest numbers set the week.
Map each weak score back to its fixEvery gap has a home in the track
- FinOps / COGS
- Re-drill cost attribution, showback vs. chargeback and why traditional cloud FinOps breaks on dynamic AI workloads; rebuild the take-home cost model
- GPU / capacity
- Re-drill reserved-vs-burst, the 60–80% sustained-use breakeven, utilization targets and tying GPU demand to DAU growth
- Program execution
- Re-drill scoping, critical path, RAID/risk registers, operating cadence and the influence-without-authority moves
- Systems literacy
- Re-drill inference-serving fundamentals - latency distributions, batching/throughput, model routing, what drives $/request
- Values / why-Cursor
- Rehearse the three debate prompts, the update-vs-hold drill and the 90-second why-Cursor with a peer poking holes
Confirm the story bank and the product usageTwo cheap checks people skip
Each hits a different value: ownership, truth-seeking, action bias, influence without authority, every-altitude.
Each leads with a number - % COGS cut, GPUs saved, a quarter protected - not “massive impact.”
If two stories prove the same value, replace one; if a value has no story, build it.
Log real sessions before the loop if your usage is thin - tab, agent mode, a multi-file change.
Carry one specific observation about cost or latency you can name in the values round.
“I've used it twice” is a quiet fail; a concrete observation is a quiet pass.
A one-week plan weighted to your lowest twoAttack the gaps, then a full dry-run
- 1Mon–Tue. Your two lowest competencies, one per day: re-read the deep dive, then do the timed drill - a full take-home rebuild or a 45-minute whiteboard capacity rep on that exact gap.
- 2Wed. Execution drill: run the slipping-migration recovery end to end and produce the risk register and forcing escalation as artifacts, not narration.
- 3Thu. Values day: record the three debate prompts and the 90-second why-Cursor, grade for update-vs-hold and concreteness, re-record the weakest.
- 4Fri. Full mock loop dry-run: take-home walkthrough, whiteboard capacity plan, execution recovery and values round, all scored against this rubric.
- 5Weekend. Light flashcard review only. Rest beats cramming the night before intensity is being measured.
The rubric converts a vague “am I ready?” into a ranked list of drills. Re-score after the Friday dry-run. If every competency clears a 4 and you can do the two things this role really tests - build a reconciled cost model with a defensible recommendation and design a capacity plan that names the cost of being wrong both ways - you're ready. If one competency still sits at a 2, that's the only thing left to work, so work exactly that.
Takeaway. Score the five competencies before you study, route each weak score to its deep dive, confirm 5–6 quantified stories and real Cursor usage, then run one full mock loop dry-run weighted to your lowest two scores.