Batch API Requests with Retry Delays
Reported by candidates from Decagon's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Decagon OA reported in September 2026 looks like a plain batching task, then punishes you on ordering. You dispatch up to five eligible requests per batch, failed ones come back after a delay, and the output has to match exactly. It's a simulation with a priority queue underneath. If you've got an invite for the next day or two, read the edge case below first. StealthCoder is the invisible fallback if the ordering logic slips away mid-assessment.
The problem
You are given request IDs, the number of failed attempts each request will produce before succeeding, and a fixed retry delay for each request. All requests are initially eligible at logical time 0. Repeatedly dispatch a batch containing the first at most five eligible unfinished requests in original input order. A failed attempt reduces that request's remaining failure count and makes it eligible again at currentTime + retryDelay; a successful attempt completes it. If no request is eligible, jump to the smallest next eligibility time. Return one line per batch as time:id1,id2,.... Multiple batches may occur at the same time when more than five requests are eligible. Function scheduleRequestBatches(requestIds: String[], failuresBeforeSuccess: int[], retryDelays: int[]) → String[] Examples Example 1 requestIds = ["a","b"] failuresBeforeSuccess = [1,0] retryDelays = [5,1] return = ["0:a,b","5:a"] b succeeds immediately; a fails once and returns at time 5. Example 2 requestIds = ["a","b","c","d","e","f"] failuresBeforeSuccess = [0,0,0,0,0,0] retryDelays = [1,1,1,1,1,1] return = ["0:a,b,c,d,e","0:f"] The six initially eligible requests require two batches at time 0. Constraints 1 <= requestIds.length <= 10^4; all three arrays have the same length. IDs are unique and contain no colon or comma. Failure counts are nonnegative; retry delays are positive.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is that eligible requests must be dispatched in original input order, not in the order they became eligible. So a plain FIFO queue is wrong. Keep a min-heap of (eligibleTime, index) for requests waiting on a delay, and a second min-heap of indices for requests that are eligible right now. At each step, move everything with eligibleTime <= currentTime into the eligible heap, then pop up to five smallest indices. That's the batch. The edge case: when more than five are eligible, several batches happen at the same time, and the clock must not advance between them. Also, a request that fails in this batch returns at currentTime + delay, which is strictly later because delays are positive, so it can't rejoin the same batch. If the eligible heap is empty, jump currentTime to the smallest waiting time. Pitfalls are sorting by ID string and advancing time after every batch. StealthCoder can cover you live if the two-heap structure won't come to you.
StealthCoder is the hedge for the one pattern you didn't drill. It runs invisibly during the screen share.
You can drill Batch API Requests with Retry Delays 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. If you're reading this with an OA window open, you're who this was built for.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Decagon's OA.
Decagon reuses patterns across OAs. If you're reading this with an OA window open, you're who this was built for. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Batch API Requests with Retry Delays FAQ
What's the trick in the Decagon batch retry problem?+
Use two heaps. One holds waiting requests keyed by eligibility time. The other holds currently eligible requests keyed by original input index. Each batch pops the five smallest indices. Ordering by input position, not by when they became eligible, is what trips most people.
Why does a simple queue fail here?+
A queue orders by arrival into eligibility. The problem demands original input order among eligible requests. A retried request with an early index must jump ahead of later requests that became eligible before it. A min-heap on index handles that correctly.
Can multiple batches share the same timestamp?+
Yes. If more than five requests are eligible at time t, you emit several lines with the same time. Don't advance the clock after a batch. Only jump time forward when the eligible heap is empty and you need the next waiting request.
How do I handle the time jump when nothing is eligible?+
Peek at the waiting heap and set currentTime to its smallest eligibility time. Then move every request with eligibility time at or below that into the eligible heap. Skipping that step is the usual cause of an infinite loop or a missed batch.
How do I prep for this in 48 hours?+
Write the two-heap simulation once from scratch and test both examples. Add a case with seven eligible requests and a retry that lands between batches. With n up to 10^4, heap operations are plenty fast, so focus on correct output formatting.