Implement Malloc
Reported by candidates from Nvidia's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Nvidia OA reported in September 2026 asks you to build a toy malloc. Simulate a heap, handle ALLOC and FREE, and don't blow up on edge cases. The constraints are tiny, 200 commands and a 10^4 byte heap, so nobody's asking for a clever data structure. They're checking whether you can keep a free list consistent under splits and merges. It's a design problem wearing a simulation costume. If you blank on the coalescing logic mid-assessment, StealthCoder is the invisible safety net that reads the screen and hands you a working structure.
The problem
Simulate a heap of heapSize bytes that starts as one free block at offset 0. Process commands in order. Each command is one of: ALLOC x: reserve a block of x bytes after rounding x up to the next multiple of 8. Choose a best-fit free block (the smallest free block that can hold the rounded size). Break ties by choosing the lowest start offset. Split any leftover tail back into the free list. Return that start offset, or -1 if no free block is large enough. FREE offset: release the live allocation that starts at offset. Adjacent free blocks must coalesce into one free block. A FREE of an unknown or already-freed offset is a no-op. Return the list of ALLOC results in command order. FREE commands do not produce an output value. Function processMallocCommands(heapSize: int, commands: String[]) → int[] Examples Example 1 heapSize = 32 commands = ["ALLOC 8","ALLOC 16","FREE 0","ALLOC 8"] return = [0,8,0] ALLOC 8 takes offset 0. ALLOC 16 takes offset 8. FREE 0 reopens [0, 8). The next ALLOC 8 fits that hole and returns 0. Example 2 heapSize = 48 commands = ["ALLOC 24","ALLOC 8","FREE 0","ALLOC 8"] return = [0,24,32] After freeing offset 0, the free holes are [0, 24) and [32, 48). Best-fit for 8 bytes chooses the smaller hole at offset 32. Constraints 8 <= heapSize <= 10^4. heapSize is a multiple of 8. 1 <= commands.length <= 200. Each command is ALLOC x with 1 <= x <= heapSize, or FREE offset with an integer offset.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is that the constraints let you stay simple. With at most 200 commands and a heap of 10^4 bytes, a sorted list of free blocks (start, size) plus a map of live allocations offset to size is plenty. ALLOC: round x up to a multiple of 8, scan all free blocks, pick the smallest that fits, tie-break on lowest offset, then shrink or remove that block and record the allocation. FREE: look up the offset in the live map. If it's missing, do nothing. Otherwise insert the block, sort by start, and merge neighbors where one block's end equals the next block's start. Common pitfalls: forgetting to round before comparing, picking first-fit instead of best-fit, merging only one side, and letting a double FREE corrupt the list. Example 2 tests best-fit directly. If the live OA has you stuck on merge logic, StealthCoder is the hedge.
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 Implement Malloc 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
You've seen the question.
Make sure you actually pass Nvidia's OA.
Nvidia 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.
Implement Malloc FAQ
How hard is the Nvidia Implement Malloc question really?+
Medium at most. There's no fancy algorithm. The difficulty is bookkeeping: splitting blocks, coalescing neighbors, and handling bad FREE calls. With 200 commands max, an O(n) scan per command is fine. Candidates usually lose points on edge cases, not on complexity.
What's the trick to best-fit allocation here?+
Round the request up to a multiple of 8 first. Then scan every free block, keep the one with the smallest size that still fits, and break ties by lowest start offset. Compare on size first, offset second. Don't stop at the first match.
How do I handle coalescing correctly?+
After a FREE, add the block to the free list, sort by start offset, then walk the list merging any block whose end equals the next block's start. Check both left and right neighbors. Sorting plus one linear merge pass handles both without special cases.
What happens on a FREE of an unknown offset?+
Nothing. Keep a map of live allocations from offset to rounded size. If the offset isn't in it, skip the command. Delete the entry when you free it, so a second FREE of the same offset becomes a no-op automatically.
How do I prepare for this in 48 hours?+
Write the solution once from scratch with a sorted free list and a live map. Test both examples by hand, then add cases: full heap, -1 return, double free, and merging on both sides. Focus on clean state updates rather than optimizing.