中国联通校招数据分析面试经验——求职精灵（finsight.work）

两分钟以内，按「背景—一个项目—方向选择」三段。

• 背景：学校、专业、毕业时间一句话，直接点出与数据相关的训练，比如统计学、计量经济学或数据库课程。
• 项目：只讲一个最能证明能力的，把问题、数据规模、方法、结论说清。比如用三十万条订单数据做用户分层，用 RFM 模型分出四类客群，产出差异化运营建议。
• 方向选择：从兴趣、能力、行业三条线说。兴趣是享受从数据里找规律的过程；能力是 SQL、Python 与统计基础已被项目验证；行业是数据驱动决策在通信、金融、零售都在普及，方法论可迁移。

收尾一句：选数据分析不是因为热，而是这类问题愿意反复琢磨。追问预警：可能接着问「为什么不去算法岗」。

先讲思路，再写关键片段，最后说边界条件。
思路分三步：

• 按月聚合：按用户与月份分组，算出每月消费额，活跃定义为当月有计费行为。
• 标记连续：用 ROW_NUMBER 给每个用户按月排序，再用「月份序号减去排名」构造分组键。连续月份的差值相同，同组内计数大于等于三即为连续三个月。
• 过滤：用 HAVING 筛出月均消费大于 100 且连续计数达标的用户。

关键片段可以说成：先 GROUP BY user_id, month 求 SUM(amount)，再 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY month)，最后按差值分组 COUNT 并 HAVING。
边界要主动提：跨年月份要转成连续整数，缺失月份先补齐，否则连续会被误判。收尾一句：这类题考的是把「连续」翻译成窗口函数的能力。

按「定义—取数—分层—建模—落地」五步走。

• 定义：先统一口径，连续多少天无计费、无流量视为流失，观察窗口取多长。口径不清，后面的数都白算。
• 取数：用户属性（入网时长、套餐档位、终端型号）、消费行为（ARPU 变化、流量使用率、是否超套）、体验数据（投诉、网络质量、客服触点）、外部因素（合约到期、竞品促销）。
• 分层：按套餐、地域、入网时长、ARPU 分箱看流失率差异，找出高流失群。合约到期前后是最典型的窗口。
• 建模：用逻辑回归做可解释基线，再用随机森林或 XGBoost 提升效果，看特征重要性而不是只看准确率。
• 落地：输出可执行动作，比如到期前三十天做续约触达，对流量超套用户推升档包。

收尾一句：流失分析的价值在于提前多少天能识别，而不是事后解释。

从定义、设计、陷阱三段讲。
A/B 测试是把用户随机分成实验组与对照组，只改变一个变量，用统计方法判断差异是否由策略带来，而不是随机波动。
设计分六步：

• 定目标：明确要提升的指标，比如新套餐办理转化率。
• 定指标：一个主指标加若干护栏指标，防止转化上升但投诉率也上升。
• 算样本：按基线转化率、最小可检测效应、显著性水平与统计功效反推样本量，再据此定实验周期，避免中途偷看结果。
• 分组：随机分流，保证两组用户结构可比。
• 监控：看指标趋势与数据质量，发现埋点异常及时停。
• 判定：做显著性检验，同时看效应大小是否具备业务意义。

陷阱要提两点：辛普森悖论，分层后结论可能反转；季节性与竞品活动干扰，最好用同期对照或延长观察。

用 STAR 讲，把重点放在「分析结论怎么变成业务动作」。

• 情境：一句话交代背景与问题，比如某业务线的新用户七日内流失偏高。
• 任务：说清自己负责的部分，是独立完成分析，还是负责取数与建模。
• 行动：分三层。先做数据清洗与口径对齐，处理重复与缺失；再做探索分析，按渠道、机型、首日行为分层，发现未完成关键引导的用户流失率高出数倍；最后做验证，用同期对照排除了渠道结构差异。
• 结果：给出量化结论和落地建议，比如把引导步骤从五步压到三步，上线后七日留存提升几个百分点。
• 反思：说清当时没做好的地方，比如早期忽略埋点缺失导致返工。

