企业官网建设流程全解析

不用铺垫太多，这几个月我陆续经历了多家北美大厂的在线测评，上周刚把Amazon的OA做完。刚好最近身边好几个朋友在准备亚麻的面试，问到我Online Assessment的体验，干脆把这次的完整记录整理出来。

先说结论：Amazon的Online Assessment整体难度在北美大厂里属于中等偏下，重点不在“难倒你”，而在“筛掉明显不合格的人”。但正因为如此，它考察的东西很明确——你能不能写干净的基础算法代码、能不能用他们的行为准则（Leadership Principles，LP）讲故事。这两块我都展开讲讲，包括题目类型、时间分配、踩过的坑，以及我自己的复盘心得。准备投亚马逊或者正在OA阶段的朋友，这篇可以直接当参考。

1. OA整体结构与考察目标拆解

1.1 一次OA到底考什么

Amazon的OA一共三个环节，两个是算法题，一个是工作场景题。整体时长大约两小时，但这只是系统默认的时间，实际做题的时候比想象中要紧张，尤其是第一道算法题如果卡住，后面的节奏很容易被带崩。

三道题的结构如下：

第一道算法题是LeetCode中等偏简单的难度。考察的多是数组、哈希表这类基础数据结构，实际做下来感觉就是“基本功检测”。第二道算法题是LeetCode中等偏难的难度，通常涉及DFS/BFS、双指针、动态规划或者贪心思想，需要你能把问题抽象成熟悉的模型，再写出一个复杂度合理的方案。第三道是工作场景题，不是写代码，而是模拟你在亚马逊当SDE（Software Development Engineer，软件开发工程师），遇到各种日常工作中的情境，让你选择怎么处理。

其实这个结构挺有代表性的。亚麻的OA这么多年一直是这个配方，核心逻辑很清晰：先确认你能写代码，再确认你能用代码解决实际问题，最后确认你这个人“合不合亚麻的文化”。

我个人的体感是，前两道算法题才是整个OA里真正起决定性作用的关卡。第三道工作场景题只要能正常表达，不出现明显违背常识的极端选项，一般不会是挂人的关键。真正拦人的，还是那两道算法题。

1.2 为什么难度不高但要重视

很多人看到“难度不高”就会放松警惕，这是最大的误区。Amazon的OA难度确实不算高，但它是“宽进严出”的筛选器——题不难，但提交了错误答案就是错误答案，没有面试官给你解释的机会，也没有“思路对了给点分”这种说法。

而且Amazon OA还有一个硬性要求：所有代码必须一次性编译通过。你在代码编辑器里写得再好，只要最终交上去是编译错误或者超时，这一轮就直接挂了。不像现场面试还有追问和引导，OA是一个纯结果导向的考核，代码跑不跑得通、复杂度合不合理，系统一看便知。

另外要注意的是，OA的题目难度是相对稳定的，但每一轮的题目组合会有差异。有人遇到的两道算法题都非常基础，有人第二道就明显偏难。这种随机性也意味着，不能只刷easy题碰运气，中等偏难的题必须练到手熟。

还有一个容易被忽略的点：OA的时间压力是真实存在的。系统默认给的时间看上去宽裕，但你要留出时间读题、想思路、写代码、测试边界情况，如果再有debug，时间很快就没了。后面我单独写一节时间分配，这里先提个醒——平时练习尽量卡着时间做，不要慢悠悠地写完就算完事。

2. 算法题深度拆解：两道题到底考什么

2.1 第一道题：高频考点的“送分题”也不能大意

我这次遇到的第一道题是数组相关的题目，大致意思是给定一个数组，要求找到某种符合条件的元素对或者子序列，输出对应的数量或者结果。具体题目我不方便直接贴出来，因为OA题目是“内部题库”，反复贴原题对后来的同学反而是误导——但考点完全可以说清楚。

这种题的典型套路就是哈希表。你只要能想到用哈希表记录已出现过的状态，基本上十秒钟就能确定方案。比如“两数之和”的OA变体题，核心思路是先遍历数组，每到一个元素就判断“目标值减去当前值”是否已经在哈希表里，如果在，就找到了一对；如果不在，就把当前值加进去。

第一道题之所以放在开头，我觉得有一个很实际的原因：Amazon想用一道不太烧脑的题过滤掉“完全没刷过题”的候选人。毕竟OA是海量候选人共同参与的环节，必须有一道题能让大部分合格的人快速通过、拿到基础分，否则整个筛选机制就没有区分度了。

但这道题本质上有几个暗坑，容易在看似简单的地方翻车：

