Amazon SDE NG 的四轮 VO 往往排在同一天。每场接近一小时，前一轮刚收尾，下一位面试官就会进来。写出主逻辑只是起点，边界、复杂度、测试和 Leadership Principles 的追问都会落在细节上。
第一面：BQ
开场先聊了紧 deadline 下推进项目的经历，随后进入任务依赖图题。
给定一组依赖关系 A -> B，找出某个任务延期后受影响的所有下游任务。追问是找出最长的连锁延期路径。
解答思路：先确认 A -> B 表示 B 依赖 A，再按这个方向建立邻接表。从延期任务出发做 DFS 或 BFS，就能找到所有可达的下游任务。用 visited 记录访问过的节点，避免同一个任务经不同路径到达时被重复加入结果。
最长路径需要先确认图是否为 DAG。如果是，可以用记忆化 DFS 计算每个节点向下的最长路径，并记录下一步节点来还原路径。如果允许成环，则需要先明确循环依赖的处理规则。
测试可以用一个分叉后又汇合的例子：A 影响 B 和 C，B、C 又都影响 D。这样能检查 D 是否只返回一次，以及最长路径是否正确。
第二面：Coding
这一轮先做 Sliding Window 变体，随后做 Tree 变体。
现有题目描述没有交代窗口的有效条件，也没有说明树题需要返回什么，因此无法还原具体解法。这部分保留题型信息即可，不宜直接套用某一种滑动窗口或回溯模板。
练习这类双题轮时，可以给第一题设一个自测节点：主逻辑写完，先跑样例、检查边界，再开始第二题。否则第一题留下的小问题，很容易拖到两道题都写完才发现。
第三面：OOD 设计一个包依赖系统，并实现核心方法
这一轮是 OOD 加 Coding。题目要求设计一个 package system，每个包可以依赖其他包，支持注册包、添加依赖、查询依赖闭包，并处理循环依赖。
解答思路：可以先定义 Package 和 PackageRegistry。前者保存包的标识与直接依赖，后者管理包的注册和查找。
查询依赖闭包时，从目标包向下遍历，用集合保存结果。环检测需要区分“已经处理完的节点”和“当前递归路径上的节点”：遇到前者可以跳过，遇到后者说明存在循环依赖。
添加依赖时也要检查。例如准备添加 A -> B，如果 B 已经能沿依赖关系到达 A，这条新边就会形成环，应按接口约定拒绝操作。
写代码前，先约定几个行为：重复注册怎么处理、依赖的包不存在时返回什么、查询结果是否包含自身。这些决定会直接影响方法实现和测试。
版本管理、更新失败后的回滚可以作为额外练习。如果扩展到这些需求，再讨论版本比较规则和更新的原子性，不必在最初的设计里一次性加入所有功能。
第四面：BQ+项目
这一轮以行为问题为主，涉及 Ownership、Dive Deep、Earn Trust、Deliver Results 等 LP，也会聊到项目中的技术决策。
问题包括：
- 时间很紧时，你如何决定哪些工作先做、哪些延后？
- 有没有一次，你承担了原定职责之外的工作，并把事情推进到结束？
- 谁不同意你的决定？你们后来怎么解决分歧？
- 结果不如预期时，你做了什么？
回答思路：背景交代到面试官能理解问题即可，多留时间讲自己的判断和行动。
例如讲 deadline 下的取舍，需要说清哪些需求被延后、为什么这样选、和谁确认过，以及这次取舍带来了什么影响。只说“协调资源，最终按时交付”，后面很难接住追问。
涉及团队成果时，要区分自己完成的部分和同事负责的部分。结果有数据就说明数据和统计口径；没有明确数字，也可以讲交付结果、用户反馈或后续改动，不必为了量化而硬凑。
四轮 VO 怎么准备
算法练习可以按接近一轮面试的时长计时，把读题、沟通、实现和测试都算进去。图题重点练依赖关系、可达性和环检测；对象设计则练到能把接口写出来，并处理无效输入。
LP 可以先整理六个项目故事。每个故事记下当时的限制、你做的决定、结果，以及最容易被追问的地方。练习时让对方打断你问细节，检查自己是否真的能解释当时的选择。
如果四轮安排在同一天，提前确认每轮时间和中间的休息间隔，准备好水、纸笔与电脑供电。
关于 CSINTERVIEWHELP
需如果你也在准备 Amazon 的OA/VO、NG 或其他大厂的OA，感觉复习效率低、方向模糊，欢迎联系 CSINTERVIEWHELP 的 OA 辅助、VO 辅助和系统设计辅助：查看服务详情。
