Backend coding interview
Rate Limiter Coding Interview Problem
What this interview round tests
Rate limiting is one of the most common backend interview rounds because almost every real API needs it, and it exposes exactly the skills interviewers care about: correct time-based accounting, safe concurrency, and clean handling of edge cases. It shows up for SDE1 and SDE2 backend roles at companies that run high-traffic services.
Unlike an algorithm puzzle, a good rate-limiter round is really about correctness under pressure — can your implementation admit exactly the right number of requests when many callers hit the same client bucket at the same instant, and does it stay fair between clients?
The scenario
You’re maintaining a backend service that fronts a public API. Each client is allowed a fixed budget of requests over time, enforced by a token-bucket policy: tokens refill continuously at a configured rate up to a capacity, and a request is admitted only when at least one token is available.
The service already has the shape of a rate limiter, but it misbehaves under load. When many requests race against the same bucket, it admits more than it should. One noisy client can starve others. Timestamps that arrive equal or slightly out of order corrupt the token count. Your job is to make the enforcement correct and safe.
What you’ll practice
- Token bucket and sliding-window rate-limiting mechanics
- Making refill → check → consume a single atomic critical section
- Concurrency: guarding shared state so 20 racing requests admit exactly the capacity
- Per-client isolation so one client cannot drain another’s budget
- Time-based accounting: clamping to capacity and handling equal or backward timestamps
- API correctness and edge cases: computing a correct retry-after and validating policy config
How to approach it
Think about the unit of contention: every admit decision for a given client must read tokens, refill based on elapsed time, and consume — all without another caller observing the same last token. That means one atomic critical section per bucket, not a shared global lock that serialises unrelated clients.
Key each bucket by its scope and client so budgets are isolated, and lazily create a lock per bucket. Refill should only add tokens when real time has advanced, clamp to capacity, and never let a backward clock drain tokens. Validate configuration up front so bad policies fail loudly rather than silently mis-enforcing.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Is this a token bucket or sliding window problem?
The core policy is a continuously-refilling token bucket, which is the pattern most production APIs use. The concepts transfer directly to sliding-window questions — both hinge on correct time-based accounting and safe concurrent access.
What makes rate limiting hard in an interview?
The tricky part is not the formula, it’s correctness under concurrency and messy time. Interviewers watch whether you make the refill-check-consume step atomic per client, isolate clients, and handle equal or out-of-order timestamps without corrupting the count.
Do I need to write everything from scratch?
No. Like a real job, you start from an existing repository with a failing test suite and fix the enforcement logic, then run the bundled verify script locally until the tests pass.