数据分析面试常见问题有哪些？怎么准备（校招 / 社招）

一句话：用数据帮业务回答「发生了什么、为什么、接下来该怎么做」。数据分析师每天打交道的是业务方（产品、运营、市场、销售、管理层）提出的问题，你要把模糊的问题翻译成能用数据回答的问题，取数、清洗、分析，最后给出结论和建议，并跟进建议有没有落地、效果怎么样。

日常工作大致分几块：

• 取数与报表：写 SQL 从数据仓库里取数，维护日报、周报和看板。这是基本功，也是新人最开始做得最多的事。
• 指标体系：定义核心指标和口径，把指标拆成可以追踪、可以归因的层级，让大家对「数字是什么意思」有共识。
• 专题分析：指标异动排查、用户分群、转化漏斗、留存与流失、活动复盘等，最后要落到可执行的建议。
• 实验分析：参与 AB 实验设计，算样本量、看实验结果、判断能不能上线。
• 沟通与推动：把结论讲给不懂数据的人听，推动业务方据此改动作，再复盘效果。

业务分析、商业分析、数据产品 / 数仓方向有什么不同？

招聘时都叫「数据分析」，实际差别不小，投递前先看清楚 JD 偏哪一类：

互联网和传统行业的数据分析有什么区别？ 互联网公司数据量大、埋点全、迭代快，AB 实验是日常工具，面试更看实验和快速拆解问题的能力；传统行业（零售、制造、金融业务支持等）数据分散在多个业务系统里，口径统一和数据清洗的工作量更大，面试更看业务流程理解和把数据整理成可用报表的能力。两边的 SQL 和统计基础要求差不多。

级别上，一般是初级（能按需求准确取数、做报表）→ 中级（能独立负责一个业务线的分析，主动发现问题）→ 高级 / 资深（能搭指标体系、主导实验和专题、影响业务决策）→ 负责人（规划数据团队和分析体系）。级别越高，面试里「你的分析改变了什么」的比重越大，「这个函数怎么用」的比重越小。各公司职级叫法不同，以 JD 和面试官描述为准。

JD 上的每一句要求，几乎都会变成面试里的一类问题。拿到 JD 先按下表拆一遍：

读 JD 的小技巧：看 JD 里业务词（如「增长」「用户」「商业化」「供应链」）和动词（「负责」「参与」「支持」）。业务词决定 Case 面会出什么场景，动词决定期望你独立到什么程度——写「负责指标体系建设」的，面试一定会追问你亲手定过哪些口径、和谁吵过、最后怎么统一的。

不同公司差别较大，下面是互联网公司常见的结构，仅供参考，具体以招聘方通知为准：

社招常见的变化：笔试少了，但一面就会深挖项目；会专门问指标体系怎么搭、分析结论怎么推动业务改变、和产品 / 运营的协作方式；部分岗位会给一份带回家的数据作业，让你拿一份脱敏数据做分析并汇报。

一个规律：越往后，题越开放。SQL 和统计有标准答案，Case 题没有，面试官看的是你拆问题的顺序、提假设的依据，以及最后能不能给出一个业务方真的能执行的建议。

1. 01给你一张新增用户表和一张活跃日志表，写 SQL 算每天新增用户的次日留存率。专业知识笔试技术一面校招 · 社招 · 实习 · 跳槽转行基础

   考察点： 留存的口径是否清楚（分母是谁、分子是谁），能否正确处理日期关联和去重。

   答题思路：

   • 先说口径：次日留存 = 某天新增的用户中，第二天又活跃的人数 ÷ 当天新增人数。分母是「当天新增」，不是「当天活跃」。
   • 思路：以新增表为主表，左连接活跃表，关联条件是同一个用户、且活跃日期正好是新增日期的后一天。
   • 写法示例：SELECT a.reg_date, COUNT(DISTINCT a.user_id) AS new_users, COUNT(DISTINCT b.user_id) AS d1_users, COUNT(DISTINCT b.user_id) * 1.0 / COUNT(DISTINCT a.user_id) AS d1_rate FROM new_user a LEFT JOIN active_log b ON a.user_id = b.user_id AND b.active_date = DATE_ADD(a.reg_date, INTERVAL 1 DAY) GROUP BY a.reg_date
   • 讲三个细节：必须用 LEFT JOIN，否则没留存的用户被丢掉、分母变小；活跃表一个人一天可能有多条记录，要用 COUNT(DISTINCT ...)；乘 1.0 是为了避免有的数据库做整数除法得到 0。
   • 最近一天的新增用户还没有「第二天」，结果会偏低，要么排除，要么标注「数据未成熟」。

   校招怎么答 / 社招怎么答： 校招写对 SQL、讲清左连接和去重就够；社招可以补一句扩展：如果要同时算次日、7 日、30 日留存，会先算出每个用户「活跃日期与注册日期相差几天」，再用条件聚合一次性算出来，而不是写三遍关联。

   可能的追问： 如果要算的是「活跃用户」的次日留存，SQL 哪里要改？7 日留存是指第 7 天活跃，还是 7 天内任意一天活跃？两种口径各适合什么场景？

   练一练
