← DoorDash Interview Insights

DoorDash·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
Apr 2026

Summary

DoorDash software engineer interview with a coding problem around driver pay calculation. The problem itself was straightforward but the debrief got weird when the interviewer pushed back on correct math and just... wouldn't let it go.

Questions Asked (1)

Q1

Given a service that returns a delivery driver's order start and end times by driver ID, and a per-minute wage rate, write code to calculate the driver's total pay. Also write a small mock of the external API.

Algorithms & Data StructuresAPI & IntegrationsTechnical Trade-offs
Author's notes

Pretty approachable.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the API contract and edge cases (e.g., time zones, overlapping orders, missing data), then design a clean mock API and a pay calculation function that handles real-world scenarios like breaks and rounding. Implement the solution with testable, modular code and discuss trade-offs such as precision and performance.

Pro tip: Demonstrate production thinking by discussing how to handle API failures and data inconsistencies, and mention that you'd write unit tests for edge cases like zero-duration orders and daylight saving time changes.

1. Clarify requirements and edge cases

Ask questions to understand the API response format, time zone handling, whether orders can overlap, and how breaks or gaps between orders affect pay. Identify edge cases like missing data, zero-duration orders, and rounding rules.

2. Design the mock API

Create a simple mock that returns realistic order data for a given driver ID, including start and end times. Consider adding configurable delays or errors to simulate real-world conditions.

3. Implement pay calculation

Write a function that fetches orders, computes total minutes worked (handling overlaps and gaps appropriately), and multiplies by the wage rate. Use precise time arithmetic and round only at the end.

4. Handle errors and edge cases

Add error handling for API failures, invalid data, and empty order lists. Discuss how to handle time zone conversions and ensure calculations are correct across daylight saving boundaries.

5. Test and discuss trade-offs

Write unit tests for normal and edge cases, and explain design decisions like using UTC timestamps, avoiding floating-point errors, and optimizing for performance if the order list is large.

Key Points to Mention

  • Time zone handling and using UTC timestamps to avoid daylight saving issues
  • Overlap detection and merging intervals to avoid double-counting pay
  • Rounding strategies (e.g., round total minutes vs. per-order) and their impact
  • Error handling for API failures and data validation
  • Mock API design with realistic data and potential failure simulation
  • Unit testing for edge cases like zero-duration orders and empty responses

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