看到“搜狐畅游2020校招笔试 - BI工程师”这个标题估计不少准备投数据分析方向的同学都会愣一下游戏公司也招BI进去是写报表还是做数仓说实话我当年收到笔试通知时也是这样一脸懵。后来真正做完笔试、走完面试又在这个方向干了几年回头看才发现游戏行业恰恰是BI工程师最能体现价值的地方——数据量够大、业务链路够长、决策诉求够急一个合格的BI工程师在这里不是“做图表的”而是实打实的经营分析支撑角色。这篇文章就把我围绕这次校招笔试做的准备、踩过的坑、以及后来在工作中验证过的重点完整梳理一遍。不管你目标是搜狐畅游这种游戏厂商还是其他公司的BI岗位只要笔试考察范围里出现了Power BI、SQL、经营分析报表这些关键词这篇内容都能帮你建立一个相对完整的备考框架。1. 游戏公司里的BI工程师到底在做什么1.1 从岗位名字看真实职责不是“做报表的”很多人对BI工程师的第一印象是“用工具画Dashboard”这个认知不能说错但太片面了。尤其在校招笔试里面试官不会只考你工具操作他们更想确认你有没有“通过数据支撑业务决策”的思维。在游戏公司BI工程师的日常工作大概分四块。第一块是数据仓库建设游戏业务埋点数据多、渠道数据杂需要你梳理清楚底层表结构产出统一的指标口径第二块是报表开发把运营、市场、策划关心的数据做成固定报表或自助分析看板第三块是专项分析比如版本更新后留存为什么波动、某个渠道买量质量为什么下降第四块是数据产品规划推动公司从“人肉取数”走向“自助分析”。笔试题目一般不会直接让你写一段数仓代码但会通过业务场景题考察你是否理解这些工作之间的逻辑关系。比如问你“某游戏新版本上线后次日留存下滑5个百分点如何分析”表面上是个分析题实际上考的是你懂不懂埋点数据、懂不懂留存口径、能不能用BI工具把问题定位出来。1.2 游戏业务的数据链路从埋点到经营看板游戏行业的数据链路相比电商和金融稍微特殊一点。核心链路是客户端/服务端埋点 → 日志上报 → 数据清洗 → 数仓分层 → 指标计算 → 报表/看板展示。笔试时如果给你一张用户行为表、一张付费表让你计算付费率或者LTV你得清楚这些表在真实场景中是怎么产生的。比如“付费”这件事游戏里可能包含首充、续充、活动充值不同业务口径算出来的付费率差距很大。BI工程师最大的价值往往不是SQL写得有多花哨而是能把口径定义清楚。我当时笔试准备时专门梳理了游戏行业的核心指标框架用户规模类DAU/WAU/MAU/新增用户、留存类次日留存/7日留存/30日留存、付费类付费率/ARPU/ARPPU/LTV、渠道类CAC/LTV/CAC比值。后来证明这个框架非常有用。笔试里很多题目表面上在问工具、问SQL实际上底层都是这些指标的计算逻辑。1.3 BI工程师和数据分析师的分工边界笔试或者面试里经常会被问到“BI工程师和数据分析师有什么区别”。这个问题没有标准答案但你要能说出自己的理解。我的理解是BI工程师更偏向数据基建设施和报表体系的搭建核心是“让数据可以被稳定、高效地消费”数据分析师更偏向具体业务问题的探索和策略输出核心是“从数据中发现问题和机会”。两者有重叠但在团队协作中侧重点不同。畅游这类游戏公司往往会有数据组、运营组、市场组协作的格局。BI工程师要和运营同学反复确认指标口径要和数仓同学沟通取数逻辑还要把业务方的需求翻译成技术方案。这种跨角色沟通能力笔试考不出来但会反映在你对业务场景题的理解深度上。答业务题时能体现出“我懂业务方到底想要什么”很加分。2. 笔试重灾区Power BI的三大高频考点2.1 Power BI Desktop的建模逻辑先把表和表之间的关系想清楚“power bi”和“bi学习”在热搜词里长期霸榜确实这是BI工程师笔试面试绕不开的工具。Power BI Desktop是微软推出的自助式BI工具笔试中关于它的题目通常集中在数据建模、DAX、可视化三个层面。很多新手容易忽略“建模”这一步拿到数据就开始拖图表结果做出来的报表不但算得慢指标口径还有问题。正确的做法是先理清事实表和维度表的关系再建度量值最后才做可视化。举个游戏业务的例子。假设你要分析“各渠道新增用户的7日留存”那么你的模型中通常有一张用户注册表维度渠道、注册日期、设备一张用户活跃表事实用户ID、活跃日期、在线时长一张渠道维度表渠道ID、渠道名称。把用户注册表按用户ID关联活跃表再把渠道ID关联渠道维度表就能建出一个星型模型然后写一个“7日留存”的度量值后续不管怎么切片结果都不会乱。笔试中如果给你几个表问你“怎么设计数据模型”你至少要有能力指出谁是事实表、谁是维度表、关联字段是什么。这一题答好了能拉开很大差距。2.2 Import模式与DirectQuery模式笔试最爱问的“二选一”热搜词里有一条非常具体“power bi 如何连接mysql导入和directquery区别”这说明很多人在这个点上卡过。笔试里Power BI的题目十有八九会涉及到这两种连接模式的区别。Import模式也就是导入模式把数据源的数据加载到Power BI的内存中。优点是查询性能快可以做复杂的数据转换和DAX计算缺点是数据不是实时的需要手动或定时刷新。适合数据量不大比如几百万行以内、实时性要求不高的场景。DirectQuery模式直连模式Power BI不缓存数据每次交互都直接向数据源发送查询。优点是数据实时缺点是性能受数据源影响大而且很多数据转换功能会被限制。适合数据量极大、实时性要求高、或者不想维护数据副本的场景。笔试和实际工作中我的建议很简单能用Import就用Import只有当数据量实在太大或者业务明确要求实时数据时才用DirectQuery。原因有三条Import模式对前端用户更友好交互流畅DAX函数支持更完整不会因为底层数据库压力导致报表打不开。如果笔试问你“用MySQL数据源做报表你会选哪种模式”你可以回答“默认Import因为报表数据一般按天刷新就够了而且性能稳定。如果业务方要求看到当日实时数据再评估DirectQuery但要做好索引优化和查询限流。”2.3 从Power BI到FineBI国产工具的笔试存在感很多准备笔试的同学只看Power BI忽略了国内企业包括搜狐畅游这类公司常用的国产BI工具。“帆软bi考试”这个热搜词说明FineBI在求职中也是一个高频话题。帆软的FineBI和FineReport在国产BI市场占有率很高尤其在国内企业的报表开发场景里。FineBI主打自助分析类似Power BIFineReport主打固定格式报表填报和展示类似你用代码去写中国式复杂报表。校招笔试里如果涉及国产BI更多是问“你了解哪些BI工具”“它们有什么异同”。你可以这样回答“我主要用Power BI做自助分析也了解FineBI。FinBI和Power BI的核心思路都是数据建模可视化分析但FineBI在类Excel操作习惯和中国式复杂报表支持上更贴近国内企业需求部署方式上也更适合内网私有化。Power BI在DAX函数丰富度、微软生态集成和社区资源上更成熟。”这个回答体现出“我不是只会一个工具”同时给面试官留下了“你有工具横向对比能力”的印象。3. 数据库连接与SQLBI笔试绕不开的硬活3.1 MySQL连接那些容易翻车的细节题库里“power bi 如何连接mysql”这种检索热度一直很高说明大家在连数据库时踩过不少坑。笔试不会真让你现场去连数据库但面试官很可能在面试环节追问“你说你会连接MySQL那具体是怎么连的遇到过什么问题”流程上用Power BI连接MySQL分三步。第一步安装MySQL Connector/Net驱动这是微软官方文档里明确要求的第二步在Power BI Desktop里选择“获取数据 → MySQL数据库”输入服务器地址和数据库名第三步填写用户名密码也可以选择“高级选项”里填写SQL语句来直接指定查询。最容易出问题的地方有两个。一个是驱动版本和Power BI位数不一致比如64位的Power BI配了32位的驱动连接时直接报错另一个是MySQL服务器不允许远程访问或者防火墙没开3306端口。笔试或面试中如果要体现你的实操经验可以补一句“我在连接时发现如果表特别大最好不要在Power BI里直接整表导入而是先用SQL把数据聚合好再拉取既减轻内存压力也让模型更简洁。”这句话一出来面试官就知道你真的连过。3.2 SQL笔试JOIN、聚合、窗口函数是三大主轴BI工程师的SQL考察不会像后端开发那么深但必须熟练。笔试里常见的题型集中在三块多表关联查询、分组聚合统计、窗口函数做排名和对比计算。举个典型题目有两张表user_info表user_id, reg_date, channel和user_login表user_id, login_date。问“计算2024年1月各渠道新增用户数以及这些用户在1月内的活跃用户数”。基础写法是先JOIN两张表再用GROUP BY按渠道分组聚合。第一步统计新增用户数通过user_info的reg_date过滤第二步判断是否活跃需要关联user_login表中1月内的login_date用COUNT(DISTINCT ...去重。如果要问“每个渠道新增用户在注册后第7天是否活跃”就要用DATEDIFF来计算和比较日期。这类题目考察的其实就是日常取数的基本功能不能把业务需求翻译成准确的JOIN和WHERE条件。窗口函数也是重点。ROW_NUMBER()用来给用户分组排名LAG()用来比较上一周期值SUM() OVER(PARTITION BY ...用来做累计计算。笔试的时候如果能在SQL题里顺手用上窗口函数给出一个更优雅的解能给阅卷人留下很好的印象。3.3 数据清洗与建模笔试后大概率出现的加试题有的公司笔试会直接让你处理一份脏数据并搭一个简单的模型。搜狐畅游这类大厂校招通常会有线上编程题和简答题的组合数据清洗能力是隐性考点。数据清洗的核心操作包括去重、缺失值处理、异常值过滤、统一格式、字段拆分。用Power Query做这些操作时要注意每一步操作都会被记录成M语言所以你不用背语法但要理解操作逻辑。用SQL做清洗时关键是掌握NULL处理和字符串函数。建模方面笔试不会要求你训练机器学习模型但会考察你能否设计一个合理的表结构。比如给你一份游戏付费明细让你“设计一张报表所需的宽表”你要能想到包含用户维度、时间维度、渠道维度、付费金额、付费次数等核心字段并且处理好“一人多订单”的粒度问题。4. 经营分析思维题能不能进复试的那道坎4.1 经营分析报表不是“流水账”是“决策工具”“经营分析报表(bi)”这个热搜词指向的正是BI工程师最有含金量的工作内容。很多同学以为经营分析就是把每日流水、新增用户、DAU堆在一张表上每月底发出去就算交差。实际上真正能辅助决策的经营分析报表核心在“对比”和“归因”。对比包括同比、环比、目标达成率、渠道对比、版本对比。归因则是在指标波动时用维度下钻的方式定位问题来源。笔试中如果给出一个经营分析场景比如“某游戏的付费收入连续两周下滑你怎么用BI报表定位问题”你要有清晰的拆解思路。首先是确认数据口径是否变化看看是不是埋点或统计代码出问题然后是整体趋势拆解把收入拆成付费用户数乘以ARPPU接着是维度拆解从渠道、玩家类型、版本、活动等多个维度看哪一层掉了最后是结合业务动作判断原因比如最近有没有调概率、有没有大R流失。这样的答题逻辑无论用什么工具都成立。工具只是呈现手段思维才是BI工程师真正的核心能力。4.2 游戏核心指标体系DAU、ARPU、LTV的连环考游戏行业的经营分析指标体系和电商有明显差异。笔试中高频出现的指标包括DAU/WAU/MAU衡量用户规模新增用户数和新增渠道质量衡量拉新效果次日留存、7日留存、30日留存衡量产品粘性付费率、ARPU、ARPPU衡量变现效率LTV和CAC衡量用户生命周期价值和获客成本。这里要特别说一下ARPU和ARPPU的区别笔试里非常容易混淆。ARPU是平均每活跃用户收入计算方式是总收入除以活跃用户数包含未付费用户ARPPU是平均每付费用户收入计算方式是总收入除以付费用户数只包含付费用户。两者分子相同分母不同。如果题目问“优化付费”时通常关注的是ARPPU和付费率如果问“整体收入健康度”时ARPU更有参考意义。LTV用户生命周期价值可以拆成“平均生命周期天数 × 平均每日付费金额”来估算也可以按“ARPU × 生命周期系数”粗算。面试中问“怎么评估一个渠道的用户质量”标准答案就是对比不同渠道的LTV和CAC如果LTV大于CAC说明渠道可以持续投放。4.3 用BI看板落地分析场景从业务问题到可视化笔试里偶尔会有一道“设计方案题”比如“如果你要做一个游戏运营日报看板你会包含哪些模块和图表”。这道题考的是你能否把前面提到的指标体系落成可交付的BI产品。我的回答框架一般是四层。第一层是核心KPI总览今日DAU、新增用户、付费收入、付费率用卡片图展示旁边配一个趋势折线图第二层是留存与漏斗分析新增用户7日留存趋势注册到创角的漏斗第三层是渠道分析各渠道新增量、次日留存、LTV/CAC用表格或气泡图展示第四层是异常预警核心指标周同比波动超过阈值时自动标红。这个框架的好处是既有“看数”功能又有“分析”功能还有“预警”功能。笔试时能把这个框架讲清楚比只说“我做了几个柱状图饼图”高出一个层次。5. 校招笔试的实战策略与避坑清单5.1 60-90分钟笔试怎么分配时间最稳校招笔试时间通常有限题型很可能包括客观题、SQL题和业务场景题。我的经验是先花2分钟通读全卷按分数占比和时间占比的比值决定做题优先级。如果SQL题占40分业务题占40分客观题占20分那么时间分配应大体对应“SQL题占40%-45%业务题占35%-40%客观题占15%-20%”。不要在一道SQL题上死磕超过15分钟。遇到卡壳先写能确定的部分比如已经明确的SELECT和FROM结构留在那里把其他题做完再回头补。阅卷通常按步骤给分空白才是最大的失分项。业务场景题建议先列框架再展开不要密密麻麻写一大段。用“问题拆解→数据口径确认→维度下钻→结论与建议”四段式既清晰又有条理。5.2 容易丢分的三个细节第一个细节指标口径不写清楚。比如算留存率时分子是“注册第N天登录用户数”分母是“第N天前注册用户数”不同口径结果天差地别。答题时主动写明“我这里的次日留存定义为注册后第二天有登录行为的用户占当日新增用户的比例”会显得非常专业。第二个细节SQL里没用去重。很多题目的明细表同一用户可能有多条记录不做COUNT(DISTINCT)会导致结果翻倍。笔试环境里一般没有太多测试数据纯靠逻辑判断去重意识尤其重要。第三个细节忽略异常值和极端值。比如在算ARPU时如果有用户单日充值100万平均值会被拉得很高这时候要考虑用中位数或剔除Top1%再做分析。在业务题里主动提出这一点很加分。5.3 笔试之后的准备一份作品集比证书更打动面试官笔试只是第一关紧接着的技术面和业务面才是重头戏。我强烈建议你在笔试通过后花一到两周做一份“游戏用户留存分析”的Power BI作品集哪怕只是用模拟数据。具体做法是用Python或Excel生成一份模拟游戏用户数据包含注册日期、渠道、活跃日期、付费金额等字段然后导入Power BI Desktop做数据清洗和建模再做留存分析、付费分析、渠道对比三张报表最后录一段6-8分钟的Demo讲解视频。这份作品集的价值在于它一次性证明了你的四类能力数据获取和处理能力、数据建模能力、可视化表达能力以及游戏业务理解能力。面试官看到你能独立完成从数据到结论的闭环远比你说“我考过某某证书”有说服力。我之前见过一个候选人学历背景很普通但拿着一份用FineBI做的游戏渠道分析看板来面试他从数据口径定义讲到渠道调优建议讲了15分钟面试官全程没有打断。最后他顺利拿到了Offer。笔试决定你能否进门作品集决定面试官愿不愿意为你争取名额。5.4 关于笔试复习顺序的最后建议如果你现在才开始准备时间有限建议按这个优先级复习先刷SQL基础题和窗口函数题这是性价比最高的部分再花一天搞懂Power BI的Import和DirectQuery区别以及基本的DAX度量值写法然后看两篇游戏行业指标体系的文章把DAU、留存率、ARPU、ARPPU、LTV这些概念的口径背熟最后找一套业务场景题练习“从问题到指标到报表”的拆解思路。至于帆软FineBI和Power BI的选择不用焦虑。校招笔试不要求你对工具达到“专家级”只要证明你有快速上手的能力并且对核心概念有正确理解就足够了。工具会更新换代底层的数据思维和分析框架才是真正能沉淀下来的东西。我在准备这份笔试时最大的感受是BI工程师的考察范围看起来庞杂但归根结底就两条线——一条是数据加工线从数据库到数据模型到可视化另一条是业务分析线从业务问题到指标体系到决策建议。把这两条线打通无论笔试题目变成什么样你都能找到应对的抓手。
看到“搜狐畅游2020校招笔试 - BI工程师”这个标题估计不少准备投数据分析方向的同学都会愣一下游戏公司也招BI进去是写报表还是做数仓说实话我当年收到笔试通知时也是这样一脸懵。后来真正做完笔试、走完面试又在这个方向干了几年回头看才发现游戏行业恰恰是BI工程师最能体现价值的地方——数据量够大、业务链路够长、决策诉求够急一个合格的BI工程师在这里不是“做图表的”而是实打实的经营分析支撑角色。这篇文章就把我围绕这次校招笔试做的准备、踩过的坑、以及后来在工作中验证过的重点完整梳理一遍。不管你目标是搜狐畅游这种游戏厂商还是其他公司的BI岗位只要笔试考察范围里出现了Power BI、SQL、经营分析报表这些关键词这篇内容都能帮你建立一个相对完整的备考框架。1. 游戏公司里的BI工程师到底在做什么1.1 从岗位名字看真实职责不是“做报表的”很多人对BI工程师的第一印象是“用工具画Dashboard”这个认知不能说错但太片面了。尤其在校招笔试里面试官不会只考你工具操作他们更想确认你有没有“通过数据支撑业务决策”的思维。在游戏公司BI工程师的日常工作大概分四块。第一块是数据仓库建设游戏业务埋点数据多、渠道数据杂需要你梳理清楚底层表结构产出统一的指标口径第二块是报表开发把运营、市场、策划关心的数据做成固定报表或自助分析看板第三块是专项分析比如版本更新后留存为什么波动、某个渠道买量质量为什么下降第四块是数据产品规划推动公司从“人肉取数”走向“自助分析”。笔试题目一般不会直接让你写一段数仓代码但会通过业务场景题考察你是否理解这些工作之间的逻辑关系。比如问你“某游戏新版本上线后次日留存下滑5个百分点如何分析”表面上是个分析题实际上考的是你懂不懂埋点数据、懂不懂留存口径、能不能用BI工具把问题定位出来。1.2 游戏业务的数据链路从埋点到经营看板游戏行业的数据链路相比电商和金融稍微特殊一点。核心链路是客户端/服务端埋点 → 日志上报 → 数据清洗 → 数仓分层 → 指标计算 → 报表/看板展示。笔试时如果给你一张用户行为表、一张付费表让你计算付费率或者LTV你得清楚这些表在真实场景中是怎么产生的。比如“付费”这件事游戏里可能包含首充、续充、活动充值不同业务口径算出来的付费率差距很大。BI工程师最大的价值往往不是SQL写得有多花哨而是能把口径定义清楚。我当时笔试准备时专门梳理了游戏行业的核心指标框架用户规模类DAU/WAU/MAU/新增用户、留存类次日留存/7日留存/30日留存、付费类付费率/ARPU/ARPPU/LTV、渠道类CAC/LTV/CAC比值。后来证明这个框架非常有用。笔试里很多题目表面上在问工具、问SQL实际上底层都是这些指标的计算逻辑。1.3 BI工程师和数据分析师的分工边界笔试或者面试里经常会被问到“BI工程师和数据分析师有什么区别”。这个问题没有标准答案但你要能说出自己的理解。我的理解是BI工程师更偏向数据基建设施和报表体系的搭建核心是“让数据可以被稳定、高效地消费”数据分析师更偏向具体业务问题的探索和策略输出核心是“从数据中发现问题和机会”。两者有重叠但在团队协作中侧重点不同。畅游这类游戏公司往往会有数据组、运营组、市场组协作的格局。BI工程师要和运营同学反复确认指标口径要和数仓同学沟通取数逻辑还要把业务方的需求翻译成技术方案。这种跨角色沟通能力笔试考不出来但会反映在你对业务场景题的理解深度上。答业务题时能体现出“我懂业务方到底想要什么”很加分。2. 笔试重灾区Power BI的三大高频考点2.1 Power BI Desktop的建模逻辑先把表和表之间的关系想清楚“power bi”和“bi学习”在热搜词里长期霸榜确实这是BI工程师笔试面试绕不开的工具。Power BI Desktop是微软推出的自助式BI工具笔试中关于它的题目通常集中在数据建模、DAX、可视化三个层面。很多新手容易忽略“建模”这一步拿到数据就开始拖图表结果做出来的报表不但算得慢指标口径还有问题。正确的做法是先理清事实表和维度表的关系再建度量值最后才做可视化。举个游戏业务的例子。假设你要分析“各渠道新增用户的7日留存”那么你的模型中通常有一张用户注册表维度渠道、注册日期、设备一张用户活跃表事实用户ID、活跃日期、在线时长一张渠道维度表渠道ID、渠道名称。把用户注册表按用户ID关联活跃表再把渠道ID关联渠道维度表就能建出一个星型模型然后写一个“7日留存”的度量值后续不管怎么切片结果都不会乱。笔试中如果给你几个表问你“怎么设计数据模型”你至少要有能力指出谁是事实表、谁是维度表、关联字段是什么。这一题答好了能拉开很大差距。2.2 Import模式与DirectQuery模式笔试最爱问的“二选一”热搜词里有一条非常具体“power bi 如何连接mysql导入和directquery区别”这说明很多人在这个点上卡过。笔试里Power BI的题目十有八九会涉及到这两种连接模式的区别。Import模式也就是导入模式把数据源的数据加载到Power BI的内存中。优点是查询性能快可以做复杂的数据转换和DAX计算缺点是数据不是实时的需要手动或定时刷新。适合数据量不大比如几百万行以内、实时性要求不高的场景。DirectQuery模式直连模式Power BI不缓存数据每次交互都直接向数据源发送查询。优点是数据实时缺点是性能受数据源影响大而且很多数据转换功能会被限制。适合数据量极大、实时性要求高、或者不想维护数据副本的场景。笔试和实际工作中我的建议很简单能用Import就用Import只有当数据量实在太大或者业务明确要求实时数据时才用DirectQuery。原因有三条Import模式对前端用户更友好交互流畅DAX函数支持更完整不会因为底层数据库压力导致报表打不开。如果笔试问你“用MySQL数据源做报表你会选哪种模式”你可以回答“默认Import因为报表数据一般按天刷新就够了而且性能稳定。如果业务方要求看到当日实时数据再评估DirectQuery但要做好索引优化和查询限流。”2.3 从Power BI到FineBI国产工具的笔试存在感很多准备笔试的同学只看Power BI忽略了国内企业包括搜狐畅游这类公司常用的国产BI工具。“帆软bi考试”这个热搜词说明FineBI在求职中也是一个高频话题。帆软的FineBI和FineReport在国产BI市场占有率很高尤其在国内企业的报表开发场景里。FineBI主打自助分析类似Power BIFineReport主打固定格式报表填报和展示类似你用代码去写中国式复杂报表。校招笔试里如果涉及国产BI更多是问“你了解哪些BI工具”“它们有什么异同”。你可以这样回答“我主要用Power BI做自助分析也了解FineBI。FinBI和Power BI的核心思路都是数据建模可视化分析但FineBI在类Excel操作习惯和中国式复杂报表支持上更贴近国内企业需求部署方式上也更适合内网私有化。Power BI在DAX函数丰富度、微软生态集成和社区资源上更成熟。”这个回答体现出“我不是只会一个工具”同时给面试官留下了“你有工具横向对比能力”的印象。3. 数据库连接与SQLBI笔试绕不开的硬活3.1 MySQL连接那些容易翻车的细节题库里“power bi 如何连接mysql”这种检索热度一直很高说明大家在连数据库时踩过不少坑。笔试不会真让你现场去连数据库但面试官很可能在面试环节追问“你说你会连接MySQL那具体是怎么连的遇到过什么问题”流程上用Power BI连接MySQL分三步。第一步安装MySQL Connector/Net驱动这是微软官方文档里明确要求的第二步在Power BI Desktop里选择“获取数据 → MySQL数据库”输入服务器地址和数据库名第三步填写用户名密码也可以选择“高级选项”里填写SQL语句来直接指定查询。最容易出问题的地方有两个。一个是驱动版本和Power BI位数不一致比如64位的Power BI配了32位的驱动连接时直接报错另一个是MySQL服务器不允许远程访问或者防火墙没开3306端口。笔试或面试中如果要体现你的实操经验可以补一句“我在连接时发现如果表特别大最好不要在Power BI里直接整表导入而是先用SQL把数据聚合好再拉取既减轻内存压力也让模型更简洁。”这句话一出来面试官就知道你真的连过。3.2 SQL笔试JOIN、聚合、窗口函数是三大主轴BI工程师的SQL考察不会像后端开发那么深但必须熟练。笔试里常见的题型集中在三块多表关联查询、分组聚合统计、窗口函数做排名和对比计算。举个典型题目有两张表user_info表user_id, reg_date, channel和user_login表user_id, login_date。问“计算2024年1月各渠道新增用户数以及这些用户在1月内的活跃用户数”。基础写法是先JOIN两张表再用GROUP BY按渠道分组聚合。第一步统计新增用户数通过user_info的reg_date过滤第二步判断是否活跃需要关联user_login表中1月内的login_date用COUNT(DISTINCT ...去重。如果要问“每个渠道新增用户在注册后第7天是否活跃”就要用DATEDIFF来计算和比较日期。这类题目考察的其实就是日常取数的基本功能不能把业务需求翻译成准确的JOIN和WHERE条件。窗口函数也是重点。ROW_NUMBER()用来给用户分组排名LAG()用来比较上一周期值SUM() OVER(PARTITION BY ...用来做累计计算。笔试的时候如果能在SQL题里顺手用上窗口函数给出一个更优雅的解能给阅卷人留下很好的印象。3.3 数据清洗与建模笔试后大概率出现的加试题有的公司笔试会直接让你处理一份脏数据并搭一个简单的模型。搜狐畅游这类大厂校招通常会有线上编程题和简答题的组合数据清洗能力是隐性考点。数据清洗的核心操作包括去重、缺失值处理、异常值过滤、统一格式、字段拆分。用Power Query做这些操作时要注意每一步操作都会被记录成M语言所以你不用背语法但要理解操作逻辑。用SQL做清洗时关键是掌握NULL处理和字符串函数。建模方面笔试不会要求你训练机器学习模型但会考察你能否设计一个合理的表结构。比如给你一份游戏付费明细让你“设计一张报表所需的宽表”你要能想到包含用户维度、时间维度、渠道维度、付费金额、付费次数等核心字段并且处理好“一人多订单”的粒度问题。4. 经营分析思维题能不能进复试的那道坎4.1 经营分析报表不是“流水账”是“决策工具”“经营分析报表(bi)”这个热搜词指向的正是BI工程师最有含金量的工作内容。很多同学以为经营分析就是把每日流水、新增用户、DAU堆在一张表上每月底发出去就算交差。实际上真正能辅助决策的经营分析报表核心在“对比”和“归因”。对比包括同比、环比、目标达成率、渠道对比、版本对比。归因则是在指标波动时用维度下钻的方式定位问题来源。笔试中如果给出一个经营分析场景比如“某游戏的付费收入连续两周下滑你怎么用BI报表定位问题”你要有清晰的拆解思路。首先是确认数据口径是否变化看看是不是埋点或统计代码出问题然后是整体趋势拆解把收入拆成付费用户数乘以ARPPU接着是维度拆解从渠道、玩家类型、版本、活动等多个维度看哪一层掉了最后是结合业务动作判断原因比如最近有没有调概率、有没有大R流失。这样的答题逻辑无论用什么工具都成立。工具只是呈现手段思维才是BI工程师真正的核心能力。4.2 游戏核心指标体系DAU、ARPU、LTV的连环考游戏行业的经营分析指标体系和电商有明显差异。笔试中高频出现的指标包括DAU/WAU/MAU衡量用户规模新增用户数和新增渠道质量衡量拉新效果次日留存、7日留存、30日留存衡量产品粘性付费率、ARPU、ARPPU衡量变现效率LTV和CAC衡量用户生命周期价值和获客成本。这里要特别说一下ARPU和ARPPU的区别笔试里非常容易混淆。ARPU是平均每活跃用户收入计算方式是总收入除以活跃用户数包含未付费用户ARPPU是平均每付费用户收入计算方式是总收入除以付费用户数只包含付费用户。两者分子相同分母不同。如果题目问“优化付费”时通常关注的是ARPPU和付费率如果问“整体收入健康度”时ARPU更有参考意义。LTV用户生命周期价值可以拆成“平均生命周期天数 × 平均每日付费金额”来估算也可以按“ARPU × 生命周期系数”粗算。面试中问“怎么评估一个渠道的用户质量”标准答案就是对比不同渠道的LTV和CAC如果LTV大于CAC说明渠道可以持续投放。4.3 用BI看板落地分析场景从业务问题到可视化笔试里偶尔会有一道“设计方案题”比如“如果你要做一个游戏运营日报看板你会包含哪些模块和图表”。这道题考的是你能否把前面提到的指标体系落成可交付的BI产品。我的回答框架一般是四层。第一层是核心KPI总览今日DAU、新增用户、付费收入、付费率用卡片图展示旁边配一个趋势折线图第二层是留存与漏斗分析新增用户7日留存趋势注册到创角的漏斗第三层是渠道分析各渠道新增量、次日留存、LTV/CAC用表格或气泡图展示第四层是异常预警核心指标周同比波动超过阈值时自动标红。这个框架的好处是既有“看数”功能又有“分析”功能还有“预警”功能。笔试时能把这个框架讲清楚比只说“我做了几个柱状图饼图”高出一个层次。5. 校招笔试的实战策略与避坑清单5.1 60-90分钟笔试怎么分配时间最稳校招笔试时间通常有限题型很可能包括客观题、SQL题和业务场景题。我的经验是先花2分钟通读全卷按分数占比和时间占比的比值决定做题优先级。如果SQL题占40分业务题占40分客观题占20分那么时间分配应大体对应“SQL题占40%-45%业务题占35%-40%客观题占15%-20%”。不要在一道SQL题上死磕超过15分钟。遇到卡壳先写能确定的部分比如已经明确的SELECT和FROM结构留在那里把其他题做完再回头补。阅卷通常按步骤给分空白才是最大的失分项。业务场景题建议先列框架再展开不要密密麻麻写一大段。用“问题拆解→数据口径确认→维度下钻→结论与建议”四段式既清晰又有条理。5.2 容易丢分的三个细节第一个细节指标口径不写清楚。比如算留存率时分子是“注册第N天登录用户数”分母是“第N天前注册用户数”不同口径结果天差地别。答题时主动写明“我这里的次日留存定义为注册后第二天有登录行为的用户占当日新增用户的比例”会显得非常专业。第二个细节SQL里没用去重。很多题目的明细表同一用户可能有多条记录不做COUNT(DISTINCT)会导致结果翻倍。笔试环境里一般没有太多测试数据纯靠逻辑判断去重意识尤其重要。第三个细节忽略异常值和极端值。比如在算ARPU时如果有用户单日充值100万平均值会被拉得很高这时候要考虑用中位数或剔除Top1%再做分析。在业务题里主动提出这一点很加分。5.3 笔试之后的准备一份作品集比证书更打动面试官笔试只是第一关紧接着的技术面和业务面才是重头戏。我强烈建议你在笔试通过后花一到两周做一份“游戏用户留存分析”的Power BI作品集哪怕只是用模拟数据。具体做法是用Python或Excel生成一份模拟游戏用户数据包含注册日期、渠道、活跃日期、付费金额等字段然后导入Power BI Desktop做数据清洗和建模再做留存分析、付费分析、渠道对比三张报表最后录一段6-8分钟的Demo讲解视频。这份作品集的价值在于它一次性证明了你的四类能力数据获取和处理能力、数据建模能力、可视化表达能力以及游戏业务理解能力。面试官看到你能独立完成从数据到结论的闭环远比你说“我考过某某证书”有说服力。我之前见过一个候选人学历背景很普通但拿着一份用FineBI做的游戏渠道分析看板来面试他从数据口径定义讲到渠道调优建议讲了15分钟面试官全程没有打断。最后他顺利拿到了Offer。笔试决定你能否进门作品集决定面试官愿不愿意为你争取名额。5.4 关于笔试复习顺序的最后建议如果你现在才开始准备时间有限建议按这个优先级复习先刷SQL基础题和窗口函数题这是性价比最高的部分再花一天搞懂Power BI的Import和DirectQuery区别以及基本的DAX度量值写法然后看两篇游戏行业指标体系的文章把DAU、留存率、ARPU、ARPPU、LTV这些概念的口径背熟最后找一套业务场景题练习“从问题到指标到报表”的拆解思路。至于帆软FineBI和Power BI的选择不用焦虑。校招笔试不要求你对工具达到“专家级”只要证明你有快速上手的能力并且对核心概念有正确理解就足够了。工具会更新换代底层的数据思维和分析框架才是真正能沉淀下来的东西。我在准备这份笔试时最大的感受是BI工程师的考察范围看起来庞杂但归根结底就两条线——一条是数据加工线从数据库到数据模型到可视化另一条是业务分析线从业务问题到指标体系到决策建议。把这两条线打通无论笔试题目变成什么样你都能找到应对的抓手。
