DoorDash 的 Virtual Onsite 往往把算法、设计和行为问题排在同一天。准备时别把它们拆成三套话术：写图题时的约束澄清、设计配送功能时的容量判断、讲项目时的取舍逻辑，其实都在看你能不能把问题讲透。
第一面：带激活节点的树路径
Topic：给一棵二叉树，路径只能连接叶子节点。每个节点带有 active 标记，要求返回经过两个激活节点的最大路径和；如果路径不满足标记条件，就不能参与比较。
解答思路：递归函数返回两件事：从当前节点向下的最佳单支路径和，以及这条分支里是否含有激活节点。合并左右子树时，只有两侧都带激活标记才更新答案。负数分支直接截断为零，但标记信息不能跟着丢掉，否则会把不合格路径误计入答案。代码写完后先测只有一个激活叶子、激活节点在同一支、全负数和根节点本身激活四种情况。复杂度是时间 O(n)，递归栈 O(h)。
第二面：首页餐厅推荐服务
Topic：设计 DoorDash 首页的餐厅推荐服务。用户打开首页后要在较低延迟内看到附近可配送、符合时间段和库存状态的候选餐厅；餐厅营业状态与配送范围会变化。
解答思路：先把请求拆成位置、用户偏好和当前时间三个输入，明确“附近”的定义由配送区域而不是直线距离决定。候选召回服务按配送区域筛餐厅，再合并营业状态、库存和商家暂停状态；排序层读取用户特征和实时上下文。商家状态变化通过事件流更新缓存，缓存键至少包含区域和时段，避免把午餐结果留到深夜。面试里要主动问排序是否需要个性化、库存延迟允许多少、冷启动用户用什么兜底，以及高峰时如何降级到区域热门列表。
第三面：订单路径校验
Topic：给出订单状态序列和一组允许的状态跳转，验证一条订单轨迹是否合法；追问是枚举指定订单数下的所有合法状态路径。
解答思路：把状态和允许跳转建成邻接表，先顺序扫描输入轨迹，任意一步不在邻接集合内就立即返回。枚举追问用 DFS 回溯，路径长度达到订单数时收集结果；如果状态图有环，递归参数里必须带剩余步数，不能只用访问集合把正常的重复状态删掉。面试官往往会继续问状态定义变更后如何兼容，回答可以从版本化规则、灰度切换和历史订单按原规则回放切入。
第四面：HM 追问项目里的分歧
Topic：讲一次你和同事对技术方案意见不一致的经历，并说明最后怎么决定；随后会追问项目里最满意的一处设计和职业上的低谷。
解答思路：选一个有真实约束的故事，例如同步写入改异步队列。先交代当时的失败模式或性能指标，再讲两种方案各自的成本，最后说清用什么证据做决定。别把分歧写成“沟通后大家都同意”，要说出谁担心什么、你补了什么实验或监控、上线后结果怎样。被追问个人贡献时，把自己写过的接口、推动过的评审和处理过的事故分开讲，边界会更清楚。
现场准备怎么排
- 树和图题要练到能先定义状态，再解释为什么合并正确。
- 设计题准备一页草图：输入、候选集、状态更新和降级路径比服务名更重要。
- HM 故事留足细节，特别是数据、反对意见和后来复盘时改掉了什么。
FAQ
DoorDash SWE VO 的 Coding 只看答案吗？
写出主逻辑之后，边界和测试同样会被追问。把状态含义、复杂度和失败分支说清，能让面试官更容易跟上你的代码。
系统设计先画什么？
先画用户请求如何拿到候选餐厅，再补营业状态和配送范围的更新通路。这样讨论排序、缓存和降级时不会散。
参考来源
- LeetCode：DoorDash Software Engineer Virtual Onsite 记录
- Interview Experiences：DoorDash Staff Software Engineer Virtual Onsite
- Interview Coder：DoorDash Software Engineer Interview Guide
关于 CSOFFERPREP
进 VO 前，可以找 CSOFFERPREP 做备考辅导和模拟练习。无论是 OA辅助、OA 辅导、VO 辅助、VO 模拟面试、VO 辅助还是系统设计辅助，都可以按 DoorDash SWE 的 Coding 表达、设计追问和 HM 故事安排训练：CSOFFERPREP 服务详情