收尾一句：分析的价值不在于模型多复杂，而在于结论被采纳。

不要只报库名，按一条分析链路讲。

• 读取与清洗：Pandas 承担主力，DataFrame 做筛选、连接、透视，缺失值与异常值处理也在这里完成。
• 数值计算：NumPy 提供数组与矩阵运算，向量化写法比循环快一个量级，Pandas 底层也依赖它。
• 可视化：Matplotlib 控制精细，适合自定义图表；Seaborn 封装了统计图，做分布与相关性更快。
• 建模：Scikit-learn 覆盖分类、回归、聚类与评估，接口统一，适合快速验证；需要严格统计推断时用 Statsmodels，能输出系数与显著性。
• 串成例子：用 Pandas 读入话单数据，清洗缺失，按地市与套餐聚合，用 Seaborn 画消费分布，再用 Scikit-learn 做流失预测。

收尾一句：面试官更在意能不能用一条链路解决问题，而不是背了多少库名。

先说目的，再说选型规则，最后落到业务场景。
可视化的目标不是好看，是让看图的人在十秒内得到结论，所以先明确要表达什么关系，再选图形。
选型规则：

• 看趋势用折线图，横轴是时间，适合月度 ARPU、日活走势。
• 比大小用柱状图，类别多时改横向条形图，避免标签挤在一起。
• 看构成用堆叠柱或环形图，类别超过五类就不要用饼图。
• 看分布用直方图或箱线图，箱线图还能直接看出异常值。
• 看相关用散点图，点的大小或颜色可以承载第三个维度。
• 看地理用热力图或分级设色地图。

通信场景举三个：月度 ARPU 趋势用折线，基站覆盖质量用热力图，新用户转化用漏斗。收尾一句：图表选错的代价是结论被误读。

先客观讲差异，再讲选择理由，不要贬低任何一方。

• 目标不同：算法岗解决预测得准不准，产出是模型与服务；数据分析岗解决业务该怎么动，产出是判断与建议。
• 能力结构：算法岗重数学推导、特征工程、模型部署；数据分析岗重业务理解、指标体系、实验设计与沟通表达，SQL 与统计是底盘。
• 评价方式：算法看离线指标与线上效果；分析看结论是否被采纳、业务指标是否改善。

选择理由给三条：更享受把数据翻译成决策的过程；沟通与业务理解是长板；同时具备一定算法基础，能与算法团队对齐语言。
收尾一句：两个岗位是接力关系，不是高低关系。追问预警：可能问「如果业务方要你自己建模，你行吗」。

按「自查—理解—呈现—验证」四步处理，态度要开放。

• 自查：先复核数据口径、样本范围、清洗逻辑与统计方法，排除技术性错误。多数分歧出在口径不一致，而不是结论错误。
• 理解：主动问业务方的判断依据，他们可能掌握一线信息、促销安排或系统外的因素，这些是数据里看不到的。
• 呈现：把结论换成业务语言，用对比图和具体案例说明，比如「同类用户在合约到期前三十天的流失率是平日的两倍」，比抛 p 值有效。
• 验证：分歧无法收敛时，提议做小范围试点或 A/B 测试，用一段时间的数据说话，成本可控。

收尾一句：分歧不是要赢，是要让决策更接近事实。追问预警：可能问「试点结果支持对方，你怎么处理」。

分技术、制度、个人三层，落点在岗位职责上。

• 技术层：数据脱敏与假名化，敏感字段加密存储，按角色做访问控制，分析环境与生产环境隔离，必要时用差分隐私或聚合结果替代明细。
• 制度层：数据分级分类管理，最小必要原则，操作留审计日志，对外提供数据要经过审批与脱敏，跨境流动按监管要求评估。
• 个人层：不把生产数据拷到本地，不用个人账号导出明细，不在外部工具里粘贴真实用户信息，分析结论只呈现聚合结果。

可以补一句法规背景：数据安全法与个人信息保护法实施后，运营商作为数据密集型企业，合规是业务前提而不是附加要求。
收尾一句：分析能力再强，越过数据边界一次就够毁掉职业信用。