How do I practice coding and algorithm questions?

Use PracHub's coding console to write, test, and debug your solutions in Python or JavaScript. View hints, test against sample inputs, and compare with official solutions.

What difficulty level is this coding question?

This is a medium difficulty Coding & Algorithms question, commonly asked during Take-home Project rounds at DoorDash.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at DoorDash during technical interviews.

Compute dasher pay from order event logs | DoorDash Coding Question

Quick Overview

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.

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'
If a timestamp has no timezone information, treat it as UTC
event_type is one of CREATED, ACCEPTED, PICKED_UP, DELIVERED, CANCELED
0 <= rate_per_minute <= 10000, with at most 2 decimal places

Examples

Input: ([{'order_id': 'o1', 'event_type': 'DELIVERED', 'timestamp': '2024-01-01T10:31:30Z'}, {'order_id': 'o1', 'event_type': 'CREATED', 'timestamp': '2024-01-01T10:00:00Z'}, {'order_id': 'o1', 'event_type': 'ACCEPTED', 'timestamp': '2024-01-01T10:00:30Z'}, {'order_id': 'o1', 'event_type': 'PICKED_UP', 'timestamp': '2024-01-01T10:10:00Z'}], 1.5)

Expected Output: 46.5

Explanation: After sorting, order o1 is active from 10:00:30Z to 10:31:30Z, which is 31 whole minutes. Pay = 31 * 1.5 = 46.5.

Input: ([{'order_id': 'A', 'event_type': 'ACCEPTED', 'timestamp': '2024-02-01T10:00:00-05:00'}, {'order_id': 'B', 'event_type': 'DELIVERED', 'timestamp': '2024-02-01T12:00:00Z'}, {'order_id': 'C', 'event_type': 'CANCELED', 'timestamp': '2024-02-01T09:14:59+02:00'}, {'order_id': 'A', 'event_type': 'DELIVERED', 'timestamp': '2024-02-01T10:20:00-05:00'}, {'order_id': 'C', 'event_type': 'ACCEPTED', 'timestamp': '2024-02-01T09:00:00+02:00'}, {'order_id': 'B', 'event_type': 'ACCEPTED', 'timestamp': '2024-02-01T12:05:00Z'}], 2)

Expected Output: 68.0

Explanation: Order A contributes 20 minutes = 40. Order C contributes floor(14m59s) = 14 minutes = 28. Order B has DELIVERED before ACCEPTED and no later terminal event, so it is ignored. Total = 40 + 28 = 68.0.

Input: ([], 3.25)

Expected Output: 0.0

Explanation: No records means no active orders and therefore no pay.

Input: ([{'order_id': 'x', 'event_type': 'ACCEPTED', 'timestamp': '2024-03-05T10:00:00Z'}, {'order_id': 'x', 'event_type': 'PICKED_UP', 'timestamp': '2024-03-05T10:02:00Z'}, {'order_id': 'x', 'event_type': 'ACCEPTED', 'timestamp': '2024-03-05T10:03:00Z'}, {'order_id': 'x', 'event_type': 'CANCELED', 'timestamp': '2024-03-05T10:07:59Z'}, {'order_id': 'x', 'event_type': 'DELIVERED', 'timestamp': '2024-03-05T10:20:00Z'}, {'order_id': 'y', 'event_type': 'CREATED', 'timestamp': '2024-03-05T09:00:00Z'}], 1)

Expected Output: 7.0

Explanation: Order x starts at the first ACCEPTED and ends at the first later terminal event, which is CANCELED at 10:07:59Z. That is 7 whole minutes. Later DELIVERED is ignored. Order y never becomes active.

Input: ([{'order_id': 'n1', 'event_type': 'ACCEPTED', 'timestamp': '2024-03-01T10:00:00'}, {'order_id': 'n1', 'event_type': 'DELIVERED', 'timestamp': '2024-03-01T10:59:59'}, {'order_id': 'n2', 'event_type': 'ACCEPTED', 'timestamp': '2024-03-01T11:00:00Z'}, {'order_id': 'n2', 'event_type': 'DELIVERED', 'timestamp': '2024-03-01T11:00:00Z'}], 0.5)

Expected Output: 29.5

Explanation: Naive timestamps are treated as UTC. Order n1 is active for floor(59m59s) = 59 minutes, so pay is 29.5. Order n2 starts and ends at the same instant, so it contributes 0.

Hints

Normalize every timestamp to the same timezone before comparing them.
Group events by order_id, sort each group, then scan for the first ACCEPTED followed by the first terminal event.

Quick Overview