2. 02ROW_NUMBER、RANK、DENSE_RANK 有什么区别？怎么取每个类目销量前 3 的商品？专业知识笔试技术一面校招 · 实习 · 跳槽转行基础

   考察点： 窗口函数的基本用法，以及对并列情况的处理是否敏感。

   答题思路：

   • 三者都是按 PARTITION BY 分组、按 ORDER BY 排序后给每行编号，区别在于遇到并列：ROW_NUMBER 不管并列，编号 1、2、3、4 连续不重复；RANK 并列同号、后面跳号，如 1、1、3；DENSE_RANK 并列同号、后面不跳号，如 1、1、2。
   • 取每个类目前 3：先在子查询里算 DENSE_RANK() OVER (PARTITION BY category ORDER BY sales DESC) AS rk，外层再筛 WHERE rk <= 3。窗口函数的结果不能直接写在同一层的 WHERE 里，因为 WHERE 先于窗口函数执行。
   • 说明怎么选：业务要求「恰好 3 个」用 ROW_NUMBER（并列时要再加一个排序字段让结果稳定）；要求「并列的都算上」用 DENSE_RANK 或 RANK。主动问一句「并列怎么处理」会很加分。

   可能的追问： 窗口函数和 GROUP BY 有什么本质区别？LAG / LEAD 能用来做什么？怎么用窗口函数算累计销售额？

   练一练
3. 03怎么查出连续登录 N 天及以上的用户？专业知识笔试技术一面校招 · 社招 · 实习 · 跳槽转行进阶

   考察点： 经典的「日期减序号」思路，以及去重、边界意识。

   答题思路：

   • 第一步去重：同一个用户一天可能登录多次，先 SELECT DISTINCT user_id, login_date 得到「用户 × 日期」的唯一记录。
   • 第二步编号：对每个用户按日期排序编号，ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn。
   • 第三步做差：用 DATE_SUB(login_date, INTERVAL rn DAY) AS grp_date 算出一个「分组日期」。连续登录的那几天，日期每加 1、序号也加 1，相减后得到同一个值；一旦中断，差值就变了。
   • 第四步聚合：按 user_id, grp_date 分组，HAVING COUNT(*) >= N 就是连续登录 N 天及以上的用户，MIN 和 MAX 可以拿到这段连续期的起止日期。
   • 讲清为什么要先去重：不去重的话同一天会被编两个号，差值算错。

   校招怎么答 / 社招怎么答： 校招边写边讲思路，写完拿一个具体例子（比如某用户 1、2、3、5 号登录）手算一遍验证；社招可以补充数据量大时的做法，例如先按日期分区过滤出最近一段时间再计算，避免全表扫描。

   可能的追问： 如果允许中间断一天也算连续，怎么改？不用窗口函数能做吗？

   练一练
4. 04WHERE 和 HAVING 有什么区别？LEFT JOIN 和 INNER JOIN 呢？专业知识笔试技术一面校招 · 实习 · 跳槽转行基础

   考察点： SQL 执行顺序和关联语义，这是很多 SQL 写错的根源。

   答题思路：

   • 先说逻辑执行顺序：FROM / JOIN → WHERE → GROUP BY → HAVING → SELECT（含窗口函数）→ ORDER BY → LIMIT。
   • WHERE 在分组之前过滤「行」，不能用聚合函数；HAVING 在分组之后过滤「组」，可以写 HAVING COUNT(*) > 10。能放在 WHERE 里的条件尽量放 WHERE，先减少数据量。
   • INNER JOIN 只保留两边都能匹配上的行；LEFT JOIN 保留左表全部行，右表匹配不上的字段为 NULL。
   • 讲一个常见坑：LEFT JOIN 之后在 WHERE 里写右表条件（如 WHERE b.status = 1），会把右表为 NULL 的行过滤掉，效果等于变成了 INNER JOIN。想保留左表全部行，右表条件要写在 ON 里。
   • 再提一句：关联键在右表不唯一时，LEFT JOIN 会让左表行数变多，算人数要用 COUNT(DISTINCT ...)。

   可能的追问： COUNT(*)、COUNT(1)、COUNT(字段) 有什么区别？NULL 参与比较和聚合时有什么特别的地方？

   练一练
5. 05一个大表查询特别慢，你会怎么排查和优化？情景应变技术一面社招 · 跳槽转行进阶

   考察点： 是否在真实的大数据环境里写过 SQL，有没有性能意识。

   答题思路：

   • 先定位慢在哪：看执行计划，看是扫描数据太多、关联太重，还是某个任务一直跑不完（常见于数据倾斜）。
   • 减少扫描量：分区表一定要带分区条件（如日期分区），只取需要的列，不写 SELECT *；能在子查询里先过滤、先聚合的，就别等关联完再过滤。
   • 优化关联：大表关联前先把小表的数据范围缩到最小；避免关联条件两边类型不一致导致无法走优化；去掉不必要的 DISTINCT 和多次重复关联。
   • 处理数据倾斜：某些关联键（如空值、默认值、某个超大用户）数据特别集中时，会让个别任务特别慢。常见处理是把空值单独处理、给热点键加随机前缀打散后再聚合。
   • 长期办法：常用的复杂口径沉淀成中间表，每天预先算好，分析时直接用，而不是每次从明细表现算。

   校招怎么答 / 社招怎么答： 校招能说出分区过滤、先过滤后关联、少用 SELECT * 就够；社招最好讲一次真实的优化经历，说清优化前后的耗时变化（用你自己的数据）。

   可能的追问： 什么是数据倾斜，怎么判断发生了倾斜？UNION 和 UNION ALL 哪个更快，为什么？

   练一练
