Delivery Driver Payroll Tracker With Accrued, Settled and Unpaid Wage Totals

Implement an in-memory payment tracker for delivery drivers, who are paid by the hour for the time they spend on deliveries. The class must support these operations: - `add_driver(driver_id, usd_hourly_rate)`: register a driver with an hourly rate in US dollars. - `record_delivery(driver_id, start_time, end_time)`: log a completed delivery, given as the interval during which the driver was working. - `get_total_cost()`: return the total labor cost accrued across all drivers and all recorded deliveries, regardless of what has been paid. - `pay_up_to(pay_time)`: settle, that is mark as paid, the wages for all work performed up to `pay_time`. Calling it again with the same time or an earlier time must not pay anything twice. - `get_total_cost_unpaid()`: return the total wages that remain unsettled after the payouts so far. The interview allowed about 45 minutes for the design and a working implementation. ```hint Keep the getters cheap The two getters may be called far more often than the other operations. Think about which totals can be kept up to date as deliveries and payouts happen. ``` ```hint What exactly has been paid? A payout time splits every delivery into a part before it and a part after it. Decide what you must remember so that a repeated or earlier `pay_up_to` call cannot settle the same minutes of work again. ``` ```hint Money is not a float An hourly rate applied to a duration in seconds rarely comes out to a whole number of cents. Choose a representation in which sums stay exact. ``` ### Constraints and Clarifications - Assume timestamps are integers in seconds, such as Unix time, and that the cost of a delivery is the driver's hourly rate times the delivery's duration in hours. Confirm the time unit with the interviewer. - All state lives in memory in one process; persistence and concurrent callers are out of scope unless the interviewer adds them. - Amounts are returned in US dollars. ### Clarifying Questions - If a delivery is still in progress at `pay_time` (it started before it and ends after it), is the part worked before `pay_time` settled now, or is a delivery settled only once it has ended by the payout time? - If a delivery is recorded after a payout whose time is later than the delivery's start, has that work been settled, or should a later payout settle it? - Can a driver have overlapping deliveries, and if so, is the overlapping time paid once or once per delivery? - What should happen for an unknown `driver_id`, a second `add_driver` call for the same id, or an interval that ends before it starts? - How precise must the returned amounts be: exact, or rounded to cents? ### What a Strong Answer Covers - A working class with clear state for drivers, recorded work, and settled and unsettled amounts - A settlement mechanism that makes repeated and earlier `pay_up_to` calls safe, with its behavior for in-progress and late-recorded deliveries stated explicitly - Exact money arithmetic, with a stated rule for when rounding to cents happens - The time complexity of every operation, with cheap getters and payouts that do not rescan already settled work - Input validation, and a short walk-through or tests showing the totals before and after payouts ### Follow-up Questions - A driver's hourly rate changes at a given time. How do you price deliveries that cross the change? - How would you report unpaid wages per driver, and turn each payout into per-driver amounts in whole cents without losing fractions of a cent? - The tracker becomes a service, and a `pay_up_to` request may be retried after a timeout. How do you make sure each payout happens exactly once? - Millions of deliveries are recorded between payouts. What does each operation cost, and what would you change?