Applied Coding & Editor Primitives

Cursor's technical screen is not LeetCode theater. You get one medium-hard problem and it usually sits on top of a real slice of the codebase rather than in a blank file.

The role builds the editor itself, so the screen probes whether you can reason about the structures an editor actually runs on. A Software Engineer, Product who has shipped real features recognizes these problems instantly; someone who crammed abstract algorithm puzzles the night before tends to flounder the moment the problem touches a file system or a text buffer.

Candidates have reported a consistent flavor of question. Treat these as the genre, not a leaked answer key.

The deeper pattern is that applied problems lean on AI-editor primitives. Interviewers have framed problems around multi-file edit coordination, context retrieval for LLM prompts and streaming edit application. You are not expected to have built Cursor, but you are expected to reason about these like an engineer who uses the product daily.

What they actually gradeclean and correct beats clever

The bar is clean, correct, readable code with clear reasoning out loud. A working O(n log n) solution you can explain beats a half-finished O(n) trick you can't. Name your invariants, handle the empty and single-element cases before the interesting ones and say why you chose a Map over an object.

// Find duplicate files: group paths by identical content.
// Input:  Array<{ path: string; bytes: Uint8Array }>
// Output: string[][]  - each inner array is one duplicate group (size >= 2)
// Constraints: 100k files, files up to 100MB - cannot hash everything blindly.
function findDuplicates(files: FileEntry[]): string[][] { /* ... */ }

An editor is a machine for inserting and deleting characters in huge documents, fast. The naive answer - a single string you keep re-slicing - collapses the moment a file is large or edits are frequent.

Three representations come up. You rarely have to implement a rope from scratch in a 45-minute screen, but you must be able to name them, sketch one and reason about why an editor picks the one it does.

Applying a single editoffset + length + replacement

Model an edit as a range you cut and a string you splice in. The minimal shape is { offset, length, text }: delete length characters at offset, then insert text. Everything harder is built on this.

interface Edit {
  offset: number;  // 0-based start in the current buffer
  length: number;  // chars to delete (0 = pure insert)
  text: string;    // chars to insert ('' = pure delete)
}

function applyEdit(buf: string, e: Edit): string {
  return buf.slice(0, e.offset) + e.text + buf.slice(e.offset + e.length);
}

Composing many edits without corrupting positionswhere off-by-one bugs are born

The trap: every edit you apply shifts the offsets of every later edit. Apply edit A at offset 10 and an edit that used to target offset 50 now targets a different character. Two disciplines avoid the corruption.

1. 1Resolve against one snapshot. Compute all edit offsets relative to the original buffer, never against the partially-mutated one.
2. 2Apply right-to-left. Sort edits by descending offset and apply from the end of the file backward, so each edit lands before any unprocessed edit's position can shift.

function applyEdits(buf: string, edits: Edit[]): string {
  const sorted = [...edits].sort((a, b) => b.offset - a.offset);
  for (const e of sorted) {
    if (e.offset < 0 || e.offset + e.length > buf.length) {
      throw new Error(`edit out of range at ${e.offset}`);
    }
    buf = buf.slice(0, e.offset) + e.text + buf.slice(e.offset + e.length);
  }
  return buf;
}

When an agent rewrites a function and updates its three call sites in other files, that is a multi-file edit. It must land as one unit or not at all.

Model the whole change as a map from file path to a list of in-file edits. The unit of work is the batch, not the individual edit, because a half-applied refactor leaves the repo broken.

type MultiFileEdit = Map<string, Edit[]>;

interface ApplyResult {
  applied: Map<string, string>;  // path -> new contents
  conflicts: string[];           // paths that could not apply
}

Apply atomically, report conflictsall-or-nothing across files

Compute every new file body first, in memory, before you write a single byte to disk. If any file fails - overlapping edits, a stale base, an out-of-range offset - you abort the whole batch and report which paths conflicted. The user sees one clean failure, not a repo in a torn state.

1. 1Validate per file. Run each file's edits against its current contents in memory; collect failures.
2. 2Gate on conflicts. If the conflict list is non-empty, return it and write nothing.
3. 3Commit together. Only when every file validated, persist all of them in one pass.

Computing the diffline-level for review, char-level for precision

A diff is the minimal set of changes that turns the old text into the new. The textbook engine is a longest-common-subsequence (LCS) computation: find the longest run of unchanged lines and everything outside it is an insertion or deletion. Most production diffs run LCS at line granularity for a readable review, then refine to character granularity inside changed lines.

