Articles · Amazon

Amazon 软件工程师面试准备：把 Coding、设计与 Leadership Principles 连成一套

Amazon SWE 面试准备：区分 SDE II、University OA 及邀请，用退款事件练习身份、参数冲突和累计上限，再延伸到并发、提交后断线与外部结果未知。把 Leadership Principles 联系到真实项目的责任、取舍和量测证据，不把不同地区面经拼成固定 Loop。附代码、失败路径与五个追问。

Amazon 软件工程师面试准备，可以把 Coding、设计与 Leadership Principles 放进同一套证据习惯：明确契约，验证失败路径，说明自己为何做出一个选择。它们不是三个独立的背诵清单，也不意味着用同一段 STAR 故事回答所有问题。

先确认级别、地区、申请渠道与邀请。本文用原创退款事件模型，把代码正确性延伸到幂等、并发和恢复，再展示如何从真实项目中整理 LP 证据。例子不是 Amazon 的实际试题或生产系统，虚构回答也不能作为个人经历复述。

官方资料要按角色和阶段使用

Amazon 的 SDE II 官方准备页讨论编码、设计与 Leadership Principles，强调可执行而非伪代码的实现、边界与测试，并建议用过去的行为说明发生了什么、如何行动及为何选择。它是 SDE II 的资料，不应把页面中的具体流程套给所有实习或 SDE I 候选人。

University SDE OA 官方说明针对学生及相关早期职业申请，区分全职与实习，并说明结构会依国家而变、邮件提供具体信息。它能帮助准备对应 OA，不能证明你一定收到相同题数、时长或环节。

官方 OA 页面对于公开资料访问的说明，也不能被扩展成所有面试都允许 AI 或外部协助。以你自己的邀请与正式规则为准；准备阶段用工具学习和正式测验允许哪些工具，是两件事。不清楚时向招募方确认，不自行尝试未获允许的辅助方式。

邀请若没有写设计，保留基本准备并确认范围，而不是默认完全没有设计。相反，不能因为某篇高职级面经谈了大规模架构，就把它当作校招下一轮的必考内容。角色资料决定适用边界，邀请决定当前任务。

个人面经可以提出问题，不能替你确认 Loop

一位欧洲 SDE I 候选人的 2026 年报告描述 Coding、项目、行为和设计相关对话，以及自己的后续团队沟通。另一位2026 年 SDE I 报告作者记录了代码复杂度、口头 dry run 与项目追问，其中标出 7 月和 8 月的面试日期。

这两位作者是不同个体，但并不构成美国同市场、同渠道、同周期流程的交叉验证。本文不由此推导固定轮次、每轮 LP 数量、统一难度或结果等待时间。它们有用之处是提醒你：技术回答可能需要继续解释，项目细节也可能被重复追问。

读面经时，给每个信息加上地区、级别、申请渠道、经历日期与公开程度。发布日期不一定是面试日期，评论区猜测也不是作者的经历。遇到被隐藏或未说明的细节，留下空白，不用另一位候选人的帖子补成一个完整的“标准 Loop”。

准备一个最小确认问题，例如：“这次设计讨论更偏类与接口还是跨服务架构？”然后把回答转成练习产物。比起追求互联网题单的完整性，这能更直接决定接下来做什么。

用一段事件模型练习 Coding 契约

原创练习：已知订单的已支付金额，按输入顺序处理退款事件。每条事件是 (event_id, order_id, amount)；金额使用整数最小货币单位，不用浮点金额。目标是返回每个订单的累计退款和各次请求的原始处理结果。

契约先明确：金额必须为正整数，订单已存在；同一事件 ID 同订单同金额是重试，不重复加钱；同 ID 不同参数是冲突，整次函数调用报错。不同事件 ID 可以作用于同一订单，但累计退款不能超过已支付额。

请求身份与参数不是同一回事。 两次退款都为 100，可能是两个合法业务请求；同一事件重送两次，则应该识别为同一次。只拿金额或整行内容去重，会把合法请求合并，或者让冲突参数变成另一次请求。

这版还规定：超过上限的有效请求记录为 over-cap，并保存该结果；同一请求以后重复到达，仍返回原结果。这是为了让练习契约明确，不代表所有退款产品都应采用该规则。跨订单事件 ID 在这个函数内全局唯一，多租户生产系统则需要重新定义身份范围。

实现去重和上限，测试别只看总额

下面只在一次函数调用的内存中处理有限、顺序排列的事件。输入映射与事件元组格式符合声明的接口；金额、身份类型、未知订单与冲突会被检查。函数不会更改传入的支付映射，也不会向外部付款系统发送任何操作。

