Worker Management, Part 3: Promotions and Salary
Reported by candidates from Anthropic's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Anthropic reported this one in July 2026, and it's a stateful simulation, not a clever algorithm. Part 3 of the worker management series adds promotions and salary calculation on top of register, GET and TOP_N_WORKERS. The trap is timing. A promotion doesn't apply when you call PROMOTE, it applies when the worker next enters the office at or after the start timestamp. If you've got an OA coming up, expect to spend your time on state bookkeeping and the interval math, not on any fancy data structure. StealthCoder is the safety net if the edge cases pile up and you blank mid-assessment.
The problem
Continue the worker management system from Parts 1 and 2. Existing operations keep their behavior. Promotions ["PROMOTE", worker_id, new_position, new_compensation, start_timestamp]: register a pending promotion. Return success, or invalid_request if the worker is missing or already has an unapplied promotion. The promotion becomes active when the worker first enters the office at a timestamp greater than or equal to start_timestamp. A session that begins earlier keeps the previous position and compensation. TOP_N_WORKERS considers only each worker's current position. GET continues to sum completed time across every past and current position. Salary ["CALC_SALARY", worker_id, start_timestamp, end_timestamp]: return the salary earned during the half-open interval [start_timestamp, end_timestamp). Only completed office sessions are paid. For each session, multiply the length of its intersection with the requested interval by the compensation active for that session. Return an empty string for a missing worker. Function workerManagementLevel3(operations: String[][]) → String[] Examples Example 1 operations = [["ADD_WORKER","John","Middle Developer","200"],["REGISTER","John","100"],["REGISTER","John","125"],["PROMOTE","John","Senior Developer","500","200"],["REGISTER","John","150"],["PROMOTE","John","Senior Developer","350","250"],["REGISTER","John","300"],["REGISTER","John","325"],["CALC_SALARY","John","0","500"],["TOP_N_WORKERS","3","Senior Developer"],["REGISTER","John","400"],["GET","John"],["TOP_N_WORKERS","10","Senior Developer"],["TOP_N_WORKERS","10","Middle Developer"],["CALC_SALARY","John","110","350"]] return = ["true","registered","registered","success","registered","invalid_request","registered","registered","35000","John(0)","registered","250","John(75)","","45500"] The session beginning at 150 keeps the old compensation because it starts before 200. The promotion applies when John next enters at 325. Salary over [110,350) is 15*200 + 150*200 + 25*500 = 45500.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The pattern is simulation with per-worker session history. Store each completed session as (enter, exit, compensation), where compensation is fixed when the session begins. Keep one pending promotion per worker. On each enter-REGISTER, check if pending.start <= timestamp. If so, apply it, change position and compensation, and clear it. The pitfall in the example is the session starting at 150. The promotion was set for 200, so that session keeps the old pay even though it runs past 200. Never reprice a session retroactively. For CALC_SALARY, intersect each completed session with [start, end) using max(starts) and min(ends), clamp at zero, and multiply by that session's stored compensation. Skip open sessions. GET sums time across all positions, but TOP_N_WORKERS only counts the current position. Use long integers. If the live OA gets tangled, StealthCoder can give you a working structure when you freeze.
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 Worker Management, Part 3: Promotions and Salary 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 Anthropic's OA.
Anthropic 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.
Worker Management, Part 3: Promotions and Salary FAQ
What's the trick in Worker Management Part 3?+
Lock compensation per session at the moment the session starts. A promotion only activates on the next enter at or after its start timestamp. If you store the pay rate on each session record, salary calculation becomes simple interval intersection and nothing needs repricing.
Why does the session starting at 150 keep the old pay?+
Because it began before the promotion's start timestamp of 200. The rule looks at when the session begins, not when it ends. That session crosses 200, but it was already running under the old position and compensation, so it's paid at 200 per unit.
How do I compute CALC_SALARY correctly?+
For each completed session, take max(session start, interval start) and min(session end, interval end). If the overlap is positive, multiply it by that session's stored compensation and add it up. Ignore any session that's still open. Return an empty string if the worker doesn't exist.
What happens if PROMOTE is called twice before the worker re-enters?+
The second call returns invalid_request, since the worker already has an unapplied promotion. Only after the promotion activates on an enter can a new one be registered. A missing worker also gives invalid_request. Track a single pending promotion per worker.
How should I prepare for this in 48 hours?+
Rebuild Parts 1 and 2 cleanly first, since Part 3 depends on them. Then write the promotion and salary logic and test it against the sample. Hand-check the 45500 result. Watch for off-by-one errors on the half-open interval and for integer overflow on salary totals.