Peak Elements in Removal Order
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 February 2022 looks like a simulation puzzle, but it's really a priority problem in disguise. You remove the leftmost peak, recompute, and repeat until the array is empty. With up to 2000 elements, the naive approach is tempting and probably passes. The cleaner version tracks peaks as neighbors change. If you're taking this in the next day or two, know the trick before you start typing. StealthCoder sits invisibly on your screen as a safety net if your mind goes blank mid-assessment, but the idea here is short enough to hold in your head.
The problem
Repeatedly remove one peak from the current array until it is empty. An interior element is a peak when it is not smaller than either current neighbor. An endpoint is a peak when it is not smaller than its only neighbor, and the sole remaining element is a peak. At each step remove the leftmost current peak. Return the removed values in order. Function removePeaks(values: int[]) → int[] Examples Example 1 values = [1,3,2,4] return = [3,4,2,1] Peaks are recomputed after each leftmost removal. Example 2 values = [7] return = [7] The sole element is a peak. Constraints 0 <= values.length <= 2000 -1000000000 <= values[i] <= 1000000000
Reported by candidates. Source: FastPrep
Pattern and pitfall
Start with the brute force, because n is only 2000. Each step scans the current array for the leftmost index where the element is not smaller than its existing neighbors, removes it, and appends the value. That's O(n^2) total, about four million operations, which is fine. The pitfall is the comparison. Peaks use not-smaller, so equal neighbors still count. Endpoints compare against one neighbor only, and a single element is always a peak. Also handle the empty array by returning an empty list. Don't compare against stale neighbors from the original array, since removal changes adjacency. A global maximum is always a peak, so a peak always exists and the loop terminates. If you want faster, use a linked list plus a min-index set of peak candidates, rechecking only the two neighbors after each removal. StealthCoder is the hedge if you freeze on the edge cases during the live OA.
The honest play: practice the pattern, and have StealthCoder ready for the one you didn't see coming.
You can drill Peak Elements in Removal Order 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
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.
Peak Elements in Removal Order FAQ
How hard is the ZipRecruiter peak removal problem really?+
Easy to medium. The rules are simple, but the edge cases trip people up. The constraint of 2000 elements means a straightforward quadratic simulation is acceptable. Getting the not-smaller comparison and the endpoint rules right matters more than any clever data structure.
What's the trick to removing peaks in order?+
Always remove the leftmost current peak, then recompute adjacency. Scan from the left, check each element against its live neighbors, and remove the first one that qualifies. Using the original array's neighbors is the main mistake. After each removal, the neighbors change.
Do equal neighbors count as a peak?+
Yes. A peak is not smaller than its neighbors, so ties qualify. For example, in [2,2], the first element is a peak because it isn't smaller than its only neighbor. Using a strict greater-than check will give wrong output on arrays with duplicates.
Can I solve it with sorting?+
Not directly. Sorting by value breaks the leftmost-peak rule, because a smaller value may be a peak earlier in the array. The order depends on position and live neighbors, so simulate removals instead. A heap or sorted set of candidate indices only helps in the optimized version.
How do I prepare for this in 48 hours?+
Write the quadratic simulation from scratch and test it on [1,3,2,4], [7], an empty array, and arrays with duplicates. Then sketch the linked-list optimization so you can explain it. Practice handling edge cases cleanly, since that's where this question tends to cost points.