Worker Management, Part 1: Office Registration
Reported by candidates from Airbnb's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Airbnb OA reported in July 2026 looks like a system design question, but it's a hash map and a running total wearing a trench coat. Worker Management Part 1 asks you to process a list of operations in order and return one string per operation. If you've got an invite for this one, expect Part 1 to be easy and later levels to build on your structure, so write it cleanly. StealthCoder sits invisibly on your screen as a safety net if you blank mid-assessment, but the logic here is short enough to hold in your head.
The problem
Build the first level of a worker management system. Process each operation in order and return one string result per operation. Operations ["ADD_WORKER", worker_id, position, compensation]: add a worker and save the position and hourly compensation. Return true on success or false if the ID already exists. ["REGISTER", worker_id, timestamp]: toggle the worker's office state. When outside, record an entry; when inside, close the session. Return registered, or invalid_request if the worker does not exist. REGISTER timestamps are strictly increasing. ["GET", worker_id]: return the total time from completed office sessions. An unfinished visit contributes zero. Return an empty string for a missing worker. Worker IDs and positions contain only English letters and spaces. Function workerManagementLevel1(operations: String[][]) → String[] Examples Example 1 operations = [["ADD_WORKER","Ashley","Middle Developer","150"],["ADD_WORKER","Ashley","Junior Developer","100"],["REGISTER","Ashley","10"],["REGISTER","Ashley","25"],["GET","Ashley"],["REGISTER","Ashley","40"],["REGISTER","Ashley","67"],["REGISTER","Ashley","100"],["GET","Ashley"],["GET","Walter"],["REGISTER","Walter","120"]] return = ["true","false","registered","registered","15","registered","registered","registered","42","","invalid_request"] Ashley's completed sessions are [10,25) and [40,67), totaling 42. The entry at 100 is unfinished and does not count.
Reported by candidates. Source: FastPrep
Pattern and pitfall
What it really reduces to: a dictionary keyed by worker ID, where each value stores position, compensation, an inside flag, the last entry timestamp, and a running total of completed time. ADD_WORKER checks the key and returns true or false. REGISTER flips the flag. If the worker is outside, store the timestamp. If inside, add timestamp minus entry time to the total. GET returns the total as a string, or an empty string if the worker is missing. The pitfalls are small but costly. Return strings, not booleans or ints. Don't count an open session in GET, as the example shows with the entry at 100. Missing worker means invalid_request for REGISTER but empty string for GET. Keep the worker as an object or class, because Part 2 will almost certainly extend it. If you freeze in the live OA, StealthCoder is the hedge, but this is mostly careful reading.
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 1: Office Registration 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 Airbnb's OA.
Airbnb 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 1: Office Registration FAQ
How hard is Airbnb's Worker Management Part 1 really?+
Easy on algorithms, but picky on details. It's a hash map with simple state per worker. Most failures come from output formatting, like returning true instead of the string "true", or miscounting unfinished sessions. Read the example twice and trace it by hand.
What's the trick to this problem?+
Store per-worker state: inside flag, last entry time, and total completed time. REGISTER toggles the flag. On exit, add the difference to the total. GET just returns the total. There's no sorting or searching involved, only careful state handling.
How should I handle an unfinished session in GET?+
It contributes zero. In the example, Ashley enters at 100 and never leaves, so GET still returns 42 from the two closed sessions. Only add time to the total when a REGISTER closes a session, never when GET is called.
What happens with missing workers?+
It differs by operation. REGISTER on a nonexistent worker returns invalid_request. GET on a nonexistent worker returns an empty string. ADD_WORKER on an existing ID returns false and shouldn't overwrite the original data. Mixing these up is the most common bug.
How do I prepare for this in 48 hours?+
Write a small version yourself with a class or dict per worker, then run the sample input and match the output exactly. Practice parsing timestamps and compensation from strings. Structure the code so adding new operations later is easy, since this is labeled Part 1.