Count Unstable Processes
Reported by candidates from IBM's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The IBM OA reported in February 2026 looks like a monitoring problem, but it reduces to group, sort, scan. Three parallel arrays, up to 2 * 10^5 records, and you need to count processes whose limit goes both up and down over time. If you've got an invite for this one, the work is bookkeeping, not cleverness. Get the grouping right and the rest is a single pass per process. StealthCoder sits as a quiet safety net during the live OA if your mind goes blank on the setup, but the logic here is short enough to hold in your head.
The problem
You are given three arrays of equal length: process, timestamp, and limit. Entry i records that process process[i] had limit limit[i] at time timestamp[i]. For each process, order its records by increasing timestamp. A process is unstable if its ordered limit sequence has at least one increase and at least one decrease between consecutive records. Return the number of unstable processes. Function countUnstableProcesses(process: String[], timestamp: int[], limit: int[]) → int Examples Example 1 process = ["A", "B", "A", "C", "D", "A"] timestamp = [10, 25, 30, 35, 15, 20] limit = [20, 18, 10, 8, 30, 27] return = 1 Process A has records ordered by time 20 -> 27 -> 10, which includes both an increase and a decrease. The other processes are not unstable. Example 2 process = ["A", "A", "B", "B", "B"] timestamp = [1, 2, 1, 2, 3] limit = [5, 7, 3, 2, 1] return = 0 Process A only increases, and process B only decreases, so neither is unstable. Constraints 1 <= process.length == timestamp.length == limit.length <= 2 * 10^5 process[i] is a non-empty string. 0 <= timestamp[i] <= 10^9 -10^9 <= limit[i] <= 10^9 No process has two records with the same timestamp.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Group records by process name using a hash map, storing (timestamp, limit) pairs. Sort each group by timestamp. Then walk consecutive pairs and set two flags: sawIncrease when limit rises, sawDecrease when it falls. If both flags are true, count the process and stop scanning it. Equal consecutive limits change nothing, so don't treat them as either direction. The classic pitfall is skipping the sort because the input arrives unordered, as Example 1 shows with A at timestamps 10, 30, 20. Another is comparing against the first record instead of the previous one. Total cost is O(n log n) from sorting, which fits the 2 * 10^5 bound. You can also sort all indices once by timestamp, then scan and track the last limit and two flags per process in a map. If you blank mid-OA, StealthCoder can supply this skeleton so you only have to verify edge cases.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill Count Unstable Processes 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 would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass IBM's OA.
IBM reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Count Unstable Processes FAQ
How hard is Count Unstable Processes really?+
Easy to medium. There's no hidden algorithm. You group by process, sort by timestamp, and check for both an increase and a decrease. Most failures come from forgetting to sort or mishandling equal limits, not from complexity.
What's the trick to solving it?+
Treat each process as its own time series. Sort its records by timestamp, then compare each limit to the previous one. Track two booleans, one for any rise and one for any drop. Count the process only when both are true.
Do equal consecutive limits count as an increase or decrease?+
No. Only strict increases or strict decreases count. A flat step changes neither flag. A sequence like 5, 5, 5 is not unstable, and 5, 5, 7 has only an increase, so it isn't either.
What time complexity should I aim for?+
O(n log n) is the target, driven by sorting. Grouping with a hash map is O(n). With n up to 2 * 10^5, a quadratic approach that rescans records per process will likely time out, so avoid it.
How do I prepare for this in 48 hours?+
Practice grouping parallel arrays into a hash map of lists, sorting by a key, and scanning adjacent pairs with flags. Write the solution once from scratch, then test the two given examples plus a single-record process and an all-equal process.