一是边界条件和空输入。数组为空、只有一个元素、全部元素相同、结果不存在，这些情况都要提前想好。二是时间复杂度的细节，哈希表解法是O(n)，但如果你在循环里嵌套了循环去查哈希表，表面看是O(n)，实际可能因为写得不干净变成O(n²)。三是返回值的形式，题目要的是数量还是下标、顺序有没有要求，这些细节在提交前必须确认清楚。

我的建议是，第一道题控制在20分钟以内完成，包括读题、写码和自测。如果20分钟还没有清晰思路，说明平时哈希表这一类的题刷得太少，需要针对性补强。

2.2 第二道题：算法能力的“分水岭”

第二道题才是OA真正筛人的地方。我这次遇到的是和图遍历相关的题目，典型的解法是DFS/BFS。它给的场景是一个网格或者图结构，让你判断连通性、路径是否存在、或者满足条件的最小步数。

这种题只要识别出“图遍历”的本质，难度就降低了一半。关键是怎么识别——我总结了几个信号：出现二维网格、矩阵、邻接表这样的输入；问题是“能否到达”“最短路径”“最大连通区域”；需要用“上下左右”之类的方向移动。出现这些信号，脑子里要立刻跳出DFS/BFS两兄弟。

DFS适合“是否存在一条路径”或者“有多少条路径”的问题，缺点是递归深了容易栈溢出，迭代写法需要手动维护栈。BFS适合“最短路径”和“最少步数”的问题，天然逐层扩展，找到目标时一定是最短的。

我当时用的是BFS，因为在网格题里BFS的写法相对模板化，不容易在递归深度上出问题。整个代码结构大致是：用队列维护当前节点，用一个visited数组防止重复访问，用方向数组控制上下左右移动，然后循环弹出节点、判断是否满足条件、把相邻的合法节点继续入队。

这里有一个高频的优化点：有些题目里visited数组可以改成原地标记，直接把值改成特殊数字来标识已经访过。能省掉不少额外空间，代码也更简洁。

这道题的时间体感明显比第一道紧张，我大概用掉了35到40分钟才完成，主要是调试了一个边界情况：网格只有一个格子的时候，我的代码会误判成无法到达。这类边界问题在LeetCode上其实很常见，建议平时把“空输入”“单元素”“全边界”这些特殊case列成一个自查清单，做题的时候挨个过一遍。

2.3 算法题复习的必要性：LeetCode必刷基础不要跳

说完这两题，我想重点提一句：如果你正打算面Amazon，千万不要因为OA简单就跳过基础题环节。LeetCode上的必刷基础题，比如Two Sum、Valid Parentheses、Binary Tree Level Order Traversal、Number of Islands、Climbing Stairs、Longest Substring Without Repeating Characters，这些题是OA题目的“母题”，几乎所有的OA变体都是基于这些经典题加了一层外壳。

比如第一道题，外壳可能是“找一对商品凑够预算”，本质还是Two Sum；第二道题，外壳可能是“网格上的机器人避开障碍物”，本质还是BFS最短路径。剥开外壳之后，考的还是那些最核心的基础能力。

我的建议是：

• 按数据结构刷，不要按题号刷。数组、哈希表、链表、二叉树、图、动态规划各刷一定数量，比刷三百道散题要系统得多。
• 每题至少掌握两种语言（如果时间允许），至少一种语言要达到“不看API文档直接写出来”的熟练度。
• 刷题过程中把“提交通过”当最低标准，更重要的是复盘：你这道题为什么想到这个解法？还有没有更优解？空间能不能再少？

我当时用的语言是Python，因为OA里Python写起来最省时间，尤其是处理字符串和列表时比Java、C++都简洁。如果你对Java更熟，也没问题，Amazon OA本身支持多种语言，选你最熟练的就好。但要注意，有些题用Python可以几句写完，用Java可能要多写三五行，这种差距在计时环境里会被放大。

3. 工作场景题：比想象中重要的“第三题”

3.1 工作场景题到底长什么样

工作场景题是Amazon OA很有特色的一个环节，其他公司基本没有。它的形式是：给你一个工作场景描述，下面列出4到5个选项，让你选择“在这种情况下你会怎么做”，以及“你最不会怎么做”。不是做题，而是模拟你是否具备亚马逊人（Amazonian）的工作思维。

我遇到的几个场景大概覆盖了这几种类型：你负责的项目快要上线了，但发现一个潜在的缺陷，要不要告诉经理？你的同事跟你意见不一致，认为自己方案更好，怎么办？你的项目延期了，但另一个项目组希望你帮他们赶工，怎么处理？你的代码上线后出现了一个小概率问题，影响面很小，是先报告还是先修复？

