Worker Management Module

You are tasked with implementing an in-memory worker management module. This module will track worker metadata, their attendance history, and facilitate payroll calculations and performance rankings.

Data Model

Each worker entity will possess the following attributes:

• workerId: A unique identifier (string or integer).
• title: The worker's current job title (string).
• salary: A numeric value representing the pay rate per unit time (e.g., dollars per hour). Pay is accrued exclusively when the worker is actively in the office.

Time is represented by integer timestamps, which are guaranteed to be monotonic (non-decreasing) within a single worker's timeline. Attendance is managed by a toggle mechanism:

• If a worker is currently out of the office, a timestamp provided to registerTime signifies the start of a new in-office interval.
• If a worker is currently in the office, a timestamp provided to registerTime signifies the end of the current in-office interval.

Assume that inputs are generally valid, but your design should explicitly define behavior for any identified edge cases.

Operations to Implement

1. Basic Attendance Management

1. addWorker(workerId, title, salary): Registers a new worker with their initial details.
2. registerTime(workerId, timestamp): Records an attendance event, toggling the worker's in/out status as per the rule above.
3. getTotalInOfficeTime(workerId) -> totalTime: Returns the worker's total accumulated time spent in the office across all completed attendance intervals.

2. Ranking by In-Office Time

1. topNByInOfficeTime(n) -> list: Retrieves the top n workers, ranked by their total accumulated in-office time.
2. topNByInOfficeTimeForTitle(n, title) -> list: Similar to the above, but filters the ranking to include only workers whose current title matches the specified title.

For ranking operations, you must define the output format (e.g., a list of (workerId, totalTime) pairs) and specify the tie-breaking rules.

3. Promotions with Deferred Effect

1. promote(workerId, newTitle, newSalary): Initiates a promotion for a worker.
   • A promotion can only be applied immediately if the worker is currently out of the office.
   • If the worker is currently in the office, the promotion must be queued. It will then be applied at the next timestamp when the worker enters the office (i.e., at the start of their next in-office interval).
   • If multiple promotions are queued for the same worker, only the most recent queued promotion is relevant; older queued promotions are discarded/overwritten.

4. Payroll Query

1. getPay(workerId, startTime, endTime) -> pay: Calculates the worker's total pay earned within the specified time window [startTime, endTime).
   • Pay is computed by identifying the overlap of each in-office interval with [startTime, endTime). The duration of this overlap is then multiplied by the salary rate that was effective during that specific time segment.
   • Promotions alter the effective salary (and title) from the moment they are applied, following the deferred-effect rule.

Design Considerations and Clarifications

Your design should address and clarify the following points:

• Whether registerTime timestamps are strictly non-decreasing per worker.
• How incomplete intervals (where a worker is currently in the office) should be handled by getTotalInOfficeTime or getPay.
• The behavior for edge cases such as an unknown workerId, attempting to addWorker with a duplicate workerId, or startTime >= endTime in getPay.
• The expected time complexity targets for each operation, particularly for topN* methods and getPay.