Capstone: Full Mock Loop

Cursor's first technical screen bans AI past editor autocomplete on purpose. As Michael Truell put it, “programming without AI is still a really great time-boxed test for skill and intelligence.” So the only honest prep is to run that exact constraint on yourself.

This is the one round you can't lean on tooling to fake. Open a blank file, kill Copilot and Cursor's agent, leave only token autocomplete and start a 45-minute timer. Pick a problem with the texture of infra work: a graph, a tree or something concurrent.

Pick one representative problemDrill scope

Narrate the whole time, out loud, as if an interviewer is on the call. State your approach and its complexity before you type, then talk through each tradeoff as you hit it.

The 45-minute protocolRun it like the real screen

1. 10–5 min · Clarify and restate. Pin down inputs, ranges and the failure cases. Can the graph have cycles? Are weights negative? What's the IP-set size? Ask the questions that change your data-structure choice.
2. 25–10 min · State the plan and the Big-O. Name your approach and its time and space complexity before writing code: “BFS over the dependency graph, O(V+E) time, O(V) for the visited set.” Commit to it out loud.
3. 310–35 min · Write clean production code. Real names, small functions, no dead branches. Handle the empty input and the single-element case as you go, not as an afterthought.
4. 435–42 min · Test it. Run a normal case, an empty case and the nastiest edge you can construct. Fix what breaks while narrating the bug.
5. 542–45 min · Discuss complexity and alternatives. Restate the Big-O, name one approach you rejected and why and call out what you'd profile if this ran at 1M+ DAU scale.

type Bucket = {
  capacity: number;
  tokens: number;
  refillPerSec: number;
  last: number; // epoch ms of last refill
};

function allow(b: Bucket, now: number, cost = 1): boolean {
  // Lazy refill: compute tokens earned since last check, cap at capacity.
  const elapsedSec = (now - b.last) / 1000;
  b.tokens = Math.min(b.capacity, b.tokens + elapsedSec * b.refillPerSec);
  b.last = now;
  if (b.tokens >= cost) {
    b.tokens -= cost;
    return true;
  }
  return false; // throttle: caller returns 429 + Retry-After
}

Typing it isn't the point. The point is that you can answer: why lazy refill instead of a background timer, what breaks under concurrent callers, why tokens is a float and not an int. If you can't defend a line, you don't actually know it.

Self-score honestly

• Did you reach a working solution that passes your own tests inside the box?
• Did you state complexity before coding and discuss the tail at scale?
• Did you handle the empty and single-element edge cases without prompting?
• Where did you stall - recursion, pointers, locking, graph traversal?

Infra design at Cursor isn't a background concern. You're drawing the foundation under a product serving 1M+ DAUs where multi-region latency, abuse-resistance and cost are first-order business problems. The design round watches whether you reason like the person who owns that.

Run one full prompt under a 45-minute clock, on a whiteboard or in a doc, narrating as you go. Use a Cursor-shaped problem so the tradeoffs are real.

Two prompts to runPick one per session

Drive the same six phases every timeDesign protocol

1. 1Requirements. Quantify before you draw. How many requests per second at peak, what's the p99 latency budget, what's the abuse threat model, what's the cost ceiling? Numbers anchor every later tradeoff.
2. 2Topology. Sketch the regions, the edge tier, the load balancers and where state lives. Convert any picture in your head into named components and the path between them.
3. 3Data flow. Trace one request end to end: DNS or Anycast, edge termination, WAF and rate-limit check, route to the nearest healthy region, backend, response. Say where each hop adds latency.
4. 4Failure modes. Kill each component on purpose. A region drops, the limiter's state store partitions, a backend gets slow not dead. State what degrades and what the user sees.
5. 5Cost / reliability tradeoffs. Make the call explicit. Active-active doubles spend for seconds of failover; active-passive is cheaper but loses minutes. Pick one and defend it against the budget.
6. 6SLOs. Close with the SLIs, the targets and the error budget that govern this. p99 under 200ms, 99.95% availability and here's what we shed first when the budget burns.

For the rate-limiting prompt, the algorithm choice is where strong candidates separate. Name the tradeoff out loud rather than defaulting to whatever you used last.

Score your own tapeSelf-rubric

The deep-dive is where Cursor checks that you operate as a functioning senior IC, not someone who watched a project happen near them. They pick the at-scale thing you built and drill until they hit either bedrock or hand-waving.

Pick your strongest at-scale infra project and rehearse it cold. The selection rule matters: choose the one where you owned a hard decision and can put numbers on the outcome, not the one with the prettiest diagram.