每个场景都没有标准答案，但有明显的“亚麻偏好”。你需要把Leadership Principles往选项里套。比如遇到项目缺陷，正确答案往往和“最高标准（Insist on the Highest Standards）”以及“客户至上（Customer Obsession）”相关——你要主动暴露问题、宁可推迟也不牺牲质量；同事意见不一致，要体现“深入探究（Dive Deep）”“强烈表达观点并承诺付出（Have Backbone；Disagree and Commit）”；时间冲突的时候，要优先对客户影响大的事情，同时跟领导沟通排优先级。

3.2 答题技巧：别凭直觉，先搭STAR框架

工作场景题最简单的答法是完全凭直觉，但这种情况很容易踩中“极端选项”。我带大家看一下它的选项逻辑——每个场景的选项里，都会有一个“特别激进”的选项：比如同事不同意你的方案，就自己偷偷按原方案做；项目有缺陷但影响面小，就当成没看见先上线。这些选项就是为了筛选掉不具备基本职业素养的人。

正确的答法是用STAR框架去套：情境（Situation）、任务（Task）、行动（Action）、结果（Result）。先看场景属于什么情境，再想涉及哪些LP，最后选那个最能体现“主动、坦诚、为结果负责”的选项。

举个例子，如果场景是“项目上线前发现缺陷”，先拆解：缺陷影响面有多大？上线窗口期还来不来得及修？谁是决策者？然后按LP排序，最高标准要求你不能放任缺陷上线；客户至上要求你优先考虑客户体验；假设自己是owner（Ownership）要求你不仅仅指出问题，还要给出修复方案和时间表。综合下来，答案应该落在“主动向经理汇报，说明影响面和修复方案，评估是否符合上线标准”这类选项上。

但反直觉的是，很多人在这种题上栽跟头，是因为选成了“自认为正确但不符合亚麻口味”的选项——比如以“按时交付”为第一优先级，试图等上线后再补。这个逻辑在日常工作里是合理的，但亚麻的文化是“先做对的事，再讨论时效”。所以复习期间，一定要刻意训练自己“先看价值观，再看纯业务逻辑”的答题习惯。

还有一个细节：工作场景题不仅问你“会怎么做”，还会让你选“最不会怎么做”。这个后面的问题更考验敏感性，因为你要反向避开那些和LP完全相悖的选项。比如“自己默默处理”“隐瞒缺陷”“推卸责任”这类的，基本就是“最不会做”的必选。

3.3 复习工作场景题的正确姿势

很多人觉得工作场景题没法准备，只能临场发挥，其实不是。Amazon把Leadership Principles贴在官网，一共16条，这些就是工作场景题的题库范围和答案来源。

建议不要在OA前两天才开始看LP，因为光记住条目没用，得能快速判断一个场景和哪些条LP关联。我当时的方法是把LP分成几个组理解：

• 客户相关：Customer Obsession（客户至上）、Ownership（主人翁精神）、Insist on the Highest Standards（坚持最高标准）
• 决策相关：Dive Deep（深入探究）、Have Backbone（有骨气）、Disagree and Commit（有异议但会承诺）
• 合作相关：Learn and Be Curious（不断学习）、Hire and Develop the Best（招纳培养最佳人才）、Deliver Results（达成目标）
• 自我相关：Frugality（节俭）、Earn Trust（赢得信任）、Strive to Be Earth’s Best Employer（成为全球最佳雇主）、Success and Scale Bring Broad Responsibility（成功和规模带来巨大责任）、Are Right, A Lot（经常做对的选择）、Invent and Simplify（创新和简化）、Bias for Action（崇尚行动）

做工作场景题的心态可以调整为：你是演员，题目是剧本，LP就是人物设定。不用“自己平时会怎么做”来回答，而用“一个合格的亚马逊人应该怎么做”来回答。这不是教你虚伪，而是OA本来就是一个“你与公司文化是否匹配”的测试，顺着文化答题不是投机取巧，是对双方的尊重。

4. 实战流程与时间管理：两小时应该怎么分配

4.1 OA环境的两个细节

进入OA之前，有三件事需要提前准备好，不然容易手忙脚乱。

第一，摄像头和屏幕共享。Amazon的OA是需要开启摄像头的，系统会记录你的屏幕和影像，用于防止作弊。环境要安静、光线不要太暗、网络要稳定，中途断网虽然可以恢复，但白白浪费几分钟时间很不划算。

