亚马逊工程师岗位助手

你在对齐什么

去亚马逊或做 AWS 相关业务时，难点往往不是「会不会写代码」，而是决策语言和文档习惯是否一致：面试要按 Leadership Principles 用 STAR 讲故事；立项要先写 PR/FAQ 再写代码；评审会上大家先默读六页叙事，而不是对着 PPT 点头。若你只背服务列表却不理解 Customer Obsession、Bias for Action 在评审里如何被追问，很容易在行为面和技术讨论里脱节。

技能如何组织信息

本技能把亚马逊工程语境拆成可检索的几块，便于在对话里按需引用：

• 文化与原则：16 条 Leadership Principles（含 2021 年后新增的两条）、Day One 心态，以及 IPO 以来影响工程文化的关键决策（例如 2004 年起用书面备忘录替代 PowerPoint）。
• 逆向工作法（Working Backwards）：在动手前起草一页 Press Release 与多页 FAQ；资料中强调「新闻稿难写，产品多半不够好」这一检验标准，并列举 S3、Prime、Kindle、Echo 等由 PR/FAQ 驱动的产物。
• 组织与决策：两披萨团队（约 8–10 人）、单线程负责人、API 式协作；单向门 / 双向门决策框架（约 90% 决策可快速试错）。
• 技术与规模语境：AWS 规模指标、核心服务分类与 Well-Architected 六大支柱与原则的对应关系；零售侧飞轮、目录/推荐/履约等系统所面对的大规模工程问题。
• 工程日常工具：输入指标 vs 输出指标的分工、六页叙事会议结构，以及 Bar Raiser 面试中「抬杠」与 LP 行为题的常见追问方式。

在模型侧，你可以把它当作岗位与文化对齐的上下文包：写 PR/FAQ 草稿、模拟 LP 面试追问、或解释某项架构选择时，显式引用上述框架，而不是泛泛谈「大厂最佳实践」。

适用边界

这是文化与方法论导航，不是 AWS 账号操作手册，也不替代官方文档与实时配额/定价。领导力原则表格里的「面试触发问法」是准备线索，真实面试流程以招聘方为准。文中营收、机器人数量等数字来自技能资料中的时点表述，做商业或投资判断时请自行核对最新财报与公告。