Compute dasher pay from order event logs
Company: DoorDash
Role: Software Engineer
Category: Coding & Algorithms
Difficulty: medium
Interview Round: Take-home Project
You are given a list of delivery-order event records for a single dasher. Each record contains:
- `order_id`
- `event_type` in `{CREATED, ACCEPTED, PICKED_UP, DELIVERED, CANCELED}`
- `timestamp` as a datetime string (may include timezone; events may not be pre-sorted)
Rules:
1. An order is considered **active** for pay starting at `ACCEPTED` and ending at the first of `DELIVERED` or `CANCELED`.
2. The dasher is paid **$rate_per_minute** for every minute the order is active (rounding rule should be stated and applied consistently, e.g., round down to whole minutes).
3. Ignore malformed sequences (e.g., `DELIVERED` without `ACCEPTED`) or define a reasonable handling; your solution should be explicit.
4. Multiple orders can exist; compute **total pay** across all orders.
Task: Implement a function that parses the datetimes correctly, reconstructs each order’s state transitions, and returns the total pay.
Quick Answer: This question evaluates datetime parsing, event-stream reconstruction, state-machine reasoning for order lifecycles, and aggregation of timed intervals to compute compensation, including handling unordered timestamps, timezones, rounding, and malformed transitions.
You are given event records for delivery orders handled by a single dasher. Each record is a dictionary with these keys:
- order_id
- event_type, one of {CREATED, ACCEPTED, PICKED_UP, DELIVERED, CANCELED}
- timestamp, an ISO 8601 datetime string that may include a timezone offset or end with Z
Records may be unsorted.
For each order, pay starts at the first ACCEPTED event and ends at the first later DELIVERED or CANCELED event. An order contributes pay only if it has a valid ACCEPTED -> terminal pair after sorting its events chronologically.
Apply these rules:
1. Ignore CREATED and PICKED_UP events for pay calculations.
2. If an order never has ACCEPTED followed later by DELIVERED or CANCELED, that order contributes 0.
3. If multiple events for the same order have the exact same timestamp, process them in this order: CREATED, ACCEPTED, PICKED_UP, DELIVERED, CANCELED.
4. If a timestamp has no timezone, treat it as UTC.
5. For each order, active minutes = floor((end_time - accept_time) / 60 seconds).
6. Total pay = sum(active_minutes * rate_per_minute) across all orders.
7. Return the total pay as a float rounded to 2 decimal places.
Implement a function that parses the datetimes correctly, reconstructs each order's relevant state transitions, and returns the total pay.
Constraints
- 0 <= len(records) <= 200000
- Each timestamp is a valid ISO 8601 datetime string and may include a timezone offset or end with 'Z'