Ramp·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Jul 2026

Summary

Ramp coding round for a software engineer position. The main problem was a rate limiter variant, which sounds straightforward until you actually sit with the edge cases around rejected requests not counting toward the limit.

Questions Asked (1)

Given sorted request timestamps, IP addresses, a request limit, and a time window length, return an array indicating whether each request is accepted or rejected. Each IP can have at most `limit` accepted requests within any window of the given length, and rejected requests don't count toward future limits.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

The rejected-requests-don't-count part is what trips people up, me included for a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Use a sliding window approach with a hash map that tracks accepted request timestamps per IP address, maintaining a deque or list of accepted timestamps to efficiently check and enforce the rate limit within any rolling time window. Since timestamps are sorted, you can process requests sequentially and prune stale timestamps outside the window as you go. Emphasize that only accepted requests count toward the limit, which is a critical constraint that simplifies the counting logic.

Pro tip: Explicitly call out the 'rejected requests don't count' rule early — this is a deliberate design choice that mirrors real-world rate limiting (e.g., Ramp's own API infrastructure), and acknowledging it shows you read requirements carefully and understand the product implications of fairness in rate limiting.

1. Clarify Constraints & Edge Cases

Confirm input assumptions: are timestamps guaranteed sorted globally or per-IP? Ask about edge cases like duplicate timestamps, empty input, or limit=0. This demonstrates thoroughness before writing any code.

2. Choose the Right Data Structure

Use a hash map from IP address to a deque (or list) of accepted request timestamps. The deque allows O(1) removal from the front when timestamps fall outside the time window, keeping the solution efficient.

3. Implement the Sliding Window Logic

For each incoming request, first evict all timestamps from the front of that IP's deque that fall outside the window (i.e., timestamp < current_timestamp - window_length). Then check if the deque's size is less than the limit to decide accept or reject.

4. Handle the Accept/Reject Decision

If accepted, append the current timestamp to the deque and record 'accepted' in the result array; if rejected, do NOT append the timestamp (since rejected requests don't count), and record 'rejected'. This is the key invariant to maintain.

5. Analyze Complexity & Discuss Trade-offs

State that time complexity is O(n) amortized since each timestamp is added and removed from a deque at most once, and space is O(n) in the worst case. Discuss how this approach scales and how it compares to alternatives like token bucket or fixed window counters.

Key Points to Mention

Sliding window vs. fixed window: explain why a sliding window is more accurate and fair, avoiding boundary burst issues that fixed windows suffer from
Rejected requests are excluded from the count — this must be enforced by only appending to the deque on acceptance, not on every request
Deque-based pruning: since timestamps are sorted, stale entries are always at the front, making eviction O(1) amortized per request
Hash map keyed by IP to independently track state for each client, enabling O(1) average-case lookup
Real-world relevance: mention how this mirrors production rate limiting systems (e.g., API gateways, financial platforms like Ramp) where fairness and accuracy matter
Potential extensions: discuss how you'd adapt this for distributed systems (e.g., Redis-backed sliding window with atomic operations) to show system design awareness

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