6. 06假设检验的基本思路是什么？p 值到底是什么意思？专业知识笔试技术一面校招 · 社招 · 实习 · 跳槽转行基础

   考察点： 统计基本概念是否准确，尤其是 p 值的常见误读。

   答题思路：

   • 基本思路是「反证」：先假设没有差异（原假设，比如新旧方案转化率一样），在这个前提下看我们观察到的数据有多「不寻常」，如果非常不寻常，就拒绝原假设。
   • p 值的准确说法：假设原假设成立时，得到当前结果或更极端结果的概率。p 值小于事先定好的显著性水平（常用 0.05），就说结果统计显著。
   • 一定要讲清常见误读：p 值不是「原假设成立的概率」，也不是「新方案更好的概率」；p 值小只说明差异不太可能完全由随机波动造成，不说明差异有多大、有没有业务价值。
   • 补一句置信区间：95% 置信区间可以通俗理解为，用同样方法反复抽样，大约 95% 的区间会覆盖真实值。它比单看 p 值更有用，因为能看出效果大概有多大。

   校招怎么答 / 社招怎么答： 校招把定义说准、主动点出误读就很好；社招可以结合实验场景讲「统计显著但效果很小，业务上不值得上线」的例子。

   可能的追问： 显著性水平为什么常用 0.05，可以改吗？单侧检验和双侧检验怎么选？t 检验和卡方检验分别用在什么场景？

   练一练
7. 07第一类错误和第二类错误分别是什么？和样本量有什么关系？专业知识笔试技术一面校招 · 实习 · 跳槽转行基础

   考察点： 对检验结论可能出错的方式是否理解，并能对应到业务风险。

   答题思路：

   • 第一类错误（弃真）：原假设其实成立（新方案没用），却判断为有效。概率就是显著性水平 α。业务上的后果是「上线了一个没用甚至有害的改动」。
   • 第二类错误（取伪）：原假设其实不成立（新方案有用），却没检测出来。概率记作 β，1 - β 叫统计功效。业务上的后果是「错过了一个好改动」。
   • 和样本量的关系：α 固定时，样本量越大，β 越小、功效越高；想同时降低两类错误，只能加样本量。
   • 说说怎么权衡：改动风险大（如涉及支付、价格）时更怕第一类错误，可以把 α 定得更严；探索性的小改动更怕错过机会，可以更关注功效。

   可能的追问： 实验结果不显著，能说明「新方案没效果」吗？为什么同时看很多指标时更容易出现第一类错误？

   练一练
8. 08「相关不等于因果」，你能举个例子吗？怎么验证因果？专业知识技术一面业务面校招 · 社招 · 实习 · 跳槽转行进阶

   考察点： 分析结论是否严谨，会不会把相关性当成因果去给建议。

   答题思路：

   • 举一个业务例子：数据显示「使用过收藏功能的用户留存更高」，但不能直接得出「引导所有人收藏就能提升留存」。很可能是本来就更活跃、更喜欢这个产品的用户才会去收藏——这是反向因果或自选择。
   • 再讲混杂因素：比如「看过直播的用户客单价更高」，可能是因为高消费用户本来就集中在某些城市或某个渠道，直播只是恰好在这些人群里推得多。
   • 验证因果的方法，按可靠程度排：首选随机实验（AB 实验）；做不了实验时，可以找自然实验或前后对比加对照组（双重差分思路）；再不行就分群对比、控制住主要的混杂变量，同时在结论里写清楚「这是相关性，建议用实验验证」。
   • 落到建议：好的分析报告会把「已验证的因果」和「观察到的相关」分开写。

   校招怎么答 / 社招怎么答： 校招讲清两三种「相关但非因果」的原因并举例；社招要讲你真实遇到过、差点误判的一次，以及最后怎么验证的。

   可能的追问： 如果业务方坚持要根据这个相关性做决定，你怎么办？什么是辛普森悖论？

   练一练
