High-Traffic IPs in a Sliding Window
Reported by candidates from Google's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Google reported this one in September 2026, and the detail that matters is the half-open window (t - windowSeconds, t]. A request exactly windowSeconds old is out. That single boundary decides whether your answer matches Example 2. The task is a per-IP sliding window over a sorted timestamp stream, then a lexicographically sorted list of offenders. You have an OA coming and need the pattern fast. It's a hash map of queues with eviction, nothing more exotic. If you blank on the eviction condition live, StealthCoder is the invisible safety net that reads the problem and hands you the working code.
The problem
You receive a chronological stream of server requests. The arrays timestamps and ipAddresses describe the same requests, and timestamps[i] is the integer arrival time of ipAddresses[i]. For each IP address, consider every sliding window of the form (t - windowSeconds, t] whose right endpoint t is one of that IP address's request timestamps. An address is high traffic if at least one such window contains strictly more than requestThreshold requests from that address. Return every high-traffic IP address exactly once, sorted in lexicographic order. Requests with the same timestamp are all inside the same active window. Process the requests in chronological order without rescanning the full history for every request. Function findHighTrafficIps(timestamps: int[], ipAddresses: String[], windowSeconds: int, requestThreshold: int) → String[] Examples Example 1 timestamps = [1,2,3,12,13] ipAddresses = ["10.0.0.1","10.0.0.1","10.0.0.1","10.0.0.1","10.0.0.2"] windowSeconds = 10 requestThreshold = 2 return = ["10.0.0.1"] At timestamp 3, the window (-7, 3] contains three requests from 10.0.0.1, which is strictly more than the threshold of two. Example 2 timestamps = [0,10,10,20] ipAddresses = ["x","x","y","x"] windowSeconds = 10 requestThreshold = 1 return = [] A request exactly windowSeconds before the current timestamp is outside the half-open window. No IP has more than one request in any active window. Constraints 0 <= timestamps.length == ipAddresses.length <= 200000. 0 <= timestamps[i] <= 10^9, and timestamps is sorted in nondecreasing order. Every IP address is a non-empty string of at most 64 visible ASCII characters. 1 <= windowSeconds <= 10^9. 1 <= requestThreshold <= max(1, timestamps.length).
Reported by candidates. Source: FastPrep
Pattern and pitfall
Keep a hash map from IP to a deque of its recent timestamps. For each request in order, push the timestamp onto that IP's deque, then pop from the front while front <= t - windowSeconds. If the deque size is now strictly greater than requestThreshold, add the IP to a result set. Each timestamp enters and leaves once, so it's O(n) plus the final sort of the distinct IPs. The classic pitfall is the boundary. Use <= when evicting, not <, or Example 2 breaks. Duplicate timestamps are fine because you push before checking, so all same-time requests count together. Another trap is rescanning history per request, which the statement forbids and which times out at 200000 entries. Use a set so each IP appears once. If the eviction logic slips under pressure, StealthCoder is the hedge during the live OA.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill High-Traffic IPs in a Sliding Window 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. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Google's OA.
Google reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
High-Traffic IPs in a Sliding Window FAQ
What's the trick in the Google high-traffic IPs problem?+
Per-IP deque with eviction. Add the new timestamp, drop everything at or before t - windowSeconds, then check if the size exceeds requestThreshold. Collect flagged IPs in a set and sort at the end. It's a sliding window grouped by key.
How do I get the window boundary right?+
The window is (t - windowSeconds, t], open on the left. A timestamp equal to t - windowSeconds is expired. Evict with front <= t - windowSeconds. Example 2 tests exactly this: the request at 0 is outside the window at 10.
Do I need a deque or can I use two pointers?+
Either works. Group timestamps by IP into lists, then run a two-pointer window on each list. Or use a deque per IP while streaming. Both are linear. The deque version matches the statement's chronological processing hint more directly.
What's the time complexity I should aim for?+
O(n) for the window work since each request is added and removed once, plus O(k log k) to sort the k flagged IPs. With up to 200000 requests, anything that rescans history per request is too slow.
How do I prepare for this in 48 hours?+
Write the per-key deque solution from scratch once, then test both examples by hand. Check the equal-timestamp case and the boundary case. Also confirm you return a sorted, deduplicated list, and handle the empty input returning an empty array.