Leftmost Memory Block Allocator
Reported by candidates from Capital One's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Capital One reported this one in August 2026, and it looks fancier than it is. Strip the allocator vocabulary and it's a simulation over a binary array: find the leftmost run of x zeros, flip it, remember where it went, and flip it back on erase. With memory and queries both capped at 2000, nothing clever is required. If the OA clock has you rattling and you blank on the bookkeeping, StealthCoder runs invisibly as a safety net during the live assessment.
The problem
You are given a binary array memory. A value of 0 means that the corresponding memory unit is free, and a value of 1 means that it is occupied. Process the two-element rows of queries in order while maintaining the current memory state: [0, x] allocates x consecutive units. Find the smallest start index s such that every unit from s through s + x - 1 is free. If such a block exists, mark it occupied, assign it the next allocation ID, and output s. Allocation IDs start at 1 and increase only after successful allocations. If no block fits, output -1 and do not consume an ID. [1, id] erases an active allocation. Free exactly the units owned by id and output the allocation's length. If id does not exist or has already been erased, output -1. Units that are occupied in the initial memory array do not belong to any allocation ID and cannot be erased by a query. Return one output for every query, in the same order as the queries. Function processMemoryQueries(memory: int[], queries: int[][]) → int[] Examples Example 1 memory = [0,0,1,0,0] queries = [[0,2],[0,1],[1,1],[0,2]] return = [0,3,2,0] The first allocation occupies indices 0 and 1 and receives ID 1. The second allocation occupies index 3 and receives ID 2. Erasing ID 1 frees two units. The final allocation then uses the leftmost free block, starting at index 0. 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] The first erase is invalid because no allocation exists yet. Allocating three units fails because index 0 was initially occupied, so no ID is consumed. Allocating two units succeeds at index 1 with ID 1. Its first erase returns length 2; the repeated erase returns -1. The initial occupied unit remains unavailable, so the final allocation also fails. Constraints 1 <= memory.length <= 2000 memory[i] is 0 or 1. 1 <= queries.length <= 2000 Every row in queries contains exactly two integers. queries[i][0] is 0 or 1. For [0, x], 1 <= x <= memory.length. For [1, id], 1 <= id <= queries.length.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The reduction: a leftmost-fit scan plus a map from allocation ID to (start, length). For each allocate query, walk the array counting consecutive zeros. When the count hits x, the start is i - x + 1. Mark those cells 1, store the record under the next ID, and increment the ID counter only on success. For erase, look up the ID. If it's missing or already deleted, output -1. Otherwise zero out exactly its range, delete the record, and output the length. Worst case is 2000 queries times 2000 cells, about 4 million operations, which is fine. The pitfalls are all state bugs. Don't burn an ID on a failed allocation. Don't let erase touch the initial 1s, since they have no ID. Reset the zero counter whenever you hit a 1. StealthCoder is the hedge if you blank on the live OA, but the logic here is short enough to hold in your head.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Leftmost Memory Block Allocator 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 passed his OA cold and still thinks the filter is broken.
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 Capital One's OA.
Capital One reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Leftmost Memory Block Allocator FAQ
What's the trick in the Capital One memory allocator problem?+
There isn't a hidden trick. It's a simulation. Scan for the first run of x zeros, mark it occupied, and store start and length in a map keyed by allocation ID. Erase reads that map and clears the range. Brute force is fast enough.
Is brute force actually fast enough here?+
Yes. Memory length and query count are both at most 2000, so a linear scan per query is about 4 million steps total. You don't need a segment tree or interval structure. Save that complexity for a version with much bigger limits.
When does the allocation ID increment?+
Only after a successful allocation. If the request returns -1 because no block fits, the next success still gets the same ID. Example 2 shows this: the failed 3-unit request doesn't consume ID 1, so the next successful allocation is ID 1.
What edge cases break most solutions?+
Erasing an ID that never existed, erasing the same ID twice, and trying to erase the initial occupied cells. Initial 1s have no ID, so they stay occupied forever. Also reset your zero-run counter on every 1 while scanning.
How do I prepare for this in 48 hours?+
Write it once from scratch with a dictionary for allocations and a simple scan. Then test both examples by hand. Practice similar simulation problems where state updates must be exact. Focus on clean bookkeeping, not fancy data structures.