亚马逊数据科学家 SQL 面试模板：下载检查清单
一句话总结
亚马逊数据科学岗位的 SQL 面试核心不在于考察你能写出多复杂的嵌套查询，而在于判断你是否具备在 PB 级脏数据环境中通过低成本查询定位业务真问题的能力。大多数候选人花费大量时间背诵窗口函数和递归逻辑，却忽略了亚马逊特有的“逆向工作法”在代码层面的体现：先定义业务产出，再反推数据路径，这直接决定了你在 Debrief 会议上是被定义为"Builder"还是仅仅是一个"Code Monkey"。正确的判断是，面试官手中的评分表上，"Data Quality Awareness"和"Business Impact"的权重远高于"Syntax Perfection"，你之前认为的“写出最优解”大概率是错的，因为在一个分布式系统中，可维护性和容错性才是唯一的真理。不要试图用炫技般的单行代码去征服面试官，那是在展示你的自负，而不是工程素养；真正的通过者，是那些愿意为了团队长期利益而写出略显冗余但逻辑透明代码的人。记住，拿到 Offer 的关键不是你的代码跑得快不快，而是你的代码在凌晨三点挂掉时，能不能让值班工程师在五分钟内看懂并修复。这不是关于技术的较量，而是关于工程文化和风险偏好的匹配度测试，你的每一个变量命名、每一次连接方式的选择，都在向面试官传递你是否属于这个组织的信号。
适合谁看
这篇文章专为那些已经收到亚马逊数据科学家面试邀请，但误以为凭借 LeetCode 刷题经验就能通关的技术人员准备。如果你认为数据科学家的 SQL 面试只是把 Medium 难度的题目做出来，或者你以为只要掌握了 Hive 和 Redshift 的语法差异就能应对自如，那么你需要立刻停止这种危险的幻想。真正的受众是那些在过往经历中习惯了对着干净的数据集做分析，却从未在缺乏文档、表结构混乱、数据倾斜严重的生产环境中挣扎过的候选人。这里不欢迎只想通过背诵模板来碰运气的投机者，因为亚马逊的面试官经过专门训练，能够敏锐地捕捉到你代码背后是否有真实的业务场景支撑。适合阅读的人，是那些准备好接受“不是展示你会什么，而是展示你如何思考边界情况”这一残酷现实的专业人士。如果你在之前的面试中因为“代码能跑但逻辑有漏洞”被拒，或者你在听到“如果这张表有十亿行数据，你的查询会发生什么”时感到后背发凉，那么这篇文章就是为你写的裁决书。这不是给初学者的入门指南，而是给那些站在门槛上却看不清门内规则的人的一张地图。你需要明白，亚马逊寻找的不是最聪明的解题者，而是最稳健的构建者，你的代码风格必须从“个人英雄主义”转向“团队可持续性”。如果你的目标是进入一个对数据质量零容忍、对业务逻辑深究到底的环境，那么请继续往下读，因为这里的每一条规则都是用无数失败案例换来的血泪教训。
亚马逊数据科学家 SQL 面试主要考察什么能力？
在亚马逊的 SQL 面试环节，面试官手中拿的不仅仅是一份代码评分表，更是一份关于你工程直觉的体检报告。很多人误以为这里考察的是语法的熟练度，实际上，考察的核心是你面对未知数据环境时的决策框架。这不是关于你能否在十分钟内写出一个包含五个 CTE 的复杂查询，而是关于你能否在第一眼看到表结构时，就本能地询问“这个字段为空意味着什么”以及“这张表的数据更新频率是多少”。在亚马逊内部，我们见过太多候选人写出了语法完美但逻辑灾难的代码，他们能够熟练使用 RANK() 和 LAG()，却在处理重复数据时直接选择了 DISTINCT，完全无视了这可能掩盖了底层 ETL 流程的严重 Bug。正确的判断是，面试官希望看到的“不是 A（快速给出答案），而是 B（花时间澄清假设并设计鲁棒方案）”。
想象一个真实的 Debrief 场景：三位面试官围坐在会议室里，面前投影着候选人的代码记录。面试官 A 说：“他的查询效率很高，用了自连接解决了时间区间重叠问题。”面试官 B 反驳道：“是的，但他完全没有处理 eventtime 为 NULL 的情况，在我们的日志数据中，这占了 5% 的比例，这意味着他的查询会直接丢掉二十分之一的数据，导致业务方做出错误决策。”面试官 C 补充：“而且他没有考虑数据倾斜，如果某个 userid 对应了海量日志，他的 Join 操作会导致整个集群倾斜。”最终，这位语法完美的候选人被判定为"No Hire"，因为他缺乏对数据真实性的敬畏。这就是亚马逊的残酷之处：代码能跑通只是及格线，代码能应对极端脏数据才是加分项。
你需要展现出一种特质：在动手写代码之前，先进行“数据侦探”式的提问。这不是在浪费时间，而是在展示你的工程成熟度。当面试官给出一张 orders 表和一张 users 表时，不要急着写 SELECT FROM users JOIN orders。你要问：“这两个表的关联键是唯一的吗？如果一个用户有多条订单记录，我是需要去重还是保留？如果 orders 表里有测试数据（比如 user_id 为负数或特定前缀），我该如何过滤？”这些看似啰嗦的问题，在面试官耳中是黄金般的信号，表明你不是在真空中写代码，而是在为一个真实的、混乱的业务系统负责。错误的做法是默认数据是干净的，直接开始堆砌逻辑；正确的做法是假设数据全是脏的，每一行都需要验证。这种思维模式的转变，是从“做题家”到“工程师”的跨越。在亚马逊，我们宁愿要一个花五分钟问清楚需求再花十分钟写简单代码的人，也不要一个不问青红皂白两分钟写出复杂代码然后留下无数隐患的人。记住，你的目标不是证明自己比编译器聪明，而是证明你比系统里的 Bug 更聪明。
为什么标准答案在亚马逊面试中往往行不通？
在硅谷的很多面试中，存在一种“标准答案”的迷思，即认为每道算法题或 SQL 题都有一个最优解，只要复现出来就能得分。在亚马逊，这种思维是致命的。亚马逊的面试机制设计初衷就是为了过滤掉那些只会套模板的人，因为现实业务中的问题从来没有标准答案，只有基于特定约束条件下的权衡（Trade-off）。当你面对一道关于“计算过去 30 天活跃用户留存率”的题目时，如果你直接套用教科书上的日期差值计算，你很可能会掉进陷阱。面试官故意不告诉你的隐藏条件是：数据可能存在延迟到达（Late Arriving Data），昨天的订单可能今天才入库；时区可能不统一，美东时间的凌晨在美西时间还是昨天。
这里有一个典型的 Hiring Committee 讨论细节：一位候选人在处理时间窗口时，使用了硬编码的 CURRENT_DATE - 30。面试官指出，如果任务是在 UTC 时间凌晨 1 点运行，而业务方关注的是太平洋时间，那么取出的数据就会错位。候选人辩称“题目没说时区”，但这正是考察点所在。亚马逊的文化是"Ownership"和"Dive Deep"，如果你不主动考虑这些边界情况，说明你缺乏对业务全貌的掌控欲。正确的判断是，面试官期待的“不是 A（按部就班完成题目要求），而是 B（主动识别题目未言明的风险并提出解决方案）”。
再看一个关于聚合函数的例子。题目要求计算每个类别的平均销售额。很多候选人会直接写 AVG(sales)。但在亚马逊的实战场景中，sales 字段可能包含负数（代表退货），也可能包含极大的异常值（代表 B2B 大宗交易）。直接求平均会严重扭曲业务真相。高分的回答会先询问：“我们需要剔除退货吗？对于极端异常值，我们是截断处理还是单独标记？业务方看这个指标是为了看日常流水的波动，还是看整体营收规模？”然后，候选人会提供两套方案：一套是基础的 AVG，另一套是基于中位数或去噪后的统计量，并解释各自的适用场景。这种“不是给出一个数字，而是提供决策依据”的做法，才是亚马逊想要的。
此外，关于代码的可读性，标准答案往往追求极简，甚至使用缩写和复杂的单行逻辑。但在亚马逊，代码是写给人看的，顺便给机器执行。如果一个变量名叫 d，哪怕上下文中能猜到是 date，也是不合格的。在代码审查（Code Review）环节，这样的代码会被打回重写。面试中，如果你写出了只有你自己能看懂的“聪明”代码，面试官会认为你的协作成本极高。正确的做法是，把代码写得像文档一样直白，哪怕多写几行。比如，不要在一个巨大的 WHERE 子句里塞进所有的过滤条件，而是将其拆解成命名的 CTE（公共表表达式），每个 CTE 代表一个业务逻辑步骤。这样，即使是一个刚入职的同事，也能顺着你的逻辑链条读下去。记住，亚马逊看重的是“长期主义”，你的代码不仅要解决今天的问题，还要能适应明天的变化。任何增加未来维护成本的“捷径”，在面试中都是减分项。
真实的亚马逊数据科学家薪资结构与面试轮次拆解
很多候选人对亚马逊的薪资结构存在误解，认为只要技术过硬就能拿到顶格 Offer，或者混淆了不同级别（Level）的薪资带宽。在硅谷，数据科学家的薪资由 Base（基本工资）、RSU（限制性股票单位）和 Sign-on Bonus（签字费，通常分两年发放）组成，且随着级别的不同，三者的比例会发生剧烈变化。对于 L5（中级）数据科学家，典型的总包（Total Compensation, TC）范围在$220,000 到$320,000 之间，其中 Base 约为$160,000-$190,000，RSU 分四年归属，每年约$30,000-$50,000，签字费第一年较高，第二年递减。而对于 L6（高级）级别，TC 可跃升至$350,000-$550,000+，此时 RSU 成为大头，Base 增长反而放缓，约为$210,000-$240,000，但股票部分可能高达每年$100,000 以上。这种结构设计的逻辑是：级别越高，对公司长期价值的影响越大，因此用股票绑定。如果你在谈薪时只盯着 Base 看，而忽略了 RSU 的归属计划（Amazon 的归属是前两年各 5%，后两年各 45%，或者新的分级归属模式，需实时确认最新政策），你可能会做出错误的选择。
面试流程通常分为四轮技术面加一轮 Bar Raiser（把关人）面，每一轮的考察重点截然不同，绝非简单的重复考察。第一轮通常是在线测试或初筛，重点考察 SQL 基础语法和数据清洗能力，题目难度中等，但会在数据 cleanliness 上设坑。第二轮是深度技术面，面试官会给出一个开放式的业务场景，例如“如何设计一个表来追踪 FBA 库存的实时变化”，重点考察数据建模能力和对 AWS 生态（如 Redshift, Athena, EMR）的理解。这一轮不是考你会不会写 Join，而是考你懂不懂分区（Partitioning）、分桶（Bucketing）以及列式存储的优势。
第三轮往往是案例分析（Case Study），要求你根据给定的数据集（通常有缺陷）回答一个具体的业务问题，如“为什么上周 Prime 会员的转化率下降了”。这一轮不仅看 SQL 能力，更看你的业务敏感度和沟通逻辑。你需要主动定义指标，拆解维度，并给出可执行的建议，而不是仅仅扔出一堆图表。最后一轮 Bar Raiser 面最为关键，此人拥有“一票否决权”，他不属于招聘部门，唯一任务是确保候选人符合亚马逊的领导力准则。在这一轮，技术题目可能变难，也可能变偏，甚至会让你现场优化一段写得很烂的 SQL 代码，重点考察你在压力下的判断力和价值观。
在这个流程中，每一轮都有明确的通过标准。如果你在某一轮表现出对数据准确性的漠视，或者在讨论方案时完全不顾及成本（如随意使用 SELECT 或全表扫描），哪怕你技术再强，Bar Raiser 也会把你拦在门外。薪资的谈判也往往基于你在这些环节展现出的 Level 定位。如果你在所有环节都展现出 L6 级别的系统思维和业务影响力，HR 才会给出对应级别的 Offer。反之，如果技术好但缺乏业务大局观，可能只会被定在 L5。这就是为什么单纯刷题不够的原因：你需要在每一轮对话中，都精准地传递出你对“规模感”和“业务价值”的深刻理解。
准备清单
为了在这场高强度的筛选中胜出，你需要执行一份严苛的准备计划，这不仅仅是复习语法，更是重塑思维模式。
- 深入研读亚马逊领导力准则（Leadership Principles），特别是"Customer Obsession"和"Dive Deep"，并将它们转化为 SQL 面试中的具体行为，例如在写查询前先问三个关于数据质量的问题。
- 熟练掌握 AWS 数据生态特有的 SQL 方言和函数，特别是 Redshift 和 Athena 中的窗口函数、JSON 解析函数以及时序处理函数，不要只在本地 MySQL 环境下练习。
- 系统性拆解面试结构（PM 面试手册里有完整的亚马逊数据科学实战复盘可以参考），重点分析过去三年亚马逊面试中出现的高频业务场景，如库存周转、物流延迟分析、Prime 会员行为预测等。
- 准备至少三个你过去处理过的“脏数据”案例，详细描述你是如何发现异常、如何定位根源、以及如何设计机制防止复现的，用 STAR 法则（情境、任务、行动、结果）进行打磨。
- 进行模拟面试时，强制自己养成“先口述逻辑，再写代码，最后自我反驳”的习惯，记录每一次卡壳的地方，分析是因为语法不熟还是业务理解偏差。
- 复习数据库基础理论，特别是索引原理、执行计划（Explain Plan）分析、数据倾斜处理策略，确保你能从底层原理解释为什么你的查询是高效的。
- 整理一份针对亚马逊业务的“指标字典”，熟悉电商、云计算（AWS）、广告、流媒体等核心业务线的关键指标定义，避免在面试中出现概念性错误。
常见错误
在亚马逊的 SQL 面试中，犯错是常态，但犯低级错误或重复同样的错误是致命的。以下是三个典型的失败案例，展示了 BAD 与 GOOD 的巨大差异。
错误一：忽视空值与数据异常，盲目追求代码简洁。
BAD 写法：
`sql
SELECT userid, COUNT() as ordercount
FROM orders
GROUP BY user_id;
`
这种写法在面试中是灾难性的。它没有处理 user_id 为 NULL 的情况（虽然主键通常不为空，但在日志表中常见），也没有过滤掉测试数据或状态为'CANCELLED'的订单。
GOOD 写法：
`sql
SELECT userid, COUNT() as validorder_count
FROM orders
WHERE order_status = 'COMPLETED'
AND user_id IS NOT NULL
AND orderdate >= CURRENTDATE - INTERVAL '30 days'
GROUP BY user_id;
`
更重要的是，在写代码前，优秀的候选人会说：“我假设 orderstatus 只有几种枚举值，我会先确认是否有脏数据混入。另外，考虑到数据量，我会在 orderdate 上加过滤条件下推，避免全表扫描。”这种对边界和性能的考量，才是加分项。
错误二：过度优化，使用晦涩难懂的技巧。
BAD 写法：为了在一行内解决问题，使用了多层嵌套的子查询和复杂的正则表达式，变量名全是 t1, t2, col1。
GOOD 写法：使用 CTE（Common Table Expressions）将逻辑拆解为清晰的步骤，每一步都有明确的命名，如 filteredlogs, aggregatedmetrics, final_ranking。并在注释中解释为什么要这么做，例如：“这里使用 Left Join 而不是 Inner Join，是为了保留没有匹配到用户信息的异常订单，以便后续排查数据源问题。”不是 A（展示个人聪明才智），而是 B（降低团队理解成本）。
错误三：对业务场景无感，机械地转换需求。
BAD 场景：面试官问“如何计算用户的留存率”，候选人直接写了一个固定的 7 天留存公式，没有询问业务背景。
GOOD 场景：候选人反问：“我们要看的是自然日留存还是 7 日滚动留存？是针对新客的次留，还是老客的复购？不同的业务目标（如拉新 vs 促活）对应的定义完全不同。如果是为了评估一个新功能的上线效果，我们可能还需要做 A/B 测试的分层处理。”这种对业务上下文的敏感度，区分了普通技工和高级数据科学家。
FAQ
Q1: 如果我在面试中完全不知道某个 SQL 函数或语法，应该直接放弃还是尝试瞎编？
绝对不要瞎编，也不要直接说“我不会”然后沉默。亚马逊看重的是解决问题的能力和诚实（Earn Trust）。正确的做法是坦诚说明你不熟悉该特定语法，但立刻给出你的解决思路。例如：“我目前记不清 Redshift 中处理 JSON 提取的具体函数名是 jsonextractpath_text 还是其他，但我清楚逻辑是先将 JSON 字符串解析，再提取对应 Key 的值。在实战中，我会查阅文档或询问同事，但在当前场景下，我可以先用伪代码或通用 SQL 逻辑表达这一步，您看可以吗？”这种回答展示了你的逻辑清晰度和协作态度，远比硬背一个错误的函数名要好得多。面试官想看到的是你在未知领域的探索能力，而不是百科全书式的记忆。
Q2: 亚马逊的 SQL 面试会考察存储过程（Stored Procedures）或复杂的脚本编写吗？
通常不会深入考察存储过程的具体编写细节，因为现代数据架构（尤其是 AWS 生态）更推崇 ELT 模式，即在数据仓库中使用 SQL 进行转换，逻辑下沉，应用层只做读取。面试重点在于你对集合操作（Set-based operations）的理解，而不是游标（Cursor）或循环逻辑。如果你花费大量时间用循环去逐行处理数据，这反而是一个负面信号，表明你缺乏大规模数据处理的思维。面试官更希望看到你如何利用 Window Functions、CTE 和自连接来高效解决问题。当然，如果你能提到在特定场景下（如复杂的数据清洗流程）使用存储过程的利弊，并指出在 AWS Glue 或 Lambda 中替代的方案，会是极大的加分项。核心在于展示你对“扩展性”和“维护性”的考量。
Q3: 面试结束后，多久能知道结果？如果没有通过，会有反馈吗？
通常在面试结束后的 24-48 小时内，Recruiter 会给出初步的口头通知，正式的 Offer Letter 或拒信会在 1-2 个工作日内发出。亚马逊的 Debrief 会议通常在所有面试结束后的当天或次日早上召开，所有面试官集中讨论并投票。关于反馈，遗憾的是，由于法律和公司政策原因，亚马逊通常不提供具体的面试技术细节反馈，只会给出笼统的“与岗位要求匹配度不足”等官方回复。这是因为避免法律纠纷以及保护面试题库。但是，如果你的表现处于“边缘”状态（Borderline），Recruiter 可能会在电话中委婉地暗示你在某些方面（如领导力准则的某一条）表现不够突出。因此，不要在等待反馈中浪费时间，无论结果如何，立即复盘自己在面试中的每一个回答，对照领导力准则进行自我修正，为下一场战斗做准备。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。