AO
AceOffer

Cursor Interview Process & Rounds

Cursor's process runs one round at a time: each round is scheduled only after you pass the one before, so it can take weeks. The first round is almost always a coding screen of 45 to 60 minutes: build a Merkle tree, which reports also call a hash tree, over a real repository, then diff two trees and use the tree to sync a client and a server. Ten reports describe it, and several candidates say it is hard to finish in time without having written it before. One report allowed Google or AI for syntax but not for the implementation. A second coding screen has been either a notification rate limiter with user, team and company limits, or an in-memory transactional key-value store, on CoderPad, with follow-ups that depend on what you built. Later rounds reported include system design (a job scheduler, or storing and syncing IDE settings), a project deep dive and a hiring-manager conversation; one candidate's phone-screen stage had all four, which they called the longest phone screen they had seen. The final stage is working in Cursor's office alongside the team: two days in earlier reports, one day for some teams in 2026, and candidates say each team sets its own problems. Two reports come from Graphite, the code review startup Cursor acquired: a bug-fixing round on a parser and an internationalisation design.

Part of the full catalog of Cursor interview questions, covering every round.

Key facts

  • •2 distinct round types
  • •6 questions reconstructed from 18 candidate reports
  • •Reports span May 2025 – Sep 2026
  • •Refreshed monthly · last updated October 2026

The Cursor loop, from candidate reports

Cursor's process runs one round at a time: each round is scheduled only after you pass the one before, so it can take weeks. The first round is almost always a coding screen of 45 to 60 minutes: build a Merkle tree, which reports also call a hash tree, over a real repository, then diff two trees and use the tree to sync a client and a server. Ten reports describe it, and several candidates say it is hard to finish in time without having written it before. One report allowed Google or AI for syntax but not for the implementation. A second coding screen has been either a notification rate limiter with user, team and company limits, or an in-memory transactional key-value store, on CoderPad, with follow-ups that depend on what you built. Later rounds reported include system design (a job scheduler, or storing and syncing IDE settings), a project deep dive and a hiring-manager conversation; one candidate's phone-screen stage had all four, which they called the longest phone screen they had seen. The final stage is working in Cursor's office alongside the team: two days in earlier reports, one day for some teams in 2026, and candidates say each team sets its own problems. Two reports come from Graphite, the code review startup Cursor acquired: a bug-fixing round on a parser and an internationalisation design.

What does Cursor ask in each round?

Cursor interviews span 2distinct round types, shown below. Counts reflect distinct questions per round across the loops we’ve indexed.

Coding screens of 45 to 60 minutes. The first is a Merkle tree over a real repository: get_hash, diff, then client/server sync. A second screen has been a user, team and company notification rate limiter with pluggable rules, or an in-memory transactional key-value store with concurrency follow-ups.
3 questions
Most-reported: Merkle Tree over a Repository: Hash, Diff and Sync (10 reports)
A job scheduler introduced as CI/CD (triggering scheduled jobs, the task queue and workers, worker failure), storing and syncing IDE settings for users and teams (versioning, reconnects), and, at Graphite, internationalising a large website.
3 questions
Most-reported: Design a Distributed Cron / Job Scheduler (2 reports)
What passing candidates do
  • •Writing a file-system Merkle tree before the interview. Candidates say the screen is hard to finish in 60 minutes otherwise, and one who had written file-system code before finished their part.
  • •Settling the interface first. One candidate advises modelling the diff as added, modified and removed from the start and pinning down the class signatures, after their own comparison ran out of time.
  • •Keeping new rules out of the core code. In the rate limiter's second part, one candidate added a register_handler so each new rule is its own handler.
  • •Clarifying throughout. A candidate who passed the first screen gave one piece of advice for the second: practise and keep clarifying.
Where candidates lose points
  • •Not finishing the diff in the Merkle-tree screen, which leaves no time for the follow-ups.
  • •Running out of time before an extension: one rate-limiter candidate failed because the design part was not complete.
  • •Assuming a complete solution is enough. A candidate who finished the part they were given, with tests and one or two small bugs fixed, was still rejected and believes the bar is a fast, uninterrupted run.
  • •Not knowing Python's file-system library. One candidate says anyone who has not used it will not finish the Merkle tree.

FAQ

How many rounds is the Cursor interview?▾
Cursor's loop spans 2 round types: Coding screens of 45 to 60 minutes. The first is a Merkle tree over a real repository: get_hash, diff, then client/server sync. A second screen has been a user, team and company notification rate limiter with pluggable rules, or an in-memory transactional key-value store with concurrency follow-ups., A job scheduler introduced as CI/CD (triggering scheduled jobs, the task queue and workers, worker failure), storing and syncing IDE settings for users and teams (versioning, reconnects), and, at Graphite, internationalising a large website..
What is the Cursor interview process?▾
Cursor's process runs one round at a time: each round is scheduled only after you pass the one before, so it can take weeks. The first round is almost always a coding screen of 45 to 60 minutes: build a Merkle tree, which reports also call a hash tree, over a real repository, then diff two trees and use the tree to sync a client and a server. Ten reports describe it, and several candidates say it is hard to finish in time without having written it before. One report allowed Google or AI for syntax but not for the implementation. A second coding screen has been either a notification rate limiter with user, team and company limits, or an in-memory transactional key-value store, on CoderPad, with follow-ups that depend on what you built. Later rounds reported include system design (a job scheduler, or storing and syncing IDE settings), a project deep dive and a hiring-manager conversation; one candidate's phone-screen stage had all four, which they called the longest phone screen they had seen. The final stage is working in Cursor's office alongside the team: two days in earlier reports, one day for some teams in 2026, and candidates say each team sets its own problems. Two reports come from Graphite, the code review startup Cursor acquired: a bug-fixing round on a parser and an internationalisation design.
How fresh is this Cursor interview data?▾
It's reconstructed from candidate reports spanning May 2025 – Sep 2026 and refreshed monthly as new reports come in.

Get the full Cursor catalog

Every question, every candidate-reported follow-up, and what passers actually do. Monthly refresh.

See pricing← All Cursor interview questions
Is this helpful?