数据分析与商业分析面试，常常需要把业务问题、数据定义、查询结果和建议连起来。只会写出一条 SQL，还不足以说明结果能否使用。准备时应练习先澄清口径，再检查数据，最后用普通语言解释发现和限制。
先读清楚岗位到底偏什么工作
Data Analyst、Business Analyst、Business Intelligence Engineer 等名称并不保证职责相同。有的岗位重视经营指标和沟通，有的更需要数据建模、报表开发或技术实现。先从官方职责里判断日常交付，再决定准备顺序。
Amazon 的学生数据岗位准备页分别介绍了业务智能和数据工程相关能力。它可以作为一个雇主示例，不能用来推断所有公司都采用相同轮次或题型。具体测评与面试说明要跟着目标岗位走。
可以建立能力清单：数据读取、口径定义、基础统计、业务判断、可视化与沟通、项目解释。每项写一份已有证据和一个需要补的练习。不要把软件数量当成准备程度，重点是能否完成岗位需要的任务。
遇到业务问题先澄清目标
假设对方问“哪个渠道表现更好”。直接按收入排序会跳过很多问题：公司想提高收入、利润、付费人数，还是长期留存？比较哪个时间范围？不同渠道的投入、客户类型和归因方式是否相同？
你可以先简短确认决策场景，再提出关键口径。不是用大量问题拖延开始，而是选择会改变结论的条件。例如是否把退款计入、是否按用户去重、是否包含测试订单，都会影响计算方式。
如果面试官让你自行假设，就把假设说出来并继续。可以说明先采用一个清楚定义完成分析，之后再讨论换口径是否改变判断。把未知部分明确标记，比默默采用有利于结果的定义更容易讨论。
先知道一行数据代表什么
拿到表以后，确认记录粒度：一行是订单、商品、支付事件还是用户某天的活动。同样叫订单表，也可能一笔订单对应多行商品。没有确认粒度就统计行数，可能把商品数量误当订单数量。
检查主键是否唯一、关键字段是否缺失、状态值有哪些、日期使用哪个时区。连接两张表之前，也要判断关系是一对一还是一对多。数据重复并不一定来自脏数据，有时是连接后改变了粒度。
可以先选少量记录手算，再写完整查询。小样本不是为了代表全部业务，而是帮助发现定义与实现不一致。面试中展示这种检查过程，能够让对方知道你怎样避免给出看似精确的错误数字。
一组可以手算的教学数据
以下是本文构造的八条模拟订单，每行一笔订单，编号唯一，金额单位相同，渠道按本表既定归属记录。状态是同一观察时点的快照，只有已支付、已取消和已全额退款三种。它不是公司真实数据，也不是招聘原题。
| 订单编号 | 渠道 | 状态 | 金额 |
|---|---|---|---|
| 1 | search | paid | 120 |
| 2 | search | paid | 80 |
| 3 | social | cancelled | 50 |
| 4 | social | paid | 60 |
| 5 | search | refunded | 40 |
| 6 | social | paid | 40 |
| 7 | social | paid | 100 |
| 8 | search | cancelled | 70 |
本次练习只统计观察时点仍为 paid 的订单金额，以及各渠道的总订单数和 paid 订单数。它不是财务净收入，也不是广告转化率。没有访问量、投放成本和退款发生时间，就不应给这些概念换名字。
先写计算步骤再写 SQL
第一步按渠道分组。第二步统计本表订单行数。第三步在每个渠道中筛选状态为 paid 的记录，计算数量和金额。最后再比较结果，并检查是否与手算一致。
下面的 SQL 可以在 SQLite 中运行。聚合函数的含义可查阅 SQLite 官方说明。真实工作可能使用其他数据库，日期与类型转换等细节需要按具体系统调整。
SELECT
channel,
COUNT(*) AS total_orders,
SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_orders,
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_amount
FROM orders
GROUP BY channel
ORDER BY channel;
查询结果应当是 search 有四笔总订单、两笔 paid 订单、paid 金额二百；social 有四笔总订单、三笔 paid 订单、paid 金额也是二百。这段示例已按上述数据运行核对，后续修改数据时也应同步检查结果。
相同金额背后可能有不同结构
在这个小样例中，两渠道 paid 金额相同，但 paid 订单数量不同。按本次定义，search 的 paid 订单平均金额是一百，social 约为六十六点六七。可以进一步说两者的订单结构不同，但不能从八条模拟记录推出哪个渠道更值得投入。
如果计算 paid 订单占本表订单数的比例，search 为百分之五十，social 为百分之七十五。这个比例必须叫清楚：它只是当前样例中相应状态的订单占比。因为没有访问人数或访问次数，不能称为从流量到付费的转化率。
这正是面试中的重要区别：算出数字以后，还要确认名字是否准确、分母是否合适、结论有没有超过数据。术语一旦用错，业务读者可能按照错误含义作决定。
退款与取消如何影响口径
本例把全额退款订单从 paid 金额中排除，是因为我们明确选择了观察时点的状态口径。真实业务可能要统计某段期间的支付发生额、退款发生额或财务确认收入，这时仅看当前状态通常不够。
如果一笔订单上月支付、本月退款，要回答本月的净现金变化，需要事件时间和金额。把所有 refunded 订单都从上月收入中直接删除，可能改变原本想回答的问题。遇到部分退款、多次支付或跨币种，也需要补充数据结构和业务定义。
面试中可以说明这个限制，再提出下一步需要哪些字段。承认当前表不能回答全部问题，是合理分析的一部分，不代表不会写更复杂的查询。
连接表时先防止重复计算
假设还要连接订单明细表，一笔订单有多件商品。直接连接以后再把订单金额求和，可能把同一笔金额重复计算多次。正确处理取决于目标粒度，可以先把明细聚合到订单层，再与订单表连接。
如果连接客户表，也需要确认每个客户是否只有一条当前记录。存在历史版本时，必须说明按哪个时间点或版本连接。不能看到总额突然增大就认为业务增长了，要先检查行数与键的唯一性。
一个实用检查是比较连接前后的订单唯一数量和总金额。发生变化时，说明变化是否符合预期。这个检查方式比在结果异常后反复增加 DISTINCT 更有解释力，因为去重也可能掩盖模型问题。
怎样把发现讲成业务建议
先给结论范围：在当前样例和定义下，两渠道 paid 金额相同，但数量与平均金额不同。再给限制：样本小，没有成本、流量和长期表现。最后提出下一步：补充对应投入、观察期和用户后续行为，再比较更适合决策的指标。
不要跳到“增加 social 预算”这样的建议，因为目前没有获得新客户的成本，也不知道这些订单是否来自可持续需求。可以提出一个待验证假设，例如研究 social 是否更适合较低客单价用户，但要把它与已经证实的事实分开。
解释给非技术对象时，不必逐行朗读 SQL。说清统计对象、定义、主要差异与下一步即可。对技术面试官则可以进一步解释查询、边界和性能考虑，依据听者需要调整细节。
指标突然下降怎样拆解
遇到“本周收入下降”时，可以先确认数据更新是否完成、指标定义是否变化、观察期是否可比较。半天的数据与完整一天相比，可能制造一个并不存在的业务问题。节假日、活动和数据延迟也需要纳入核对。
随后按能够解释业务的维度拆分，例如客户类型、产品、渠道或地区。拆分需要有目的，不是把所有字段都画一遍。可以用总量与结构变化区分：每组都下降，还是占比变了，或者主要问题集中在一组。
最后再讨论原因候选和验证方法。指标变化与某次活动同时发生，不等于活动造成变化。需要更合适的对照、实验或其他证据，才能作更强的因果判断。
统计和实验问题怎样准备
理解均值、分布、波动和样本的重要性，比只记公式更容易迁移到不同题目。看到平均值时，可以问是否被少数大值影响；看到两个组差异时，可以问样本怎样产生、观察是否独立，以及差异是否可能来自其他因素。
对于 A/B 测试，练习说明目标指标、分配方式、观察周期、异常检查和可能干扰。没有给定样本和条件时，不要凭空报一个通用所需人数。可以先解释需要哪些信息，以及会怎样判断结果是否足够支持决策。
这篇文章不试图用一个小案例替代完整统计训练。目标是帮助你在面试中形成清楚顺序：先定义，再计算，再检查，最后解释。具体岗位更强调哪类统计知识，还要回到官方职责和准备材料。
项目追问如何准备
选一段亲手做过的分析，准备数据从哪里来、最容易错在哪里、怎样验证、最终由谁使用，以及你没有解决的问题。面试官可能不要求你记住每行代码，但会关心你是否真正理解结果。
如果项目只停留在图表展示，可以补充数据检查与业务口径说明。没有真实实施结果时，明确写课程或模拟项目。不要把一个模型指标提升自动描述成真实业务增长，也不要用大量工具名遮住对问题的理解。
练习时请对方改变一个条件，例如把一对多连接加入数据、让一个渠道没有订单、加入未知状态。观察自己能否重新说明口径和处理方案。这比只反复运行一份不会变化的数据更接近真实工作。
给自己安排一轮完整练习
第一步选一个小业务问题，写清需要支持的决定。第二步用少量可检查的数据完成计算。第三步加入一个异常或边界，说明结果怎样变化。第四步用三分钟左右的个人练习时间，向不看代码的人解释结论。
再把实际输出与手算结果对照，记录错误来自语法、数据定义还是业务理解。不同错误需要不同练习。语法问题可以做小查询，口径问题需要重新写定义，解释问题则要练习把术语换成普通语言。
完成以后保留问题、数据、查询、检查结果和结论。一个能够完整复盘的小案例，可以同时帮助准备简历项目、技术问题和业务沟通，也能让你知道下一步应该补什么能力。
加入缺失值以后怎样解释结果
真实数据中金额可能为空，渠道可能没有记录，状态也可能出现新的取值。先决定缺失意味着尚未获取、确实不存在，还是数据错误，再选择处理方式。不能把所有空值自动当成零，因为零金额和金额未知表达的是不同事实。
在本例中，如果某笔 paid 订单的金额缺失，直接求和可能得到不完整的金额结果。可以同时输出金额缺失的订单数量，并在结论中说明目前金额是否可用于比较。这样业务读者知道表格中的数字覆盖了什么，而不是误以为所有记录都完整。
如果一个渠道在观察期内没有订单，分母可能为零。比例应按照事先约定显示为空或明确标记不适用，不能为了让图表好看而随意显示为零。写查询之前先说明这些语义，能够减少代码完成以后再返工。
图表与结论也要一起检查
展示结果时选能回答问题的图，不需要同时放很多形式。比较金额可以用清楚的条形图，比较结构则要说明总量与占比。坐标、单位、时间范围和样本定义必须可见，不能只在口头解释中补充。
最后让一个没有看过查询的人复述结论。如果对方以为本例证明了广告效率，就说明指标名称或说明还不够准确，需要调整。数据工作的完整交付包括计算，也包括防止读者误用结果。
继续安排下一步
技术练习可以与目标岗位和申请时间同步安排，先确定职责方向，再选择与工作内容一致的项目和题目。
常见问题（FAQ）
DA 和 BA 面试准备可以完全一样吗
不能只按岗位缩写判断。先看职责、数据工作比例和官方测评说明，再选择 SQL、统计、业务或沟通的准备重点。
SQL 写出来能运行就够了吗
还需要检查口径、记录粒度、连接重复、缺失值和结果。能运行只说明语法及执行完成，不代表回答了正确的业务问题。
没有业务经验怎么练习分析判断
可以用公开或合成数据构造小案例，明确模拟性质，练习定义问题、检查结果和说明限制。不要把练习结果包装成实际客户成果。
面试不知道某个字段含义怎么办
先提问或明确假设。若该字段会改变结论，说明需要核实后才能作判断；不要为了尽快写查询而默默猜测。
- Interview Preparation for Data Roles· Amazon Jobs
- Built-in Aggregate Functions· SQLite
结合目标岗位、现有经历和申请阶段，向 STEM Career 顾问咨询简历、面试及海外与回国求职准备。