← Back to Directory

Cursor interview notes, page 1 of 2

Small

Screna has 14 Cursor interview write-ups. The most reported round is the technical phone screen (9).

14 interview notes · updated Jul 2026

Cursor·Software Engineer·Technical Phone Screen

Apr 2026
Cursor SE interview that went deep on cryptographic data structures. The whole session was basically one long Merkle tree implementation with a lot of follow-up questions baked in. Not a bad experience but I underestimated how much they'd push on the security angles.
  • Implement a Merkle tree from scratch given a list of data blocks. You need to support building the tree, returning the root hash, generating an inclusion proof for a leaf at a given index, and verifying that proof.
  • How do you handle an odd number of leaves when building the Merkle tree?
  • What hash function would you choose and how would you protect against second-preimage attacks in a Merkle tree?
  • What is the time and space complexity for building the tree, generating a proof, and verifying a proof?

“I started with the build function and got through it okay, hashing leaves then pairwise hashing up.”

View Post

Cursor·Backend Engineer·Technical Phone Screen

Apr 2026
Cursor backend interview, one coding round, one problem the whole time. The question looks clean on paper but there are enough edge cases to keep you busy for a while.
  • Implement a rate limiter function that takes a user ID and a timestamp and returns whether the notification attempt should be allowed. The system enforces sliding-window limits over the past 10 minutes at three levels simultaneously: per user (max 3), per team (max 10), and per company (max 20). Allowed requests must be recorded immediately; denied ones must not. Timestamps are integers in seconds and arrive in non-decreasing order. Be ready to walk through test cases and discuss complexity.

“I went straight to a deque-per-entity approach, one deque each for user, team, and company, and prune entries older than 600 seconds before checking counts.”

View Post

Cursor·Software Engineer·Technical Phone Screen

May 2026
Cursor SWE interview that was basically one meaty coding problem: build a Merkle tree over a real filesystem and use it to diff two repo snapshots. Felt more like a systems design exercise dressed up as a coding question, which I wasn't fully prepared for.
  • Implement a Merkle tree over a real directory structure on disk, where files are leaf nodes and folders are internal nodes, then use it to compute which files changed between two filesystem snapshots. The API requires a constructor that builds the tree from a root path and a diff method that returns a list of relative file paths with their change types (added, modified, or removed).

“The hashing part clicked pretty fast for me: SHA the file contents for leaves, then for directories sort children by name and hash the concatenation of name+child_hash pairs.”

View Post

Cursor·Software Engineer·Technical Phone Screen

May 2026
Cursor technical phone screen for a software engineer role. The main problem was designing a Merkle tree over a git-style repository so a client and server can sync state by exchanging hashes instead of file contents. Dense question for a one-hour slot.
  • Design a Merkle tree over the contents of a cloned repository. Walk through the data model, how you'd construct it, how updates propagate, and what the client/server sync protocol looks like.
  • Should directory names factor into the internal node hashes, or only file paths and file contents?
  • How would you handle incremental updates when a single file changes, rather than rebuilding the whole tree?
  • How would the sync protocol handle a very large repository that doesn't fit in memory?
  • What would change in your design if files can be renamed?
  • How would you test that your hashing is deterministic across different platforms or operating systems?

“This is a lot to cover in an hour.”

View Post

Cursor·Software Engineer·Technical Phone Screen

May 2026
Cursor SWE interview that was heavier on systems thinking than I expected. The main problem sounds deceptively like a data structures exercise but it really tests whether you can reason about real filesystems and design around actual constraints.
  • Implement a Merkle tree that mirrors a real directory structure on disk, where each directory is an internal node and each file is a leaf. You can only use standard library functions to read files and compute hashes.
  • Given two snapshots of the same repository, produce a diff showing which files were added, modified, or removed.
  • How would you efficiently handle large directories to avoid rehashing unchanged subtrees when comparing two snapshots?
  • How would you handle edge cases like symlinks, empty directories, and binary files in your implementation?

“The textbook Merkle tree is always binary, so my first instinct was to go that route.”

View Post

Cursor·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at Cursor for a software engineer role. The whole thing was basically one big question that kept expanding, starting from a rate limiter and then getting pushed into distributed systems territory fast.
  • Design a distributed rate-limiting system that supports hierarchical scopes (user, team, company), including the API surface, storage layer, and how it behaves across multiple service nodes.
  • Compare sliding window counters, token buckets, and leaky buckets for rate limiting. What are the tradeoffs and which would you pick here?
  • How do you handle Redis outages in a rate limiter? Walk through the tradeoffs of different failure strategies.
  • How would you scale this rate limiter to millions of users while keeping p99 latency under 5ms?

“Started with the API and felt okay there.”

View Post

Cursor·Software Engineer·Technical Phone Screen

May 2026
Cursor SWE interview with a meaty coding problem around rate limiting. The core task was implementing a sliding window notification gate across three hierarchy levels simultaneously, plus writing and manually tracing through your own test cases.
  • Implement a function `should_send_notifications(user_id, timestamp)` that returns true or false based on a hierarchy of rolling-window rate limits: at most 3 per user, 10 per team, and 20 per company, all within a 10-minute window. The user-to-team-to-company mapping is provided. If the notification is allowed, record it and return true; otherwise return false. Also write real test cases and trace through them by hand.

“The per-entity sliding window part clicked pretty fast for me, keep a list of timestamps per user/team/company and prune anything older than 10 minutes on each call.”

View Post

Cursor·Software Engineer·Technical Phone Screen

May 2026
Cursor SWE interview that was basically an OOD exercise disguised as a systems question. You build an in-memory key-value store with transactions, then they start layering on concurrency problems until things get uncomfortable.
  • Design and implement an in-memory transactional key-value database. Your class should support beginning a transaction, getting and setting values within a transaction, and committing or rolling back.
  • Two transactions try to write to the same key at the same time. How do you handle that write-write conflict?
  • Consider two transactions doing a swap: tx1 reads key A and writes it to key B, tx2 reads key B and writes it to key A. If both commit, the swap is a no-op. How do you detect and abort one of them?

“The skeleton they gave was pretty clean so I didn't waste time on structure.”

View Post

Cursor·Software Engineer·Recruiter / HR Screen

May 2026
Applied for a SWE role at Cursor and got asked the classic motivation question. Not much else to go on here.
  • Why do you want to work at Cursor?

“Pretty standard opener but I fumbled it a bit.”

View Post

Cursor·Software Engineer·Onsite - Coding / Algorithms

Jun 2026
Interviewed for a SWE role at Cursor and got asked to build a hash tree algorithm. Pretty sparse on details but it was clearly a technical coding round.
  • Implement a hash tree (Merkle tree) algorithm from scratch.

“Not something I'd drilled recently.”

View Post