Minimum Preparation Time for Two Handlers
Reported by candidates from Amazon's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Amazon's April 2026 OA includes a problem about scheduling work across two handlers with switching costs. You have a queue of jobs, each with a type, and each handler pays a prep cost that depends on whether the previous job was the same type or different. The trick is figuring out which handler to assign each job to so the total prep time is minimized. This is a dynamic programming problem, and you need to track which handler processed the last job and what type it was.
The problem
A work queue workList must be processed in order by two handlers. Each value in workList is a work type from 1 through m. For work type t, the first time a handler processes that type, or whenever the handler's previous job was a different type, that handler pays longPrepTime[t]. If the handler's previous job was the same type, that handler pays shortPrepTime[t] instead. Each job must be assigned to exactly one of the two handlers, and jobs must be processed in the order they appear. Return the minimum total preparation time. Function Description Complete the function minPreparationTime in the editor below. minPreparationTime has the following parameters: Returns int: the minimum total preparation time. Assign work type 1 to the first handler, then assign both type-2 jobs to the second handler. The total cost is 4 + 5 + 3 = 12. Use the same handler for all three jobs to pay one long preparation and two short preparations.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The core pattern is DP with state tracking. Define dp[i][lastHandler][lastType] as the minimum cost to process the first i jobs, where the i-th job went to lastHandler and had type lastType. For each new job, you have two choices: send it to handler 1 or handler 2. If the new job's type matches the last job's type and goes to the same handler, you pay shortPrepTime. Otherwise, you pay longPrepTime. Build the table bottom-up, iterating through jobs and considering both handler assignments. If you blank during the live OA, StealthCoder can surface the recurrence relation and state definitions in real time so you don't waste 15 minutes on the structure.
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 Minimum Preparation Time for Two Handlers 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 paint house ii. If you have time before the OA, drill that.
You've seen the question.
Make sure you actually pass Amazon's OA.
Amazon 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.
Minimum Preparation Time for Two Handlers FAQ
Is this problem asking me to reorder jobs?+
No. Jobs must be processed in the exact order they appear in the queue. You only decide which of the two handlers processes each job. The order constraint is what makes this DP, not a greedy assignment.
What's the trick to not overcomplicate the state?+
Track only the index of the current job, which handler just processed a job, and what type that handler last processed. You don't need to track both handlers' histories. The previous state fully determines whether the next assignment incurs a long or short prep cost.
How do I handle the first job?+
The first job always costs longPrepTime for whichever handler you assign it to, because there's no previous job. Initialize your DP base case to reflect that, then transition normally from job 2 onward.
Does the prep cost depend on the handler's identity or just the type continuity?+
Both. A handler pays longPrepTime if it's processing a type for the first time or if its previous job was a different type. If it processes the same type twice in a row, it pays shortPrepTime. The handler's identity matters only as a tracker of what it last did.
What's the time complexity I should target?+
O(n * m) where n is the number of jobs and m is the number of work types. You iterate through n jobs, and for each job you may need to consider previous states across m types. Space can be optimized to O(m) using rolling arrays if memory is tight.