def refund_totals(paid, events):
    for order, amount in paid.items():
        if not isinstance(order, str) or type(amount) is not int or amount < 0:
            raise ValueError("invalid paid amount")
    totals = {order: 0 for order in paid}
    seen = {}
    results = []
    for event_id, order, amount in events:
        if not isinstance(event_id, str) or not isinstance(order, str):
            raise ValueError("string identities required")
        if order not in paid or type(amount) is not int or amount <= 0:
            raise ValueError("invalid refund")
        if event_id in seen:
            old_order, old_amount, result = seen[event_id]
            if (order, amount) != (old_order, old_amount):
                raise ValueError("same event ID, different parameters")
        else:
            result = "over-cap"
            if totals[order] + amount <= paid[order]:
                totals[order] += amount
                result = "applied"
            seen[event_id] = (order, amount, result)
        results.append(result)
    return totals, results

订单 O 已支付 1,000，事件依次为 R1 退 400、R1 再退 400、R2 退 600、R3 退 1。结果总额为 1,000，状态为 applied, applied, applied, over-cap。第二个 applied 是重放 R1 的原结果，并非又执行一次退款；这个区别必须口头说明。

先测试等于上限能成功、超过一单位被拒绝，再测试重复事件、同 ID 不同金额、未知订单、空事件和多个订单互不污染。把 R1 改成 R2 不算重复，哪怕金额一样。仅总额正确还不够：若失败请求重试时改变结果，就违背了前面声明的契约。

处理 n 个事件、m 个订单，在通常哈希表操作平均为常数的假设下，时间为 O(n+m)；保存订单总额、事件结果与返回列表需要 O(n+m) 空间。它不是常数空间，也不证明持久性、跨进程去重或并发安全。

如果后续事件发生参数冲突，函数抛出异常，不返回部分结果；由于没有外部副作用，这与已经支付出款的生产 API 不同。先说清这个模型限制，再讨论设计层如何处理，不能用一段正确的字典代码暗示已经解决了金融系统可靠性。

设计追问：同一事件与不同事件都可能竞争

当面试官加入并发请求，两个工作者可能同时读到某订单仍有 100 可退，各自提交不同 ID 的 100。单纯的事件唯一键只能避免同一个请求重复，不能避免两个合法身份合计超过订单上限。需要把累计额度约束与请求结果的记录放在一致的权威提交边界。

在一个数据库交易模型中，可以锁定或条件更新订单额度，同时插入事件身份、参数摘要与结果。事务失败时全部回滚；同一键竞争时等待或读回已有结果。具体数据库隔离、唯一约束与查询顺序仍需整合测试，不是说“加一个锁”就完成所有保证。

AWS Builders’ Library 的幂等 API 说明支持调用方请求标识、去重记录与状态变化原子性的工程原则。用它理解“提交后响应丢失”：客户端不知道是否成功，应该用原请求键重试并读回原业务结果，而不是改一个新 ID 再执行。

如果真正退款需要调用外部支付服务，数据库事务不能自动包含那个远程调用。需要定义 PENDING、已确认、结果未知与对账状态，沿用外部服务支持的请求身份，并处理迟到回复。Outbox 能帮助发送工作可靠地推进，但不等于远程效果只能发生一次。

图中只展示用户 A 的一笔订单。累计上限按这笔订单的已支付额检查，不能把同一用户的不同订单混成一个额度；绿色重放也只读取原结果，不再次更新余额。持久重放与原子更新仍需前面声明的存储边界。

从代码到设计，哪些假设必须重新声明

顺序模型里，输入本身提供了处理顺序；分布式系统里，不同请求可能以不同顺序到达。若额度只够一次退款，哪个请求成功涉及接纳顺序与业务公平性。先说明你的权威服务在哪个时刻决定顺序，不要假设时间戳天然提供全局顺序。

顺序模型从空 seen 开始，因此函数重启就失去去重信息。生产路径则需保存结果与审计历史，并设定键的范围和保留期限。旧请求在记录过期后迟到怎么办，需要契约和恢复政策；无限保存只是把风险变成容量和数据生命周期问题。

若新增多币种，不能把不同货币的整数直接相加。订单金额、退款金额与货币应在同一业务边界确认；若新增撤销退款，则额度可能重新变化，先前保存的拒绝结果是否仍重放也要重新约定。新的功能往往改变状态模型，而非增加一个分支就结束。

准备设计时，至少保留两条失败时间线：原子提交后响应丢失，以及远程操作结果未知后进程重启。分别讲清客户端、权威数据库、工作者和外部服务知道什么。若只画正常请求的箭头，无法展示恢复判断。

Leadership Principles 应从决策中出现

Amazon 官方 Leadership Principles说明这些原则用于日常决策。准备时，把它们当作观察自己行为的角度，而不是为每个故事强行贴三个标签。你要证明具体做过什么，原则名称不能替代证据。

