The Interview Loop: Stages, Formats & How to Prepare

The job description gives you the skeleton in two phrases: a few “short technicals,” then “an onsite in our office, where you'll work on a small project, discuss ideas and meet the team.” Everything else in a Model Routing & Inference loop hangs off that skeleton and you should know exactly which parts Cursor states and which parts are standard for this kind of inference role.

Hold the whole shape before you prep a single answer. The loop is one sustained argument that you can ship senior-IC inference-platform work from week one, with taste about reliability, cost and latency. Each stage probes a slice of that claim.

1. 1Recruiter screen (~30 min). Background, motivation, why Cursor, team fit and whether you actually use the product.
2. 2Technical phone screens (the “2-3 short technicals,” ~60 min each). Medium-hard coding in TypeScript, Rust or Python plus a short design conversation; AI tools are allowed and you must understand every line.
3. 3Take-home / small project. Common for senior IC roles; the onsite is explicitly built around “a small project,” so expect a realistic inference- or routing-flavored build.
4. 4Onsite (SF or NY office). A hands-on project block, a design discussion and team meetings - the decisive stage.
5. 5Systems-design round. Design a high-throughput, low-latency serving or routing system with explicit latency, cost and failure budgets.
6. 6Inference / ML-systems deep-dive. Prefill and decode, KV cache, batching, provider economics, failover and backpressure tradeoffs.
7. 7Behavioral / craft / “why Cursor” round. The selective-hiring bar, pace, customer empathy and authentic product opinions.

The full span commonly runs two to three weeks and senior IC roles lean toward including a take-home. The onsite is the block that decides it, because it mirrors the real day-one work: scope a small inference problem, build a clean increment, defend the tradeoffs to the people you'd sit next to.

Thirty minutes, low on code and high on fit. The recruiter is sorting for genuine pull toward Cursor, a clear reason you want inference work specifically and whether you actually use the editor day to day.

This screen filters more candidates than people expect. The loop screens hard for superficial familiarity and superficiality shows up fastest in a casual conversation where you can't lean on a code editor.

• Why Cursor specifically, not “I want to work on AI” - name the inference path as the thing you want to own.
• Why inference and routing rather than model training or research; have a real reason you'd rather make the hot request path fast than train a model.
• Authentic usage: which surfaces you use daily and for what, said with the specificity only a real user has.
• Pace and scale fit: a sub-100-person company expecting senior-IC output from week one.

Each screen is roughly an hour: one medium-hard problem in TypeScript, Rust or Python, usually paired with a short design discussion. AI tools are allowed and expected - and the moment you submit something you can't explain, you fail.

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.

These problems carry a systems flavor rather than pure algorithm puzzles. Think streaming, concurrency and the messy realities of talking to provider APIs, not balanced-tree trivia.

1. 1Restate and bound the problem. Confirm inputs, failure modes and what “done” means before writing code.
2. 2Sketch the approach aloud. Name the data structure and the complexity and call the edge cases you'll handle (timeouts, partial reads, retries).
3. 3Use AI as a fast typist, not an oracle. Prompt for a scaffold, then read every line, test an edge case and reject what's wrong out loud.
4. 4Handle the failure path explicitly. A retry without a budget, a stream without a timeout, a limiter without fairness - name and close these.
5. 5Verify before you claim done. Walk a concrete input through, including one that breaks the naive version.

async function withRetry<T>(
  fn: () => Promise<T>,
  opts: { maxRetries: number; budgetMs: number },
): Promise<T> {
  const deadline = Date.now() + opts.budgetMs;
  let attempt = 0;
  for (;;) {
    try {
      return await fn();
    } catch (err) {
      attempt++;
      if (attempt > opts.maxRetries || Date.now() >= deadline) throw err;
      const base = Math.min(1000, 50 * 2 ** attempt);
      const jitter = Math.random() * base; // full jitter avoids retry storms
      await sleep(Math.min(jitter, deadline - Date.now()));
    }
  }
}

Senior IC loops commonly include a four-to-eight-hour take-home and the onsite is explicitly built around “a small project.” Both reward the same instinct: treat it as production code you'd own on day one, not a throwaway demo.

The likely shape maps straight onto the team's work: build or extend a gateway, router or proxy with a provider abstraction, timeouts, retries and a little observability. The brief will be slightly underspecified on purpose.

1. 1Scope first, then build a walking skeleton. Get one request flowing end to end through the abstraction before you add features.
2. 2Make the provider abstraction the spine. Onboarding a second “provider” should be config or a small adapter, not a rewrite - that's the real design signal.
3. 3Handle failure explicitly. Timeouts, retries with a budget and a clear behavior when a provider is down beat extra features.
4. 4Instrument it. Even a request counter, an error counter and a latency log signals SLO thinking.
5. 5Write a short README. State your tradeoffs, what you cut and what you'd do next - that paragraph often carries as much weight as the code.

• Correctness and clear failure handling over feature count.
• Readable code a teammate could own - names, small functions, no dead cleverness.
• A README that argues your tradeoffs honestly, including what's unfinished.
• One or two metrics that show you think in SLOs, not just happy paths.

The JD frames the onsite as “work on a small project, discuss ideas and meet the team.” Expect a hands-on build block, a design discussion that orbits the team's flagship problems and meetings that are quietly real signal.

This is the decisive stage because it simulates the job directly. You won't be graded on a sprawling half-built architecture; you'll be graded on small, correct, well-instrumented increments and how you reason out loud while building them.

1. 1Open with budgets and volume. State latency targets (sub-100ms for Tab), request volume, cost per request and a failure-rate budget before you draw boxes.
2. 2Tie each surface to its profile. Tab is latency-critical and cheap; Agent is long and expensive; chat streams - they don't get the same routing.
3. 3Make the tradeoff explicit. Hedging cuts tail latency but duplicates provider cost; say which way you'd lean and why.
4. 4Close the failure loop. Circuit break an unhealthy provider, shed load before the fleet melts and degrade gracefully rather than failing hard.

Across every stage, the same handful of signals decide it. Cursor hires selectively for engineers who ship senior-IC work from week one, so the loop rewards judgment and ownership over rote-correct answers.

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 product-opinion signal trips up strong engineers. The loop detects superficial familiarity fast, so a grounded comparison beats enthusiasm every time.

• Clean, honest engineering: you name failure modes and you say what you didn't finish.
• Cost-aware reasoning grounded in real GPU and provider dollars, not hand-waving.
• An on-call mindset: SLOs, error budgets, blast-radius thinking for a path that's always hot.