
1. 笔试的基本盘搜狐畅游数据分析师到底考什么先说说这场笔试给人的整体感觉。大多数人在准备校招笔试时都有个误区——觉得数据分析师的笔试就是考SQL、考Python、考统计学把 LeetCode 刷明白、把 pandas 文档翻一遍就能上考场。但搜狐畅游这场笔试给我最直观的感受是它根本不打算考你“会不会用工具”而是考你有没有一套完整的“业务拆解数据验证”的思维框架。工具只是载体业务才是本体。当时我在牛客网上看到笔试邀请的时候距离正式考试大概还有一周。我把市面上能搜到的游戏公司数据分析师笔经翻了一个遍发现一个规律越是头部游戏公司越喜欢在笔试里加入“业务场景还原”类的题目搜狐畅游也不例外。它不会直接问你“DAU 下降 10% 怎么分析”而是会给你一个具体的游戏版本更新背景、一段用户行为数据表结构甚至是一份简化的埋点日志让你从数据表里自己发现问题、搭建分析框架、给出结论。这种题目没有标准答案但恰恰最考验功底。整场笔试的时间大概在 120 分钟左右题量不算夸张但覆盖面很广。我把题型大致归成四类行测逻辑题、SQL 编程题、概率统计题、案例分析题。行测逻辑题占了一部分主要考察逻辑推理和图推数列难度中等偏上但和数据分析没什么直接关系这里不展开。真正决定你能不能进面试的是后面三类。有一个容易被忽略的点试卷开头会要求你填写“熟悉度自评”——对 SQL、Python、SPSS、R、Excel 的掌握程度打分。这个自评不是随便填填就完事的它有可能是简历筛选环节的延续。如果你选了“精通 SQL”那么后续 SQL 题目的难度系数可能会相应调高如果你选了“不熟悉 R”那么 R 相关的题目大概率不会出现在你的卷面里。所以填自评的时候建议诚实一点不要为了显得厉害就全部拉满否则后面做题会非常痛苦。2. 游戏行业数据指标的底层语境考前必须吃透的“游戏术语”2.1 为什么搜狐畅游的笔试绕不开游戏业务数据分析师在很多行业里都是“业务翻译官”但在游戏行业这个角色的业务门槛明显更高。搜狐畅游做的是游戏它的数据分析和电商、金融、内容平台的数据分析有一个本质区别游戏数据有非常强的生命周期属性每个版本、每次活动、每个赛季都是一次“事件”而用户在这些事件中的行为路径高度非线性。笔试里如果出现看不懂的指标名称比如 LTV、DNU、付费渗透率、7 日留存、ARPPU那就不是做题的问题了而是连题目在问什么都搞不清楚。我当时在准备阶段做了一个非常笨但非常有效的动作把游戏数据分析里常见的指标全部手写整理了一遍并且为每个指标想了一个“如果我是游戏运营我会怎么用这个指标”的场景。这个过程看起来麻烦但它让我在笔试时看到任何业务描述都能快速在脑子里构建出对应的指标公式和适用场景而不是盯着题目发呆。2.2 核心指标与衍生指标从 DAU 到 LTV 的完整链条游戏数据分析里最绕不开的几组指标笔试前一定要做到条件反射级别的熟悉。DAU/WAU/MAU 是基础活跃指标但如果题目只给你 DAU 让你做分析那一定是不够的。真正的考点在于 DAU 的构成拆解新增用户、回流用户、活跃老用户。同样是 DAU 下降 10%新增用户大幅减少和活跃老用户流失对应的运营策略是完全不同的。留存率是游戏行业的生命线笔试里出现频率极高。常见的有次日留存、7 日留存、30 日留存也有按版本、按渠道、按用户群体拆分的留存矩阵。考留存率的题一般会给你一张包含用户注册日期和行为日期的表让你自己算留存。付费类指标同样重要付费率、ARPU、ARPPU、LTV。这里特别强调一下 LTV——LTV 不是单纯看一个用户花多少钱而是看这个用户从进入到流失的整个生命周期里贡献的总价值。笔试里如果让你算 LTV通常需要结合留存曲线做估算公式大概是 LTV ARPU × 平均生命周期时长而平均生命周期可以由留存率曲线积分得到。这个考点既考公式记忆又考你对留存曲线意义的理解。需要注意的还有一个高频指标付费渗透率它和付费率的区别在于分母不同。付费渗透率通常是付费用户占活跃用户的比例也可以拆到新增用户口径上。笔试中如果区分不清很容易在计算题里翻车。2.3 指标异动分析的“标准套路”除了单个指标的定义笔试案例分析题还特别喜欢考“指标异动归因”。这类题的答题套路其实是非常结构化的我总结下来的框架是这样的第一明确指标的统计口径和波动范围。是日环比、周同比还是版本对比波动多少算异常很多同学一上来就分析原因但忘了先确认这个下降是否在正常波动区间内。第二拆维度定位。渠道、版本、机型、地区、用户分层、时间维度逐层下钻找到波动的主要来源。比如整体 ARPU 下降就要先从付费用户占比和免费用户占比的结构变化入手再去看是不是某个渠道买量质量下降导致的。第三结合业务动作和时间节点找因果关系。版本更新时间、活动排期、竞品动态、外部环境因素这些都可能成为异动诱因。第四给出可落地的建议。不能只说“可能是付费引导做得不好”要具体到建议在哪个节点做什么样的调整怎么验证。这套框架在笔试案例分析题和面试题里都特别管用强烈建议在考前就用自己的话整理成模板考试时直接套用省时又不容易漏点。3. 笔试题型深度拆解从 SQL 窗口函数到案例分析题的完整解题路径3.1 SQL 题窗口函数与留存计算的组合拳SQL 题是搜狐畅游笔试的重头戏考察方式基本就是给你几张表让你写查询。表面上考的是语法实际上考的是你有没有用 SQL 解决真实业务问题的能力。我印象最深的一道题是要求用 SQL 计算某游戏版本的用户 7 日留存率表结构大概是这样的user_login_log ( user_id string, login_date string, version string )登录日志非常稀疏一个用户可能一天登录好多次也可能某天根本不登录。如果直接拿这张表算留存很容易把重复登录算成多个用户。正确做法是先按 user_id 和 login_date 去重得到用户的每日活跃记录然后再做留存计算。我在考场上写的大致思路是这样的WITH daily_active AS ( SELECT user_id, login_date FROM user_login_log WHERE version v2.1 GROUP BY user_id, login_date ), first_seen AS ( SELECT user_id, MIN(login_date) AS first_date FROM daily_active GROUP BY user_id ), retention AS ( SELECT f.first_date, d.login_date, COUNT(DISTINCT f.user_id) AS retained_users FROM first_seen f LEFT JOIN daily_active d ON f.user_id d.user_id AND f.first_date d.login_date AND DATEDIFF(d.login_date, f.first_date) 7 GROUP BY f.first_date, d.login_date ) SELECT first_date, SUM(retained_users) AS day_7_retained_users, (SELECT COUNT(DISTINCT user_id) FROM first_seen WHERE first_date r.first_date) AS total_new_users, SUM(retained_users) * 1.0 / (SELECT COUNT(DISTINCT user_id) FROM first_seen WHERE first_date r.first_date) AS retention_rate FROM retention r GROUP BY first_date这道题我写完之后花了点时间检查逻辑如果某天没有满足条件的留存用户LEFT JOIN 会留下 NULL 行所以需要在分组后处理好。后来复盘时我发现更简洁的写法是用窗口函数 LAG/LEAD 或者直接做日期差值的条件计数但只要能算出正确结果考场上的写法其实不重要。SQL 题里另一个高频考点是窗口函数。比如用 ROW_NUMBER() 给每个用户的登录记录按时间排序标号然后筛选每个用户的最新一条记录或者用 SUM() OVER (PARTITION BY ... ORDER BY ...) 计算累计值考察“每个渠道的累计付费金额”。这些考点在力扣题库里经常出现但数据库环境可能从 MySQL 变成了 Hive SQL语法上要注意 PARTITION BY 和 ORDER BY 的位置还有 Hive 对某些函数的支持情况。3.2 概率统计题AB 测试与显著性检验概率统计题在笔试里占了不小的比重主要考察能不能用统计学方法解决业务问题。搜狐畅游笔试里出现比较多的是 AB 测试相关的内容——一个典型的场景是游戏里新加了一个付费引导弹窗产品经理想知道这个改动是否显著提升了付费转化率运营给了两组用户的实验数据让你判断这个提升是否显著、需要多少样本量、结果能不能推广。这类题的核心考点在于中心极限定理、正态分布假设、假设检验的流程。实操中容易踩的坑是不加验证就直接用 t 检验。注意比例类指标转化率的比较通常用卡方检验或者 Z 检验均值类指标比如时长、付费金额才用 t 检验。如果题目给的是转化率的数据正确的做法是构造 2×2 列联表算卡方统计量再判断 p 值是否小于显著性水平。还有一种变形题是给你一个置信区间让你判断显著性。比如对照组转化率 3.2%实验组 3.8%实验组 95% 置信区间是 [3.5%, 4.1%]问是否显著提升。答案是显著因为对照组转化率 3.2% 不在实验组的置信区间内。这种题表面上考置信区间实际上考的是你对“统计推断到底在推断什么”的理解。关于 AB 测试我还想多说一句一般笔试题里不会要求你手算统计量但要求你写出完整的实验设计思路比如怎么分层抽样、怎么控制变量、需要多长时间、样本量如何确定。这个部分一定要体现出你对“随机化”和“控制变量”的理解不能只写“把用户分成两组”。3.3 Python 题数据处理与自动化Python 考察点主要集中在 pandas 和 numpy偶尔会有一些小算法题。搜狐畅游的 Python 题不算难但非常贴近实际数据处理场景。比如给你一个 CSV 文件里面是玩家充值记录要求读取后按渠道分组计算每组的总流水、平均流水和付费用户数并按总流水从高到低排序输出。这种题用 pandas 就是几行代码的事import pandas as pd df pd.read_csv(recharge_log.csv) # 按渠道分组统计 result df.groupby(channel).agg( total_revenue(amount, sum), avg_revenue(amount, mean), pay_users(user_id, nunique) ).reset_index() # 按总流水降序排列 result result.sort_values(total_revenue, ascendingFalse) print(result)这道题的考点其实在细节上如果直接对 user_id 用 count会把重复充值算作多个用户应该用 nunique 去重。这个细节在笔试判分时很关键因为很多题目的表里会有大量重复记录考察的就是你有没有这个数据清洗意识。另一个经常出现的 Python 题是写一个小函数处理时间格式比如把字符串 “2020-08-01 12:30:45” 转换成日期对象然后按小时提取用户活跃时段。这种题目用 datetime 模块的 strptime 函数就能解决但要注意时间戳转换的边界条件和时区问题。Python 题目我个人的策略是优先保证思路清晰、结果正确其次才追求代码简洁。笔试环境里没有本地调试写得太花哨反而容易出错。3.4 案例分析题最拉分的一道题案例分析题是搜狐畅游笔试的压轴题也是最拉分的一道题。我记得当时遇到的一道题大概是某游戏最近一个月流水下降了 15%但是 DAU 没有明显变化让你分析可能的原因并提出后续的运营和产品建议。这种题没有任何数据给你全靠自己的框架和积累去回答。我当时的答题思路分为四个部分第一先对齐定义。这里说的“流水”是指日流水还是月流水“DAU 没有明显变化”是说 DAU 没跌还是 DAU 稳中有升先把口径定义清楚避免后面的分析失去锚点。第二拆流水构成。流水 DAU × 付费率 × ARPPU。DAU 没变那问题一定出在付费率或者 ARPPU 上。进一步拆付费率是否下降ARPPU 是否下降如果是 ARPPU 下降是单笔付费金额变小还是参与付费活动的用户变少第三分维度定位。如果流水下降集中在某个特定渠道的买量用户身上问题可能出在买量质量下降或渠道作弊如果集中在某个版本的玩家身上大概率是版本改动影响了付费体验如果集中在某几天需要去对齐那几天的运营活动和大盘环境。版本更新、道具价格调整、付费引导弱化、新用户占比升高、老用户活跃但付费疲劳这些原因我都列出来逐一排查。第四给建议。如果判断是付费率下降建议优化付费引导设计和新手付费礼包如果判断是 ARPPU 下降建议调整道具定价梯度、增加大额礼包档位如果判断是渠道问题建议暂停该渠道投放并排查数据异常。案例分析题的核心是逻辑链完整、表达清晰、有业务场景感。写的时候不要害怕字数多关键是让阅卷人一眼看到你的分析框架是合理的。4. 工具链选择与笔试实战策略哪些工具在考场上真能救你4.1 从 Excel 到 Python笔试时的“工具能力分层”笔试和实际工作有一个很大的不同笔试时间有限不能上网查资料不能反复试错所以工具能力的核心不是“用得有多熟”而是“能不能在高压环境下快速选择最顺手的工具”。有些同学在笔试时会在 Excel、Python、SPSS 之间来回切换结果每道题都只做了一半这个是大忌。我的经验是工具能力要分层次笔试时遵循“能算则算、能写则写、能画则画”的原则。对于明确要求写代码的题比如 SQL 题和 Python 题就没有任何替代方案直接写代码。对于没有明确要求工具的题比如数据计算和相关性分析如果题目描述看起来非常像“用 Excel 操作一下就能出结果”那我建议还是用 Python 写因为考官的阅卷逻辑里代码比纯文字更有说服力。4.2 SQL、pandas、numpy、Spark 的适用边界笔试中经常出现的工具包括 SQL、pandas、numpy偶尔会提到 Spark。不同工具的适用边界一定要分清不能混用。SQL 适合处理结构化表格数据的查询、聚合、Join、窗口计算只要题目给的是表结构首选 SQL。pandas 适合处理 CSV、Excel 这样的本地文件做数据清洗、分组聚合、时间序列处理特别方便。numpy 适合做数值计算和矩阵运算如果题目里涉及大量数值运算比如计算均值方差协方差矩阵用 numpy 会快很多。Spark 在笔试里出现的频率不高但偶尔会有题目问“如果数据量超过单机内存你会怎么做分析”。这种题考的是分布式计算的思维数据分区、MapReduce 思想、宽窄依赖、shuffle 优化。我当时准备的时候重点看了 shuffle 的性能瓶颈和分区数设置明白这些概念后即使笔试没有真正的 Spark 环境也能把思路写清楚。4.3 时间分配与得分优先级整场笔试的时间大概 120 分钟我个人的时间分配策略是这样的行测逻辑题控制在 25 分钟内完成不会的题先蒙一个做标记不要恋战。SQL 题安排 35 分钟Python 题安排 30 分钟概率统计题 20 分钟案例分析题 30 分钟。最后留 5 到 10 分钟检查一遍SQL 的字段名是否有拼写错误、代码块的括号是否完整、案例分析的逻辑是否有漏洞。得分优先级上我的判断是SQL 题和案例分析题是拿分大头因为这两种题的区分度最高概率统计题虽然占分不多但如果你会做性价比也高Python 题只要跑通思路就赢了一大半。行测逻辑题如果时间不够可以战略性放弃最后几道难题。4.4 考试环境中的“模拟感”训练这里想特别提醒一个准备阶段容易被忽略的点不要只在本地 IDE 里刷题一定要提前去牛客网或者赛码网做几套模拟题适应在线笔试环境。在线笔试的编程题没有本地调试代码写完直接提交报错了只能肉眼 debug。我考前大概在赛码网上练了三套题专门训练自己“写完代码不运行也能发现明显错误”的能力这对实际笔试帮助非常大。另外草稿纸非常重要。案例分析题和概率统计题需要大量计算和思路整理考场上如果只用脑袋想很容易漏掉重要维度。我的习惯是先把答案框架写在草稿纸上理清顺序后再誊写到答题区这样答案的条理性和完整性都会高很多。5. 从笔试到面试那些笔试没写但面试会追问的内容5.1 面试官如何从你的笔试卷面判断真实水平笔试结束不等于万事大吉面试官往往会拿着你的答卷进行追问。好几家公司都问过我“你笔试那道留存题答案里最大胆的假设是什么”“你的案例分析里提到的‘付费疲劳’具体怎么量化”这其实是在考察你是真的理解还是只是在堆术语。所以准备笔试的时候不能只满足于“做对题”还要能说清楚思路。尤其是 SQL 题为什么用窗口函数而不是子查询为什么用 LEFT JOIN 而不是 INNER JOIN这些选择背后的原因比答案本身更重要。面试官问“你当时怎么想到这个方案”的时候如果你能讲出分析和取舍过程会给面试官留下很深刻的印象。5.2 游戏业务场景下的面试追问方向搜狐畅游的面试风格比较务实喜欢围绕游戏业务出场景题。比如问如果你发现某款游戏的新用户次日留存率显著低于竞品你会从哪几个维度定位问题如果让你设计一个游戏内活动你会怎么评估它的效果这类问题没有标准答案但需要你展现出对游戏用户行为数据的敏感度。一个常见误区是很多候选人答这种题时把游戏业务当一个抽象用户增长模型来处理完全不管游戏特有的玩法、关卡难度、付费设计、社交机制。面试官其实很希望听到你结合游戏本身的特点来分析比如“这个游戏是卡牌还是 MMO卡牌游戏的次日留存核心在首抽体验MMO 的核心在前期主线引导”。这种对游戏品类差异的理解是区分普通候选人和优秀候选人的关键。我自己的经验是面试前可以挑一款搜狐畅游旗下的游戏比如《天龙八部》系列简单了解一下它的核心玩法、付费模式和用户画像。不用非常深入但要能说出这款游戏的数据指标重点应该放在哪里而不是泛泛而谈。6. 复盘与建议一次笔试暴露出的问题清单6.1 几个容易被扣分的细节考完搜狐畅游的笔试我复盘了自己的答卷发现了几个特别容易丢分的细节。第一个是 SQL 题里没考虑重复登录记录的去重。日志表里的数据几乎一定有重复记录可以直接 count 的情况极少大多数情况下要先 GROUP BY user_id, login_date 再去重统计。第二个是概率统计题里没写清楚原假设和备择假设。很多同学算 p 值算得飞快但忘记了最基本的“先写假设”这个步骤。虽然这不是计算的关键但体现了你是否理解假设检验的逻辑结构面试官看到这种细节会觉得你基础不牢。第三个是案例分析题里只列原因不给评估方案。分析题如果只写出“可能是版本更新导致付费下降”但没有提出“怎么用数据验证这个假设”这道题的得分会大打折扣。6.2 准备清单给想冲游戏公司数据岗的同学笔试准备到这个阶段我有几条比较通用的建议第一把游戏行业的数据分析指标表做一个自己的速查手册DAU、WAU、MAU、留存、付费率、ARPU、ARPPU、LTV、K-factor、CAC、ROI这些指标的定义、公式、适用场景、局限性全都要能讲清楚。第二SQL 练习不只是刷题还要当成业务问题来练。每道 SQL 题做完以后可以问自己这个查询结果如果在真实业务场景里运营会拿它做什么决策如果答不上来说明你对业务的理解还不够。第三概率统计一定要重视假设检验和 AB 测试这是互联网和游戏行业考核频率最高的统计考点。样本量计算、显著性水平、置信区间、第一类错误和第二类错误这些概念要做到能给别人讲明白的程度。第四Python 的数据分析库要熟练掌握 pandas 和 numpy 的常用操作尤其是 groupby、agg、merge、pivot_table、时间序列处理这些是笔试题里的高频考点。第五案例分析是拉分项一定要多看面经和真题但更重要的是形成自己的分析框架。我自己的框架概括成四个关键词是“口径—拆解—定位—建议”你可以根据个人习惯调整但一定要有一个能顺畅输出的框架。最后再说一点个人体会。数据分析师这个岗位尤其是游戏行业的数据分析师笔试考的不只是技术能力更是你把数据翻译成业务语言的能力。搜狐畅游这场笔试让我印象最深的就是这一点它所有的技术题最终都指向一个目标——你能不能利用数据帮助游戏团队做更好的决策。抱着这样的视角去准备笔试很多题目做起来就会举一反三而不是机械地刷题。希望这篇经验分享能给正在准备校招的你一些参考也祝你在笔试中发挥出自己的真实水平。