Build a Delivery Payout Calculation API
DoorDashSoftware Engineer · Technical ScreenLast updated
Build a payout endpoint that retrieves delivery activity and accrues 30 cents per minute for each concurrent order. The solution covers interval sweeps, malformed events, exact money, day boundaries, final rounding, upstream timeouts, retry limits, caching, and layered tests.
Build a Delivery Payout Calculation API
Build a payment-service endpoint POST /payout that accepts a delivery worker ID, requests that worker's order-activity sequence for a specified day from an upstream dependency, calculates the payout, and returns the dollar amount.
The base rate is $0.30 per minute. During any interval, the rate is the number of ongoing deliveries multiplied by the base rate. For example, two simultaneous active deliveries earn twice the one-delivery rate during their overlap.
For this practice version, the upstream activity contains an orderId, a START or END type, and a timestamp. Calculate from exact elapsed seconds, prorate the per-minute rate, and round the final daily total to cents once using the agreed monetary rounding rule.
Constraints & Assumptions
- Every valid order has one
STARTfollowed by oneENDfor the requested worker and day. - Activities may arrive unsorted; equal timestamps create no paid elapsed interval between them.
- A malformed or incomplete activity sequence causes an explicit error and no guessed payout.
- Money uses exact decimal or integer minor-unit arithmetic rather than binary floating point.
- Upstream URL, authentication, timeout, response schema, day boundary, and response envelope are provided by the assessment.
Clarifying Questions to Ask
- Is pay prorated by second, rounded per order, rounded per interval, or rounded only on the final total?
- Which timezone defines the workday, especially across daylight-saving transitions?
- Can an order cross the requested day boundary, and how is the opening active state obtained?
- What status should the payout endpoint return for upstream timeout, malformed activity, or an unknown worker?
- May the activity response be cached, and what correction or freshness behavior invalidates it?
Follow-up questions
- How do you detect a duplicate `START` that would otherwise inflate the active-delivery count?
- Two events share a timestamp. Why should their internal ordering not change accrued pay?
- What changes if an order begins before midnight and ends during the requested day?
- Which upstream failures are safe to retry, and how do you prevent a retry storm?
- How would you prove that overlapping deliveries are counted without rounding each interval differently?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.