Katkat
Back

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

RipplingSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

Design and implement an in-memory payroll tracker for hourly-paid delivery drivers that records delivery intervals, reports total and unpaid labor cost, and settles wages up to a given time without ever paying twice. It tests stateful class design, idempotent settlement, treatment of in-progress and late-recorded work, and exact money arithmetic.

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.

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?

Hints

Hint 1

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 2

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 3

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.

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?