整理了几份 DoorDash 的面经之后，一个非常明显的特点是：流程标准化、题库稳定，但节奏快、信息密度高。整体结构通常包括 CodeCraft、System Design、Debugging、Behavioral，再加上一轮偏 AI 或 workflow 的 coding。题目本身很多来自高频题库。

CodeCraft：不是算法，是工程实现能力

CodeCraft 可以理解为 DoorDash 特有的一类 coding round，更像是快速实现一个业务模块，而不是传统算法题。高频题包括 Dasher payment、Aggregated Bootstrapper API 等。比如 dasher pay，本质是根据规则计算配送员收入，但难点在于规则多、数据复杂，而且 follow-up 非常多，比如 peak hour 处理、异常数据处理等。

这一轮的关键不是算法难度，而是你能否快速把需求转成清晰的逻辑，并且写出结构合理的代码。很多人卡在时间不够，其实问题不在不会，而是在前期理解和设计花太久。一个很典型的坑是用 TDD 的方式慢慢写，这在时间充足的情况下是好习惯，但在这个场景下反而会拖慢节奏。更好的策略是先把主逻辑写出来，确保可以跑通，再补边界和测试。

Debugging

Debugging 轮也是 DoorDash 的特色之一，而且非常工程化。常见题包括 Round Robin、Dasher map、pick dasher 等。这一轮不会让你写很多代码，而是给你一段有 bug 的系统，让你快速定位问题并修复。典型 bug 包括 hashmap 初始化错误、null pointer、key 使用错误等。

但这一轮不只是找 bug。很多情况下，修完 bug 之后还会有 follow-up，比如让你写 test case，或者讨论如果是 production code 应该怎么改。有些题还会延伸到系统设计，比如让你用 TreeMap 手写 consistent hashing。这一部分代码量不小，如果时间不够，可以主动和面试官沟通先写一个简化版本。这一轮其实在考察你真实的工程经验，包括你如何读代码、如何定位问题、以及你对系统稳定性的理解。

System Design：经典题，但会深挖细节

System Design 基本都是高频题，比如 review + reward 系统，或者 3-day donation 这样的支付系统设计。这些题表面上看不难，但面试官往往会挖得很深，尤其是在支付相关场景。比如你需要考虑 idempotency key 的设计，对账和审计系统，webhook 的处理，以及异步系统如何保证 exactly-once。

一个很重要的点是，不同设计选择会导向完全不同的系统架构。比如支付流程是 redirect 还是 iframe，这会直接影响你是否需要引入异步消息系统来解耦服务。如果一开始没有和面试官对齐假设，后面很容易走偏。另外，有些面试官会刻意增加压力，比如不断打断、challenge 你的方案。这种情况下更需要你主动掌控节奏，把关键设计点讲清楚，而不是被带着走。

总体来说，这一轮的核心不是画架构图，而是你是否理解系统中的关键 trade-off。

AI Coding / Workflow：新趋势，偏系统 + 编程结合

有些面经中出现了 AI coding round，这一轮比较新颖。典型题是让你实现一个 workflow engine，用来处理延迟配送场景。用户可以用文本描述 workflow，每个 step 是一个 node，系统需要解析这些描述并执行，比如触发全额或部分退款。

这一轮的难点在于，它结合了 parsing、系统设计和代码实现。你不仅要定义 workflow 的数据结构，还要设计执行逻辑。更特别的是，还需要你设计 AI-generated test cases 来验证代码。这其实是在考察你如何利用 AI 工具辅助开发，以及你对系统正确性的理解。

Behavioral：标准问题，但看重实际经验

Behavioral 部分整体比较常规，包括 conflict、feedback、failure、most impactful project 等。但有一个特点是，问题会尽量贴近业务场景，比如如何处理丢失订单、错误订单等。这类问题更看重你是否有实际经验，而不是泛泛而谈。另外，hiring manager 轮通常会围绕你的项目展开，重点是确认你是否能在他们的业务中快速发挥作用。