9. 09一个 AB 实验应该怎么设计？样本量怎么估？专业知识技术一面业务面校招 · 社招 · 实习 · 跳槽转行进阶

   考察点： 实验设计的完整度：假设、分流、指标、样本量、周期、决策规则。

   答题思路：

   1. 明确假设：改了什么、预期哪个指标往哪个方向变、变多少才有意义。
   2. 选分流单位：一般按用户分流，确保同一个人始终看到同一个版本；要注意用户之间互相影响的场景（社交、双边市场），可能需要按城市或时间片分流。
   3. 定指标：一个核心指标（决定实验成败）、若干护栏指标（防止某处变好、别处变坏，如留存、投诉、性能）。
   4. 估样本量：取决于核心指标的基线水平和波动、想检测的最小提升（最小可检测效应）、显著性水平和统计功效。常用的粗略估算是：显著性水平 0.05、功效 80% 时，每组样本量约为 16 × 方差 ÷ 最小可检测差值的平方，转化率类指标的方差可以用 p × (1 - p) 近似。
   5. 定周期：至少覆盖一个完整周（避免工作日和周末差异），并且达到样本量；事先定好周期，不要看到显著就提前停。
   6. 上线前检查：两组用户的样本比例是否符合预期、实验前的指标是否一致（空跑检验），确认分流没问题。

   校招怎么答 / 社招怎么答： 校招把这 6 步讲完整、能说清样本量和哪些因素有关就很好；社招要讲你实际设计过的实验，包括怎么选指标、遇到过什么坑。

   示范回答（校招版）：

   我拿「把商品详情页的购买按钮从页面底部改成悬浮在屏幕下方」这个改动来说。我的假设是，悬浮按钮让用户随时能点到，详情页到下单的转化率会提升。分流上我按用户 ID 随机分成两组，各占【50%】的流量，确保同一个人每次看到的都是同一个版本。核心指标是详情页到下单的转化率，护栏指标我会看退款率和页面停留时长，防止用户因为误点下单后又退款。 样本量方面，假设目前转化率是【p】，我希望能检测出【X 个百分点】的提升，在显著性水平 0.05、功效 80% 的条件下，每组大约需要 16 × p × (1 - p) ÷ X² 个用户，再结合每天详情页的访问人数，算出大概要跑【N 天】，并且至少跑满一周。上线前我会先检查两组用户数比例是不是接近 1:1，如果偏差明显，说明分流可能有问题，要先排查再看结果。实验结束后，我会同时看结论是否统计显著、提升幅度是否值得上线，以及护栏指标有没有变差，三者都满足才建议全量。

   示范回答（社招版）：

   我讲一个我在【某电商业务】实际设计过的实验：运营想把新人券从【满减】改成【无门槛小额券】，希望提升新用户首单转化。我先和运营对齐了假设和成功标准：核心指标是新用户 7 天内首单转化率，护栏指标是首单客单价、单用户补贴成本和 30 天复购，因为无门槛券很可能吸引来「只薅一次」的用户，只看首单会高估效果。 分流单位上，因为券是在注册时发放的，我按新用户 ID 分流，并和工程同学确认了老用户不会被误分进来。样本量我是用历史【N 周】新用户首单转化率的均值和波动来算的，按我们关心的最小提升【X 个百分点】估算，每组需要约【M】人，按当时的新增量要跑【D 天】，最后定了两周。上线第一天我先做了样本比例检查，发现实验组用户偏少，排查下来是某个渠道的注册页没有接入实验配置，修复后重新开始计时。 实验结束时，首单转化率实验组高了【X】且显著，但 30 天复购没有明显差异、单用户补贴成本上升了【Y】。我把这三个数放在一起算了单个新用户的投入产出，结论是只在【低转化的几个渠道】推无门槛券更划算，而不是全量替换。这个实验让我养成了一个习惯：实验开始前就把「怎么判定成功」和「什么情况不上线」写下来，避免结果出来以后再找理由。

   可能的追问： 核心指标显著提升但护栏指标显著下降，上不上线？实验跑到一半结果已经显著了，能不能提前停？如果同时有好几个实验在跑，会不会互相干扰？

   练一练
10. 10AB 实验结果显著，但你觉得结论不可靠，可能是什么原因？专业知识业务面社招 · 跳槽转行深挖

    考察点： 对实验的「坑」是否有实战经验，能不能对结果保持怀疑。

    答题思路：

    • 分流有问题：两组样本比例和设计不符，说明分流或数据上报有偏差，结论不可信，要先修。
    • 新奇效应：新样式刚上线时大家好奇点一点，指标短期上升，过一段时间回落。可以只看实验中后期的数据，或看老用户和新用户分别的表现。
    • 偷看数据、提前停止：每天看一次、一显著就停，会大大增加误判概率。应事先定好样本量和周期。
    • 多重比较：同时看几十个指标、几十个分群，总能「碰巧」找到几个显著的。核心指标要事先定好，事后找到的显著分群只能当新假设，要再验证。
    • 样本污染：同一个人在不同设备上被分到不同组，或者实验组和对照组的用户互相影响（如社交分享、共享库存、共享补贴预算）。
    • 辛普森悖论 / 结构变化：整体看实验组更好，按渠道拆开后每个渠道都是对照组更好，往往是两组的用户构成不一样。
    • 外部事件：实验期间恰好有大促、节假日或者其他版本发布，影响了某一组。

    校招怎么答 / 社招怎么答： 校招能说出三四种原因并解释清楚就不错；社招要挑一个你真实遇到过的，讲清楚怎么发现的、怎么处理的、最后结论怎么改的。

    可能的追问： 怎么判断是不是新奇效应？如果按城市分流，会遇到什么新问题？

    练一练
11. 11让你给一个内容类 App 搭建指标体系，你会怎么搭？案例分析业务面社招 · 跳槽转行深挖

    考察点： 能否把业务目标翻译成分层、可追踪、口径清晰的指标，而不是罗列一堆指标名。

    答题思路：

    • 先问清楚目标：现在业务处在什么阶段，是拉新、提升留存还是商业化？谁用这套指标（管理层看大盘、运营看细分、产品看功能）？
    • 定北极星指标：要反映用户获得的价值，例如「每日有效阅读用户数」或「用户人均有效消费时长」，并说明为什么不选单纯的下载量或日活。
    • 分层拆解：北极星 → 一级指标（如新增、留存、人均消费）→ 二级过程指标（如推荐点击率、完读率、互动率、发布量）。可以按用户生命周期拆（获客、激活、留存、变现、推荐），也可以按「消费侧 / 供给侧」拆，内容产品两边都要看。
    • 写清口径：每个指标的定义、计算公式、统计周期、数据来源、负责人。「有效阅读」是停留多少秒以上算？要白纸黑字写下来。
    • 配套机制：指标看板、异动预警规则、定期回顾，以及防「刷指标」的护栏（比如内容变短变水换来的时长增长要能识别）。

    校招怎么答 / 社招怎么答： 校招能讲出北极星 + 分层拆解的结构、口径意识就很好；社招要讲你搭过的一套真实体系，口径分歧是怎么统一的、上线后用它发现过什么问题。

    可能的追问： 北极星指标定好以后可以改吗？指标太多看不过来怎么办？某个过程指标提升了、北极星却没动，说明什么？

    练一练
