Design an API for pay computation with retries

Quick Overview

Assesses the candidate's ability to design robust HTTP APIs covering endpoint modeling, request/response schemas, datetime formats, idempotency strategies, retry semantics, validation/error codes, and observability for pay-computation services.

Design an API for pay computation with retries

Company: DoorDash

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Take-home Project

You’ve implemented logic that computes a dasher’s pay from order event logs (events include timestamps and state transitions). Design an HTTP API to expose this as a service. Cover: - Endpoints (e.g., compute pay for a dasher over a time window; submit events; query results) - Request/response schema (including datetime formats) - Idempotency strategy (to safely handle client retries) - Failure handling and retry semantics (client vs server retries, timeouts, backoff) - Validation and error codes - Observability (logging/metrics/tracing) Assume this API will be called by other internal services and must be robust to duplicate requests and partial failures.

Quick Answer: Assesses the candidate's ability to design robust HTTP APIs covering endpoint modeling, request/response schemas, datetime formats, idempotency strategies, retry semantics, validation/error codes, and observability for pay-computation services.

|Home/Software Engineering Fundamentals/DoorDash
DoorDash logo
DoorDash
Jan 14, 2026, 12:00 AM
mediumSoftware EngineerTake-home ProjectSoftware Engineering Fundamentals
11
0

You’ve implemented logic that computes a dasher’s pay from order event logs (events include timestamps and state transitions).

Design an HTTP API to expose this as a service. Cover:

  • Endpoints (e.g., compute pay for a dasher over a time window; submit events; query results)
  • Request/response schema (including datetime formats)
  • Idempotency strategy (to safely handle client retries)
  • Failure handling and retry semantics (client vs server retries, timeouts, backoff)
  • Validation and error codes
  • Observability (logging/metrics/tracing)

Assume this API will be called by other internal services and must be robust to duplicate requests and partial failures.

Loading comments...