第二，IDE的使用。OA的代码编辑器不是LeetCode那种傻瓜式编辑框，更像是一个简化版IDE，支持多种语言，可以本地编译和运行测试用例。它不会像LeetCode那样给你一堆现成的示例用例挨个跑，更多时候是你自己手动输入测试数据。所以平时练习时要习惯“自己构造测试用例”，而不是依赖平台自动判题。

第三，不要开其他浏览器窗口或者切出去查东西。屏幕共享状态下，切屏幕是很明显的操作，不要赌系统检测不到，也不要赌监考官看不见，得不偿失。

4.2 做题节奏：前紧后松，绝不留白

两小时三道题，我建议按“20分钟 + 40分钟 + 30分钟”来划分做题时间，剩下30分钟用于整体检查和填工作场景题。为什么前面要留这么紧凑的节奏？因为第一道题必须是“秒杀”的，如果第一道题花了30分钟以上，后续的压力会非常大。宁可第一道题略微放弃完美的可读性，也要保证快速完成一个可跑的版本，如果时间富余再回来优化。

第二道题40分钟看起来不少，但实际上写一个DFS/BFS加上调试，半小时起步是常态。如果这40分钟过了一半还没想清楚算法结构，就赶紧换个思路，别在一种解法的死胡同里硬扛——比如你发现DFS写的递归层数太多可能超栈，那就果断换成BFS或者迭代法，改起来虽然费时间，但起码能跑出正确结果。

工作场景题别看它不写代码，30分钟三道左右的情境题思考量不小。快的话20分钟做完，但建议多留时间给“最不会做”那一问的反向思考，这个比正向选择容易走神。

4.3 检查环节：最后十分钟只做三件事

很多人在时间充裕的时候喜欢反复改代码，反而越改越乱。我的经验是，代码提交前只做三类检查：

一、边界条件。数组空、数量为1、目标值不存在、网格只有一个格、全是障碍物，这些极端情况跑一遍。判断标准是“这段逻辑是否覆盖了所有可能的输入”，而不是“我心虚不心虚”。

二、复杂度核对。明确自己在提交的解法是O(n)还是O(n²)，O(n²)在OA提示的输入规模下会不会超时。如果超时风险大，哪怕代码正确也不能直接交，必须换方案。

三、返回类型与格式。题目要的是列表还是整数、顺序是否有要求、对结果有没有排序要求。这些都是“提交前一眼能确认的事情”，但漏掉的人每年都不少。

我在最后检查时发现过一次问题：某道题我返回的是整数数量，但题目要求的是具体组合的列表。当时还剩十来分钟，还好及时发现重新改了返回类型，不然后果不堪设想。这种低级错误是最冤的，希望大家都不要踩。

5. 我踩过的坑与复盘总结

5.1 三个可以提前避开的坑

第一，刷题笔记不要只记代码。我早期刷题时只把通过的代码存下来，后来发现完全没用。真正有用的是记录“这道题的识别技巧”——什么关键词出现时该想到什么算法，边界条件有哪些，当时的错误思路错在哪。这些备注式笔记在面试前突击时才真正有复盘的效率。

第二，不要忽视Python的语法手熟度。OA写Python的确省时间，但前提是API记得牢。我在场上一度忘了collections.deque的导入方式，折腾了半分钟，半分钟放在平时不算什么，但在计时环境下会打乱节奏。建议在OA前把常用库的导入、常用方法过一遍手，哪怕只是默写一遍。

第三，不要带着“模拟题不重要”的心态进入工作场景题。我自己在模拟练习时也踩过这个心态的坑——总觉得这是选择题，选一个顺眼的就行，但后来对比错题才发现，光靠直觉选，正确率只有一半多一点，用LP的思路去选之后才基本稳定。

5.2 常见问题速查表

总结一下，这几天被朋友问到最多的问题，整理成一个速查表格：

5.3 最后再聊几句OA后的心态

在线测评只是整条面试链路的第一关，哪怕OA发挥一般，也只是漫长过程的一次热身。我自己的感觉是，Amazon OA更像一次和亚麻文化的“预接触”——它考察的不只是题能不能解出来，还在于你能不能理解他们的行为准则、能不能在压力下保持稳定的输出。

整个准备过程，实际上也是对自己基础功的一次全面体检。如果你也正打算投这家的SDE岗位，我建议把OA当成一次“检测自己哪里还需要补”的机会，认真对待但不用过度紧张。题目数量有限、题型固定，练熟高频考点、熟悉行为准则，剩下的交给稳定发挥。