← Reddit Interview Insights

Reddit·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jun 2026

Summary

Reddit system design phone screen for a software engineer role. The problem was a rate limiter with a sliding window, which sounds straightforward until you're actually in it and someone's watching you think out loud.

Questions Asked (1)

Q1

Design and implement an in-memory rate limiter using a sliding time window. The API should expose an allow(key, timestamp) method that returns whether a given request is permitted, enforcing at most N requests per W seconds per key.

System DesignAlgorithms & Data StructuresTechnical Trade-offs
Author's notes

I went straight to a queue-per-key approach, storing timestamps and evicting anything outside the window on each call.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., exact vs. approximate sliding window, memory constraints, concurrency). Then describe a data structure like a deque per key to store timestamps, and explain the allow algorithm: remove expired timestamps, check count, and add new timestamp if allowed. Finally, discuss trade-offs (memory vs. accuracy) and potential optimizations like bucketing or Redis for distributed systems.

Pro tip: Mention that you'd use a lock per key to handle concurrency, and consider using a ring buffer or circular array to bound memory usage. Also, proactively discuss how you'd handle clock skew and timestamp precision.

1. Clarify requirements and constraints

Ask about expected throughput, memory limits, whether the window is exact or approximate, and if the system is single-threaded or concurrent.

2. Choose data structures

Propose a hash map from key to a deque (or queue) of timestamps. Explain that the deque stores timestamps of allowed requests in the current window.

3. Design the allow algorithm

For a given key and timestamp, remove timestamps older than timestamp - W from the deque. If the deque size is less than N, add the timestamp and return true; else return false.

4. Address concurrency and memory

Discuss using locks (e.g., per-key mutex) to ensure thread safety. Mention memory cleanup for inactive keys and bounded memory via circular buffers.

5. Discuss trade-offs and extensions

Compare exact sliding window with approximate methods (e.g., sliding window counters). Mention distributed rate limiting using Redis sorted sets or similar.

Key Points to Mention

  • Time complexity: O(1) amortized per request if using deque with timestamp removal.
  • Space complexity: O(N) per key, but can be optimized with bucketing.
  • Concurrency: use per-key locks or lock-free structures to avoid contention.
  • Memory management: evict inactive keys to prevent unbounded growth.
  • Trade-offs: exact sliding window uses more memory; approximate methods (e.g., token bucket) are more memory-efficient but less precise.
  • Distributed systems: use Redis sorted sets with ZREMRANGEBYSCORE and ZCARD for a scalable solution.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.