12. 12「用户流失」怎么定义？流失分析怎么做？专业知识业务面社招 · 跳槽转行进阶

    考察点： 定义口径的严谨度，以及从分析走向召回动作的能力。

    答题思路：

    • 先定口径：不同产品的使用频率不同，流失的定义也不同。常见做法是看「连续多少天未活跃」，阈值不要拍脑袋，可以画出「沉默 N 天后再回来的比例」曲线，选回流率明显变低的拐点作为阈值。
    • 分群看：按新老用户、来源渠道、付费与否、核心行为（如是否完成过关键动作）拆分，找出流失率最高、或流失后损失最大的群体。
    • 看流失前的行为：流失用户在最后一段时间做了什么、在哪一步卡住，对比留存用户的行为路径，找差异最大的几个点。
    • 给动作：针对不同人群设计不同的召回策略（推送、优惠、内容推荐），并用实验验证召回效果，不能只看召回人数，还要看召回后的留存。
    • 别忘了「预防」：比找回流失用户更有效的，往往是在用户出现流失苗头时提前干预，可以做一个简单的流失预警规则。

    可能的追问： 如果给你做一个流失预测模型，你会用哪些特征？召回活动的效果怎么评估才不会高估？

    练一练
13. 13某天 DAU 突然下降了【X%】，你会怎么分析？案例分析业务面校招 · 社招 · 实习 · 跳槽转行进阶

    考察点： 指标异动分析的完整结构，以及能不能区分「数据问题」和「真实问题」、最终给出可执行的建议。

    答题思路：

    1. 确认数据：先排除数据本身的问题——埋点有没有改、上报有没有延迟、口径有没有变、数据任务有没有失败。
    2. 判断幅度和形态：和昨天比、和上周同一天比、和去年同期比；看是突然掉还是逐渐下滑，是否超出正常波动范围；是否有节假日、季节性因素。
    3. 拆维度定位：按平台（安卓 / iOS / 网页）、版本、渠道、新老用户、地区等拆开，找到下降集中在哪一块。也可以按公式拆：DAU = 新增活跃 + 老用户留存活跃 + 回流用户。
    4. 提假设找原因：内部因素（发版、功能改动、活动结束、推送策略变化、服务故障）和外部因素（竞品动作、政策、热点事件、天气或假期）。
    5. 验证假设：用数据验证每个假设，比如查发版时间和下降时间是否吻合、受影响的是否只是新版本用户。
    6. 结论和建议：讲清原因、影响有多大、建议怎么做、后续怎么监控。

    校招怎么答 / 社招怎么答： 校招重点是结构完整、每一步说清楚为什么这么做；社招除了结构，还要体现经验——哪些原因最常见、先查哪个最省时间，以及怎么把这次的排查沉淀成监控规则。

    示范回答（校招版）：

    我会按「先确认数据、再定位、再找原因、最后给建议」的顺序来分析。第一步，我会先找数据同学确认最近有没有改埋点、昨天的数据任务是否正常跑完，排除是统计出了问题。第二步，看这个下降是不是异常：和上周同一天比、和过去几周的波动范围比，如果昨天恰好是节假日，下降可能是正常的。 如果确认是真实下降，第三步我会拆维度。先按平台拆，看是安卓和 iOS 一起降，还是只有一个平台降；再按版本、渠道、新老用户拆。假设我发现下降主要集中在安卓端的【最新版本】上，其他版本基本没变，那就高度怀疑和新版本有关。第四步，我会去查这个版本改了什么，比如启动页、推送或者登录流程，再看这个版本用户的启动成功率、崩溃率有没有异常。 最后我会给出结论和建议，比如「下降的【X%】中大约【Y】来自安卓新版本，原因很可能是【某个改动】，建议研发优先排查并考虑回滚，同时我会连续几天跟踪这个版本的指标」。如果拆完所有维度都是均匀下降，我会转向外部因素，比如当天有没有大的热点事件或者竞品活动。

    示范回答（社招版）：

    遇到 DAU 异动，我一般在半小时内先给一个初判，再用半天到一天给完整结论，因为业务方最关心的是「是不是事故、要不要马上处理」。初判阶段我先查三件事：数据任务和埋点是否正常、有没有同时发生的线上故障告警、最近 48 小时有没有发版或策略变更。这三件事能覆盖我遇到过的大部分突发下降。 排除数据问题后，我会用公式拆：DAU = 新增活跃 + 留存活跃 + 回流活跃。在我之前负责的【某内容业务】里，有一次 DAU 降了【X%】，拆下来新增和留存都正常，主要是回流用户掉了【Y%】。回流用户高度依赖推送，我再去查推送，发现前一天推送策略做了调整，【某类推送】的发送量下降了一大半。和推送负责人确认后，是新上的频控规则误伤了沉默用户人群。 结论给出后，我们当天恢复了这部分人群的推送，第二天回流基本回到正常水平。之后我推动做了两件事：一是把「DAU 三部分拆解」做成每天自动跑的看板，任何一部分超过正常波动就预警；二是和推送团队约定，策略变更必须走小流量实验，同时观察回流指标。这件事以后，类似的异动我们基本能在当天早上就定位到原因。

    可能的追问： 如果所有维度拆下来都是均匀下降，你怎么继续？你怎么判断一次下降是正常波动还是真实异常？业务方追着你要结论，但你还没查完，怎么办？

    练一练
