DoorDash·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

May 2026

Summary

DoorDash SWE interview focused on a Dasher Pay calculator problem that looked straightforward until the concurrent orders wrinkle came up. Pretty design-heavy for a coding round, with a real emphasis on talking through data structures before writing anything.

Questions Asked (2)

Design and implement a Dasher Pay calculator using OOP. Each order has an accept time and a deliver time, and a dasher earns a per-minute rate for time spent on an order. If multiple orders overlap during the same minute, that minute counts once per concurrent order. Before coding, discuss your choice of data structures for input and output with the interviewer.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

The concurrent overlap part is what gets you.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and discussing data structures for input orders and output pay, then design classes (Order, Dasher, PayCalculator) and implement an efficient algorithm using a sweep line over time intervals to count concurrent orders per minute. Validate with edge cases and analyze time/space complexity.

Pro tip: Proactively discuss trade-offs between minute-by-minute simulation and event-based sweep line, and mention how to handle large inputs or real-time constraints, showing you think beyond the basic implementation.

1. Clarify Requirements and Constraints

Ask about input format, time granularity (minutes), rate structure, and whether orders can span multiple days. Confirm output format and any performance requirements.

2. Discuss Data Structures

Propose using a list of Order objects for input, and for output, a map from minute to count or a list of pay per order. Explain why these structures support efficient processing.

3. Design OOP Model

Define classes: Order (acceptTime, deliverTime), Dasher (id, rate), PayCalculator (method to compute pay). Consider using interfaces for extensibility.

4. Implement Algorithm

Use a sweep line: create events for start and end times, sort them, and sweep to count concurrent orders per minute. Multiply count by rate and sum.

5. Test and Analyze

Walk through edge cases (overlapping, adjacent, zero-duration orders) and state time complexity O(n log n) due to sorting, space O(n).

Key Points to Mention

Choice of data structures: list of orders, event list for sweep line, and map for minute counts.
Handling overlapping orders: a minute counts once per concurrent order, so pay = sum over minutes of (concurrent count * rate).
Sweep line algorithm: create events (start +1, end -1), sort by time, sweep to maintain active count.
Time complexity: O(n log n) for sorting events, O(n) for sweep; space O(n).
Edge cases: orders that start and end at same time, orders spanning multiple days, zero-duration orders.
OOP design: encapsulation, single responsibility, and potential use of strategy pattern for different rate calculations.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Walk through your test cases for this calculator. How would you cover no overlap, full overlap, partial overlap, rounding or fractional minutes, and empty input?

Algorithms & Data StructuresTechnical Trade-offs

Author's notes

They specifically asked me to be thorough here, not just write one happy-path test.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the calculator's expected behavior and input/output contract, then systematically walk through each scenario (no overlap, full overlap, partial overlap, rounding/fractional minutes, empty input) with concrete examples. For each, state the input, expected output, and edge cases, and explain how you'd implement or test it.

Pro tip: Tie each test case to a real-world DoorDash scenario (e.g., delivery time windows) to show product empathy and domain awareness, and mention how you'd automate these tests to prevent regressions.

1. Clarify requirements and contract

Ask questions to confirm input format (e.g., time ranges, units), output expectations (e.g., overlapping minutes, rounded values), and error handling. This ensures you test the right behavior.

2. Enumerate scenarios and edge cases

List each required scenario (no overlap, full overlap, partial overlap, rounding/fractional minutes, empty input) and identify boundary conditions like zero-length intervals or negative values.

3. Define concrete test cases

For each scenario, specify input values and expected output. Use simple, representative examples (e.g., [1,5] and [6,10] for no overlap) and include fractional minutes like 2.5.

4. Explain implementation and rounding logic

Describe how you'd compute overlap (e.g., max(0, min(end1,end2) - max(start1,start2))) and how rounding is handled (e.g., round to nearest minute, floor, or ceiling) with justification.

5. Discuss testing strategy and automation

Mention unit tests, property-based tests, and integration tests. Highlight how you'd cover edge cases and ensure maintainability.

Key Points to Mention

Boundary conditions: zero-length intervals, intervals that touch exactly at endpoints, and intervals with negative or reversed start/end times.
Rounding rules: specify whether to round half up, half down, or to nearest even, and how that affects fractional minutes (e.g., 2.5 minutes).
Empty input handling: define behavior for null, empty array, or missing fields, and whether to throw an error or return zero.
Overlap calculation formula: max(0, min(end1, end2) - max(start1, start2)) and its application to each scenario.
Test case examples: provide at least one concrete example per scenario, such as no overlap: [1,5] and [6,10] → 0; full overlap: [1,10] and [2,5] → 3; partial overlap: [1,5] and [3,8] → 2.
Automation and regression: mention using a testing framework (e.g., JUnit, pytest) and adding these cases to a CI pipeline.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.