Occupy and Clean Memory by Allocation ID
Reported by candidates from ZipRecruiter's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The ZipRecruiter OA reported in October 2022 is a memory allocator in disguise, and the solution hinges on one small data structure: a map from allocation ID to its start index and length. Allocate carves the first k cells out of the leftmost free run that fits. Clean frees exactly what that ID owned. Sizes cap at 2000, so you don't need anything fancy. The trap is the bookkeeping, not the algorithm. If you blank on the details, StealthCoder runs invisibly during the live assessment and can hand you a working structure while you keep your head straight.
The problem
You are given a binary array memory, where 0 is free and 1 is initially occupied. Process each row in queries: [0, k]: reserve the first k cells of the leftmost free run having length at least k. A successful allocation receives and returns the next positive allocation ID; failure returns -1 and does not consume an ID. [1, id]: free exactly the cells owned by the active allocation id and return its length. Return -1 for an unknown or already-cleaned ID. Initially occupied cells belong to no allocation and cannot be cleaned. Function processMemoryAllocations(memory: int[], queries: int[][]) → int[] Examples Example 1 memory = [0,0,1,0,0] queries = [[0,2],[0,1],[1,1],[0,2]] return = [1,2,2,3] The successful allocations receive IDs 1, 2, and 3; cleaning ID 1 frees two cells. Example 2 memory = [1,0,0] queries = [[1,1],[0,3],[0,2],[1,1],[1,1],[0,3]] return = [-1,-1,1,2,-1,-1] Only the two-cell allocation succeeds. Its first cleanup frees two cells; repeated cleanup fails. Constraints 1 <= memory.length,queries.length <= 2000 memory[i] is 0 or 1. Every query has exactly two integers and follows one of the stated forms.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Brute force wins here. Keep the memory array and a hash map from ID to (start, length). For an allocate query, scan left to right, tracking the current run of zeros. When a run hits length k, mark those k cells as 1 and record the start. Take the leftmost run that fits, and note the allocation takes the first k cells of that run. Increment the ID counter only on success. For a clean query, look up the ID, set those cells back to 0, delete the entry, and return the length. A missing ID returns -1, which covers both unknown and already-cleaned. Each query is O(n), so total O(n*q), about 4 million operations. Pitfalls: consuming an ID on failure, trying to clean the initially occupied cells, and forgetting to delete the map entry. StealthCoder is the hedge if the live OA scrambles your index handling under pressure.
The honest play: practice the pattern, and have StealthCoder ready for the one you didn't see coming.
You can drill Occupy and Clean Memory by Allocation ID 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 for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play.
Get StealthCoderRelated leaked OAs
This OA pattern shows up on LeetCode as design memory allocator. If you have time before the OA, drill that.
You've seen the question.
Make sure you actually pass ZipRecruiter's OA.
ZipRecruiter reuses patterns across OAs. Built for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Occupy and Clean Memory by Allocation ID FAQ
How hard is the ZipRecruiter memory allocation OA really?+
Easy to medium. There's no clever algorithm, just careful simulation. With lengths up to 2000, an O(n) scan per query passes. Most failures come from ID handling and off-by-one errors on run boundaries, not from the core idea.
What's the trick to the allocate query?+
Scan the array once, counting consecutive zeros. The moment the count reaches k, the run's start is the current index minus k plus 1. Because you stop at the first hit, it's automatically the leftmost run that fits. Then mark those k cells as 1.
Do failed allocations consume an ID?+
No. The statement says failure returns -1 and does not consume an ID. Only increment your counter after you've confirmed a run exists. Example 2 shows this: the failed size-3 request doesn't shift the next successful ID to 2.
What data structure should I use for cleanup?+
A hash map from ID to start and length. On cleanup, look it up, zero out that range, remove the entry, and return the length. Removing the entry makes repeated cleanups return -1 automatically, with no extra flag needed.
How do I prepare for this in 48 hours?+
Write the simulation yourself once and trace both examples by hand. Watch the cases where cleanup frees cells that later allocations reuse. Then test edge cases: k larger than the array, cleanup of an unknown ID, and an initially occupied array.