USA | Cursor (Anysphere) | Technical Phone Screen
Summary
I completed and passed a technical phone screen for Cursor (Anysphere) where I was tasked with designing and implementing a flexible rate limiter system. I received a positive follow-up an hour later and moved to the next round.
Full Experience
Completed and passed technical phone screen for Cursor. Anysphere is the parent company that develops Cursor (the AI editor that you use)
Reflection
-
Goal from the interviewer was to get a working solution. Don't overindex on time and space complexity optimization
-
First part was pretty straightforward in terms of implementing the provided stub. Just use the simple way
-
Second part required some thinking and I ended up going with an interface and 2 concrete classes to support the types of rate limits developer want. I got like 95% of the way through and had the primitives ready. I just didn't get time ot add all the initializations in the main function, but interviewer wasn't too concerned about that. They cared about how I'd run the main function on all the rate limiters and decide allow or deny.
-
I received followup in an hour after the interview and moved to next round
-
Keep communicating your thoughts to the interviewer and involve them like a stakeholder
Interview Questions (1)
Design a Flexible Rate Limiter System
Cursor has experienced a rapid growth in developers using the completions API and other endpoints. We are building a rate limiter
You have a list of data (in memory for now) of the form [user_id, request_url, body_size (bytes), timestamp (seconds)] and need to complete the below tasks
Task 1: Enforce a rate limit for one endpoint
Enforce a rate of 3 requests/second for the v1/completions/standard endpoint. Do not count "denied requests" for the calculation. Other endpoints do not have a rate limit enforced this iteration
Rate limits are enforced on the per user basis. Read the problem requirement to understand why!
Task 2: Rate Limiter Interface
Suppose that 10 other developers come to you to build a rate limiter for their endpoints. You need to extend your interface to support patterns like this:
- Rate limit the
v1/completions/chunkedendpoint at 7 requests/minute - Allow 5 requests/second to the
v2/completions/chunkedendpoint - Allow requests to the
v1/completions/chunkedendpoint if the total request byte size doesn't exceed 100 in the past minute - Allow 7 requests/hour total across all endpoints
- The rate limit rule from task 1
If all the above checks are satisfied, then you count that request. If even one is denied, don't process and don't count for the calculation