刚收到 Amazon Online Assessment 邀请的时候我其实挺惊讶的——距离我投递简历才过去一周还没有任何面试准备。等真正做完这套 OA我的第一感受是整体难度确实不高但前提是基础算法题刷到位同时对工作场景题Leadership Principles 题有一套自己的答题框架。这篇文章就把我的完整体验、题目类型拆解、解题思路和踩过的坑整理出来希望能给正在准备亚麻 OA 的朋友一个参考。先说结论Amazon Online AssessmentSDE 岗通常包含两道算法题和三道左右的工作场景题整体做题时间在 90 到 105 分钟之间。算法题集中在数组操作、HashMap、双指针、BFS/DFS 等基础题型不会刻意考复杂的动态规划和偏难怪数据结构的题。工作场景题则以行为面试题为主重点考察你是否匹配亚马逊的 Leadership Principles。只要提前做好针对性训练这套 OA 的通过率是相当可观的。1. OA 的整体流程与时间分配别把时间全砸在算法题上Amazon OA 一般会有邮件通知在收到链接后的 7 到 14 天内需要完成具体看你申请的地区和岗位。我当时收到的是 90 分钟版本包含两道算法题 三道工作场景题。邮件里会说明平台要求、浏览器兼容性和网络环境这些细节后面我会专门讲因为确实有人在环境上栽过跟头。1.1 三道题的组成结构与实际体验我先说总体的做题感受。进入 OA 系统后页面会先引导你走一遍规则说明和摄像头检测这个过程大概 5 分钟。随后是三道工作场景题也就是常说的 LP 题每道题都会有大约 20 分钟的回答时间限制形式是视频录制。录制的时候屏幕上显示题目文字同时开启摄像头和麦克风你需要对着镜头讲一段个人经历时长一般在 3 到 5 分钟。三道 LP 题之后就是两道算法题。每道算法题大概有 30 分钟的作答时间平台自带一个代码编辑器支持 Python、Java、C、C# 等主流语言。点击运行时会对样例用例进行评测但不会像 LeetCode 那样一次性看到所有测试用例的结果一部分隐藏用例在提交之后才会给出结果这个机制和 HackerRank 很像。也就是说你得自己多造几个边缘用例去验证。1.2 合理分配 90 分钟的基本策略我建议的分配方式是LP 题 25 到 30 分钟每道算法题 25 到 30 分钟最后至少留 5 分钟检查。很多人的问题不是不会做题而是在 LP 题上发挥不稳导致后面算法题时间紧张。实操上我会先把所有题目快速浏览一遍做到心里有数再去一题一题做。LP 题先抓关键词判断它对应哪个 Leadership Principle算法题则先分析输入约束再确定数据结构和算法思路。记住一个原则宁可每道题都完成到 80%也不要在一道算法题上死磕 100% 而放弃后面整道题。2. 第一道算法题数组操作与 HashMap看起来简单但藏着两个坑第一道算法题拿到手题目描述大概两三段本质上是一个频率统计 排序的问题给定一个包裹 ID 列表需要找出出现频率最高的前 K 个包裹 ID并按照出现次数降序输出如果出现次数相同则按照 ID 升序输出。这个题型我相信刷过 LeetCode 的人都能一眼识别出来就是经典的前 K 个高频元素变种。难度确实不高但 OA 里的坑在于输入约束和排序规则比我预期的更细。2.1 解题思路推演从暴力排序到桶排序的取舍最直观的思路是先做遍历统计再用排序或优先队列解决。我的第一版思路是这样的第一步用 HashMap 遍历一遍数组统计每个元素出现的次数。这一步时间复杂度是 O(n)空间复杂度是 O(n)。第二步把统计结果转化成键值对列表然后按照题目要求的规则排序。这里如果没有次数相同按 ID 升序这个要求直接用优先队列维护一个大小为 K 的最小堆会更高效但有这个要求之后直接排序反而更稳妥因为堆的排序规则要额外处理多级比较器写起来不复杂但容易出错。第三步把排序后的前 K 个元素输出。实际写代码时我用的是 Python 的 Counter 加 sorted代码量很小from collections import Counter def top_k_frequent(nums, k): counter Counter(nums) sorted_items sorted(counter.items(), keylambda x: (-x[1], x[0])) return [item for item, _ in sorted_items[:k]]如果你用的是 Java可以用 Map 加 Stream 处理排序或者自己实现 PriorityQueue 的比较器。我这里要特别提醒一下OA 平台上 Java 代码的编译速度和运行内存是有限的Stream 虽然写起来优雅但在数据量大的时候性能和清晰度都不如传统写法。我当时 Java 版本用的是 HashMap Collections.sort稳一点。2.2 容易踩的两个坑同频排序和用例自测第一个坑是同频排序。很多人做前 K 高频元素习惯只按频率排序忽略了频率相同按值升序这个附加规则。OA 的测试用例里确实会包含这种同频情况如果你没按题目要求处理隐藏用例会直接挂掉。所以拿到题目后第一件事是找排序规则按什么升序、什么降序、优先级怎么排。第二个坑是自测用例准备不足。平台不会把所有测试用例都摆在你面前隐藏用例往往专门用于测试边界条件。我的习惯是写完代码后至少造三个用例空数组、全部元素都相同、包含负数或极大整数。在 OA 页面上自己跑一遍比盲目提交要稳得多。另外如果要展示全面的解法先写暴力解再优化对这个题意义不大。因为它的目标就是考察基础的数据结构熟练度直接给出最优解即可。3. 第二道算法题BFS 找最短路径难度不高但状态表示要小心第二道算法题的场景我印象很深大概是这样的机器人从仓库网格的左上角出发需要到达右下角取货点网格中部分格子是障碍物机器人可以上下左右移动问最少需要多少步。这是一个典型的最短路径问题用 BFS 就能解决。难度确实不高LeetCode 上有很多升级版比如带传送门、带收集物品、机器人可以连续走多步等这道题是把难度降到了标准 BFS。但问题恰恰出在这里越是看起来标准的题越容易在状态表示和边界处理上翻车。3.1 BFS 的思路与代码实现BFS 解决这类问题的核心逻辑就是逐层扩散。我从起点开始用一个队列记录每一步的位置然后用一个 visited 二维数组记录哪些格子已经访问过。第一次到达终点时当前层数就是最短步数。Python 版的实现可以是from collections import deque def min_steps(grid): if not grid or not grid[0]: return -1 rows, cols len(grid), len(grid[0]) if grid[0][0] 1 or grid[rows-1][cols-1] 1: return -1 visited [[False] * cols for _ in range(rows)] queue deque() queue.append((0, 0, 1)) visited[0][0] True directions [(1, 0), (-1, 0), (0, 1), (0, -1)] while queue: x, y, dist queue.popleft() if x rows - 1 and y cols - 1: return dist for dx, dy in directions: nx, ny x dx, y dy if 0 nx rows and 0 ny cols and not visited[nx][ny] and grid[nx][ny] 0: visited[nx][ny] True queue.append((nx, ny, dist 1)) return -1如果换成 Java我一般用一个 int 数组存坐标和步数或者自建一个简单的 Node 类。注意一点不要把步数信息放到 grid 里覆盖原始数据后面调试的时候你会感谢自己没有破坏输入数据。我当时差点为了省空间把 visited 直接写到 grid 上后来想想还是算了SA 的隐藏用例可能还要跑第二个方法输入数据一改全乱套。3.2 边界条件起点和终点被堵住的情况这道题最容易被忽略的边界条件是起点或终点本身就是障碍物。如果你不加判断BFS 一开始就把起点入队visited 标记为 true最后可能返回一个从起点到起点步数为 1的错误答案。我提交前特意加了一个前置判断if grid[0][0] 1 or grid[rows-1][cols-1] 1: return -1这个判断在样例里可能用不到但在隐藏用例里非常常见。我记得当时看到这个题目还花了一点时间考虑0 表示可通过、1 表示障碍还是反过来的不同题目设定不一样这个也值得在写代码前确认。另外还有一个细节如果题目要求返回步数要搞清楚是从 0 开始数还是从 1 开始数。很多版本要求机器人第一步也算一步也就是起点位置步数为 1也有版本定义起点步数为 0。我的建议是读题时圈出来或者在代码里用一个清晰的变量注释掉避免心态紧张时搞混。3.3 为什么 BFS 而不是 DFS可能有朋友会问这题用 DFS 也能做吗能做但没必要。DFS 找到的路径不一定是最短路径除非你遍历所有路径才能取最小值复杂度会爆炸。BFS 第一次到达终点的层数就一定是最短步数这是 BFS 在无权重图上天然具备的性质。我见过有人在 OA 里用 DFS 写这种最短路题最后返回的结果经常比最短路径长。也许样例能过但隐藏用例大概率会挂。所以遇到最少步数、最短路径这类关键词第一反应就应该是 BFS而不是 DFS。这是套路也是经验。4. 工作场景题LP 题门槛不高但答好需要方法很多人对 Amazon OA 的算法题如临大敌对工作场景题反而轻视。实际上按照身边朋友和我的实际体验算法题过了但栽在 LP 题的人并不少见。LP 题虽然看着像讲故事但它有一套自己的评判标准。4.1 三道 LP 题分别考察什么我遇到的三道题大概是这个方向第一道题请你讲一个你主动发现问题并推动解决的经历。 第二道题请你讲一个你需要处理多方不同意见并达成一致的经历。 第三道题请你讲一个你在信息不完整的条件下作出重要决策的经历。从 Leadership Principles 来看这三道题分别对应 Ownership / Bias for Action、Have Backbone; Disagree and Commit、Are Right, A Lot 或 Bias for Action。换句话说亚麻的核心领导力准则是 OA 工作和场景题的出题依据而不是随便聊聊团队协作或者履历故事。4.2 用 STAR 法则组织答案但注意两个升级版要求STAR 法则Situation, Task, Action, Result是回答行为面试题的基础框架但 OA 录视频和真人面试有个很大的区别没有追问环节。你不会有机会补充细节所以每个部分都必须自己说完整。我的操作方式是这样的Situation背景用两三句话交代场景突出复杂度和紧迫感。不要花太多时间铺垫背景重点在 Action 和 Result。 Task任务明确你的职责范围同时指出为什么最终由你来推动。 Action行动这部分要占到答案的一半以上最好拆成两三个具体步骤说明你自己做了什么、怎么协调资源、怎么应对困难。 Result结果量化结果是最关键的。如果你说最后我们按时完成了任务这是一个非常弱的 Result。更好的表述是最后我们提前 3 天完成任务客户满意度从 82% 提升到 95%。我录第二道题时就把一个之前和同事在一个技术选型上意见不一的经历按照这个结构重新组织了一遍。重点讲清楚我是如何用数据说服对方、又是如何在小范围内尝试验证对方方案中的合理部分。整体回答时间控制在 3 到 4 分钟没有超时。4.3 应对 LP 题的素材库准备我强烈建议在 OA 前准备 8 到 10 个经历故事覆盖以下几个主题主动发现并解决问题、处理客户投诉、与同事分歧、在压力下快速决策、长期项目推进、发现流程低效并改进。这些故事不一定要多伟大关键是有细节、有冲突、有量化结果。准备故事的时候每个故事都写一个 300 到 500 字的完整草稿然后练习用口语讲述。为了适应 OA 录题你可以在摄像头前练习两三次注意眼神、语速和手势。不要背稿子但要记结构。背稿子的最大问题是你在录视频时一旦忘了下一句会整个人卡住记结构的话则可以即兴补充反而更自然。5. 备考建议与资源路线两周时间够不够我觉得准备 Amazon OA 两周时间是足够的前提是目标明确、路线清楚。接下来聊聊我实际用过的刷题和准备方式不一定适合所有人但应该具备普适参考价值。5.1 算法题怎么刷按主题突破而不是按数量堆我建议优先刷 LeetCode 的 Top 100 Liked 和 Amazon 高频题。高频题有两个好处一是覆盖常见题型二是很多题目本身就是在 OA 题目基础上改的有很高的参考价值。具体来说以下主题我是重点刷的数组和字符串两数之和、三数之和、最长无重复子串、合并区间HashMap 相关前 K 个高频元素、字母异位词分组双指针盛最多水的容器、移动零、最多水的容器二叉树二叉树的最大深度、层序遍历、最近公共祖先BFS/DFS岛屿数量、腐烂的橘子、课程表这些题量加起来大概 30 到 50 道不需要做太多。每道题都要做到能独立写出来而不是看着题解说我懂了。我自己的标准是把编辑器关掉白纸上画一下思路然后不看任何参考写完整代码再自己造几个用例验证。5.2 刷题语言的选择Python 还是 JavaOA 平台支持多种语言你的选择会影响答题速度。我自己在 OA 里用了 Python因为代码量少、API 丰富。比如 Counter、deque、sorted 一下子就能解决很多问题写起来几乎是带着代码提示在打字。但如果你更熟悉 Java就用 Java。LeetCode 上很多题解都是 Java面试官对 Java 的代码可读性也有较高接受度。这里我要提醒一个点无论选哪种语言都要提前在模拟平台上熟悉它的输入输出格式和评测机制。OA 平台有时候不会自动帮你处理输入输出你得自己写 Scanner 或 input()这个细节会浪费你不少时间。5.3 如何处理时间不够用的情况如果你只有一周时间我的建议是放弃那些偏难题比如动态规划中的复杂状态压缩、图论中的高级算法把精力集中在核心题型上。Amazon OA 的算法题难度大致相当于 LeetCode Easy 到 Medium 之间只要把数组、哈希表、双指针、BFS/DFS 这几类基础题练熟通过概率已经很高了。更有策略性的做法是按资源来分配如果是系统设计类岗位,那你需要了解的知识面会更广但 OA 的算法题部分基本一致。如果时间紧张刷题时可以先做 Easy、再做 MediumHard 题可以直接跳过。我看过一些朋友花大量时间死磕 Hard 题结果 OA 里根本没有这种难度属于典型的复习跑偏。6. 踩过的坑和实用经验环境、心态和细节真的很影响发挥最后这部分我想分享几个 OA 过程中我自己踩过的坑和一些实用经验这些往往是常规面经不会写的内容。6.1 环境准备网络、摄像头、浏览器缺一不可OA 一般需要开启摄像头有些还会录制屏幕。我当时在家做提前一小时检查了摄像头和麦克风结果发现浏览器权限没有打开。这里建议你至少提前一天做一次模拟测试确认摄像头、麦克风、屏幕共享都正常。另外OA 平台通常对浏览器有要求Chrome 支持最好。如果你开了多个电脑端的远程控制软件可能会被系统识别为切出页面这样会标记违规。我的做法是只开 OA 页面和必要的本地代码编辑环境别开任何其他软件。这个细节千万注意因为一旦被判定切屏轻则提示警告重则直接取消成绩。6.2 看到题目先不要急着写代码做算法题时有一个非常常见的心理陷阱看到题目仿佛见过就立刻开始写代码。这种冲动往往会让你忽略题目中某些关键差异。正确的顺序是先读题两遍确认输入输出的形式和约束范围然后在代码编辑器里写清注释再开始实现。我在第二道算法题上有点想当然地以为地图一定不为空差点漏掉空数组的处理。还好我留了一个检查步骤造了个极端用例及时发现了问题。6.3 别忘了给自己留出复查时间很多人在 OA 结束前最后一分钟还在改代码这其实很危险。一道题的评分不只取决于测试用例是否通过还取决于代码的整体逻辑和可维护性。如果因为匆忙改动引入了语法错误会前功尽弃。我的建议是每道算法题写完至少留 5 分钟复查主要看三件事输入边界、递归或循环终止条件、是否有多余的占用空间。代码长度不追求极简但要保证自己一眼能看懂。这个习惯不仅适用于 OA对你的工程实践也有帮助。6.4 心态管理把 OA 当作一次普通的编程练习最后说一个和技能无关但很重要的事情心态。Amazon OA 的通过与否直接关系到下一轮面试机会紧张是自然的。但越紧张越容易在基础题上出错。我自己的体会是把 OA 当成一次普通的编程练习目标不是我一定要通过而是我要把这套题尽量完整地做下来。一旦放下了思想包袱你的思路会清晰很多。我在答 LP 题的时候就把它当作和朋友讲故事而不是一个被评判的考试。这种心态上的放松反而让我的表达更自然逻辑也更清楚。如果你能从现在开始把基础算法题刷扎实再把 8 到 10 个 STAR 故事准备好最后注意环境检查和时间分配那么这套 Amazon Online Assessment 通过的可能性已经非常高了。祝顺利。