Per-Client Sliding-Window Rate Limiter
Reported by candidates from General Motors's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The General Motors OA reported in August 2026 is a per-client sliding-window rate limiter, and the whole thing hinges on one boundary. A request at time t kicks out anything at or before t - windowSeconds, so a timestamp exactly on the edge is already gone. Miss that and Example 2 fails. The pattern is a hash map of client to queue, with a sliding window inside each queue. If you blank on the expiry rule mid-assessment, StealthCoder is the invisible safety net that reads the problem and hands you the logic. Otherwise, the script is below.
The problem
Process an ordered batch of requests through a per-client sliding-window rate limiter. Request i belongs to clientIds[i] and arrives at timestamps[i]. For this exercise, assume the batch is processed by one limiter in nondecreasing timestamp order. Before deciding a request at time timestamp, expire that client's accepted requests whose times are at most timestamp - windowSeconds. Accept the request when fewer than maxRequests accepted requests remain for that client. Record only accepted requests; a rejected request does not consume future capacity. Clients are independent. Requests with the same timestamp are processed in input order. Return one boolean decision for every request, in the original order. Function allowRequests(clientIds: String[], timestamps: int[], maxRequests: int, windowSeconds: int) → boolean[] Examples Example 1 clientIds = ["A","A","A","A","B"] timestamps = [0,1,2,3,3] maxRequests = 3 windowSeconds = 10 return = [true,true,true,false,true] Client A fills its window with accepted requests at times 0, 1, and 2, so its request at time 3 is rejected. Client B has independent capacity and its request is accepted. Example 2 clientIds = ["x","x","x","x","x"] timestamps = [0,0,1,3,3] maxRequests = 2 windowSeconds = 3 return = [true,true,false,true,true] The first two requests fill the window and the request at time 1 is rejected without consuming capacity. At time 3, both accepted requests from time 0 are exactly at the expiration boundary and leave the window before the two new requests are processed. Constraints 1 <= clientIds.length <= 100000. clientIds.length == timestamps.length. Each client ID is a nonempty printable ASCII string of length at most 50. 0 <= timestamps[i] <= 10^9. timestamps is nondecreasing. 1 <= maxRequests <= 100000. 1 <= windowSeconds <= 10^9.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Keep a hash map from clientId to a deque of accepted timestamps. For each request, pop from the front while the front is <= timestamp - windowSeconds. Then if the deque size is below maxRequests, push the timestamp and output true. Otherwise output false and push nothing. The pitfalls are all small. Using < instead of <= on expiry breaks the boundary case in Example 2. Pushing rejected requests inflates the window and wrongly blocks later calls. Scanning the whole list per request turns it into O(n^2) at 100000 requests. Since timestamps are nondecreasing, each timestamp is pushed and popped at most once, so total work is O(n). If the logic slips under pressure, StealthCoder is the hedge during the live OA, but this one is short enough to hold in your head.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Per-Client Sliding-Window Rate Limiter cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass General Motors's OA.
General Motors reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Per-Client Sliding-Window Rate Limiter FAQ
What's the trick in the General Motors rate limiter problem?+
Expiry is inclusive. Before deciding a request, drop every accepted timestamp that is at most timestamp - windowSeconds. Then compare the remaining count to maxRequests. Also, only accepted requests get recorded. Rejections cost nothing and never extend the window.
What data structure should I use?+
A hash map from clientId to a queue or deque of accepted timestamps. Because input timestamps are nondecreasing, the oldest entry is always at the front, so expiring is just popping from the front. No sorting or heaps needed.
What's the time complexity I should aim for?+
O(n) overall. Each accepted timestamp is added once and removed at most once, so the amortized cost per request is constant. With up to 100000 requests, anything that rescans a client's full history per request risks being too slow.
How hard is this really?+
Easy to medium. The idea is simple, but the boundary condition and the rule that rejected requests don't count are where people lose points. Trace both examples by hand before submitting, especially the time 3 case in Example 2.
How do I prepare for this in 48 hours?+
Write this limiter from scratch twice, once per client with a deque and once with a plain list and a start pointer. Then test edge cases: equal timestamps, a request exactly on the boundary, maxRequests of 1, and many distinct clients.