前阵子有朋友问起搜狐畅游校招里BI工程师岗位的笔试考什么说网上能找到的信息很零散大多是求面经、求题库的帖子真正讲透考点和答题思路的很少。这让我想到自己当初备考游戏行业数据岗笔试的经历也跟着踩过不少坑。今天这篇就把2020年搜狐畅游校招BI工程师笔试做一次完整复盘重点讲清楚游戏公司的BI工程师到底做什么、笔试爱考什么、开放题怎么答、哪些失分点最可惜。内容适合准备投递游戏公司BI或数据分析岗的应届生也适合已经笔试过但没搞明白自己为什么挂的人对照自查。1. 先搞清楚游戏公司里的BI工程师到底是个什么角色1.1 岗位定位与校招特点很多应届生把BI工程师当成写SQL取数的这么理解不算错但只看到了冰山一角。游戏公司里BI工程师的工作本质是围绕业务数据构建一条完整链路游戏客户端和服务器产生海量行为日志经过清洗、加工、建模进入数据仓库再由BI工程师开发成面向运营、策划、发行团队的报表和分析专题最终支撑每一个版本决策。比如某个活动要不要加投放、某个职业的数值是否失衡、新用户次留为什么下滑、买量渠道的ROI是否回本这些问题背后都要有BI工程师保证数据准确、口径统一、结论可解释。搜狐畅游这类老牌厂商产品线很宽既有长线运营的MMORPG项目也有后来的移动端产品。不同项目之间的埋点规范、数据格式、业务定义往往不统一这给BI工程师带来的挑战比想象中大得多。校招笔试不指望应届生有完整项目经验所以考察重点落在三块基础功底SQL、数仓、统计、业务嗅觉游戏核心指标、玩家行为理解、逻辑思维面对开放问题时的排查路径。如果你提前知道这三块复习方向就会清晰很多不至于一头扎进算法题里出不来。1.2 笔试想筛出什么人笔试的筛选逻辑我认为一句话可以概括不要只会背题的人要能干活、能沟通、能自己把事情往下想的人。举一个很典型的例子同一道写留存SQL的题有人用窗口函数写得非常简洁有人用一堆子查询也能跑对还有人会在答案旁边主动注明我这里假设同一用户一天内多次登录只算一个活跃。三种答案都能跑但第三种往往更容易过因为他展示了定义先行的意识。游戏业务里到处都是口径问题比如付费率的分母到底是DAU还是注册用户、登录时长的统计窗口按自然日还是按会话拆分这些定义一旦含糊报表就会变成垃圾输入、垃圾输出。再看业务题。笔试如果给一个某区服收入突然下降的场景大多数人上来就猜是不是活动结束了是不是大版本更新出Bug了但合格的候选会先反问收入下降是全服还是单区服是活跃用户少了还是付费率降了先下降后回升还是一条线往下掉这种先界定问题再找原因的习惯就是游戏BI工程师的日常。所以笔试表面上考知识点实际上考的是你有没有养成数据人该有的思考方式。2. 盘点搜狐畅游这类游戏公司BI笔试的核心考点2.1 SQL功底不是会写就行要写出能跑的SQL是游戏公司BI笔试的绝对大头也是淘汰率最高的一环。这类笔试通常不会考特别偏门冷僻的语法但题目会带业务属性比如计算某日新增用户第30天的留存人数或者统计各渠道首日付费率。这些题看着基础实际有暗坑留存的日期偏移怎么算、登录表一天多条记录要不要去重、渠道字段有空值怎么处理。如果只背过教材里的例句、从没在像样的数据量上跑过很容易写出逻辑对但工程上一碰就炸的查询。我在实际工作中最常用到的SQL技能不外乎以下几类也建议校招前练到闭眼能写分组聚合与Having过滤能快速回答哪些渠道DAU超过10万这类问题。窗口函数包括row_number、rank、lag/lead、sum over游戏排名、前后版本对比必备。日期函数date_format、datediff、date_add不同数据库写法有差异但思路一致。多表关联特别是自关联求留存、关联明细表求转化漏斗。去重方法distinct、group by、row_number编号后取1要在合适的场景选对。SQL题一般分值占比最高而且答案可以机器跑分对就是对、错就是错因此也是笔试里最值得投入时间准备的部分。建议找一些公开数据集或者自己造一张玩家登录表把上述几类查询各写十遍以上写到不需要想语法为止。2.2 数据仓库与建模基础BI工程师和数据分析师最显著的区别就是BI工程师必须懂数仓。笔试里经常出现概念题和简答题比如什么是星型模型、什么是缓慢变化维、数仓为什么要分层。这类题如果你只背定义阅卷人一眼就能看出来因为写出来的东西没有层次感。游戏业务相比常规互联网业务更依赖事件而不是访问。普通分析关注PV/UV游戏里要看的是登录、创角、新手引导完成、关卡通过、充值、购买、消耗、组队、公会等大量自定义事件。这些事件天然适合用事实表和维度表来组织。拿玩家充值这个事实举例维度可以是玩家ID、区服、角色职业、充值金额档位、渠道、时间度量指标就是充值金额和订单数。理解了这种组织方式再去理解维度建模就会顺很多。比如维度建模四步走选择业务过程、声明粒度、确认维度、确认事实。这套方法论在笔试简答题里特别好用。你不需要写得像教科书那么长但一定要结合游戏场景说清楚。举个例子选择业务过程选的是玩家充值声明粒度是每笔充值订单一行维度是时间、渠道、区服、玩家、档位事实是订单金额和支付成功数。这么答完阅卷人会认为你真的理解数仓建模在游戏里怎么落地。2.3 指标理解与业务常识第三个高频考点就是游戏业务指标。游戏行业的指标体系和电商、内容行业差别很大笔试会直接给几个日常运营常用指标让你解释口径或者算数。我整理了一份游戏BI最常被问到的指标清单也可以拿来自查指标常见口径核心用途DAU / MAU日活 / 月活用户数用户规模与活跃度留存率新增用户次日、3日、7日、30日活跃占比衡量产品黏性和内容节奏付费率付费用户数 / 活跃用户数变现广度ARPU总收入 / 活跃用户数单用户平均价值ARPPU总收入 / 付费用户数付费用户深度LTV用户生命周期内贡献的总收入买量回本和版本评估但光背名词没用笔试更爱考的是指标波动怎么解读以及指标之间的勾稽关系。比如次留高但7留低说明玩家前期被吸引进来但内容消耗太快、缺少中期目标这就是典型的产品内容断层信号。再比如ARPU上升但付费率下降通常意味着头部大R付费强劲但中小R的付费意愿在变弱。这种串联指标的解读能力才是BI工程师真正值钱的地方也是校招试卷用来拉开区分度的关键。3. 笔试实操复盘一套贴近真实题风的模拟题加答题示范3.1 题型一SQL写留存题目背景有一张玩家登录日志表login_log字段包含uid玩家ID、login_date登录日期格式yyyy-mm-dd。另有一张玩家注册表reg_user字段包含uid、reg_date注册日期格式yyyy-mm-dd。请用一条SQL计算2020年1月1日注册的玩家分别在1月2日、1月8日、1月31日的留存人数。这道题的考点很集中时间偏移计算、多表关联、去重逻辑。参考写法如下SELECT COUNT(DISTINCT a.uid) AS reg_cnt, COUNT(DISTINCT CASE WHEN l2.uid IS NOT NULL THEN a.uid END) AS day1_retained, COUNT(DISTINCT CASE WHEN l8.uid IS NOT NULL THEN a.uid END) AS day7_retained, COUNT(DISTINCT CASE WHEN l31.uid IS NOT NULL THEN a.uid END) AS day30_retained FROM ( SELECT uid, reg_date FROM reg_user WHERE reg_date 2020-01-01 ) a LEFT JOIN login_log l2 ON a.uid l2.uid AND l2.login_date DATE_ADD(2020-01-01, INTERVAL 1 DAY) LEFT JOIN login_log l8 ON a.uid l8.uid AND l8.login_date DATE_ADD(2020-01-01, INTERVAL 7 DAY) LEFT JOIN login_log l31 ON a.uid l31.uid AND l31.login_date DATE_ADD(2020-01-01, INTERVAL 30 DAY)这里面有三个细节值得在笔试时注意。第一先限定注册日期再和登录表关联可以显著减少关联规模真实环境里直接用全表关联可能跑不动。第二登录日志一天内会有多条记录所以要用COUNT(DISTINCT)而不是COUNT()否则人数会翻倍。第三日期偏移用DATE_ADD处理不要手写2020-01-02这类硬编码否则跨月、跨年容易出错也会让阅卷人觉得你的SQL可维护性不够。如果笔试时间有余量可以在答案旁边补一句如果login_log数据量很大也可以先把登录表按uid和登录日期去重后再参与关联进一步减少数据量。这种注释式的说明会让阅卷人一眼看出你有真实项目经验而不是只会写教材答案。3.2 题型二设计一套游戏核心指标体系题目背景某游戏项目需要搭建一套日报体系请为运营、策划、发行三个角色分别设计核心指标说明每个指标的口径和用途。这种开放题没有标准答案但答题结构很容易拉开差距。我的建议是按用户规模、用户黏性、行为质量、付费变现、游戏健康五个维度去组织再用一张表把指标、口径、服务对象说清楚指标大类指标示例口径说明主要服务角色用户规模新增用户、DAU去重后的账号或设备数运营用户黏性次留、7留、30留新增用户注册后N日活跃占比运营、策划行为质量平均在线时长、新手引导完成率、关卡通过率按账号或会话统计策划付费变现付费率、ARPU、ARPPU、首充转化率以充值订单和流水为准发行、运营游戏健康付费用户流失率、崩溃率、举报量从稳定性与生态维度补充全局关键是表格背后要有一条主线新增用户进来能不能留下来有没有形成活跃是否产生付费付费之后会不会流失。这样一套逻辑串下来所有的指标都能落在玩家生命周期这根链条上。答完表格之后再补一句不同角色的日报看重要有侧重但同一指标在不同看板之间的口径必须全局统一这句话能把答案的层次拉高因为这正是BI工程师日常协调业务方时最头疼的问题你能主动写出来说明真的理解岗位。3.3 题型三业务场景分析题题目背景某游戏昨天整体付费收入环比下降30%作为BI工程师你会怎么分析原因请给出完整的排查路径。这类题阅卷人最怕看到先查一下数据五个字就结束的答案所以答题一定要有流程感。我的框架是五步先证实指标、再拆维度、列假设、做验证、给结论。第一步先别急着归因先确认收入是否真的下降了。有没有埋点补传、订单回滚、支付渠道回调延迟、统计口径临时调整很多波动其实是统计问题而不是业务问题把这一点作为默认动作写进答案会立刻显得你专业。第二步按维度拆分时间维度精确到小时再加上渠道、区服、付费档位、新老玩家、充值入口这几个维度找到下降最集中的子群体。第三步列假设从外部事件竞品上线、节日波动、内部事件版本更新、活动下线、支付故障、人群变化买量暂停、新增质量下降三个方向展开。第四步用数据验证比如下载量骤降可能就是买量停了某支付渠道订单成功率下降就是渠道问题。第五步输出结论时要给出可落地的建议而不是只说建议提升收入这种正确的废话。有一个小技巧值得写进答案拆分维度时优先看收入 活跃用户数 × 付费率 × ARPPU这个恒等式先判断是哪一端变了再往下钻。比如DAU没变、付费率暴跌那问题大概率出在活动或付费入口上如果三者的变化都很平稳那要考虑外部环境或者统计异常。这套拆法不仅能用在笔试里实际工作中排查问题也是这么做的。3.4 题型四数仓设计题题目背景请设计一张玩家每日登录事实表说明粒度、维度、度量并简述产出流程。数仓设计题在校招笔试里出现频率不低。答这种题第一句要先声明粒度比如每玩家每日一行同一玩家同一自然日最多一条记录。粒度声明完之后后面所有维度、度量才有意义这也是维度建模里被强调最多的一件事。维度可以设计为日期stat_date、玩家IDuid、区服IDserver_id、渠道IDchannel_id、玩家注册日期reg_date。度量可以设计为当日登录次数login_cnt、当日累计在线时长duration_sum、当日活跃时长所在的时段等。产出流程可以按ODS到DWD再到DWS来说ODS层直接同步原始登录日志DWD层做清洗和解析DWS层按日、按玩家聚合得到这张表。这条链路把数仓分层、ETL调度、指标口径一次性表达清楚了面试官看到这种答案会认为你已经有过完整项目认知而不是停留在概念背诵。再说一个加分细节把登录时长这类度量单独说明是当日每次登录会话时长之和还是截至当日0点的累计在线时长因为很多游戏按自然日切分会话时会有时区边界问题。你愿意主动思考这种口径歧义阅卷人会觉得你是真的上手处理过数据的人。4. 校招笔试的高频失分点与实战避坑指南4.1 失分点一细节废掉整个答案我见过太多笔试答案思路是对的最后因为细节丢分甚至直接判错。最典型的几个第一审题不仔细题目说计算新增用户第30天留存却拿全量活跃表当注册表用整个统计口径直接反了第二日期边界不处理跨月、跨年的情况如果用了硬编码日期很容易算错要用DATE_ADD这类函数第三空值和脏数据不处理游戏里渠道、区服、玩家名经常有空值你要在答案里说明空值是保留还是剔除第四SQL不写注释阅卷人一天看几十份卷子逻辑清楚的注释能降低很多沟通成本也会让你答案的专业度上一个台阶。还有一个很多人忽略的点阅卷人拿到的是静态代码不是真的跑SQL。如果你写了错误的关键字或者明显语法不对即便思路正确也可能被扣分。所以交卷前一定要做语法自查尤其是JOIN条件、括号、逗号这些细节。宁可多花两分钟读一遍自己的SQL也别因为一个逗号丢了整道题的分。4.2 失分点二时间分配失衡校招笔试总时长一般是90到120分钟题量不会小。很多人抱着把每道题做到完美的心态在SQL大题上卡了40分钟结果后面的业务题和数仓简答完全没时间答整体分数反而被拉低。我的习惯是先花两分钟快速扫完全部题目把会做但需要思考的题圈出来优先做自己有把握拿分的题尤其是概念题和简答题这些题得分效率高先拿下来再说。时间分配上如果总时长120分钟可以大概按SQL题45分钟、数仓和概念题15分钟、指标与业务题30分钟、开放设计题20分钟、最后留10分钟检查来切。当然这个比例要根据自己强弱项调整但有一个原则不要破不要在一道题上死磕超过20分钟。写不出来的SQL说明考点真的没掌握继续耗着边际收益极低不如转向业务题用结构化表达去捞分。4.3 笔试答卷要当成面试素材来写这一点很少有人提但我觉得特别重要笔试答卷就是你后续面试的素材。我在实际招聘中看到太多候选人笔试写得挺好面试时却被追问你当时为什么这么设计如果数据偏差你会怎么排查结果答得支支吾吾反而让面试官怀疑是不是抄的。如果你在笔试时就把关键假设、设计理由写在答题区旁边不光是给阅卷人看更是给自己留了一份思考备忘录。比如数仓设计题里你写了登录时长的统计口径按会话切分面试官追问时你就能顺势展开讲为什么这么设计因为有些玩家跨零点在线如果按自然日硬切会把一段连续游戏时间拆成两天影响人均在线时长这个指标。这种从笔试答案延伸出来的深度对话是最自然、也最能加分的面试表现前提是你笔试的时候真的认真思考了而不是靠模板凑出来的。5. 写在最后想进游戏行业做BI校招真正该储备什么5.1 我复盘后最想补的一课踩过这么多坑之后如果让我重新准备一次搜狐畅游这类游戏公司的BI校招笔试我会先做一件事把SQL练成肌肉记忆。不是会写而是拿到任何一张表结构、任何一个业务问题能快速判断该用哪种查询方式、该注意哪些坑。具体方法就是自己造一张玩家登录表和一张充值表然后模拟各种问题——算DAU、算留存、算付费率、算首充转化、算渠道榜单。每个问题用三五天换着花样写直到不需要查语法为止。第二件事我会把游戏核心指标之间勾稽关系想透。不只是背定义而是能讲清楚留存率下降对LTV意味着什么、ARPU和付费率同步下跌说明什么这类连环问。因为笔试的业务题本质是考察变量之间的关系不是考孤立知识点。你脑子里有一条完整的数据指标链条遇到任何波动题都能顺着链条往下拆。5.2 一条适合大多数人的备考路径最后分享一条我自己验证过、也比较适合大多数人的备考路径。第一步花一周时间把SQL基础语法过一遍重点练窗口函数和日期处理这是性价比最高的一周。第二步找一款自己真正玩过的游戏以它为例设计一套指标体系试着用数据拆解为什么我玩到某个等级流失了这个过程能帮你建立业务感觉比看十篇面经都有用。第三步系统梳理一遍数仓分层的意义和维度建模基本方法不用太深但要能用自己的话结合游戏案例讲出来。第四步拿往年真题或模拟题掐时间做两套完整试卷训练节奏和答题排版。我个人的体会是BI工程师这个岗位在校招里确实有一定门槛但它不是靠天赋而是靠刻意练习。游戏行业的数据分析逻辑非常完整清晰玩家从新增、活跃、留存到付费是一条完整生命周期你只要把这条主线理解透笔试也好、面试也好都会顺畅很多。希望这篇复盘能帮你把备考方向摆正少走我当年走过的弯路。