Filter and Sort Scheduled Tasks
Reported by candidates from Rippling's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Rippling OA reported in July 2026 looks friendly: filter some tasks, sort the survivors, return IDs. With up to 10^5 tasks, though, anything quadratic dies, so the only real question is whether you write the comparator cleanly under pressure. It's a sorting problem with a three-key tie-break and parallel arrays instead of objects. Easy to understand, easy to fumble on the details. If you blank on the comparator or the index bookkeeping mid-assessment, StealthCoder runs invisibly as a safety net on the live OA. Know the shape anyway, because you'll want to move fast.
The problem
Given parallel arrays describing scheduled tasks and a current timestamp, return the IDs of all eligible tasks in execution order. A task at index i is eligible exactly when: statuses[i] is PENDING; and scheduledTimes[i] is at most currentTime. Sort eligible tasks by: priorities[i] descending; scheduledTimes[i] ascending; then taskIds[i] lexicographically ascending. Return the ordered task IDs. The judged practice combines the reported filtering and sorting capabilities into one result; it does not invent a separate undisclosed third part. Function filterAndSortTasks(taskIds: String[], scheduledTimes: long[], priorities: int[], statuses: String[], currentTime: long) → String[] Examples Example 1 taskIds = ["task-a","task-b","task-c","task-d"] scheduledTimes = [10,5,10,1] priorities = [2,3,3,9] statuses = ["PENDING","PENDING","RUNNING","PENDING"] currentTime = 10 return = ["task-d","task-b","task-a"] task-c is not pending. The other tasks are due, so priority places task-d first, followed by task-b and task-a. Example 2 taskIds = ["z","a","b","late"] scheduledTimes = [7,7,3,11] priorities = [5,5,5,9] statuses = ["PENDING","PENDING","PENDING","PENDING"] currentTime = 7 return = ["b","a","z"] late is not due. The other tasks have equal priority, so the earlier timestamp places b first and the lexicographic tie-break places a before z. Example 3 taskIds = ["done","future"] scheduledTimes = [1,100] priorities = [10,10] statuses = ["COMPLETED","PENDING"] currentTime = 50 return = [] The completed task is ineligible and the pending task is not due, so the result is empty. Constraints 0 <= taskIds.length <= 10^5. All four task arrays have the same length. Task IDs are unique non-empty strings. Each timestamp fits in a signed 64-bit integer and each priority fits in a signed 32-bit integer. Every status is PENDING, RUNNING, or COMPLETED.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Filter first, sort second. Walk the arrays once and keep only indexes where statuses[i] equals PENDING and scheduledTimes[i] is at most currentTime. Then sort those indexes (or small tuples) with a comparator: priority descending, scheduledTime ascending, taskId lexicographically ascending. That's O(n log n), which is what 10^5 demands. Pitfalls: subtracting longs in the comparator and casting to int overflows, so use Long.compare or direct less-than checks. Priority is descending, so flip the order for that key only. Compare IDs with compareTo, not numeric parsing. Handle the empty input and return an empty array. Don't sort everything and filter later, it wastes work and invites mistakes. If the comparator logic slips during the live OA, StealthCoder is the hedge that hands you a clean version, but this one is short enough to write from memory.
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 Filter and Sort Scheduled Tasks 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 Rippling's OA.
Rippling 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.
Filter and Sort Scheduled Tasks FAQ
How hard is the Rippling Filter and Sort Scheduled Tasks problem really?+
Easy to medium. There's no clever algorithm, just a filter and a multi-key sort. Most failures come from a flipped sort direction, a long overflow in the comparator, or a mishandled empty input. If you can write a comparator, you can solve it.
What's the trick to getting the order right?+
Sort by priority descending, then scheduledTimes ascending, then taskId ascending. Only the first key is reversed. Check your comparator against Example 2, where equal priorities force the timestamp and then the ID tie-break to decide the order.
Do I filter before or after sorting?+
Before. Keep only PENDING tasks whose scheduledTime is at most currentTime, then sort that smaller set. Sorting everything first works but wastes time. Note the boundary: a task scheduled exactly at currentTime is eligible, as in Example 1.
What complexity should I aim for with 10^5 tasks?+
O(n log n) from a single sort after an O(n) filter. Anything quadratic, like repeated min-selection or insertion sort, is too slow at 10^5. Extra memory for the index list or tuples is fine and expected.
How do I prepare for this in 48 hours?+
Practice writing custom comparators in your language with three keys, including a descending one. Test with equal priorities, equal times, an empty array, and large long values. Check that string comparison is lexicographic. That covers nearly every edge case here.