Customer Obsession 可以体现在你改变了处理优先级，因为某个技术症状造成真实用户损失；Ownership 可以体现在你把排查、协调与后续验证做完，而不只关闭自己的工单；Dive Deep 则需要展示你如何从表面指标追到机制。它们可以共享一个项目，但回答不同问题时，重点应不同。

例如“我修了退款重试问题，所以体现了 Ownership”信息太少。需要继续问：你负责的是客户端、后端还是支付集成？谁发现症状？哪个证据支持重复执行假设？为什么没有选择直接关闭重试？修补后如何确认仍能恢复暂时网络故障？

也准备一个合理的不同意见。伙伴可能希望按时上线，你认为结果未知路径尚未测试；双方不一定有人粗心。说明你提出了什么风险、怎样比较可逆试运行与延期，以及决策确定后如何执行。这比讲自己“说服所有人”更能展示判断。

把真实项目整理成可防守的证据链

下面是虚构项目的证据结构，不是建议候选人冒充经历。场景是一个团队发现用户重复点击后的退款状态不清晰；你负责事件身份与后端状态，同事负责界面和支付集成。真正准备时，把每一项换成能合法披露且确实发生的事实。

证据环节	虚构示例中的具体问题	真实回答需要提供什么
用户症状	是重复扣额度，还是同一结果显示两次？	区分真实业务效果与界面呈现
个人责任	你改的是身份、交易还是对账？	自己的代码与共同决策边界
被放弃的方案	为什么不直接禁止所有重试？	可恢复故障与重复效果的取舍
验证范围	是否测提交后断线、重启和迟到？	实际做过的测试，不只是计划
结果口径	重复率分母是什么，观测多久？	可观察结果及归因限制
后续改变	新功能是否沿用这套身份契约？	一个持续机制，不只一次补丁

结果的数字应能重新解释。假设测试中原本 100 次断线注入有 8 次出现重复请求处理，修补后同一测试集为零，只能证明那个测试集的变化。它不等于线上退款错误率下降百分之百，更不证明所有未测故障已经消失。

如果没有精确量测，可以用真实、有限的观察描述，并说明未保存的数字。不要用团队整体营收、流量增长或事故减少作为自己的单一因果功劳。机密资料脱敏，内部客户、凭证和代码不放入面试练习文档。

混合追问时，回到当前问题而不是背完故事

Coding 之后被问“为什么选这个状态”，回答当前模型的不变量，不必立刻讲完整项目。项目里被问“如果并发十倍怎么办”，先说当时实际负载和已测边界，再推演新假设；不要把练习架构反写为自己已经做过的生产成果。

STAR 可以帮助压缩背景、任务、行动和结果，但不能压掉技术机制。先给短版本，再根据对方的问题展开身份、事务或量测。若对方重复提问，检查自己是否只回答了行动，却没解释为什么、具体怎样做或怎样知道有效。

失败故事也要真实。说明当时错误的假设、造成的影响、你自己的责任以及后来改变的机制。不能把“我要求太高”包装成失败，也不需要把合理的团队限制都归咎于自己。可解释的边界比夸大的英雄故事更容易承受深挖。

最后确认准备是否覆盖不同证据，而非不同标签。至少有一次技术取舍、一次诊断、一次协作或不同意见、一次真实修正；这些可以来自少数项目，但每个回答应有独立的决策细节。不要编造经历填满原则列表。

用五个不同追问检查下一次准备

下表包含 Amazon 记录与跨公司练习，后者已明确标注，不是 Amazon 出题预测。选题围绕故事、失败、交付、工具验证与技术取舍，避免仅用五段同类 LP 题替代 Coding 和设计练习。

题目	本篇选择理由	练完留下什么
Prepare Leadership Principle Stories	Amazon 记录，先整理真实故事	行动、理由、结果与个人边界
Describe a Failure and the Change It Prompted	Google 记录，跨公司检验复盘	错误假设及持续改变
Explain Tight-Deadline Delivery and a Missed Deadline	Amazon 记录，防止只说按时完成	范围、沟通与交付取舍
Walk Through a Project, a Project That Went Wrong, and How You Use AI	Decagon 记录，练习工具与个人理解	验证方式及真实使用边界
Cache Trade-offs and a Constant-Time Least-Recently-Used Cache	用实现连接性能与状态取舍	不变量、复杂度与故障限制

下一次在 Amazon Software Engineer 题库选一个与当前邀请匹配的任务，先独立完成，再加一个需求变化。最后从自己的真实项目里选一项相关决策接受追问。连接三个准备方向的是你能说明并验证的判断，不是一份固定 Loop，也不是漂亮的原则标签。

资料来源与延伸阅读

资料核对：2026 年 10 月 6 日。本文不提供正式测验答案、不推测通过分数，也不承诺面试或录取结果。