Request Retry Count
Reported by candidates from IBM's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
IBM reported this one in June 2026, and it looks friendlier than it is. Request Retry Count hands you two parallel arrays and a gap, and asks how many times the same request ID shows up again within that many seconds. It's a hash map problem in disguise. With n up to 2 million, anything quadratic dies on arrival. If you've got the OA coming in a day or two, learn the one-pass idea below. StealthCoder sits invisibly as a safety net if you blank during the live assessment.
The problem
An integer gap defines the maximum allowed time difference, in seconds, to consider a retry. Two arrays are provided: requestIds, where each element represents the request ID of a log timestamps, where each element represents the time of the corresponding log, sorted in non-decreasing order A retry occurs when two consecutive logs for the same request ID have a time difference of at most gap. Compute the total number of retries across all request IDs and return the result. Function getRetryCount(gap: int, requestIds: String[], timestamps: int[]) → int Examples Example 1 gap = 10 requestIds = ["r1", "r1", "r1", "r2", "r2"] timestamps = [100, 105, 200, 300, 302] return = 2 The table below shows the total number of retries for each request ID: Request Retry TableRequest IDTimestampsRetry PairsRetry Count r1[100, 105, 200](100, 105)1 r2[300, 302](300, 302)1 The total number of retries = 1 + 1 = 2. Hence, the answer is 2. Constraints 1 ≤ gap ≤ 10^9 1 ≤ n ≤ 2 * 10^6 0 ≤ timestamps[i] ≤ 10^9
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is one pass with a hash map from request ID to the last timestamp seen for that ID. For each log, look up the previous timestamp for its ID. If it exists and the current timestamp minus the previous is at most gap, add one to the count. Then overwrite the stored timestamp with the current one. That's O(n) time and O(k) space for k distinct IDs. The brute force pairs every log against every other log, which is hopeless at 2 * 10^6. The common pitfall is reading 'consecutive' wrong. It means consecutive for the same ID, not adjacent in the array, so interleaved IDs still count. Also use the difference, not an absolute value, since timestamps are sorted. Check the example: r1 gives 100 to 105 as a retry, but 105 to 200 isn't. If you freeze on the live OA, StealthCoder can hand you this loop as a hedge.
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 Request Retry Count 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 IBM's OA.
IBM 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.
Request Retry Count FAQ
What's the trick for Request Retry Count?+
Keep a hash map of request ID to its most recent timestamp. For each log, compare against the stored value for that ID, count a retry if the difference is at most gap, then update the map. One pass, no sorting, no nested loops.
Why does brute force fail here?+
The constraints allow n up to 2 * 10^6. Comparing every pair of logs is roughly 4 * 10^12 operations, which will time out. You need a linear scan with constant-time lookups per log, which the hash map gives you.
Do I need to sort anything?+
No. Timestamps are already sorted in non-decreasing order, so each ID's logs appear in time order. The last stored timestamp for an ID is always its previous log. Sorting would only add cost and risk breaking the pairing.
Does a retry chain count multiple times?+
Yes, per consecutive pair. If an ID has logs at 100, 105 and 110 with gap 10, both 100-105 and 105-110 count, giving 2. You compare each log to the one right before it for that ID, not to the first one.
How do I prepare for this in 48 hours?+
Write the hash map loop from memory twice and test on the IBM example, expecting 2. Then try edge cases: a single log, all the same ID, and a difference exactly equal to gap. That boundary is inclusive, so use less than or equal.