14. 14GMV 怎么拆解？GMV 下降了从哪里入手？案例分析业务面校招 · 实习 · 跳槽转行基础

    考察点： 指标拆解的基本功，以及拆解是否「互不重叠、合起来完整」。

    答题思路：

    • 先说定义：GMV 是一段时间内的成交总额，要先确认口径——是否含退款、是否含运费和优惠、按下单还是按支付算。
    • 常见拆法：GMV = 访问用户数 × 转化率 × 客单价；客单价 = 件单价 × 人均购买件数。每一项还能继续拆，访问用户数可以拆成新老用户、各渠道流量；转化率可以拆成「浏览 → 加购 → 下单 → 支付」的漏斗。
    • 另一种拆法：按品类、按地区、按商家拆，找到贡献下降最多的那一块。
    • 下降时的入手顺序：先看是哪一个因子变了（流量、转化还是客单价），再沿着那一项继续往下拆，直到找到一个可以对应到具体动作的原因。
    • 提醒一个容易忽略的点：拆完要能把各部分的变化「加回去」解释总变化，否则说明拆漏了。

    可能的追问： 流量涨了但 GMV 没涨，可能是什么原因？客单价上升一定是好事吗？

    练一练
15. 15一个新功能上线了，你怎么评估它到底好不好？案例分析业务面校招 · 社招 · 实习 · 跳槽转行进阶

    考察点： 从「功能目标」出发设计评估方案，区分可信和不可信的对比方法。

    答题思路：

    • 先问目标：这个功能是为了解决什么问题、希望影响哪个指标？没有目标就没法评估。
    • 定指标：功能本身的使用情况（渗透率、使用频次、使用后的完成率）；它想影响的业务指标（如留存、转化）；护栏指标（有没有挤占其他功能、有没有增加投诉或性能问题）。
    • 选方法：最好是 AB 实验，能直接回答「有这个功能 vs 没有」；做不了实验时，用前后对比要小心，因为同期可能有其他变化，可以找一个没上线的地区或用户群做对照，看两边的变化差异。
    • 避免一个常见错误：直接对比「用了功能的人」和「没用的人」，前者往往本来就更活跃，这种对比会高估功能效果。
    • 给结论：功能有没有达成目标、对哪类用户效果最好、是否值得继续投入或调整。

    校招怎么答 / 社招怎么答： 校招把指标分层和「用实验而不是直接对比用户」讲清楚即可；社招要讲你评估过的一个功能，结论有没有影响后续决策，比如功能被下线或改版。

    可能的追问： 功能的使用率很高，但核心指标没变化，说明什么？如果老板已经决定全量上线了，你还能怎么评估？

    练一练
16. 16用 Python 处理数据时，缺失值和异常值你一般怎么处理？专业知识技术一面校招 · 实习 · 跳槽转行基础

    考察点： 数据清洗的基本方法，更重要的是「先看业务含义再动手」的意识。

    答题思路：

    • 先摸底：用 df.info()、df.describe()、df.isna().sum() 看每列的缺失比例和分布，而不是一上来就删或者填。
    • 缺失值先问「为什么缺」：是没采集到、用户没填，还是业务上本来就没有（比如没下单的人没有订单金额）？业务上本来就没有的，往往应该填 0 或单独标记，而不是用平均值填。
    • 常见处理：缺失比例很高、又不重要的列可以删掉；少量缺失可以删行（dropna）或填充（fillna，用中位数、众数、前后值或分组均值）；也可以新增一列「是否缺失」作为特征保留信息。
    • 异常值先判断真假：用箱线图（四分位距规则）、标准差或业务规则（年龄 200 岁、订单金额为负）找出来，再判断是录入错误还是真实的极端值。录入错误修正或剔除；真实极端值（如大客户）不要随便删，可以单独分析，或者在算均值时用中位数、截尾处理来降低影响。
    • 记录下来：清洗规则要写清楚，结论里说明剔除了多少数据、为什么。

    校招怎么答 / 社招怎么答： 校招能说出几种方法和 pandas 对应函数，并强调先看业务含义；社招要讲一次「清洗方式影响了结论」的真实经历。

    可能的追问： pandas 里 merge 和 concat 有什么区别？groupby 之后想对不同列做不同的聚合怎么写？数据量太大内存放不下怎么办？

    练一练
17. 17Excel 里你常用哪些函数？数据透视表能做什么？专业知识技术一面校招 · 实习 · 跳槽转行基础

    考察点： 日常办公分析工具是否熟练，很多岗位的日常沟通和快速分析依然离不开表格。

    答题思路：

    • 分类说更有条理：查找引用类（VLOOKUP、XLOOKUP、INDEX + MATCH）；条件统计类（SUMIFS、COUNTIFS、AVERAGEIFS）；逻辑类（IF、IFERROR）；文本和日期类（LEFT、TEXT、DATEDIF 等）。
    • 讲一个常见坑：VLOOKUP 默认近似匹配，精确匹配要把最后一个参数设为 FALSE 或 0；查找值有多余空格、数字存成文本时也会匹配不上。
    • 数据透视表：拖拽就能做分组汇总、交叉表、占比和环比，适合快速探索数据和给业务方出简单报表；配合切片器可以做简单的交互筛选。
    • 说清边界：数据量很大、需要反复跑或需要复杂关联时，用 SQL 或 Python 更合适；Excel 适合最后一公里的整理和展示。

    可能的追问： VLOOKUP 和 INDEX + MATCH 相比有什么局限？你怎么确保一份每周更新的 Excel 报表不出错？

    练一练
