How should I practice Worker Management, Part 4: Worker Merge?

Start by reading the full statement, solve the visible examples, then compare the pattern against related Airbnb online assessment problems in FastPrep.

Is Worker Management, Part 4: Worker Merge associated with Airbnb?

FastPrep tags this as a Airbnb online assessment coding practice problem when the problem catalog has that company and stage context.

Problem · Hash Table

Worker Management, Part 4: Worker Merge

Learn this problem

● Hard

AirbnbFULLTIMEOA

Problem statement

Build the worker management register through Level 4. Process the cumulative operation contract below.

Practice Interface

FastPrep-authored scaffolding: the source exposes direct methods. This practice version serializes the same calls as one finite ordered String[][] operations batch. Implement workerManagementLevel4WorkerMerge and return one string response per row, in order. Direct list results are joined as described below; a missing optional integer is serialized as an empty string.

Operations from Levels 1 and 2

["ADD_WORKER", workerId, position, compensation]: add a worker. Return true, or false when the ID already exists.
["REGISTER", workerId, timestamp]: toggle entry or exit. Return registered, or invalid_request for a missing worker.
["GET", workerId]: return total time in completed sessions, or an empty string for a missing worker. An open session contributes nothing.
["TOP_N_WORKERS", n, position]: consider workers whose current position equals position. Sort by completed-session time descending, then worker ID alphabetically; format each as workerId(time) and join with , . Include zero-time workers and return an empty string when no worker matches.

Level 3 Operations

["SET_OVERTIME_RULE", workerId, threshold, timestamp]: on success, return success. Return invalid_request for a missing worker.
The rule applies to sessions that begin after the operation. In each such session, the first threshold time units are paid at the session's regular compensation and all remaining time is paid at twice that compensation.
A rule change while the worker is inside does not change the open session; it applies on the next entry. If several rules are set before that entry, only the latest applies.
["CALC_SALARY", workerId, startTimestamp, endTimestamp]: return salary from completed-session time overlapping the query range, or an empty string for a missing worker. The regular/overtime split is measured from each session's start. With no applicable rule, the whole overlap uses regular compensation.
Changing overtime rules never changes GET or TOP_N_WORKERS.

Level 4 Operation

["MERGE_WORKERS", workerId1, workerId2, timestamp]: merge worker 2 into worker 1 and return success. Return invalid_request unless both IDs exist, differ, and both workers are outside the office.
Worker 1 keeps the current position, compensation, and both current and pending overtime rules. Worker 2's current and pending settings are discarded, and worker 2 is removed.
Transfer every completed session from worker 2 with its original timestamps, compensation, and overtime rule. Do not combine or deduplicate sessions; overlapping ranges count independently in time, ranking, and salary.

Function

workerManagementLevel4WorkerMerge(operations: String[][]) → String[]

Examples

Example 1

operations = [["ADD_WORKER","Mia","Engineer","10"],["ADD_WORKER","Noah","Analyst","20"],["SET_OVERTIME_RULE","Mia","2","5"],["SET_OVERTIME_RULE","Noah","1","6"],["REGISTER","Mia","10"],["REGISTER","Mia","14"],["REGISTER","Noah","20"],["REGISTER","Noah","23"],["MERGE_WORKERS","Mia","Noah","30"],["GET","Mia"],["TOP_N_WORKERS","5","Engineer"],["TOP_N_WORKERS","5","Analyst"],["CALC_SALARY","Mia","0","100"],["GET","Noah"]]return = ["true","true","success","success","registered","registered","registered","registered","success","7","Mia(7)","","160",""]

Mia keeps position Engineer. Her session earns 60; Noah's transferred session retains compensation 20 and threshold 1, earning 100. The merged worker therefore has time 7 and salary 160.

Example 2

operations = [["ADD_WORKER","Ava","Developer","10"],["ADD_WORKER","Ben","Developer","5"],["SET_OVERTIME_RULE","Ben","2","5"],["REGISTER","Ava","10"],["REGISTER","Ben","15"],["REGISTER","Ava","20"],["REGISTER","Ben","25"],["REGISTER","Ava","30"],["MERGE_WORKERS","Ava","Ben","31"],["REGISTER","Ava","32"],["MERGE_WORKERS","Ava","Ben","33"],["GET","Ava"],["CALC_SALARY","Ava","0","100"],["ADD_WORKER","Ben","QA","7"],["REGISTER","Ben","40"],["MERGE_WORKERS","Ava","Ben","41"],["REGISTER","Ben","42"],["MERGE_WORKERS","Ava","Ava","43"]]return = ["true","true","success","registered","registered","registered","registered","registered","invalid_request","registered","success","22","210","true","registered","invalid_request","registered","invalid_request"]

The first merge is rejected because Ava is inside. After Ava exits, the merge succeeds. Ava's and Ben's overlapping sessions count independently, so the merged time is 22 and salary is 210. Ben can be added again after removal; a merge is rejected while the new Ben is inside, and self-merge is always invalid.

Constraints

Every operation row is well formed and uses one of the listed operation shapes.
Worker IDs and positions contain only English letters and spaces.
Compensation and overtime thresholds are integer values supplied in the operation rows.
The mutation timestamps supplied to REGISTER, SET_OVERTIME_RULE, and MERGE_WORKERS are strictly increasing across the batch.
For every salary query, 0 <= startTimestamp < endTimestamp <= 10^6.
Durations and overlaps are timestamp differences. The practice serialization writes a session or salary range as [start, end); a boundary does not contribute an extra time unit.