Coding & Engineering Craft: TS, Rust, Python on the Hot Path

The coding screens for Model Routing & Inference are language-agnostic in theory and very opinionated in practice. You pick the language; the interviewer watches whether you actually live in it.

Cursor runs a small, polyglot stack and the inference path touches all three of its working languages. The JD names TypeScript, Rust or Python, but those are not interchangeable here. Each one owns a part of the request path and a strong candidate can say which and why without hedging.

Choose the one you can think aloud in. The screens are timed and conversational, so the cost of a second-favorite language shows up as hesitation: pausing to recall syntax instead of reasoning about the failure mode. Pick where your reflexes are fastest, then be genuinely conversant in the other two.

TypeScript at depththe default for gateway work

If you pick TypeScript, the bar is not “I write React.” It is modeling a provider abstraction in the type system so that an impossible state cannot compile. The single most reusable pattern for an inference gateway is a discriminated union over provider outcomes plus an exhaustive switch that the compiler forces you to keep complete.

type ProviderResult<T> =
  | { kind: "ok"; value: T; tokensIn: number; tokensOut: number }
  | { kind: "rateLimited"; retryAfterMs: number }
  | { kind: "timeout" }
  | { kind: "upstreamError"; status: number; retryable: boolean };

function classify<T>(r: ProviderResult<T>): "retry" | "failover" | "return" {
  switch (r.kind) {
    case "ok":           return "return";
    case "rateLimited":  return "failover";
    case "timeout":      return "retry";
    case "upstreamError":return r.retryable ? "retry" : "failover";
    // no default: adding a new variant becomes a compile error here.
  }
}

Rust and Python in their lanesknow the edges

The screen is “medium-hard with a systems flavor,” which is a specific genre. The problems sit close to what the inference platform does every second: consuming streams, throttling traffic and surviving a flaky upstream.

Generic algorithm puzzles still appear, but the distinctive ones are recognizably from this domain. A candidate who runs the product and the request path sees the editor connection immediately; someone who only drilled abstract puzzles tends to miss the partial-chunk and failure cases that are the whole point.

Worked example: a stream transformerpartial chunks are the trap

The classic version hands you a byte stream of newline-delimited JSON events and asks you to parse and re-emit them. The failure everyone forgets is that a chunk can split a line in half. Buffer the remainder and only emit on a complete delimiter.

async function* parseLines(
  chunks: AsyncIterable<Uint8Array>,
): AsyncGenerator<string> {
  const decoder = new TextDecoder();
  let buf = "";
  for await (const chunk of chunks) {
    buf += decoder.decode(chunk, { stream: true });
    let nl: number;
    while ((nl = buf.indexOf("\n")) !== -1) {
      const line = buf.slice(0, nl);
      buf = buf.slice(nl + 1);
      if (line.trim()) yield line;
    }
  }
  // flush a trailing line with no terminating newline
  if (buf.trim()) yield buf;
}

1. 1Restate as a contract. Write the typed signature and the constraint sentence (chunk sizes are arbitrary; lines can split) before any logic.
2. 2Brute-force first. Get a correct version that handles whole lines, then introduce the partial-chunk buffer.
3. 3Name the failure cases out loud. Split delimiter, empty chunk, no trailing newline, stream that errors mid-flight.
4. 4Then complexity and tradeoffs. O(n) over bytes, constant extra memory beyond one pending line; mention what changes if a single line can be huge.

These five primitives are the reusable parts of an inference gateway. Interviewers ask for one in code and then probe whether you understand how it composes with the others under load.

You will not build the whole platform in a screen. You will be asked to implement one piece cleanly and reason about its interactions: what happens when a retry fires inside a hedge or when a timeout cancels a request that already mutated state.

Backoff with jitter and a budgetthe storm-avoidance primitive

async function withRetry<T>(
  fn: (signal: AbortSignal) => Promise<T>,
  opts: { maxAttempts: number; baseMs: number; capMs: number; signal: AbortSignal },
): Promise<T> {
  let attempt = 0;
  for (;;) {
    try {
      return await fn(opts.signal);
    } catch (err) {
      attempt++;
      if (attempt >= opts.maxAttempts || opts.signal.aborted) throw err;
      const ceil = Math.min(opts.capMs, opts.baseMs * 2 ** attempt);
      const delay = Math.random() * ceil; // full jitter
      await sleep(delay, opts.signal);
    }
  }
}

Two details earn the credit. Full jitter (random() * ceil, not ceil + random()) is what actually de-synchronizes a thundering herd. A bounded maxAttempts is the retry budget that stops a dead provider from amplifying load forever.

Hedging without doubling the billlatency vs cost, made explicit

1. 1Fire the primary. Start the request and a timer for the hedge delay (often near the p95 of normal latency).
2. 2Hedge only on the tail. If the primary hasn't returned by the delay, launch a second attempt - ideally to a different provider.
3. 3Take the first, cancel the rest. Resolve on the first success and abort the loser so it stops consuming tokens and GPU.
4. 4Cap the duplicate cost. Hedge a bounded fraction of traffic; if hedge rate climbs, that's a signal the primary is unhealthy, not a reason to hedge everything.

Cursor lets you use AI tools in the coding screens. That permission is also the test. They are watching whether you drive the model or the model drives you.

The stated bar is blunt: candidates must understand every line, reject poor suggestions and explain their debugging decisions. Pasting raw model output you can't defend is treated as an instant rejection. The interviewer is hiring a senior IC who owns correctness, not someone who outsources it.

That narration does three jobs at once: it shows you read the suggestion, it shows you have a correctness opinion and it shows the specific domain knowledge (jitter strategy) that the tool doesn't supply. Silence while you accept a completion reads as the opposite.

Run a real Cursor-native workflowfluency, not a demo

Treat the model as a fast junior pair. It produces volume; you supply judgment, architecture and the tradeoff calls it can't make. You stay accountable for every line that ships, exactly as you would reviewing a teammate's PR.

1. 1Frame the contract yourself. State the signature, constraints and failure cases before invoking any AI - you set the target, not the model.
2. 2Generate in small slices. Ask for one function or one edit, not the whole solution, so each diff is reviewable.
3. 3Audit out loud. For each suggestion say accept-or-reject and the reason; fix anything you wouldn't merge.
4. 4Verify, don't trust. Run it, trace an edge case and narrate the debugging - never claim it works because the model wrote it.

On a sub-100-person team where you ship senior IC from week one, the code you write in the screen is a sample of the code you'd put up for review. They read it that way.

The difference between a strong and a weak finish is rarely the algorithm. It's whether you talked in tradeoffs, named edge cases before they had to ask and left the file in a state a teammate could merge.

Talk in tradeoffs, not just answersthe senior signal

• State complexity and the failure modes: “O(n) over tokens, but it buffers one full line, so a pathological no-newline stream grows unbounded - I'd cap it.”
• Name what you'd test before they ask: empty stream, partial chunk, provider 500, timeout, oversized input.
• Call out what you're deferring and why, so a deferral reads as judgment rather than a gap.

Leave it reviewablethe merge test

Honesty about what's unfinished is a senior tell, not a confession. It shows you know what “done” means and can prioritize the remaining work - which is exactly the gray-area judgment the role is screened for.

1. 1Increment small and correct. Land a working slice, confirm it, then extend - never a big half-working sketch.
2. 2Verify each slice. Trace one real edge case aloud before moving on, so correctness is demonstrated, not asserted.
3. 3Tidy before time's up. Rename the rushed variable, delete the scratch branch, so the final read is clean.
4. 4Close with next steps. State what you'd do with another hour; it leaves the interviewer with your roadmap, not your gaps.