更新题目 Work Simulation 与 Work Style
题目 amazon-oa-work-simulation · 修改（rev 5） · · 2026-10-27 00:33
body
@@ -1,9 +1,18 @@ +## TL;DR + +- 每一屏先看背景和发消息的人，再看问法和量表方向，先挑出最差和最好的选项，中间的再细分（思路的「先弄清楚它在考什么」）。 +- 截图里的量表左边是 Not at all Effective、右边是 Extremely Effective，开始前确认一次方向（易错点）。 +- 把明显差的打到 1–2、明显好的打到 4–5，比纠结一个好选项该打 4 还是 5 重要（思路的「先弄清楚它在考什么」）。 +- 人际和流程题选自己担起来、坏消息早说并带计划、风险直接交给负责的人、客户和测试不让步的选项（思路的「人际和流程场景」）。 +- 设计取舍题先从背景里找需求，业界常规做法和托管服务打高分，靠人工救火的打最低分（思路的「设计取舍场景」）。 +- Work Style 凭第一反应答、前后一致，往 SDE 的岗位画像上靠，别全选最极端的一档（思路的「Work Style 怎么答」）。 + ## 题目 -Amazon 的 OA（online assessment，在线笔试）先考编程，包括算法题和 [[q:amazon-oa-ai-debug]]；编程之后还有一段不考编程的部分，本页讲的就是这一段。各篇帖子对它的叫法很不统一，有 Work Simulation、Workplace Simulation、工作情境测验、Communication、Work Style Survey / Assessment、Survey、BQ（behavioral question，行为题）、LP 问卷、性格测试，还有人写成「behavioral type design choice questions」或「BQ / LP / SD 选择题」（SD 指 system design）。这些说的其实都是下面两样东西，有的帖子里还多一个约 5 分钟的小测试。这几部分全是选择题，不用写文字回答，也不用写代码。 - -LP 是 Leadership Principles 的缩写，指 Amazon 公开的一套领导力准则，比如 Ownership（把事情当成自己的事、负责到底）、Customer Obsession（一切从客户出发）。Amazon 的行为面试围着这套准则问，这一段的选择题，发帖人们也普遍说要按它来选。 - -帖子里的 SDE I、SDE II 是 Amazon 软件开发工程师（Software Development Engineer）的级别，I 是入门级，II 高一级。各帖的写法不统一（也有写成阿拉伯数字、加连字符的），下文沿用原帖的写法。 +Amazon 的 OA（online assessment，在线笔试）先考编程，包括算法题和 [[q:amazon-oa-ai-debug]]。编程之后还有一段不考编程的部分，本页讲的就是这一段。各篇帖子对它的叫法很不统一，有 Work Simulation、Workplace Simulation、工作情境测验、Communication、Work Style Survey / Assessment、Survey、BQ（behavioral question，行为题）、LP 问卷、性格测试，还有人写成「behavioral type design choice questions」或「BQ / LP / SD 选择题」（SD 指 system design）。这些叫法说的都是下面两样东西，有的帖子里还多一个约 5 分钟的小测试。几部分全是选择题，不用写文字回答，也不用写代码。 + +LP 是 Leadership Principles 的缩写，指 Amazon 公开的一套领导力准则，比如 Ownership（把事情当成自己的事、负责到底）、Customer Obsession（一切从客户出发）。Amazon 的行为面试围着这套准则问，发帖人们也普遍说这一段的选择题要按它来选。 + +帖子里的 SDE I、SDE II 是 Amazon 软件开发工程师（Software Development Engineer）的级别，I 是入门级，II 高一级。各帖写法不统一（也有写成阿拉伯数字、加连字符的），下文沿用原帖的写法。 ### Work Simulation（情景判断） @@ -12,12 +21,12 @@ - 界面像邮箱或聊天窗口。最上面是一段项目背景，中间是某位同事发来的消息，发消息的可能是同组的 SDE、senior 或 principal 工程师（principal 比 senior 更资深）、team lead 或 mentor。下面是 Task，也就是这一屏要你做的事：要么给 3–5 个回复、行动或技术方案逐个打分，要么把 5 个选项从好到坏排序。 -- 打分用的量表（rating scale）在截图里是五档文字，从低到高依次是 Not at all、Slightly、Moderately、Very、Extremely Effective，界面上没有数字。一位 SDE1 应届发帖人给参考打分时，把这五档记成 1–5（1 = least effective / valuable，5 = most）。这只是这位发帖人自己的记法；SDE1 那套题的界面上有没有数字，没见到截图，未核实。 +- 打分用的量表（rating scale）在截图里是五档文字，从低到高依次是 Not at all、Slightly、Moderately、Very、Extremely Effective，界面上没有数字。一位 SDE1 应届发帖人给参考打分时，把这五档记成 1–5（1 = least effective / valuable，5 = most）。这只是这位发帖人自己的记法。SDE1 那套题的界面上有没有数字，没见到截图，未核实。 - 每一屏的问法都不一样，比如「第一条、立刻发出的消息」「回复里会包含什么」「这些好处对做推荐有多大价值」「写方案前要先问对方什么」「这些测试策略 / 存储方案有多有效」。 -- 整套题的组织方式，各帖说法不完全一样。那位 SDE1 应届发帖人整理的题分成 3 个 module，每个 module 是一个独立的虚构项目或团队（Project Alert、Sound Traveller、Amazon Games），每个 module 下面有 4 个 scenario（场景）；2026-08 另一位发帖人贴的两张截图，也来自两个互不相关的项目。也有不同的描述：一位实习发帖人说题目「围绕一个虚构的团队协作场景展开」；Glassdoor（一个可以匿名写公司面经的网站）上一位说有 3–4 个场景，都是「你刚加入新团队后遇到的情况」。 +- 整套题怎么组织，各帖说法不完全一样。那位 SDE1 应届发帖人整理的题分成 3 个 module，每个 module 是一个独立的虚构项目或团队（Project Alert、Sound Traveller、Amazon Games），下面各有 4 个 scenario（场景）。2026-08 另一位发帖人贴的两张截图，也来自两个互不相关的项目。一位实习发帖人则说题目「围绕一个虚构的团队协作场景展开」，Glassdoor（一个可以匿名写公司面经的网站）上一位说有 3–4 个场景，都是「你刚加入新团队后遇到的情况」。 从帖子看，题目有两种风格： 1. **人际和工程流程类。** 应届、SDE1、实习的帖子里多是这种。场景包括 code review 的反馈、进度受阻时怎么汇报、同事求助、同事的进度有风险、代码有隐患时要不要批准（approve）、赶工期时要不要跳过测试、用第三方服务还是自己开发。 -2. **设计取舍类。** 在职跳槽、SDE II 的帖子里多是这种，要你给存储选型、消息传输方式、项目的下一步行动打分，评的是每个方案有多有效。SDE II 帖子的说法是「System Design 相关」「DB 选型、batch 执行 vs 异步消息队列」「LLD / HLD 场景下做决策」。LLD 和 HLD 分别指 low-level design 和 high-level design，前者是类和接口层面的详细设计，后者是系统整体架构层面的设计。 +2. **设计取舍类。** 在职跳槽、SDE II 的帖子里多是这种，要你给存储选型、消息传输方式、项目的下一步行动打分，评的是每个方案有多有效。SDE II 帖子的说法是「System Design 相关」「DB 选型、batch 执行 vs 异步消息队列」「LLD / HLD 场景下做决策」。LLD 是 low-level design，指类和接口层面的详细设计。HLD 是 high-level design，指系统整体架构层面的设计。 ### Work Style（问卷） @@ -25,5 +34,5 @@ Work Style 是一份自我描述的问卷。见过两种题型： -- **强制二选一（forced-choice）。** 每屏给两句自我描述，中间一个「or」。你要选出更像自己的那一句，同时选程度：两侧各有 Most like me 和 More like me 两档，所以一共四档。那位 SDE1 应届发帖人整理了 35 道；2026-01 一位在职跳槽的发帖人分两个帖子贴了 18 张截图（发帖人说还有 3 张没贴）。 +- **强制二选一（forced-choice）。** 每屏给两句自我描述，中间一个「or」。你要选出更像自己的那一句，同时选程度：两侧各有 Most like me 和 More like me 两档，一共四档。那位 SDE1 应届发帖人整理了 35 道。2026-01 一位在职跳槽的发帖人分两个帖子贴了 18 张截图（发帖人说还有 3 张没贴）。 - **同意程度量表（Likert scale）。** 每题一句陈述，按 Strongly Agree / Agree / Neutral / Disagree / Strongly Disagree 五档选你有多同意。2026-03 前后一位 SDE II、一位 SDE-1 做的都是这种。 @@ -37,8 +46,9 @@ | --- | --- | --- | | 应届 / SDE1 | Work Simulation「typically 45 分钟」，Work Style 15 分钟 | 都不计时，可以慢慢做 | -| SDE II（2026-07 底一位贴出的 OA 说明） | Work Simulation 约 15 分钟（SDE 在 Amazon 遇到的开发决策）；Work Style Surveys 约 10 分钟，两份问卷 | 2026-03 另一位 SDE II 说两部分都不限时 | +| SDE II，Work Simulation（2026-07 底一位贴出的 OA 说明） | 约 15 分钟，内容是 SDE 在 Amazon 遇到的开发决策 | 2026-03 另一位 SDE II 说两部分都不限时 | +| SDE II，Work Style（同一份说明） | Work Style Surveys 约 10 分钟，两份问卷 | 同上 | | 实习整套 | 官方说明约 1 小时 45 分钟（含编程），收到邀请后 7 天内做完 | 1 小时 45 分钟其实够用，别在人格测评上想太久 | -【推断】看邀请邮件里 Work Simulation 写的是 15 分钟还是 45 分钟，大致能知道拿到的是设计取舍类还是人际类：SDE II 那份说明写的时长短，内容是开发决策；应届那份邮件写的时长要长得多。她的 OA 情况见 [[p:amazon/overview]]。 +【推断】看邀请邮件里 Work Simulation 写的是 15 分钟还是 45 分钟，大致能知道拿到的是设计取舍类还是人际类。SDE II 那份说明写的时长短，内容是开发决策，应届那份邮件写的时长要长得多。Amazon OA 的整体情况见 [[p:amazon/overview]]。 ## 面经里怎么考的 @@ -50,22 +60,22 @@ - 2026-04 一位应届生说，Work Simulation 是邮件形式的选择题，要分别扮演前端、后端和测试的角色，回应同事发现的 bug、code review 之类的事。 - 2026-06 一位应届生说界面像邮箱，题目比如「某人的代码有问题、但你要赶进度」，问你该怎么办。 -- 2026-06 另一位应届生（6 月底做的 OA，之后拿到了 VO，也就是 virtual onsite，线上进行的终轮面试）说，题目给几个工作场景，要把 5 个选项从好到坏排序，按 LP 排就行；Work Style 像性格测试，感觉没有正确答案。 +- 2026-06 另一位应届生（6 月底做的 OA，之后拿到了 VO，也就是 virtual onsite，线上进行的终轮面试）说，题目给几个工作场景，要把 5 个选项从好到坏排序，按 LP 排就行。这位说 Work Style 像性格测试，感觉没有正确答案。 - 2026-06 一位 SDE1 应届生把三个 module 都整理了出来，每个 module 是一个独立的虚构项目： - - **Project Alert**，主题是 API 设计、处理反馈和排查问题。场景有这几个： + - **Project Alert**，主题是 API 设计、处理反馈和排查问题： - Ryan 在 code review 里提了一个更复杂、但他认为长期来看更好的方案。 - - 你照着改了两天，碰上了竞态条件（race condition）；Matthew 来问进度，问你第一条消息怎么回。 + - 你照着改了两天，碰上了竞态条件（race condition）。Matthew 来问进度，问你第一条消息怎么回。 - senior 工程师 Becky 查出了全局变量（global variable）的问题，而且对你的整体方案有顾虑，想当天就谈。 - 同事 Claire 在调用你的 API，照你的建议改了还是报错，想在明早的状态同步会之前解决。 - - **Sound Traveller**，主题是数据追踪平台和一个跳转按钮。场景有这几个： + - **Sound Traveller**，主题是数据追踪平台和一个跳转按钮： - 用第三方平台还是自己开发，要你给两边各自的好处打分，看每条好处有多大价值。 - 写跳转按钮的方案之前，应该先问 team lead Mai 什么。 - 同事 Kyle 跟 Mai 说进度 on track（按计划进行），但你看过他的代码，觉得他赶不上。 - Kyle 的代码已经被另一位同事批准了，你发现它会让一小部分客户出错。 - - **Amazon Games**，主题是测试和上线压力。场景有这几个： + - **Amazon Games**，主题是测试和上线压力： - 跳转按钮坏了，Amber 估计要 4 天，还要补单元测试，Monique 却要求当天修好。 - 同事在改购买功能，想跳过新的集成测试。 - 同事跳过了测试，求你快点批准。 - Amber 请你出主意，防止「没测就上线」的事再发生。 - - 这位发帖人提醒，打分时别把 1–5 的方向弄反；附的参考打分，发帖人自己也说不保证准。 + - 这位发帖人提醒打分时别把 1–5 的方向弄反。附的参考打分，发帖人自己也说不保证准。 ### 在职跳槽和 SDE II 的帖子（2026-01 到 2026-09） @@ -74,37 +84,40 @@ - 2026-01 一位 SDE II 说，第二部分是设计取舍题，最后是行为题。 -- 2026-03 一位后来拿到 offer 的 SDE 2 说，考的是 DB 选型、batch 执行 vs 异步消息队列之类，题目很直接；行为问卷是 Strongly Agree 到 Strongly Disagree 的五档量表。 -- 2026-03 底一位 SDE 2 说，Work Simulation 和 System Design 相关，Work Style 和 Leadership Principles 相关，两部分都不限时。 -- 2026-04 一位在职跳槽、没写级别的发帖人说，Work Simulation 是偏系统设计的选择题，Work Style 是和 LP 相关的选择题。 +- 2026-03 一位后来拿到 offer 的 SDE 2 说，考的是 DB 选型、batch 执行 vs 异步消息队列之类，题目很直接。行为问卷是 Strongly Agree 到 Strongly Disagree 的五档量表。 +- 2026-03 底另一位 SDE 2 说，Work Simulation 是 System Design 方面的题，Work Style 是 Leadership Principles 方面的题，两部分都不限时。 +- 2026-04 一位在职跳槽、没写级别的发帖人说，Work Simulation 是偏系统设计的选择题，Work Style 是考 LP 的选择题。 - 2026-05 一位 SDE II 把它叫作「behavioral type design choice questions」。 - 2026-07 一位 SDE II 说，题目是 LLD / HLD 场景下的决策，并在回帖里确认全是选择题。 -- 2026-09 一位在职跳槽、OA 通过了的发帖人说，有一屏是项目还没开工，让你给几种下一步行动打分；另一屏是给 5 种 vote storage（投票数据存储）方案打分。 +- 2026-09 一位在职跳槽、OA 通过了的发帖人说，有一屏是项目还没开工，让你给几种下一步行动打分。另一屏是给 5 种 vote storage（投票数据存储）方案打分。 - 也有在职跳槽的帖子写得很简略，只说「work simulation 和以前一样」「常规 BQ 选择题」「AI 调试之后接 work simulation 和 LP 选择题」「100 分钟编程再加性格测试题，做得非常累」。 ### 没写身份或级别的帖子 -- 2026-08 一位身份、级别都没写的发帖人贴了两张截图，来自两个互不相关的项目。第一个项目是交通摄像头的视频服务，数据经消息队列上报；principal 工程师说部分摄像头的数据很大，客户想把它传上来，要你给 5 种传输做法打分。第二个项目是 SaaS 库存系统要给商品做缩略图，同事列了 5 种存储方案请你打分。发帖人说这部分不长，比 coding 简单。 -- Glassdoor 上 2026-08 San Jose 的一位（没拿到 offer，No offer）说，这是邮件形式的 work-style simulation，有 3–4 个场景，每个都是加入新团队后遇到的情况。 +- 2026-08 一位身份、级别都没写的发帖人贴了两张截图，来自两个互不相关的项目。第一个项目是交通摄像头的视频服务，数据经消息队列上报。principal 工程师说部分摄像头的数据很大，客户想把它传上来，要你给 5 种传输做法打分。第二个项目是 SaaS 库存系统要给商品做缩略图，同事列了 5 种存储方案请你打分。发帖人说这部分不长，比 coding 简单。 +- Glassdoor 上 2026-08 San Jose 的一位（No offer）说，这是邮件形式的 work-style simulation，有 3–4 个场景，每个都是加入新团队后遇到的情况。 ### 发帖人们的心得 -- 2026-02 做 OA、后来拿到 offer 的一位 SDE2 说，重点考 Ownership 和 Bias for Action（遇事先动手推进，不拖着等），别只挑看起来「稳妥」的选项，要挑能为客户交付结果的。 +- 2026-02 做 OA、后来拿到 offer 的一位 SDE2 说，重点考 Ownership 和 Bias for Action（遇事先动手推进，不拖着等）。别只挑看起来「稳妥」的选项，要挑能为客户交付结果的。 - 2026-04 一位 SDE2 说，题目是给职场场景的几种回复排序，应该选以客户为先、承担长期 ownership 的。 -- 2026-04 一位投 NG（new grad，应届生）岗位的在职跳槽发帖人（帖子里自己注明部分文字由 AI 生成）说，重点是邮件回得得体，要有 ownership，把事当成自己的事负责到底，别推卸责任。 -- 2026-03 一位实习生说，要贴近 Amazon 的企业文化，体现主动思考、合作和 ownership；性格测试要按 SWE（software engineer，软件工程师）的思路选，偏 PM（产品经理）那种沟通协调的选项，尽量换成直接解决问题的。 -- 2026-07 一位实习生总结了好坏选项的规律。好选项既保住自己的 ownership，又真的去理解对方的关切，比如追问具体例子、把模糊的反馈变成能执行的事、直接找相关的人一对一解决。差选项是为自己辩解、推卸责任，不加判断地照做，或者动不动就升级给上级、让上级当裁判。关于 Work Style，这位发帖人说同一个特质会反复问，凭第一反应答、前后一致最重要；还说如果全选最极端的正面选项，会触发印象管理（impression management，即刻意把自己往好里说）检测（未核实）。 +- 2026-04 一位投 NG（new grad，应届生）岗位的在职跳槽发帖人（帖子里自己注明部分文字由 AI 生成）说，重点是邮件回得得体，要有 ownership，别推卸责任。 +- 2026-03 一位实习生说，要贴近 Amazon 的企业文化，体现主动思考、合作和 ownership。性格测试要按 SWE（software engineer，软件工程师）的思路选，偏 PM（产品经理）那种沟通协调的选项，尽量换成直接解决问题的。 +- 2026-07 一位实习生总结了好坏选项的规律： + - 好选项既保住自己的 ownership，又真的去理解对方的关切，比如追问具体例子、把模糊的反馈变成能执行的事、直接找相关的人一对一解决。 + - 差选项是为自己辩解、推卸责任，不加判断地照做，或者动不动就升级给上级、让上级当裁判。 + - Work Style 里同一个特质会反复问，凭第一反应答、前后一致最重要。如果全选最极端的正面选项，会触发印象管理（impression management，即刻意把自己往好里说）检测（未核实）。 - 2026-01 一位 SDE II 说，行为 / Work Style 部分要认真、前后一致地答完。 -- 2026-06 那位 SDE1 应届生说 Work Style 好像没有标准答案；两句一样正面或一样负面时，发帖人倾向选 More like me，而不是 Most like me。 -- 2026-09 一位发帖人说，做 Work Style 时打开 Amazon 的 LP 对照着答；另外还有一个 5 分钟的小测试，和本人性格一致就行，没有正确答案。 +- 2026-06 那位 SDE1 应届生说 Work Style 好像没有标准答案。两句一样正面或一样负面时，发帖人倾向选 More like me，不选 Most like me。 +- 2026-09 一位发帖人说，做 Work Style 时打开 Amazon 的 LP 对照着答。另外还有一个 5 分钟的小测试，和本人性格一致就行，没有正确答案。 ### 结果上的教训 - 2025-12 一位实习发帖人编程的测试用例全过了，Work Style 也自认是按 LP 答的，三天后还是被拒，自己也不知道原因。 -- 一篇汇总了大量面经的长帖（下称整理帖）说，技术部分过了、OA 却没通过的，大概率是 Work Simulation 没答好；Work Style 前后不一致也容易被拒。这是整理帖的说法，未核实。 +- 一篇汇总了大量面经的长帖（下称整理帖）说，技术部分过了、OA 却没通过的，大概率是 Work Simulation 没答好，Work Style 前后不一致也容易被拒。这是整理帖的说法，未核实。 - 2026-04 一位 SDE II 说，见过算法做得差、调试做得好的人拿到了面试，反过来的也有，所以几部分可能是合起来看的（传闻）。 ### 和整理帖说法的冲突 -同一篇整理帖说「SDE-2 的 OA 有独立的系统设计、没有 Work Simulation」。【推断】它说的「系统设计」多半就是 SDE II 版的 Work Simulation，理由有两条：SDE II 的 OA 说明里这一节就叫 Work Simulation，内容写的是「SDE 在 Amazon 遇到的开发决策」；SDE II 发帖人们描述的，也正是选型和设计取舍的选择题。 +同一篇整理帖说「SDE-2 的 OA 有独立的系统设计、没有 Work Simulation」。【推断】它说的「系统设计」多半就是 SDE II 版的 Work Simulation，理由有两条。第一，SDE II 的 OA 说明里这一节就叫 Work Simulation，内容写的是「SDE 在 Amazon 遇到的开发决策」。第二，SDE II 发帖人们描述的，也正是选型和设计取舍的选择题。 ## 思路 @@ -112,61 +125,161 @@ ### 先弄清楚它在考什么 -- Work Simulation 是情景判断题，发帖人们一致说要按 Leadership Principles 来选。它考的是「Amazon 的工程师该怎么做」，而不是「你平时会怎么做」。Work Style 问的则是「你是什么样的人」（这是 2026-07 那位实习发帖人的说法）；【推断】不过它的打分多半也是拿岗位要求的人物画像去比对。 -- 【推断】打分题一般是看你的分数和标准答案有多接近来给分。所以把明显差的选项打到 1–2、明显好的打到 4–5，比纠结一个好选项该打 4 还是 5 重要：把一个选项的好坏打反会差出好几档，而在相邻两档之间选错只差一档。打分题的每个选项是独立打分的，可以并列（那位 SDE1 应届发帖人的参考打分里，常常有好几个选项都是 5）。 -- 做每一屏可以按这个顺序：先看背景，以及发消息的人是谁；再看清这一屏的问法和量表方向；然后先挑出最差和最好的选项；剩下中间的，按下面的原则细分。 +- 发帖人们一致说 Work Simulation 要按 Leadership Principles 来选，它考的是「Amazon 的工程师该怎么做」，和「你平时会怎么做」可能不一样。2026-07 那位实习发帖人说 Work Style 问的是「你是什么样的人」。【推断】不过 Work Style 的打分多半也是拿岗位要求的人物画像去比对。 +- 【推断】打分题一般看你的分数和标准答案有多接近来给分。把一个选项的好坏打反会差出好几档，在相邻两档之间选错只差一档。所以把明显差的选项打到 1–2、明显好的打到 4–5，比纠结一个好选项该打 4 还是 5 重要。打分题的每个选项独立打分，可以并列（那位 SDE1 应届发帖人的参考打分里，常常有好几个选项都是 5）。 +- 做每一屏可以按这个顺序： + 1. 看背景，以及发消息的人是谁。 + 2. 看清这一屏的问法和量表方向。 + 3. 先挑出最差和最好的选项。 + 4. 剩下中间的，按下面的原则细分。 ### Work Simulation 里人际和流程场景的判断原则 -【推断】下面这些原则，是本页从发帖人们的心得、以及那位 SDE1 应届发帖人的参考打分里归纳出来的。括号里的分数就是那份参考打分（1 最低、5 最高）。这份打分只有这一位发帖人给过，发帖人自己也说不保证准，所以只能当方向上的参考。 - -1. **自己担起来（Ownership）。** 遇到问题先自己查、自己拿出方案，不推给别人，也不半路放弃。比如为了不耽误上线，退回去改为提交自己原来的代码，这种半路放弃的做法只有 2 分。 -2. **坏消息要早说、说具体、带上计划（Bias for Action 和 Earn Trust，后者指赢得别人的信任）。** 卡住的时候，第一条消息就要说清卡在哪里、想请对方帮什么忙、自己接下来做什么（5 分），这样对方马上就能判断要不要介入、怎么帮。「先自己接着查，两天后组会上可能要大家帮忙」（2 分）把求助拖到了两天以后；只丢一句「赶不上了」（1–2 分）没有给对方任何能行动的信息。这两种的分数都低。 -3. **找对的人，用对的方式。** 手上有具体依据的风险，直接告诉负责的 team lead（5 分），或者推动当事人自己去跟 lead 说（4 分）；在当天的组会上当众提出来是中等（3 分）；群发邮件给全组偏低（2 分）；觉得「那是他自己的事」、按兵不动，最低（1 分）。可以看出，越是直接交到负责的人手上，分数越高；什么都不做最差。 -4. **听得进反馈，但不放弃自己的判断（Earn Trust、Are Right, A Lot，后者指判断经常是对的）。** 对方提了顾虑，就约他（以及直接相关的人）尽快当面聊清楚（4–5 分），这样既回应了对方，又保留了自己做决定的机会。「你说怎么改我就怎么改」「你觉得怎样好就直接改我的代码」这种放弃自己判断的回复是中等（3 分）。只修 bug、不谈方案（2 分），或者说不打算改、再找 Matthew 确认（2 分），都偏低。用一句「刚评审过，不用再看」驳回对方，最低（1 分）。 -5. **客户和质量不让步（Customer Obsession、Insist on the Highest Standards，后者指坚持最高标准）。** 参考打分里有三种情况： - - 已知某个问题会伤到一部分客户时，在代码里留评论、修好之前不批准（5 分），或者告诉之前批准的那个人、问要不要先改（4 分）；「别人已经批了，应该没事」（1 分）、「先批了上线，之后再打补丁」（2 分）、「留个评论，上线后再修」（2 分）都低，因为它们都让已知的问题先到了客户那里。 - - 购买这类流程不跳过必要的测试。明确说测试不该跳，并主动帮同事补测试或跑完整测试（5 分），以及把情况告诉 Amber（5 分），都是最高；附和「赶 deadline 最重要」最低（1 分）。 - - 赶时间修 bug 时，针对这次修复写新的单元测试最高（5 分）；先手工测、紧接着补自动化测试次之（4 分）；先回滚到旧版本、再慢慢测新代码是中等（3 分）；只抽查一部分测试就发布，或者先找人 review 再跑测试，偏低（2 分）。 -6. **帮人时要给出具体的承诺。** 同事来求助，给出今天能一起查的时间，查不出来再一起去找 Matthew（5 分）；「我现在没空，把代码发我，晚点我来改」是中等（3 分）；反问「你照我的建议做了吗」、直接让对方去找 Matthew（2 分）、甩一份文档让对方自己看（1–2 分），都偏低。高分的回答既有具体时间，又有查不出来时的后备安排，对方知道接下来会发生什么。 -7. **提问要问到点子上。** 写方案之前，问清要和哪些现有系统集成、追踪接口失败时还要不要照常跳转（5 分），或者要调用哪个 API、有没有类似的功能可以参考（4–5 分）；一上来先问「工期能不能放宽」就低（2 分）。前面几个问题问的是会影响方案设计的信息；问工期的那一个，是活还没开始干，就先要求放宽期限。 -8. **流程上的问题优先靠自动化解决。** 要防止「没测就上线」，最有效的是自动化门禁（quality gate），也就是没通过测试就不允许部署（5 分）；测试规范、根因分析（root cause analysis）报告次之（4 分）；只写一份「没测就上线之后怎么排查」的指南，帮助小（2 分）。门禁从机制上挡住了问题；测试规范要靠人自觉遵守，根因分析报告是出事之后的复盘，两者都不能从机制上挡住下一次；排查指南只是事后补救。 -9. **问「好处有多大价值」时，不是让你选边。** 第三方平台还是自建那一题，问的是每一条好处各有多大价值，所以两边真实存在的好处（按时上线、长期更省钱、能按需定制）都打了 5 分；只有「省得自己做定制方案」给了 2–3 分。 -10. **开会和升级要分成两类看。** - - 分高的一类，是约提出顾虑的当事人、以及直接相关的人，尽快当面说清楚。回复 Ryan「约你聊聊你的顾虑和建议，再决定要不要改」是 5 分，「约你和全组开会一起定」也有 4 分；约 Matthew 和 Becky，三个人一起谈出共识，是 4–5 分。把具体风险直接告诉负责的 lead，也是 5 分。 - - 分低到中的一类，包括拖到之后的例会（2 分）、把决定推给别人拍板（2 分）、群发邮件（2 分）、等别人先审完再表态（2 分）、先观望不说（1 分）。这些做法看起来稳妥，实际上都在拖延，或者回避自己该做的判断。 - - 另一位实习发帖人的说法和这一点一致：差选项之一是「动不动升级给上级当裁判」。不过这条针对的是可以回头的日常决定；遇到不可逆的决定，也就是 Amazon 说的 one-way door（单向门，走过去就回不来），仍然要谨慎，还是该找相关的人一起把关。 +【推断】下面这些原则，是本页从发帖人们的心得、以及那位 SDE1 应届发帖人的参考打分里归纳出来的。括号里的分数就是那份参考打分（1 最低、5 最高）。这份打分只有这一位发帖人给过，发帖人自己也说不保证准，只能当方向上的参考。原文只写明了 Ryan、Becky 那几组分数出自哪一屏，其余各组对到哪一屏，是本页按选项内容对的，拿不准的标了【推断】。 + +#### 1. 自己担起来（Ownership） + +遇到问题先自己查、自己拿出方案，不推给别人，也不半路放弃。比如为了不耽误上线，退回去改为提交自己原来的代码，这种半路放弃的做法只有 2 分。 + +> [!say] When I'm unsure, I gather the data myself, make a recommendation, and keep the stakeholders in the loop. I don't wait for someone else to decide. + +#### 2. 坏消息要早说、说具体、带上计划 + +这条对应 Bias for Action 和 Earn Trust（赢得别人的信任）。卡住时 Matthew 来问进度，第一条消息怎么回： + +- 说清卡在哪里、想请对方帮什么忙、自己接下来做什么（5 分）。对方马上就能判断要不要介入、怎么帮。 +- 「先自己接着查，两天后组会上可能要大家帮忙」（2 分）。求助拖到了两天以后。 +- 只丢一句「赶不上了」（1–2 分）。没有给对方任何能行动的信息。 + +> [!say] If I hit a blocker, I tell my manager right away what's broken, what I've tried, and what help I need, instead of waiting for the next team meeting. + +#### 3. 找对的人，用对的方式 + +手上有具体依据的风险时（【推断】从选项看，是 Kyle 对 Mai 说自己 on track、你觉得他赶不上的那一屏），参考打分是： + +- 直接告诉负责的 team lead（5 分）。 +- 推动当事人自己去跟 lead 说（4 分）。 +- 在当天的组会上当众提出来（3 分）。 +- 群发邮件给全组（2 分）。 +- 觉得「那是他自己的事」、按兵不动（1 分）。 + +越是直接交到负责的人手上，分数越高，什么都不做最差。 + +#### 4. 听得进反馈，也保留自己的判断 + +这条对应 Earn Trust 和 Are Right, A Lot（判断经常是对的）。Ryan、Becky 对你的方案提了顾虑： + +- 约对方（以及直接相关的人）尽快当面聊清楚（4–5 分）。比如回复 Ryan「约你聊聊你的顾虑和建议，再决定要不要改」（5 分），约 Matthew 和 Becky 三个人谈出共识（4–5 分）。这样既回应了对方，又保留了自己做决定的机会。 +- 「你说怎么改我就怎么改」「你觉得怎样好就直接改我的代码」（3 分）。放弃了自己的判断。 +- 只修 bug、不谈方案（2 分），或者说不打算改、再找 Matthew 确认（2 分）。 +- 用一句「刚评审过，不用再看」驳回对方（1 分）。 + +> [!say] Thanks for flagging this. Could we find thirty minutes today so I can understand your concerns before I decide whether to change the approach? + +#### 5. 客户和质量不让步 + +这条对应 Customer Obsession 和 Insist on the Highest Standards（坚持最高标准）。参考打分里有三种情况。 + +已知某段代码会伤到一部分客户（【推断】从「告诉之前批准的那个人」这个选项看，是 Kyle 的代码已被批准的那一屏）： + +- 在代码里留评论，修好之前不批准（5 分）。 +- 告诉之前批准的那个人，问要不要先改（4 分）。 +- 「先批了上线，之后再打补丁」「留个评论，上线后再修」（2 分）。 +- 「别人已经批了，应该没事」（1 分）。 + +后面几种分低，因为它们都让已知的问题先到了客户那里。 + +同事想在购买功能上跳过测试：明确说测试不该跳，并主动帮同事补测试或跑完整测试（5 分），以及把情况告诉 Amber（5 分），都是最高。附和「赶 deadline 最重要」最低（1 分）。 + +赶时间修 bug 时（【推断】应是 Monique 要求当天修好跳转按钮的那一屏）： + +- 针对这次修复写新的单元测试（5 分）。 +- 先手工测，紧接着补自动化测试（4 分）。 +- 先回滚到旧版本，再慢慢测新代码（3 分）。 +- 只抽查一部分测试就发布，或者先找人 review 再跑测试（2 分）。 + +#### 6. 帮人时要给出具体的承诺 + +Claire 来求助： + +- 给出今天能一起查的时间，查不出来再一起去找 Matthew（5 分）。 +- 「我现在没空，把代码发我，晚点我来改」（3 分）。 +- 反问「你照我的建议做了吗」、直接让对方去找 Matthew（2 分），甩一份文档让对方自己看（1–2 分）。 + +高分的回答既有具体时间，又有查不出来时的后备安排，对方知道接下来会发生什么。 + +#### 7. 提问要问到点子上 + +写跳转按钮的方案之前问 Mai： + +- 要和哪些现有系统集成、追踪接口失败时还要不要照常跳转（5 分）。 +- 要调用哪个 API、有没有类似的功能可以参考（4–5 分）。 +- 一上来先问「工期能不能放宽」（2 分）。 + +前几个问的是会影响方案设计的信息。问工期的那一个，是活还没开始干，就先要求放宽期限。 + +#### 8. 流程上的问题优先靠自动化解决 + +Amber 请你防止「没测就上线」： + +- 自动化门禁（quality gate），也就是没通过测试就不允许部署（5 分）。它从机制上挡住了问题。 +- 测试规范、根因分析（root cause analysis）报告（4 分）。测试规范要靠人自觉遵守，根因分析报告是出事之后的复盘，都挡不住下一次。 +- 只写一份「没测就上线之后怎么排查」的指南（2 分）。这只是事后补救。 + +#### 9. 问「好处有多大价值」时，两边分开打 + +第三方平台还是自建那一题，问的是每一条好处各有多大价值，不用选边。两边真实存在的好处（按时上线、长期更省钱、能按需定制）都打了 5 分，只有「省得自己做定制方案」给了 2–3 分。 + +#### 10. 开会和升级分两类看 + +- 分高的一类：约提出顾虑的当事人、以及直接相关的人，尽快当面说清楚（原则 4），或者把具体风险直接告诉负责的 lead（原则 3）。回复 Ryan「约你和全组开会一起定」也有 4 分。 +- 分低到中的一类：拖到之后的例会、把决定推给别人拍板、群发邮件、等别人先审完再表态（都是 2 分），先观望不说（1 分）。这些做法看起来稳妥，实际上都在拖延，或者回避自己该做的判断。 + +2026-07 那位实习发帖人说差选项之一是「动不动升级给上级当裁判」，和这一点一致。这条针对的是可以回头的日常决定。遇到不可逆的决定，也就是 Amazon 说的 one-way door（单向门，走过去就回不来），仍然要谨慎，该找相关的人一起把关。 ### Work Simulation 里设计取舍场景的判断原则 -【推断】这一节的通用顺序，以及下面对各个场景的判断，都是本页按常见的系统设计原则推出来的：这类题没有官方答案，也没有发帖人给过参考打分。 - -通用的判断顺序是这样的： - -1. 先从背景里找出需求：数据是什么形状（大文件、小记录，还是计数）、读写比例、峰值有多大、要不要实时、数据能不能修改、可用性要求多高。后面每个选项好不好，都要拿这些需求来比。 +【推断】这一节的通用顺序，以及下面对各个场景的判断，都是本页按常见的系统设计原则推出来的。这类题没有官方答案，也没有发帖人给过参考打分。 + +通用的判断顺序： + +1. 先从背景里找出需求：数据是什么形状（大文件、小记录，还是计数）、读写比例、峰值有多大、要不要实时、数据能不能修改、可用性要求多高。后面每个选项好不好，都拿这些需求来比。 2. 行不通或者要靠人工的做法打最低分，比如派人去现场物理拷贝数据、手动跑脚本救火。这类做法没法规模化，也容易出错。 3. 和需求不搭的做法打低分，比如拿搜索引擎存图片、拿图数据库（graph database）存投票。这些工具本身没问题，只是不是为这种用途设计的。 4. 能用、但要自己重新做一套现成的东西（造轮子）、维护成本高的做法打中间分，比如自己开发传输协议。 -5. 业界常规的做法和云厂商的托管服务（managed service）打最高分，因为运维、扩容和可靠性都由云厂商负责，而且这些方案已经在大规模使用中经过了验证。别被最复杂、最新潮的选项吸引：题目考的是按需求选，不是比谁的方案更复杂。 +5. 业界常规的做法和云厂商的托管服务（managed service）打最高分。运维、扩容和可靠性都由云厂商负责，这些方案也已经在大规模使用中经过了验证。别被最复杂、最新潮的选项吸引，题目考的是按需求选。 6. 问「下一步做什么」的题，在需求还没澄清之前就建表、写基础库代码、搭监控面板，都偏早。应该先和相关方澄清需求，再做概念验证（proof of concept，PoC），也就是用一个小原型先验证最关键的风险。 见过的场景和本页的判断： -- **大消息怎么走消息队列**（截图里的原题）。消息队列适合传小消息，单条消息有大小上限，所以大数据不能直接塞进队列。最贴近常规做法的是把请求的元数据和大数据分开传：队列里只放元数据和一个指向数据的引用，大数据本身存进存储服务，用的时候再按引用去取。这种做法叫 claim-check 模式，名字来自寄存行李时拿到的取件凭证。其余几种做法里，拆成多条消息能用，但接收方要处理重新组装、乱序和部分消息丢失；自己开发一套流式传输协议，成本高；挑流量低的时段再发，既不解决大小限制，还让数据晚到；派人去每个地点物理下载，最差。 -- **商品缩略图存在哪**（截图里的原题，5 个选项是 flat / file store、关系型数据库、键值存储（key-value store）、Elasticsearch、cloud file store）。最合适的是云上的文件或对象存储（object storage，比如 S3），数据库里只存图片的 URL 和元数据，因为对象存储本来就是为存放大量文件设计的，容量按需扩展，数据的耐久性由云厂商保证。键值存储放小图也能用。flat / file store 本页理解为单机或自己管理的文件存储，对 SaaS 来说不好扩展，也不够耐久。关系型数据库存二进制大对象（BLOB）不划算，图片会把数据库撑大。Elasticsearch 是搜索引擎，不是用来存图的。 -- **投票数据怎么存**。2026-09 那篇原帖只说有「5 种 vote storage 方案」。下面的场景细节和选项，来自 2026-08 截图那篇帖子的站方 AI 整理（一亩三分地是一个北美华人求职论坛，站方 AI 整理是这个网站自己用 AI 生成的整理），未经原帖证实。设定是 Amazon Prime 一档歌唱节目的实时投票：5 分钟投票窗口，数百万人同时投，结果每秒更新，截止前可以查看和修改自己的票，投票期间必须一直可用。选项是键值存储（key-value store）、文档数据库（document database）、图数据库（graph database）、账本数据库（ledger database）/ 只追加日志（append-only log）、流处理（stream processing）系统。按这个设定，以用户 ID 为键的键值存储最贴需求：改票就是覆盖写同一个键，而且键值存储容易扩展。流处理系统适合做每秒一次的聚合，作为配套也有效。文档数据库能用，但不占优势。账本数据库的吞吐量有限，它不可变、可校验的特性在这里也用不上；只追加日志能扛住写入，但要查看或修改自己当前的票，得先额外做一遍聚合，所以单独用不合适。图数据库和这个需求不相干。 -- **项目还没开工，给下一步行动打分**。原帖只说有这一屏。站方 AI 补的细节同样未经证实：场景就是上面的投票服务，5 周后决赛，经理让你牵头；选项是做 PoC、和相关方澄清需求、写基础库代码、建数据库 schema（表结构）、约设计团队开会。按这个设定，澄清需求最高，因为需求不清楚时，后面做什么都可能白做；用 PoC 验证峰值写入这类关键风险，其次；直接写代码、建表，都偏早。 +- **大消息怎么走消息队列**（截图里的原题）。消息队列适合传小消息，单条消息有大小上限，大数据不能直接塞进去。最贴近常规做法的是把元数据和大数据分开传：大数据存进存储服务，队列里只放元数据和一个指向数据的引用，用的时候再按引用去取。这种做法叫 claim-check 模式，名字来自寄存行李时拿到的取件凭证。其余几种做法： + - 拆成多条消息能用，但接收方要处理重新组装、乱序和部分消息丢失。 + - 自己开发一套流式传输协议，成本高。 + - 挑流量低的时段再发，既不解决大小限制，还让数据晚到。 + - 派人去每个地点物理下载，最差。 + +> [!say] For large payloads I keep the queue message small, just metadata and a pointer to the object in S3, instead of pushing the blob through the queue. + +- **商品缩略图存在哪**（截图里的原题，5 个选项是 flat / file store、关系型数据库、键值存储（key-value store）、Elasticsearch、cloud file store）。最合适的是云上的文件或对象存储（object storage，比如 S3），数据库里只存图片的 URL 和元数据。对象存储本来就是为存放大量文件设计的，容量按需扩展，数据的耐久性由云厂商保证。键值存储放小图也能用。flat / file store 本页理解为单机或自己管理的文件存储，对 SaaS 来说不好扩展，也不够耐久。关系型数据库存二进制大对象（BLOB）不划算，图片会把数据库撑大。Elasticsearch 是搜索引擎，不是用来存图的。 +- **投票数据怎么存**。2026-09 那篇原帖只说有「5 种 vote storage 方案」。下面的场景细节和选项，来自 2026-08 截图那篇帖子的站方 AI 整理（一亩三分地是一个北美华人求职论坛，站方 AI 整理是这个网站自己用 AI 生成的整理），未经原帖证实。 + - 设定：Amazon Prime 一档歌唱节目的实时投票，5 分钟投票窗口，数百万人同时投，结果每秒更新，截止前可以查看和修改自己的票，投票期间必须一直可用。 + - 选项：键值存储、文档数据库（document database）、图数据库、账本数据库（ledger database）/ 只追加日志（append-only log）、流处理（stream processing）系统。 + - 判断：以用户 ID 为键的键值存储最贴需求，改票就是覆盖写同一个键，键值存储也容易扩展。流处理系统适合做每秒一次的聚合，作为配套也有效。文档数据库能用，但不占优势。账本数据库的吞吐量有限，它不可变、可校验的特性在这里也用不上。只追加日志能扛住写入，但要查看或修改自己当前的票，得先额外做一遍聚合，单独用不合适。图数据库和这个需求不搭。 +- **项目还没开工，给下一步行动打分**。原帖只说有这一屏。站方 AI 补的细节同样未经证实：场景就是上面的投票服务，5 周后决赛，经理让你牵头。选项是做 PoC、和相关方澄清需求、写基础库代码、建数据库 schema（表结构）、约设计团队开会。按这个设定，澄清需求最高，因为需求不清楚时，后面做什么都可能白做。用 PoC 验证峰值写入这类关键风险，其次。直接写代码、建表，都偏早。 - **站方 AI 整理里另外列的几屏**（没见到截图、未经证实，只能当练习）： - - 一屏问消息丢失后怎么监测和加固。死信队列（dead-letter queue，专门存放多次处理失败的消息的队列）和检查重试配置最有效；延长保留时间效果一般；把处理过的消息另存一份，帮助不大。 - - 一屏问 SaaS 库存系统架构设计的下一步。 - - 一屏问面向全球客户怎么保证可用性。按需扩容、做压测并分析结果最有效；每日备份管的是数据恢复，而不是可用性；手动修复脚本、把区域设置搬进配置服务，帮助都小。 -- **DB 选型、batch 执行 vs 异步消息队列**（SDE II 的原帖只给了题目方向）。异步消息队列的用处是削峰（把突发的流量先存在队列里，让下游按自己的速度处理）、解耦（发消息的一方和处理消息的一方不直接依赖对方）和失败重试；批处理适合不要求实时、数据量大、周期性跑的任务；数据库按访问模式选：主要按键读写的用键值存储，需要关联查询（join）的用关系型数据库，要全文搜索的用搜索引擎，图片这类二进制大对象放对象存储。这和前面缩略图、投票两题的判断是一致的。 + - 消息丢失后怎么监测和加固。死信队列（dead-letter queue，专门存放多次处理失败的消息的队列）和检查重试配置最有效，延长保留时间效果一般，把处理过的消息另存一份帮助不大。 + - SaaS 库存系统架构设计的下一步。 + - 面向全球客户怎么保证可用性。按需扩容、做压测并分析结果最有效。每日备份管的是数据恢复，管不了可用性。手动修复脚本、把区域设置搬进配置服务，帮助都小。 +- **DB 选型、batch 执行 vs 异步消息队列**（SDE II 的原帖只给了题目方向）。 + - 异步消息队列的用处是削峰（把突发的流量先存在队列里，让下游按自己的速度处理）、解耦（发消息的一方和处理消息的一方不直接依赖对方）和失败重试。 + - 批处理适合不要求实时、数据量大、周期性跑的任务。 + - 数据库按访问模式选：主要按键读写的用键值存储，需要关联查询（join）的用关系型数据库，要全文搜索的用搜索引擎，图片这类二进制大对象放对象存储。这和前面缩略图、投票两题的判断一致。 ### Work Style 怎么答 -- 按真实的自己答，前后一致最重要。凭第一反应选，别回头反复改，也别想太久：想得越久，答案越像在演，前后也越容易对不上。 -- 答案往 SDE 的岗位画像上靠，也就是主动、担责、靠得住、做完为止、愿意学、能适应变化、细致。偏 PM 式「先沟通协调」和偏「直接解决问题」二选一时，后者更像 SWE。 +- 按真实的自己答，前后一致最重要。凭第一反应选，别回头反复改，也别想太久。想得越久，答案越像在演，前后也越容易对不上。 +- 答案往 SDE 的岗位画像上靠：主动、担责、靠得住、做完为止、愿意学、能适应变化、细致。偏 PM 式「先沟通协调」和偏「直接解决问题」二选一时，后者更像 SWE。 - 【推断】有几种「弱化」措辞是低分的那一边，比如「和同事差不多」（about as … as everyone else / my peers）、「被要求了才主动」「在熟悉的领域才主动」「确定马上用得上才学」「偶尔会犯容易修的错」。这些说法本身不算坏，但都在给主动性、学习意愿或细致程度打折扣。 -- 两句都正面时，选和岗位更相关、又和自己前面的答案一致的那句；拿不准就选 More like me，而不是 Most like me。两句都负面时，选对工作伤害小的那句。 -- 别全选最极端的那一档。一是有发帖人说这样会被识别成刻意美化（未核实）；二是全选 Most 也体现不出你在两句之间做了取舍。 +- 两句都正面时，选和岗位要求更贴、又和自己前面的答案一致的那句，拿不准就选 More like me。两句都负面时，选对工作伤害小的那句。 +- 别全选最极端的那一档。一是有发帖人说这样会被识别成刻意美化（未核实）。二是全选 Most 也体现不出你在两句之间做了取舍。 - 同意程度量表的版本道理一样：符合 LP 的陈述往 Agree 那边答，但同一个特质前后别自相矛盾。 @@ -175,21 +288,11 @@ ## 易错点 -- **量表方向别弄反。** 截图里最左边是 Not at all Effective，最右边是 Extremely Effective。那位 SDE1 应届发帖人按 1–5 记（1 = least effective，5 = most），也专门提醒别选反。开始做之前先确认一次方向。 -- **先分清是打分题还是排序题。** 打分题每个选项独立打分，可以并列；排序题要排出先后。 -- **看清这一屏问的是什么。** 「第一条立刻发的消息」「回复里会包含什么」「好处的价值」「写方案前先问什么」，问法一换，同一个选项的分数就不一样。 -- **「稳妥」的陷阱。**【推断】拖到之后的例会、把决定推给别人、群发邮件、先观望，这些看着安全，参考分却是低到中。但也别把所有「开会」都当成拖延：约提出顾虑的当事人和直接相关的人当面谈清楚，参考分是高的。 -- **「放弃判断」也拿不到高分。** 「你说怎么改我就改」「你直接改我的代码吧」在参考打分里只是中等。 -- **和「稳妥」相反的另一头陷阱。** Bias for Action 不等于跳过测试、批准有已知客户影响的代码、先上线再打补丁。 -- **设计题按需求选**，不是越复杂越好。 -- **编程全过也不代表 OA 稳了**，这部分别当走过场。不计时（或者只标了 10–15 分钟）的话，可以慢慢读题，但 Work Style 别拖。 -- 一位应届生说，编程和后两部分可以分开做，在一周的期限内分不同的天做完；做题时有弹窗提醒，不要切到别的窗口。 - -## 英文讲法 - -> [!say] When I'm unsure, I'd rather gather the data myself, make a recommendation, and keep the stakeholders in the loop than wait for someone else to decide. - -> [!say] Thanks for flagging this. Could we find thirty minutes today so I can understand your concerns before I decide whether to change the approach? - -> [!say] If I hit a blocker, I tell my manager right away what's broken, what I've tried, and what help I need, instead of waiting for the next team meeting. - -> [!say] For large payloads I keep the queue message small, just metadata and a pointer to the object in S3, instead of pushing the blob through the queue. +- **量表方向弄反。** 截图里最左边是 Not at all Effective，最右边是 Extremely Effective。那位 SDE1 应届发帖人按 1–5 记，也专门提醒别选反。 +- **打分题当排序题做。** 打分题每个选项独立打分，可以并列。排序题才要排出先后。 +- **没看清这一屏问什么。** 「第一条立刻发的消息」「回复里会包含什么」「好处的价值」「写方案前先问什么」，问法一换，同一个选项的分数就不一样。 +- **挑「稳妥」的选项。**【推断】拖延、推给别人、群发、观望，参考分是低到中。约当事人当面谈清楚的会，参考分却是高的（原则 10）。 +- **放弃自己的判断。** 「你说怎么改我就改」只拿中等分（原则 4）。 +- **把 Bias for Action 当成赶工。** 跳过测试、批准有已知客户影响的代码、先上线再打补丁，分都低（原则 5）。 +- **设计题挑最复杂的方案。** 按需求选（设计取舍场景第 5 条）。 +- **以为编程全过 OA 就稳了。** 这部分别当走过场。不计时（或者只标了 10–15 分钟）的话可以慢慢读题，但 Work Style 别拖。 +- **切窗口。** 一位应届生说，编程和后两部分可以在一周的期限内分不同的天做完。做题时有弹窗提醒，不要切到别的窗口。
meta
@@ -1 +1,5 @@ -{} +{ + "depth_guide": "2026-10-23", + "rewritten_by": "cloud:20261026-2313", + "rewritten_at": "2026-10-27" +}