18. 18做报表或看板时，你怎么选图表？专业知识技术一面业务面校招 · 实习 · 跳槽转行基础

    考察点： 是否理解「图表是为了回答问题」，而不是越花哨越好。

    答题思路：

    • 先想清楚要表达的关系，再选图：比较大小用柱状图或条形图（类别多、名字长时用横向条形图）；趋势用折线图；构成占比用堆叠柱状图，类别很少（三四个以内）时才考虑饼图；分布用直方图或箱线图；两个变量的关系用散点图；流程转化用漏斗图。
    • 看板设计：最重要的指标放左上角、用大数字；同一屏的指标要回答同一个问题；配上同比环比和目标线，否则单个数字没有参照。
    • 讲几个常见错误：纵轴不从 0 开始让差异看起来很夸张；一张图塞太多系列；颜色太多没有重点；用 3D 效果。
    • 给每张图加一句「结论标题」，比如不写「各渠道转化率」，而写「【某渠道】转化率连续三周下降」。

    可能的追问： 管理层看的看板和运营每天用的看板，设计上有什么不同？你做过的看板，上线后有人用吗，怎么知道？

    练一练
19. 19你做完一个分析，要给业务负责人汇报，会怎么组织内容？专业知识业务面终面校招 · 社招 · 实习 · 跳槽转行进阶

    考察点： 能不能把分析变成别人愿意听、听得懂、能拍板的内容。

    答题思路：

    • 结论先行：第一页就写结论和建议，再展开依据。业务负责人时间有限，先告诉他「要做什么决定」。
    • 金字塔结构：一个核心结论，下面两三个支撑论点，每个论点配一两张关键图表，细节放附录。
    • 建议要可执行：写清楚谁来做、做什么、预期影响多大、怎么衡量，而不是「建议加强运营」这种空话。
    • 讲清确定性：哪些结论有数据验证，哪些是推测、还需要实验验证；数据口径和局限写在显眼的地方。
    • 准备好被追问：提前想好业务方最可能质疑的点，准备备用数据。

    校招怎么答 / 社招怎么答： 校招可以讲课程项目或实习中一次汇报，重点是你怎么组织结构；社招要讲一次汇报后真的推动了决策的经历，以及你怎么根据听众调整内容。

    可能的追问： 如果汇报时老板一直打断你问细节怎么办？分析结论和老板的预期相反，你怎么讲？

    练一练
20. 20请做个自我介绍，并说说为什么想做数据分析。自我介绍技术一面HR面校招 · 社招 · 实习 · 跳槽转行基础

    考察点： 表达是否简洁有重点，经历和岗位是否相关，动机是否真实。

    答题思路：

    • 控制在 1–2 分钟：我是谁 → 和数据分析最相关的一两段经历（用了什么方法、得出了什么结论、带来了什么变化）→ 为什么想做这个岗位。
    • 「为什么做数据分析」要用具体经历支撑，比如「我在【某次课程项目 / 实习】里用数据发现了一个大家都没注意到的问题，结论被采纳后，我很享受这种从数据里找到答案的感觉」，比「我对数据很敏感」有说服力得多。
    • 技能部分别只报工具名，要说用它做成了什么。

    校招怎么答 / 社招怎么答： 校招突出 SQL、统计基础和一个完整的分析项目；社招直接讲你负责的业务、最有代表性的一两个分析成果；转行的同学讲清楚原来的行业经验怎么帮你理解业务，以及你为转行做了哪些准备（作品、课程、实际分析过的数据）。

    可能的追问： 你觉得数据分析师和数据工程师、算法工程师的区别是什么？如果入职后大部分时间都在取数和做报表，你能接受吗？

    练一练
