DoorDash 的题目有一个比较明显的特点：算法本身不一定特别偏，但是很喜欢套进配送、商家、订单这些真实业务场景里。

这次流程主要包括 Coding、Code Craft、System Design 和 Behavioral。

Coding

Given a list of delivery orders, each order has a restaurant ID, ready time and delivery deadline. Group the orders into batches so that orders from the same restaurant can be picked up together while minimizing the number of late deliveries.

给出一组外卖订单，每个订单包含餐厅、出餐时间和最晚送达时间。需要尽可能把同一家餐厅的订单合并配送，同时减少超时订单。

第一步其实不算特别难，主要是排序之后做贪心处理。

但真正的考点在 follow-up。

面试官继续问：

如果订单不是一次性给出，而是不断实时进入系统怎么办？

如果一个 Dasher 一次最多只能携带 3 个订单呢？

如果两个订单来自不同餐厅，但是餐厅距离非常近，是否还可以合单？

到这里，题目就已经不再只是单纯的算法题，而是在看候选人能不能把一个简单解法逐渐扩展成实际系统中的规则。

这类题比较容易犯的错误，就是一开始直接写代码。

更好的做法是先确认：

什么情况下允许 batching？

优化目标究竟是减少骑手数量、减少配送时间，还是减少 late delivery？

这些定义不同，最后的数据结构和算法都会不同。

Code Craft

这一轮更像实际工程题。

Design a simplified API for managing active DoorDash deliveries.

需要支持：

• 创建 Delivery
• 更新订单状态
• 查询某个 Dasher 当前配送的订单
• 取消订单

一开始只需要写一个简单版本。

后面面试官会逐渐加条件，比如：

两个请求同时修改订单状态怎么办？

重复请求怎么处理？

如果订单已经 Delivered，还能不能 Cancel？

这一轮相比“写出最优算法”，面试官更关注代码结构、状态设计以及 edge cases。

System Design

题目是：

Design a real-time order tracking system for DoorDash.

用户下单以后，需要实时看到：

Restaurant Preparing
Dasher Assigned
Picked Up
On the Way
Delivered

同时地图上还需要不断更新骑手的位置。

讨论重点主要集中在几个地方：

订单状态怎么存储；

Dasher 的 GPS 更新是否需要每次都写数据库；

客户端如何实时收到位置变化；

如果短时间有大量订单，系统如何扩展；

消息重复、延迟或者乱序应该怎么处理。

这里没有必要一开始就画一个特别复杂的架构。

比较稳妥的方式还是从最简单的：

Client → API → Order Service → Database

开始，然后再根据实时位置更新、消息量和可靠性要求逐步引入 WebSocket、Queue、Cache 等组件。

Behavioral

最后一轮主要聊项目经历。

其中一个问题是：

Tell me about a time when a project did not go as planned.

会继续追问：

当时为什么会出现问题？

你具体做了什么？

如果重新做一次，会改变什么？

这一轮最好准备几个能够继续深入追问的真实项目，而不是只背 STAR 模板。

整体来看，DoorDash 的面试比较有意思的一点是：

很多题第一眼看起来像普通算法题，但很快就会进入实际业务约束。

所以准备的时候除了刷题，也建议练习：

“简单问题 → 加业务限制 → 加并发/规模 → 讨论 trade-off”

这种连续追问的方式。

csoahelp 目前也在提供北美科技公司面试的 Mock Interview 和实时文本辅助。

如果最近准备 DoorDash、Uber、Stripe、Amazon 等公司的技术面试，可以根据具体岗位和面试轮次针对性准备，尤其是 Coding follow-up、Code Craft 和 System Design 这类比较容易在追问阶段拉开差距的环节。

我们也有代面试，面试辅助，OA代写等服务助您早日上岸~