DoorDash·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Jun 2026

Summary

DoorDash SWE round focused on a pretty meaty coding problem around dasher pay calculation, then pivoted into system design territory with the follow-up. The core problem sounds deceptively simple but there's a lot of edge case territory once you get into state machines and datetime handling.

Questions Asked (2)

Implement a dasher pay calculation system that takes a stream of order events with timestamps (assigned, picked_up, delivered, cancelled) and computes the total pay owed per order using state transitions, base pay rules, and time-based components.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

This one took me a while to even parse correctly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and assumptions, then design a state machine for order lifecycle with well-defined transitions. Model pay as a function of state transitions and time intervals, and outline an event-driven architecture that processes events in order, handling late or out-of-order events.

Pro tip: Emphasize idempotency and exactly-once processing to avoid double-paying dashers, and discuss how you'd handle late events with watermarks or event-time processing.

1. Clarify Requirements and Assumptions

Ask about pay rules (base pay, time-based components, cancellation policies), event ordering guarantees, and whether events can be late or duplicated. Confirm expected scale and latency requirements.

2. Define State Machine and Transitions

Model order states (assigned, picked_up, delivered, cancelled) and valid transitions. Identify which transitions trigger pay components (e.g., base pay on assignment, time-based pay from pickup to delivery).

3. Design Pay Calculation Logic

Break down pay into base pay, time-based pay (e.g., per-minute after pickup), and any bonuses or penalties. Define formulas and how they accumulate based on state changes and timestamps.

4. Architecture for Event Processing

Propose an event-driven system: ingest events into a queue (e.g., Kafka), process with a stream processor (e.g., Flink) that maintains per-order state, and emits pay updates. Discuss exactly-once semantics and idempotency.

5. Handle Edge Cases and Trade-offs

Address out-of-order events, late data, cancellations after pickup, and partial pay. Discuss trade-offs between consistency and latency, and how to reconcile discrepancies.

Key Points to Mention

State machine design with clear transitions and guards against invalid transitions.
Idempotent processing using unique event IDs or deduplication to prevent double payment.
Event-time processing with watermarks to handle late events and out-of-order arrivals.
Time-based pay calculation using timestamps and handling of clock skew or missing events.
Scalability considerations: partitioning by order ID, state management, and fault tolerance.
Trade-offs between exactly-once vs at-least-once processing and their impact on pay accuracy.

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

Convert the dasher pay calculator into an API endpoint. How would you handle request validation, retries with idempotency keys, and failure scenarios?

API & IntegrationsSystem DesignTechnical Trade-offs

Author's notes

Blanked a bit on idempotency key mechanics under pressure.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints of the pay calculator API, then outline a design that covers request validation, idempotent retries, and failure handling. Emphasize trade-offs and how you would ensure reliability and correctness in a distributed system.

Pro tip: Demonstrate awareness of DoorDash's existing infrastructure (e.g., Kafka, Cadence) and how you would integrate with it for idempotency and retries. Also, mention the importance of logging and monitoring for failure scenarios.

1. Clarify Requirements and Scope

Ask questions to understand the expected load, latency requirements, and whether the API is internal or external. Clarify the input parameters and expected output of the pay calculator.

2. Design Request Validation

Outline validation layers: schema validation (e.g., JSON schema), business rule validation (e.g., valid dasher ID, order details), and authentication/authorization. Mention using a validation library or middleware.

3. Implement Idempotency and Retries

Explain how to use idempotency keys to ensure that retries do not duplicate calculations. Describe storing the key and result in a datastore with TTL, and returning the cached result for duplicate requests.

4. Handle Failure Scenarios

Discuss failure modes: invalid input, downstream service failures, timeouts, and partial failures. Describe strategies like circuit breakers, fallbacks, and dead-letter queues for async processing.

5. Ensure Observability and Testing

Mention logging, metrics, and tracing for monitoring. Describe how you would test idempotency and failure scenarios, including chaos engineering and load testing.

Key Points to Mention

Use of idempotency keys with a unique constraint in a database to prevent duplicate processing.
Validation should happen at multiple levels: API gateway, service layer, and domain logic.
Retries should be implemented with exponential backoff and jitter, and only for idempotent operations.
Failure scenarios: handle timeouts, network errors, and downstream service unavailability with circuit breakers and fallbacks.
Consider asynchronous processing with a message queue for long-running calculations, and use dead-letter queues for failed messages.
Monitoring and alerting on error rates, latency, and idempotency key collisions.

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