Streaming edit applicationapply model output as it arrives

The model streams tokens, so you can't wait for the full edit before showing anything. The danger is applying a partial edit and corrupting the buffer when the next chunk arrives. The safe pattern keeps a stable base and replaces a pending region on each chunk.

1. 1Anchor a region. Pick the offset range the stream is rewriting and treat it as a single replaceable span.
2. 2Buffer the partial. Accumulate streamed text; render it into the anchored region for preview without committing.
3. 3Commit on completion. When the stream ends, apply one final, validated edit and clear the pending state. If the stream errors, drop the pending region - the base buffer was never mutated.

Cursor indexes whole repositories, so the file-system and tree problems are not arbitrary - they are simplified versions of work the editor does every time you open a project.

Find duplicate files at scalethe reported classic

Hashing every file's full contents is the obvious answer and the wrong first move at repo scale. The cheap optimization: two files can only be identical if they're the same size, so group by size first and hash only within groups that have more than one member. Most files are unique by size, so you skip hashing them entirely.

function findDuplicates(files: FileEntry[]): string[][] {
  const bySize = new Map<number, FileEntry[]>();
  for (const f of files) {
    const g = bySize.get(f.bytes.length) ?? [];
    g.push(f);
    bySize.set(f.bytes.length, g);
  }

  const groups: string[][] = [];
  for (const sameSize of bySize.values()) {
    if (sameSize.length < 2) continue;        // unique by size - skip hashing
    const byHash = new Map<string, string[]>();
    for (const f of sameSize) {
      const h = hashContent(f.bytes);         // sha-256 of bytes
      (byHash.get(h) ?? byHash.set(h, []).get(h)!).push(f.path);
    }
    for (const paths of byHash.values()) {
      if (paths.length >= 2) groups.push(paths);
    }
  }
  return groups;
}

Hash trees to detect changed filesMerkle-style structure

A hash tree (Merkle tree) hashes each file, then hashes each directory as a hash of its children's hashes, up to a single root hash. Two trees with the same root are identical. When something changes, only the path from that file to the root changes, so you find the changed subtree in O(log n) of the directory depth instead of rescanning everything.

type FsNode =
  | { kind: 'file'; name: string; bytes: Uint8Array }
  | { kind: 'dir'; name: string; children: FsNode[] };

function merkleHash(node: FsNode): string {
  if (node.kind === 'file') return hashContent(node.bytes);
  const childHashes = node.children
    .map((c) => `${c.name}:${merkleHash(c)}`)
    .sort();                                  // stable order -> stable hash
  return hashContent(new TextEncoder().encode(childHashes.join('|')));
}

Tree traversals as outline problemstop view, level order

Reframe these the way the editor uses them: a code outline is a tree and rendering it is a traversal. The top view of a binary tree - the nodes visible from above - is a BFS where you track each node's horizontal distance from the root and keep the first node seen at each distance.

interface TreeNode { val: number; left?: TreeNode; right?: TreeNode; }

function topView(root?: TreeNode): number[] {
  if (!root) return [];
  const firstAtHd = new Map<number, number>();   // horizontalDist -> value
  const queue: Array<{ node: TreeNode; hd: number }> = [{ node: root, hd: 0 }];
  let minHd = 0, maxHd = 0;

  while (queue.length) {
    const { node, hd } = queue.shift()!;
    if (!firstAtHd.has(hd)) firstAtHd.set(hd, node.val);  // BFS => topmost first
    minHd = Math.min(minHd, hd);
    maxHd = Math.max(maxHd, hd);
    if (node.left) queue.push({ node: node.left, hd: hd - 1 });
    if (node.right) queue.push({ node: node.right, hd: hd + 1 });
  }

  const out: number[] = [];
  for (let hd = minHd; hd <= maxHd; hd++) out.push(firstAtHd.get(hd)!);
  return out;
}

Cursor's loop has two coding modes. First technical screens allow only autocomplete - no AI assistance beyond that. The 8-hour onsite lets you use AI tools and even Slack questions. The same person should be strong in both.

When AI is allowed, the interviewer is not grading the model's output. They're grading your judgment about it. The whole point is that you can tell good suggestions from bad ones and act on the difference visibly.

Use AI for lookup, not for designwhere the line sits

