The Interview Loop, Decoded
Stages, format, who you meet and how to prepare for each
Loop map at a glance
After this you can see the whole sequence and how rounds build on each other.
Cursor is hiring a TPM for Infrastructure to own the unit economics of running an AI product at 1M+ DAU. The loop is built to find out whether you can build the cost model and run the room, not whether you can recite a RACI template.
Hold the full shape in your head before you prep a single answer. Every stage probes one slice of a single claim: that you can attribute inference and compute spend to products, plan GPU capacity and drive technical leaders to decisions without any formal authority over them.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Step through each stage. Round count and ordering are general-industry inference for a senior TPM loop - let your recruiter's walkthrough override it.
- 1Recruiter screen (30 min). Background, why Cursor specifically, charter fit, comp and SF-in-person logistics.
- 2Hiring-manager / program-sense screen (45-60 min). A real program you owned - scope, plan, stakeholders, what you drove without authority. This gates the rest of the loop.
- 3Take-home or practical exercise (4-8 hrs, senior/staff IC pattern). A realistic cost-attribution or capacity-planning artifact: build a model, write the recommendation doc.
- 4Program-management execution deep-dive (60 min). Risk, dependency and migration sequencing, status and escalation mechanics, operating cadence.
- 5Systems-literacy round (60 min). Infra and inference-serving fundamentals. Not coding - you reason about GPUs, latency, utilization and what drives cost.
- 6Domain / analytical round (60 min). FinOps-for-AI: define metrics, design a chargeback or showback model, defend tradeoffs with senior leaders watching.
- 7Values + cross-functional partner round (45-60 min). Truth-seeking, spirited debate, influencing ML and Finance partners - often with a founder or senior leader in the room.
- Stage
- Recruiter screen
- Source
- Standard
- What it really tests
- Motivation, why-Cursor, charter fit, logistics
- Stage
- Program-sense screen
- Source
- Role-typical
- What it really tests
- Can you scope and drive a program without authority
- Stage
- Take-home / exercise
- Source
- Senior-IC pattern
- What it really tests
- The artifact - cost model plus a decision-ready doc
- Stage
- Execution deep-dive
- Source
- Role-typical
- What it really tests
- Risk, dependencies, cadence, escalation craft
- Stage
- Systems literacy
- Source
- Cursor-distinctive
- What it really tests
- Fluent reasoning about GPUs, latency, utilization
- Stage
- Domain / analytical
- Source
- Cursor-distinctive
- What it really tests
- FinOps-for-AI judgment and live attribution design
- Stage
- Values + founder
- Source
- Cursor-distinctive
- What it really tests
- Truth-seeking, ownership, fit for a flat org
| Stage | Source | What it really tests |
|---|---|---|
| Recruiter screen | Standard | Motivation, why-Cursor, charter fit, logistics |
| Program-sense screen | Role-typical | Can you scope and drive a program without authority |
| Take-home / exercise | Senior-IC pattern | The artifact - cost model plus a decision-ready doc |
| Execution deep-dive | Role-typical | Risk, dependencies, cadence, escalation craft |
| Systems literacy | Cursor-distinctive | Fluent reasoning about GPUs, latency, utilization |
| Domain / analytical | Cursor-distinctive | FinOps-for-AI judgment and live attribution design |
| Values + founder | Cursor-distinctive | Truth-seeking, ownership, fit for a flat org |
The quantitative domain round and a likely founder in the values round are Cursor's distinctive moves. The take-home and execution deep-dive are standard for senior TPM loops; treat round counts and ordering as general-industry inference unless your recruiter says otherwise.
Most TPM loops at big tech lean process-and-coding heavy. Cursor's is unusually quantitative and finance-adjacent, because inference is the dominant COGS line. The stages above are reliable in spirit, but the exact count, whether a take-home appears and the order vary by quarter. Ask the recruiter to walk you through your real loop on the first call and let that override this map.
The bar is on the artifact, not the ceremony. They want someone who writes the doc, builds the model and runs the analysis. A whiteboard cost model or a take-home is where you win or lose and a flat org means a senior leader is judging whether they'd actually take your recommendation.
Takeaway. Seven stages, one claim: you can attribute spend, plan capacity and drive technical leaders to a decision with no authority - and the take-home plus the quantitative rounds are where the loop is actually decided.
Self-check
QWhat makes Cursor's TPM loop distinctive versus a standard big-tech TPM loop?
Recruiter & why-Cursor screen
After this you can pass the screen on motivation and charter fit.
Thirty minutes, light on substance and heavy on fit. The recruiter is sorting for a sharp reason you want this charter, genuine pull toward AI-native infrastructure and whether the SF-in-person, high-pace reality is a fit before anyone spends a loop on you.
A generic “I'm excited about AI” answer dies here. This is a finance-adjacent infrastructure role, so the screener wants to hear that you specifically want to own inference unit economics at a company already running at enormous scale.
- Why Cursor specifically - tie it to inference economics being the dominant COGS line, the 1M+ DAU scale and the AI-native bet, not to “I love developer tools.”
- A crisp 90-second story of a program you owned that moved a real number: a COGS line cut, a utilization target hit, a forecast that held.
- Action bias and comfort with shifting priorities, said plainly - these are explicit culture screens.
- What you actually build with Cursor and a guess at where its costs come from (tab prediction's tens-of-ms latency, agent runs that fan out across many model calls).
- Location
- Strong SF in-person bias; confirm relocation or remote expectations on this call.
- Pace
- Demanding and fast-shifting as model capability and competition evolve - name your appetite for it honestly.
- Charter
- COGS attribution, GPU/capacity allocation, R&D-efficiency programs - make sure that's the work you want.
- Comp / level
- Senior/staff IC TPM; align on band and scope so nothing surprises you in week three.
“I want this because inference is your biggest cost line and almost nobody has built real FinOps for AI yet - the playbooks from cloud FinOps break on dynamic, experimental GPU workloads. Owning cost-per-inference and cost-per-active-user at 1M+ DAU and being the person who turns that into capacity decisions, is the most interesting unsolved operating problem I can find right now.”
Vague enthusiasm reads as a non-believer and the people you'd partner with are model and infra leaders who can tell. Be concrete: name a feature you use, why the latency or cost shape of it is interesting and what you'd want to measure first. That proves you've connected the product to the platform economics, which is the whole job.
Takeaway. Bring a why-Cursor that names inference COGS and scale, one program story with a number and an honest read on SF-in-person and pace - generic AI enthusiasm fails this filter.
Self-check
Program-sense & execution rounds
After this you can narrate a program with the structure interviewers score on.
These two rounds are the spine of any TPM loop. The hiring-manager screen tests whether you can scope and drive a program; the execution deep-dive tests whether your operating mechanics survive contact with risk, dependencies and shifting priorities.
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.
Pick a program that rhymes with the charter - a cost-optimization push, a capacity migration, a reliability program. Then narrate it in the order interviewers actually score, leading with scope and ending with the number.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The same program, told two ways. Interviewers screen against the process-theater TPM and the hero TPM both.
- 1Scope first. State the goal, the one metric that defined success, the owners, the timeline and the top two or three risks in your first thirty seconds.
- 2Make the without-authority move explicit. Name how you got ML, Infra and Finance aligned with no formal power - a shared model everyone trusted, a forcing-function review, a tradeoff they couldn't unsee.
- 3Separate you from the team. Be precise about what you owned (the model, the doc, the cadence, the escalation) versus what engineers built. TPM credibility lives in that line.
- 4Show the operating machinery. Status cadence, escalation path, a RAID or risk register that actually changed a decision and how you managed the critical path through dependencies.
- 5Close with the outcome and the redo. The measurable result, then one honest thing you'd do differently. A clean retro signals truth-seeking.
- Term
- RAID
- What it is
- Risks, Assumptions, Issues, Dependencies log
- What good looks like in the story
- You point to one entry that changed a real decision, not a tidy spreadsheet nobody read.
- Term
- Critical path
- What it is
- The longest chain of dependent work that sets the end date
- What good looks like in the story
- You can name what was on it and the one dependency you resequenced to pull the date in.
- Term
- Operating cadence
- What it is
- The recurring reviews that keep a program honest
- What good looks like in the story
- A weekly with a tight agenda and a decision log, not a status theater meeting.
- Term
- Escalation
- What it is
- Moving a blocker up when owners can't resolve it
- What good looks like in the story
- You escalated with a recommendation and a deadline, not just a complaint.
| Term | What it is | What good looks like in the story |
|---|---|---|
| RAID | Risks, Assumptions, Issues, Dependencies log | You point to one entry that changed a real decision, not a tidy spreadsheet nobody read. |
| Critical path | The longest chain of dependent work that sets the end date | You can name what was on it and the one dependency you resequenced to pull the date in. |
| Operating cadence | The recurring reviews that keep a program honest | A weekly with a tight agenda and a decision log, not a status theater meeting. |
| Escalation | Moving a blocker up when owners can't resolve it | You escalated with a recommendation and a deadline, not just a complaint. |
Interviewers listen for whether these are live tools you used or vocabulary you memorized. Anchor each to a specific decision it changed.
When asked “what did you own,” resist claiming the engineering. Say it cleanly: “I owned the plan, the cost model, the weekly tradeoff review and the escalation when the migration slipped. The team owned the actual serving changes.” Owning the right things and not the wrong ones, is the senior signal.
Process-theater TPMs over-index on ceremony and can't name a number. Hero TPMs claim the team's work as their own. Cursor screens against both - the charter says you build the model yourself and influence without authority, so your story has to show both hands-on artifact ownership and earned alignment.
Takeaway. Lead with scope and the metric, make the without-authority alignment explicit, draw a clean line between what you owned and what the team built and close with a number plus one honest redo.
Self-check
QIn a program story, why does separating what YOU did from what the team did matter so much for a TPM?
The take-home / practical artifact
After this you can produce a decision-ready model and doc under time pressure.
This is where the loop is won or lost. Cursor uses 4-8 hour take-homes for senior IC roles and for this charter the prompt will be a realistic cost-attribution or capacity-planning problem - treated here as general-industry inference, but consistent with how they hire.
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.
The win condition is the artifact, not effort. Two deliverables: a cost model with assumptions you can defend and a one-page recommendation an engineer and a finance partner can both follow.
- 1State assumptions loudly. GPU hourly cost, utilization, tokens per request, requests per DAU. List them at the top so a reviewer can challenge inputs, not chase your math.
- 2Build the model so inputs are visible. Separate assumptions from calculations from outputs. A reviewer should be able to change one number and watch the answer move.
- 3Run sensitivity on the 2-3 variables that dominate. Find which inputs actually swing the answer (usually utilization and request volume) and show the answer across a low/base/high band.
- 4Make one clear recommendation and own the tradeoff. A point of view beats a fence-sit. Say what you'd do, what it costs and what you're trading away.
- 5Write the one-pager for two audiences. The engineer needs the mechanism; the finance partner needs the dollars and the risk. One page, both readers satisfied.
# Assumptions (challenge these, not my arithmetic)
GPU_HOURLY = 2.50 # blended $/GPU-hr, reserved + on-demand mix
UTILIZATION = 0.30 # sustained; GPUs commonly run 15-30%
REQ_PER_DAU_DAY = 40 # avg inference requests per active user/day
DAU = 1_000_000
GPU_REQ_PER_SEC = 12 # throughput per GPU at target latency
# Derived
req_per_day = DAU * REQ_PER_DAU_DAY # 40M req/day
req_per_sec = req_per_day / 86_400 # ~463 rps avg
gpus_needed = req_per_sec / (GPU_REQ_PER_SEC * UTILIZATION)
daily_cost = gpus_needed * 24 * GPU_HOURLY
cost_per_req = daily_cost / req_per_day
cost_per_dau = daily_cost / DAU
# Sensitivity: sweep UTILIZATION in {0.20, 0.30, 0.50} -> watch cost_per_dau moveDo the units cross out end to end. Does cost-per-active-user land in a believable range. Does the answer change in the direction you'd expect when you raise utilization. If a single typo in one assumption can flip your recommendation, that's exactly why you put assumptions at the top and ran sensitivity.
“It depends” with no decision is a fail. The role exists to give technical leaders a recommendation they can act on. Pick a position, state the conditions under which you'd reverse it and move. Reviewers reward a defensible point of view over a hedge every time.
Takeaway. Lead with named assumptions, build a model where one input visibly moves the answer, run sensitivity on the 2-3 variables that dominate and end with one defensible recommendation written for an engineer and a finance partner at once.
Self-check
QYou finish the take-home cost model but you're unsure of two inputs. What's the strongest way to handle that uncertainty in the artifact?
Systems-literacy & domain rounds
After this you can reason fluently about infra cost without being asked to code.
Two technical rounds with no algorithms. The systems round checks that you can reason about GPUs, latency, batching and utilization. The domain round centers on FinOps-for-AI: you'll define the right metrics and design an attribution model live, with a senior leader pushing back.
Vocabulary is table stakes. The actual signal is judgment - what to measure, what to cut and which tradeoff you'd take with imperfect data.
- Concept
- Utilization
- Why it drives cost
- GPUs often run at 15-30%; idle silicon is pure cost
- The judgment they're listening for
- You target a realistic sustained number, not 100% and know the reliability tradeoff of pushing it up.
- Concept
- Latency SLA
- Why it drives cost
- Tab prediction needs tens-of-ms latency, which limits batching
- The judgment they're listening for
- You see that tight latency caps throughput and raises cost per request and you'd route by need.
- Concept
- Batching / throughput
- Why it drives cost
- Bigger batches raise GPU efficiency but add latency
- The judgment they're listening for
- You'd batch aggressively for background agent work, lightly or not at all for tab completion.
- Concept
- Model routing
- Why it drives cost
- Small models for simple queries, large for complex
- The judgment they're listening for
- You'd send easy completions to a cheap model and reserve the expensive one for hard requests.
- Concept
- Reserved vs. on-demand
- Why it drives cost
- Reserved is cheap at high sustained use; burst is pricey
- The judgment they're listening for
- You size a reserved baseline near the 60-80% sustained-usage breakeven and burst on-demand above it.
| Concept | Why it drives cost | The judgment they're listening for |
|---|---|---|
| Utilization | GPUs often run at 15-30%; idle silicon is pure cost | You target a realistic sustained number, not 100% and know the reliability tradeoff of pushing it up. |
| Latency SLA | Tab prediction needs tens-of-ms latency, which limits batching | You see that tight latency caps throughput and raises cost per request and you'd route by need. |
| Batching / throughput | Bigger batches raise GPU efficiency but add latency | You'd batch aggressively for background agent work, lightly or not at all for tab completion. |
| Model routing | Small models for simple queries, large for complex | You'd send easy completions to a cheap model and reserve the expensive one for hard requests. |
| Reserved vs. on-demand | Reserved is cheap at high sustained use; burst is pricey | You size a reserved baseline near the 60-80% sustained-usage breakeven and burst on-demand above it. |
You won't be asked to implement any of this. You will be asked which lever you'd pull first and why.
Showback vs. chargeback and why cloud FinOps breaks here
- Showback reports each team's cost without billing them - it builds awareness and surfaces waste with low political friction. Chargeback actually allocates the cost to a team's budget, which changes behavior but invites fights over the allocation rules.
- Traditional cloud FinOps assumes stable, taggable resources. AI workloads are dynamic and experimental: training and eval runs spike, a single agent request fans out across many model calls and shared model endpoints make per-team attribution genuinely hard.
- R&D spend (training, experimentation) is an investment that shouldn't be charged like production COGS. Separating R&D from production inference is half the battle in any honest attribution model.
When they ask you to design attribution live, start with showback and a clear unit metric (cost per inference, cost per active user) before reaching for chargeback. Say why: showback gets you trustworthy data and behavior change with far less political cost and you can graduate to chargeback once the allocation rules are battle-tested. Sequencing the rollout is the senior move.
These rounds are run by people who serve models for a living. If you don't know a number, reason from first principles out loud and say what you'd measure to confirm. A confident wrong figure is worse than “I'd validate utilization against the dashboard before committing - but if it's near 25%, here's the implication.”
Takeaway. Know the levers - utilization, latency, batching, routing, reserved-vs-burst - but win on judgment: lead attribution with showback and a clear unit metric, separate R&D from production COGS and reason from first principles when you don't have the number.
Self-check
QIn the domain round you're asked to design cost attribution for inference. Why might you recommend starting with showback rather than chargeback?
Values & founder round
After this you can demonstrate the screened values under real-time debate.
The last round is a fit test run as a conversation, often with a founder or senior leader given Cursor's flat, founder-engaged culture. The values are screened, not assumed and the test is live: how you behave in spirited debate, not how well you describe yourself.
Truth-seeking is the load-bearing value. They want to see you disagree well, hold a position with evidence and change your mind when the evidence shifts - without folding into consensus the moment a senior person pushes.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Every value is screened, but they aren't weighted equally. Truth-seeking is load-bearing; the rest support it.
When pushed, engage the substance. State your reasoning, ask what evidence would change their mind, offer what would change yours.
Folding instantly reads as low conviction; digging in past the evidence reads as low ego control.
Have a real example of changing your mind when the data contradicted you.
“I was sure the migration would pay back in two quarters; the utilization numbers said four, so I rescoped it” is the shape they want.
High ownership without claiming the team's work. In a flat org with no thick management layer, you escalate by earning trust, not by org chart.
Name a failure you owned cleanly and what you changed.
A founder can smell a generic answer. Have a genuine reason FinOps-for-AI at Cursor's scale is the problem you want next.
Tie it to the unsolved nature of the problem, not to the company's logo.
“I think the most impactful cost move isn't squeezing utilization - it's model routing. Most completions are simple and don't need the biggest model. If we route by request complexity, we cut cost per inference without touching the latency users feel. I'd want to validate the complexity classifier's error rate before betting on it, but that's where I'd start.”
Bring one strong, defensible opinion about Cursor's cost or product strategy and bring the conditions under which you'd abandon it. Stating an opinion shows conviction; naming what would change your mind shows truth-seeking. That pairing is exactly the value they're screening for, demonstrated instead of claimed.
Takeaway. Demonstrate truth-seeking live - hold one strong, defensible opinion about Cursor's cost strategy, name what would change your mind and own a real example of updating on evidence without folding to seniority.