DoorDash·Software Engineer·Onsite - Multi Round·Intermediate

IntermediatePrefer not to say

May 2026

Summary

DoorDash onsite for a software engineer role, two back-to-back coding exercises that leaned more systems-flavored than pure algorithms. Nothing behavioral, just code and design the whole time.

Questions Asked (2)

Implement a service method that fans out to multiple downstream APIs, merges their responses into a single nested structure, handles transient failures, and retries failed calls. Then write tests covering the success path, a single transient failure, and repeated failures, verifying the full nested output each time.

API & IntegrationsSystem DesignTechnical Trade-offs

Author's notes

The fan-out part was fine, I've done similar things before.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints (e.g., which APIs, retry policy, timeout, idempotency). Then outline a design that uses concurrent fan-out with a retry mechanism (e.g., exponential backoff) and a merge strategy that preserves the nested structure. Finally, describe how you would test the success path, transient failures, and repeated failures, ensuring the full nested output is verified each time.

Pro tip: Mention that you would use dependency injection to mock downstream APIs in tests, and that you would verify retries by asserting the number of calls made to each mock. Also, consider using a library like Polly for .NET or similar for other languages to handle retries cleanly.

1. Clarify Requirements and Constraints

Ask about the number of downstream APIs, expected response times, retry limits, backoff strategy, and whether calls are idempotent. Confirm the desired nested output structure and error handling behavior.

2. Design the Fan-Out and Merge Logic

Use asynchronous calls (e.g., Task.WhenAll in .NET) to fan out to all APIs concurrently. Merge responses into a nested object, handling partial failures by including error details or nulls as appropriate.

3. Implement Retry with Backoff

Wrap each API call in a retry policy (e.g., exponential backoff with jitter) for transient failures. Ensure retries are bounded and that non-transient errors are not retried.

4. Write Tests for Success and Failure Scenarios

Create unit tests with mocked downstream APIs. Test the success path (all succeed), a single transient failure (one API fails then succeeds on retry), and repeated failures (one API always fails). Verify the full nested output structure and that retries occurred as expected.

5. Discuss Trade-offs and Edge Cases

Talk about trade-offs: concurrency vs. resource limits, retry amplification, timeout handling, and idempotency. Mention edge cases like partial failures, timeouts, and how to surface errors to the caller.

Key Points to Mention

Concurrent fan-out using async/await or similar to minimize latency
Retry policy with exponential backoff and jitter for transient failures
Merging responses into a nested structure while handling partial failures
Dependency injection and mocking for testability
Verifying retry counts and full nested output in tests
Trade-offs: retry limits, timeouts, idempotency, and error propagation

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

Given a buggy load balancer implementation, find and fix all the bugs, then add round-robin request distribution. After that, explain how you'd extend it to support consistent hashing for better key affinity and minimal remapping when the server pool changes.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

Bug-finding in someone else's code is weirdly stressful.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by systematically debugging the existing load balancer: identify all bugs, fix them, and verify with tests. Then implement round-robin distribution, ensuring thread safety and proper server health checks. Finally, explain how to extend to consistent hashing, focusing on hash ring, virtual nodes, and trade-offs.

Pro tip: When explaining consistent hashing, emphasize how virtual nodes improve load distribution and how the design minimizes remapping when servers are added or removed. Also, mention that you'd consider using a proven library like Ketama to avoid reinventing the wheel.

1. Understand and Debug

Review the buggy implementation, identify all bugs (e.g., off-by-one, concurrency issues, incorrect server selection), and fix them. Write unit tests to confirm fixes.

2. Implement Round-Robin

Add round-robin distribution by maintaining an atomic counter or index that cycles through healthy servers. Ensure thread safety and handle server failures gracefully.

3. Design Consistent Hashing Extension

Explain how to extend the load balancer to use consistent hashing: build a hash ring with servers and virtual nodes, map requests to servers based on key hash, and handle server additions/removals with minimal remapping.

4. Discuss Trade-offs and Edge Cases

Compare round-robin and consistent hashing: round-robin is simple but ignores key affinity; consistent hashing provides affinity and minimal remapping but adds complexity. Mention edge cases like hot keys and server heterogeneity.

Key Points to Mention

Thread safety in round-robin (e.g., using atomic operations or locks)
Health checks and server pool management (removing unhealthy servers)
Consistent hashing ring with virtual nodes for better load distribution
Minimal remapping: only K/N keys remapped when a server is added/removed
Trade-offs: simplicity vs. key affinity, performance overhead, and implementation complexity
Real-world considerations: using existing libraries (e.g., Ketama), handling hot keys, and monitoring

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