The healthy use is targeted: "what's the signature of Array.prototype.flatMap," or "generate the boilerplate for this test harness." The unhealthy use is handing the model the whole problem and steering by vibes. Keep the architecture, the data model and the tradeoffs in your own head; let AI handle the parts you already know but don't want to type.

• Reach for AI to recall an API, scaffold a test or convert a snippet - things you could do yourself, just faster.
• Keep the design decisions, complexity reasoning and edge-case handling explicitly yours, spoken aloud as you go.
• When a suggestion is wrong, say what's wrong and correct it; a visible rejection is worth more than a silent accept.

The authenticity testthey can tell within minutes

Cursor interviewers can tell within minutes whether you actually use Cursor daily for real work or skimmed the docs to prep. The way you drive AI in-round is part of that signal: fluent, opinionated use reads as authentic; hesitant or over-reliant use reads as someone performing familiarity. The fix isn't a script. Use the product on real work for weeks before the loop.

Strong driving, concretelythe moves the panel can see

"Use AI well" is too vague to rehearse. The people who actually use Cursor daily drive it with four habits that read as authentic on a shared screen. Practice each until it's reflex, because the interviewer is watching how you operate the tool, not just whether the tests pass.

The vague-vs-scoped contrast is the one to internalize, because it shows up verbatim in how engineers talk about driving the tool. A prompt like "make the app better" gives the model nothing to anchor on, so it edits at random and the cost compounds: blind edits, then reading and re-fixing the slop it just wrote. The scoped version names everything the model needs.

// WEAK: no surface, no change, no constraint - blind edits, compounding cost.
make the app better

// STRONG: surface + exact change + constraints, on a model matched to the task.
Under the shop page, add an in-stock filter next to the existing tag and
sort controls. Preserve the URL query params and update tests if needed.

TypeScript is the language the editor surface is written in, so fluency is table stakes. Fumbling syntax burns the minutes you need for reasoning and it reads as someone who doesn't write TS daily.

Be reflexively fast with the few constructs editor code leans on. Not exotic type gymnastics - the everyday tools, used cleanly.

Small, well-typed helpersdon't any your way out

Reaching for any to escape a type error reads as a tell - the interviewer sees someone fighting the compiler instead of using it. Write a typed helper instead. A clean groupBy is the single most reused shape in these problems, so have it in muscle memory.

function groupBy<T, K>(items: T[], keyOf: (item: T) => K): Map<K, T[]> {
  const out = new Map<K, T[]>();
  for (const item of items) {
    const k = keyOf(item);
    const bucket = out.get(k);
    if (bucket) bucket.push(item);
    else out.set(k, [item]);
  }
  return out;
}

// findDuplicates becomes two groupBy calls: by size, then by hash.
const bySize = groupBy(files, (f) => f.bytes.length);

Exhaustive unions catch your bugslet the compiler do the work

When you model a file-system node or a parse result as a discriminated union, a switch on the discriminant plus a never default makes the compiler error the moment you add a variant and forget to handle it. This is free correctness and showing it signals you write code the type system protects.

function size(node: FsNode): number {
  switch (node.kind) {
    case 'file': return node.bytes.length;
    case 'dir':  return node.children.reduce((n, c) => n + size(c), 0);
    default: {
      const _exhaustive: never = node;  // new variant -> compile error here
      return _exhaustive;
    }
  }
}

Prove correctness fastlightweight tests beat claims

You won't wire up a full test runner in 45 minutes, but a handful of inline assertions proves your edge cases work and reads as a tester's instinct. Run the empty case, the single element and the one tricky case you're worried about.

function assertEq<T>(got: T, want: T, msg: string): void {
  const a = JSON.stringify(got), b = JSON.stringify(want);
  if (a !== b) throw new Error(`${msg}: got ${a}, want ${b}`);
}

assertEq(findDuplicates([]), [], 'empty input');
assertEq(applyEdits('abc', [{ offset: 1, length: 1, text: 'X' }]), 'aXc', 'single edit');

A 45-minute mental template

1. 1Contract (2 min). Write the typed signature and a one-line constraint, restate aloud.
2. 2Brute force (5 min). Get a correct, obvious version working; name its complexity.
3. 3Optimize (15 min). Apply the size-before-hash / right-to-left / BFS insight; keep it readable.
4. 4Edge cases (8 min). Empty, single, overlapping, out-of-range - assert each.
5. 5Walk it (rest). Trace one input end to end out loud, then state what you'd test next with more time.