Structure the story before they askRehearsal protocol

1. 1Frame the problem and the scale. One sentence on what was breaking and the numbers around it - RPS, region count, cost, the SLO you were missing. Scale is the price of entry for a senior story.
2. 2Walk the architecture you chose. The topology, the key components and the path of a request or a deploy through them. Keep it tight enough that follow-ups have room to go deep.
3. 3Isolate your specific contribution. Say “I” and name the exact decisions you owned versus what the team or another engineer drove. Vague collective credit reads as someone who wasn't actually in the decision.
4. 4Quantify the outcome. Latency before and after, cost saved, availability gained, incidents avoided. A result without a number is an opinion.
5. 5Name what you'd change. The thing you'd redo with what you know now. Owning a flaw is a stronger signal than defending a perfect record.

Anchor it with real numbersQuantify outcomes

Then have a peer attack it. Every major choice gets a “why not X?” and you answer without flinching.

The behavioral round probes whether you fit a small, flat, talent-dense team where every hire ships from week one. They're reading for truth-seeking, bias to ship and honest cost-versus-reliability judgment - not polish.

Run these cold, out loud, one after another, each under two minutes. The constraint is the drill: a tight situation, the action you took and a quantified result.

The five prompts to rehearseRapid-fire set

The fifth prompt is the one most people fumble, so rehearse it hardest: “Tell me about a time you were wrong.” The trap is choosing a fake flaw. Pick a real mistake with a real cost and a real fix.

Hold every answer to this shapeTwo-minute structure

After each answer, check it against a Cursor value. A story that doesn't map to one isn't wrong, but it's a wasted slot.

The decision round is a 2-day on-site project where shortlisted candidates build something real with the team, share meals and present at the end. It's designed to filter people “just viewing it as a job.” You can't replicate the team or the meals, but you can replicate the shape: build and demo a real infra tool under a hard clock.

Give yourself a half-day. Pick a small infra tool with a demoable core and a vague-enough brief that you have to scope it yourself.

Pick one buildable toolDrill scope

The half-day protocolRun it like the real project

1. 1First 30 min · Orient and write your questions down. Treat it like ramping on an unfamiliar codebase. List the sharp questions you'd ask the team - which cloud account, what's the tag taxonomy, is there an existing limiter pattern, who consumes the output - instead of guessing in silence.
2. 2Scope to a demoable slice. Choose the thinnest end-to-end path that proves the tool works on one real input. Write down what you're deliberately cutting and why.
3. 3Build end-to-end first, then deepen. Get the full unglamorous slice running before polishing any layer. A vertical you can demo beats a gorgeous half that doesn't run.
4. 4Verify it on a real input. Run it against actual data or live traffic, add one test or a reproducible check and note the edge cases you didn't reach.
5. 5Write a 5-minute presentation. Show it working in the first 60 seconds, then spend the rest on the tradeoffs you made, what you cut and what you'd build next.

The on-site grades collaboration as hard as code, because you'd be on a flat team where teammates' trust is the currency. So rehearse the human signals, not just the build.

• Did you ask sharp early questions or burn an hour guessing the requirements?
• Would a teammate watching call you pleasant to pair with under a clock?
• Did you communicate progress and blockers or go dark and surface at the end?
• Did you protect the demoable slice instead of rabbit-holing on one layer?
• Could you take feedback mid-build and change course without getting defensive?

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.

Score yourself 1–5 on each area below using the evidence from the five drills you just ran, not your memory of how they felt. Anything under 3 is a blocker, because the loop is graded on your floor.

Turn scores into a dated planGap plan

1. 1Rank your two weakest areas and date them. Front-load them on the calendar - a 5 in design can't rescue a 2 in no-AI coding. Put a deadline on each weak area, not a vague “later.”
2. 2Assign concrete reps, not reading. A sub-3 in coding means three more timed, autocomplete-only problems by Wednesday, recorded and re-scored. An article isn't a rep.
3. 3Build any missing non-negotiable story. If you have no metric-backed incident story, mine your past work for the real one before inventing prep around a story that has no number.
4. 4Confirm logistics with your recruiter. Pin down stage details, the allowed languages for the coding screen (TypeScript, Go, Rust or Python) and the scope and format of the 2-day project so you're not surprised.
5. 5Lock a final-week routine. Use Cursor daily so “why Cursor” is lived, do fundamentals reps each morning and run one full mock end to end before the real loop.