21. 21讲一个你的分析推动了业务改变的例子。行为题（STAR）业务面终面校招 · 社招 · 实习 · 跳槽转行深挖

    考察点： 你的分析是否真的产生了价值，以及你在其中的具体贡献和推动能力。

    答题思路：

    • 用 STAR 结构，重点放在行动和结果：背景（业务遇到了什么问题）→ 任务（你要回答什么问题）→ 行动（怎么分析、发现了什么、怎么说服别人）→ 结果（业务做了什么改变、带来了什么效果）。
    • 讲清「从发现到落地」的完整链条：分析本身只是一半，另一半是怎么让业务方相信并采取行动。
    • 结果尽量量化，但数字要真实、能说清口径；如果效果还没完全显现，就如实说现在看到的变化。
    • 最后讲一句你的体会或复盘。

    示范回答（校招版）：

    我在【某公司运营实习】时，团队在做一个用户拉新活动，运营同学觉得效果不错，因为新增用户数比上一期多了不少。我当时的任务是做活动复盘。我先按渠道拆新增用户，发现增量几乎都来自【一个新合作渠道】；再看这些用户的后续行为，他们的次日留存只有其他渠道的【一半左右】，而且很多人领完新人奖励就再没打开过。 我把这个发现整理成一页图表：左边是各渠道的新增人数，右边是各渠道的 7 日留存和人均获客成本，结论写在最上面——「新渠道带来的用户数多，但留下来的用户少，算下来每个留存用户的成本是其他渠道的【X 倍】」。我先私下和负责这个渠道的运营同学沟通了一遍，确认数据口径没问题，也听了她的看法，然后在复盘会上一起讲。最后团队决定下一期活动减少这个渠道的投入，把预算挪到留存更好的【两个渠道】。下一期活动的新增人数略有下降，但 7 日留存用户数反而多了【Y】。这件事让我体会到，分析不能只看一个指标，而且在公开场合讲结论之前，先和相关同学对齐，事情会顺利很多。

    示范回答（社招版）：

    我在【某电商业务】负责用户增长分析的时候，业务一直觉得复购率低是因为「商品不够丰富」，计划投入【N 人月】去扩充品类。我想先确认这个判断，于是拿了近【半年】的首单用户，按「首单后 30 天是否复购」分成两组，对比他们首单的品类、配送时长、是否有售后、是否用券等特征。结果发现，影响最大的不是品类，而是首单配送体验：配送超过【X 天】的用户，复购率明显低于其他用户，而且这个差异在各个品类里都存在。 因为这是相关性分析，我没有直接下结论，而是和物流、产品一起设计了一个验证：在【两个城市】对首单用户优先分配更快的配送方式，其他城市作为对照。跑了【四周】后，试点城市首单用户的 30 天复购率比对照城市高了【Y 个百分点】，且这个差异在试点前并不存在。 拿到这个结果后，我把「首单配送时长」加进了增长看板，并推动业务把一部分扩品类的预算调到首单履约体验上。之后【一个季度】，整体复购率从【A】提升到【B】。这个项目里我最大的收获是：在业务已经有既定判断的时候，先用数据检验判断本身，再用实验验证因果，比单纯给出一个「相反的结论」更容易被接受。

    可能的追问： 你在里面具体负责哪部分？如果业务方当时不同意你的结论，你会怎么做？这个结果有没有可能是其他因素造成的？

    练一练
22. 22业务方不认可你的分析结论，你怎么办？情景应变业务面HR面校招 · 社招 · 实习 · 跳槽转行进阶

    考察点： 沟通方式，以及面对质疑时是坚持专业还是一味迎合。

    答题思路：

    • 先听清楚对方不认可的是什么：是数据口径、分析方法，还是结论和他的经验冲突？不同原因处理方法不同。
    • 先检查自己：回到数据口径和计算过程，确认没有算错、没有遗漏重要维度。分析师先承认可能的漏洞，反而更容易获得信任。
    • 补证据：对方提出的反对理由，用数据去验证；必要时换一个角度或换一份数据交叉验证。
    • 找共同目标：大家都希望业务变好，分歧往往在「哪条路更有效」。可以建议用一个小范围实验来验证，让结果说话。
    • 守住底线：如果数据确实支持你的结论，不要为了让对方满意而改结论，但可以调整表达方式，把「你错了」变成「数据显示还有另一种可能」。

    校招怎么答 / 社招怎么答： 校招讲清处理思路和态度即可，最好配一个小组项目或实习中的小例子；社招要讲一次真实的分歧，最后是怎么解决的，以及如果你错了你是怎么处理的。

    可能的追问： 如果最后证明是你错了呢？如果业务方是你的上级，坚持要你按他的结论改报告，你怎么办？

    练一练
23. 23两个部门报上来的同一个指标对不上，你怎么处理？情景应变业务面社招 · 跳槽转行进阶

    考察点： 数据口径治理意识，以及跨部门协调能力。

    答题思路：

    • 先查原因：把两边的计算逻辑、数据来源、统计时间、过滤条件逐项对比。常见原因有：统计时间点不同（下单时间 vs 支付时间）、是否剔除测试和异常数据、是否去重、取数的表不同（一个用实时表、一个用离线表）。
    • 拿出对账结果：用一张表列出两边每一步的差异和对应的数量差，让大家看到差异是怎么来的，而不是争论谁对谁错。
    • 推动统一：和指标的业务负责人一起确定标准口径，写进指标口径文档；统一从一个数据出口出数，其他报表都引用它。
    • 保留合理差异：有时两个口径各有用途（比如运营看下单、财务看支付），那就给两个指标起不同的名字，避免同名不同义。

    可能的追问： 口径统一后，历史报表的数要不要回刷？如果某个部门不愿意改口径怎么办？

    练一练
24. 24面试最后，你有什么想问我们的吗？反问技术一面业务面HR面终面校招 · 社招 · 实习 · 跳槽转行基础

    考察点： 你对岗位的关心程度和思考深度，也是你了解团队的机会。

    答题思路：

    • 问工作内容：这个岗位日常取数和报表、专题分析、实验分析的时间大概怎么分配？分析师主要对接哪些业务方？
    • 问数据基础：团队的数据基础设施和指标体系建设到什么程度了？数据质量问题多吗？
    • 问成长和期望：这个岗位前三个月最希望看到什么产出？团队里分析师的结论一般通过什么方式影响业务决策？
    • 不建议问能在公开信息里查到的内容；加班、福利等问题放到 HR 面问更合适。

    可能的追问： 面试官可能反过来问「你为什么关心这个」，提前想好一句你的理由。

    练一练

点「练一练」会复制这道题，并跳到页面底部的下载入口；打开 OfferGod 模拟面试后粘贴即可。

你在数据分析面试里遇到过本文没覆盖的 SQL 题、Case 题，或者被某个追问难住过吗？欢迎通过页面底部「发现内容有误或侵权？告诉我们」入口发给我们，说说当时的题目和你的回答思路，编辑部采纳后会整理补进题库。