2023年腾讯音乐春招数据分析岗第一批笔试我应该算是赶上了全程。那天打开牛客网笔试链接的那一刻说实话心里是有点没底的毕竟音乐类产品的数据分析岗既考通用技能也考对业务的敏感度。整套题做下来最大的感受是它不像学校里那种“背熟公式就能过”的考试更像是在模拟你入职之后第一周可能会遇到的真实工作场景。题量大、时间紧、细节多如果你只刷过SQL题没练过业务分析框架大概率会在后半段手忙脚乱。这篇文章我就完整复盘一下这次笔试的题型构成、核心考点、典型题目和解法再把我踩过的坑和后来想明白的道理一并写出来。无论是准备互联网数据分析岗春招秋招还是想了解音乐行业数据分析到底是干嘛的这篇内容都能给你一个比较真实的参照。1. 笔试整体结构与考察逻辑拆解1.1 2023年腾讯音乐春招笔试的基本情况先说一下这场笔试的基本盘。线上笔试双机位监控总时长120分钟满分100分。题目分四个模块单选题、SQL编程题、Python编程题、业务案例分析题。单选大概10道每题1分剩下的分数大头全在编程和业务题上。整套试卷的难度梯度是有的单选属于“你复习过就能拿分”SQL属于“大部分候选人能做出一半”Python属于“能跑通比写漂亮重要”业务分析则完全拉开差距。和很多大厂笔试的题量相比腾讯音乐这批题不算极端但时间依然紧张。我自己的时间分配是这样单选花了15分钟SQL两道题花了45分钟Python花了25分钟业务案例花了30分钟最后剩下5分钟检查。这基本是个比较合理的时间预算如果你在SQL上卡太久后面的业务题就会很被动。1.2 为什么笔试要这样设计我后来复盘的时候发现这个笔试结构其实很精准地对应了数据分析师日常工作的几个核心动作。单选考的是统计学基础、业务指标理解、常见陷阱辨别这对应的是你拿到数据后能不能做出正确判断SQL考的是取数能力这是数据分析师最底层的技能不会SQL基本等于不会干活Python考的是数据处理和简单建模能力对应的是自动化处理、数据清洗和探索性分析这些日常任务业务案例分析题则是在模拟你面对一个业务问题时能不能拆解问题、搭建分析框架、给出可落地的建议。说白了这套题的设计逻辑不是要你背出某个算法公式而是要证明你有能力在真实工作环境里“用数据解决业务问题”。这个思路贯穿了整场考试也是我后面要重点展开的地方。2. 核心考点深度解析与答题思路2.1 SQL题不是会写就完事关键是口径SQL题是整场笔试的重头戏也是很多人的分水岭。腾讯音乐的SQL题主要围绕音乐产品数据展开比如用户播放记录表、付费流水表、歌曲信息表、歌手信息表等。题目类型包括每日活跃用户数统计、连续播放天数计算、留存率计算、用户付费金额分层、歌曲热度排行等。这里我想特别强调一个东西口径。同样是“活跃用户数”是按用户ID去重还是按设备ID去重是当日有播放行为就算活跃还是需要播放时长超过30秒题目里有时候会给定义有时候不会给这时候你必须在答案里写清楚自己用的口径。我见过很多人在笔试里栽跟头不是因为SQL写不出来而是因为口径没说明白结果阅卷人根本不知道你统计的是什么。举个例子如果题目让你统计“2023年2月每日活跃用户数”你需要先明确“活跃用户”的定义。如果题目没给最稳妥的做法是使用用户ID去重并且在答案注释里写一句“假设活跃用户定义为当日至少有一次有效播放行为的去重用户ID”。这样即使和标准答案不完全一致阅卷人也能看出你有商业分析意识。2.2 统计学与AB测试别让假设检验成为送分题单选和业务题里都涉及统计学知识集中在描述性统计、概率计算、假设检验、置信区间、AB测试这几块。说实话这块内容只要你在大学概率论课上没完全睡着基本都能答对但有几个地方特别容易出错。第一个是p值的含义。很多人把它理解成“原假设为真的概率”这是不对的。p值是在原假设成立的前提下观察到当前样本或更极端样本的概率。这个区别在单选题里经常以“下列说法正确的是”的形式出现稍有含糊就会被绕进去。第二个是置信区间的解释。95%置信区间的正确说法是“重复抽样100次大约有95次的置信区间会包含真实参数”而不是“真实参数有95%的概率落在该区间内”。这类题目考察的是对基础概念的准确理解而不是计算能力。AB测试部分会考察样本量计算、显著性水平、统计功效、实验分组方法等。比如给你一个基线转化率、最小检测效应和显著性水平让你估算每组需要的样本量。这个问题如果你只是硬背公式很容易忘记考虑双尾检验和方差的计算。建议在复习时把AB测试的完整流程走一遍从假设设定、样本量计算、实验运行时长确定到结果分析和陷阱识别每一步都要能说出来为什么。2.3 综合业务题数据分析的核心是回答业务问题业务案例分析题是整场笔试里最有区分度的一部分也最考验一个人的数据思维。腾讯音乐的这道题通常会给一个业务场景比如“Q音某月的播放量出现了明显下降请分析可能原因”或者“付费会员的转化率低于行业平均水平请设计分析方案”。这种题的回答最怕的就是直接写几个零散的原因比如“内容不好”“竞品冲击”“用户流失”。这些答案太泛了没有任何数据分析的价值。比较正确的做法是按“指标拆解-数据验证-落地建议”的结构来组织答案。以“播放量下降”为例首先要拆解播放量这个指标它等于活跃用户数乘以人均播放次数。如果是活跃用户数下降需要进一步看新增用户、留存用户、回流用户分别的变化如果是人均播放次数下降需要看用户的使用时长、使用频次、内容消费结构的变化。每个分支都要配上可行性的数据验证方法比如用DAU趋势图确认下降的时间点用新增用户同期对比排除季节性因素用分城市/分年龄层的拆解定位下降的重点人群。这种结构化表达不是天生就会的需要平时多做业务分析案例的练习。我当时在准备时刷了很多数据分析项目案例尤其是那种强调分析框架的比如“如何分析用户流失”、“如何评估一场运营活动的效果”这些题目虽然不是原题但分析思路是通用的。2.4 Python与数据分析工具能跑通比技巧重要Python题考察的内容相对基础主要是用pandas做数据清洗和数据处理用matplotlib或seaborn做可视化偶尔会有一道简单的统计学计算或机器学习模型调用题。重点考察的是你能不能在没有IDE提示的环境里凭记忆写出正确的代码。数据清洗这块是重头戏。题目一般会给你一个包含缺失值、重复值、异常值的CSV文件让你完成清洗后输出统计结果。最稳的做法是先读入数据然后用info()和describe()快速了解数据概况再依次处理缺失值、去除重复值、处理异常值。缺失值处理要看场景数值型特征可以用均值或中位数填充分类型特征可以用众数填充如果缺失比例过高可以直接删除该列。关键是每一步都要说明理由代码注释里写清楚“因为XX原因选择中位数填充”这样即使结果有偏差也能体现思考过程。可视化题目通常会要求你画出某个指标的分布或趋势并做简单解读。这时候要注意图的类型选择、轴标签、标题这些细节。我自己在笔试时吃过一次亏程序本身没问题但因为没加标题和轴标签被扣了分细节问题确实容易被忽略。3. 典型真题复盘与解题过程实录3.1 题目一音乐播放数据清洗与活跃用户统计这道题是一道Python编程题给了一个歌曲播放记录的CSV包含字段user_id、song_id、play_time、duration_sec播放时长秒、city_id城市ID。要求完成两个任务一是清洗数据包括去重、处理缺失值二是统计2023年2月1日到2月7日的每日活跃用户数并可视化。这道题我是这样做的。先读数据、看结构import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(song_play_log.csv, parse_dates[play_time]) # 快速概览 print(df.info()) print(df.describe(includeall))然后做清洗。首先去重这里要小心不是把整行完全相同的删掉而是要考虑业务含义同一个人在同一秒播放同一首歌这种情况被视为重复是合理的但如果只是同一用户播放同一首歌两次播放时间不同那就不该删。# 严格重复去除 df df.drop_duplicates() # 同一用户同一时刻播放同一首歌视为重复 df df.drop_duplicates(subset[user_id, song_id, play_time], keepfirst) # 缺失值处理 df[duration_sec] df[duration_sec].fillna(df[duration_sec].median()) df[city_id] df[city_id].fillna(未知)写到这里我特别在注释里标明了选择中位数填充的原因duration_sec是右偏分布用均值容易被极端值拉偏中位数更稳健。笔试判分的时候这种注释很加分因为阅卷人能看到你不只是会调用函数而是明白背后的统计逻辑。接着统计每日活跃用户数并可视化df[play_date] df[play_time].dt.date daily_active df.groupby(play_date)[user_id].nunique().reset_index() daily_active.columns [play_date, active_users] daily_active.play_date pd.to_datetime(daily_active.play_date) daily_active daily_active[(daily_active.play_date 2023-02-01) (daily_active.play_date 2023-02-07)] plt.figure(figsize(10, 5)) plt.plot(daily_active.play_date, daily_active.active_users, markero) plt.title(Daily Active Users (2023-02-01 to 2023-02-07)) plt.xlabel(Date) plt.ylabel(Active Users) plt.grid(True) plt.show()这道题的核心踩分点有三个去重逻辑是否正确、缺失值处理是否合理、可视化是否完整清晰。注意nunique()而不是count()前者是去重后的用户数后者是记录数这两者区别很大如果搞混了整道题就废了。3.2 题目二付费用户留存率计算这道题是一道SQL题给了两张表用户注册表user_registeruser_id,register_date和付费记录表user_payuser_id,pay_date,pay_amount要求计算2023年1月新增注册用户在次日、3日、7日的付费留存率。留存率的计算口径必须写清楚。我的理解是次日付费留存率 1月注册用户中注册次日有过付费行为的用户数 / 1月注册用户总数。按照这个口径我写了下面这段SQLwith register_users as ( select user_id, register_date from user_register where register_date between 2023-01-01 and 2023-01-31 ), pay_users as ( select distinct user_id, pay_date from user_pay ) select count(distinct a.user_id) as total_new_users, count(distinct case when b.pay_date date_add(a.register_date, interval 1 day) then a.user_id end) as day1_pay_users, count(distinct case when b.pay_date date_add(a.register_date, interval 3 day) and b.pay_date a.register_date then a.user_id end) as day3_pay_users, count(distinct case when b.pay_date date_add(a.register_date, interval 7 day) and b.pay_date a.register_date then a.user_id end) as day7_pay_users, count(distinct case when b.pay_date date_add(a.register_date, interval 1 day) then a.user_id end) / count(distinct a.user_id) as day1_pay_retention, count(distinct case when b.pay_date date_add(a.register_date, interval 3 day) and b.pay_date a.register_date then a.user_id end) / count(distinct a.user_id) as day3_pay_retention, count(distinct case when b.pay_date date_add(a.register_date, interval 7 day) and b.pay_date a.register_date then a.user_id end) / count(distinct a.user_id) as day7_pay_retention from register_users a left join pay_users b on a.user_id b.user_id这里有几个细节要注意。3日留存和7日留存我使用的是“累计口径”即注册后3日内和7日内任意一天有付费行为就算留存而不是“第3天当天付费”。这个在题目没有明确说明的情况下我选择累计口径并在注释里做了说明因为它更符合业务上对留存的定义用户在头3天是否还有价值行为。另一个细节是pay_users表先做了distinct去重避免一个用户多笔付费记录导致重复计数。这段SQL如果在牛客网环境下运行要注意MySQL和Hive SQL在日期函数的写法差异如果题目提示了环境按照对应语法来。3.3 题目三音乐App核心指标异常排查业务分析题这道题可以说是整场笔试的压轴题。题干背景大致是某音乐App的会员开通量连续两周下滑第一周环比下降5%第二周环比下降8%需要分析原因并给出建议。这道题没有标准答案考察的就是你的分析框架。我的回答分三步走。第一步是确认事实。我会先列一个数据清单下滑是从哪一天开始的是自然周效应还是人为干预比如某天有版本发布或活动结束下滑是全面的还是某个渠道、某个城市、某个年龄段的没有这些事实所有分析都是空谈。第二步是拆解影响因素。会员开通量可以拆成流量 × 转化率。流量层面要看App的DAU有没有变化如果没有再看会员中心的访问量、开通页的曝光量、点击量有没有变化转化率层面要看从浏览到支付的转化漏斗每一层的变化情况。如果流量和转化率都没有显著变化那就要看支付环节有没有问题比如支付成功率、支付渠道故障等。第三步是结合业务场景提出假设。我会列几个常见假设暑期结束导致学生用户活跃下降竞品同期有大促活动导致用户分流最近一期VIP会员权益更新用户感知度下降支付渠道接口调整导致部分用户支付失败版本更新后会员入口位置调整导致曝光量下降。每个假设都要配上对应的数据分析方法比如检查入口曝光量、支付失败率、分渠道转化率等。最后给出建议比如如果是入口曝光下降可以恢复入口位置如果是支付失败率高需要联动技术团队排查支付通道如果是权益感知度下降可以针对流失用户推送会员权益提醒或做短期回归活动。这道题拿满分的难度很大但拿一个中高分的诀窍是结构清晰、假设完整、数据验证思路明确。我当时在回答里加了一句“以上分析需要先确认数据口径再输出结论”我觉得这句话是加分的因为它体现了一个数据人的职业习惯。4. 笔试中的常见问题与避坑经验4.1 时间控制SQL题很容易“一写就是半小时”这是我在笔试中面临的最大问题也是周围很多同学考完吐槽最多的地方。SQL看起来不难但真正手写起来各种细节会疯狂消耗时间。尤其是当你对某张表的字段记忆模糊时每写一步都要回去重新看题非常浪费时间。我的建议是先做业务案例分析题再做Python最后做SQL。因为SQL即使时间不够也能写出部分得分但业务题如果没时间写基本就等于白送掉一道大题的分数。如果你更擅长SQL顺序可以调整但一定要预留至少10分钟检查时间重点检查表名、字段名是否和题目一致join条件是否漏了字段日期函数是否写错是否考虑去重。4.2 环境问题在线IDE的隐形坑牛客网、赛码网这类平台的IDE和本地环境差别很大最大的坑是有些平台不支持某些第三方库比如seaborn在部分环境里没有预装或者pandas版本很低。我在准备阶段就吃过这个亏本地画图好好的切到在线IDE就报错。建议在笔试前一定要去目标平台熟悉一下它的代码环境。可以找一套模拟题实际跑一遍pandas和matplotlib的代码确认环境支持哪些库。如果题目要求可视化但平台不支持中文标签那就用英文标签不要硬写中文导致乱码。4.3 表达问题阅卷人想看到什么笔试题不是只有对错很多题是按点给分的。SQL题里你有没有注释说明口径Python题里你有没有写出清洗逻辑的理由业务题里你有没有分维度、分层级地拆解问题。这些都会影响你的得分。我个人的一个经验是在写代码答案时养成写注释的习惯哪怕是一两句话也要让阅卷人看懂你的思路。在业务题回答时多用“第一、第二、第三”或“先从XX维度切入再看XX指标”这样的结构化表达别写成一团乱麻。4.4 细节问题汇总这里列一下我整理出来的常见细节坑笔试前可以对照着过一遍问题类型典型错误正确做法字段名把play_time写成playtime严格看题目给的字段名别凭记忆手滑去重统计用户时用count()而不是count(distinct)想清楚是要记录数还是要人数日期日期字符串和日期类型比较统一转成日期类型后再比较留存口径把累计留存和当日留存混用说明清楚口径优先使用累计口径缺失值一律删除缺失值分情况处理删除、填充、单独分组可视化图片缺少标题和坐标轴标签完整性比美观更重要业务题只给原因不给验证方案每个原因都要配套可验证的数据方法5. 个人复盘与后续改进方向5.1 这次笔试让我想明白的事考完过了几天我复盘了整个笔试过程有几件特别想分享的事。第一基本功真的不能有死角。SQL里我有一道题把自己绕进去了因为太想写出“最优解”结果用了复杂的窗口函数反而在小数据集上逻辑出了差错。后来想想其实一个简单的group by加case when就能解决问题但在考场上就是容易想复杂。建议平时练习SQL时每道题先写一个最朴素、最容易验证的版本再考虑优化考试时能跑出正确答案比写得炫技重要得多。第二业务题拼的不是知识量而是结构感。我复习时看过很多“数据分析思维”之类的资料但真正到考场上最实用的还是那种“指标拆解-假设验证-落地建议”的三段式框架。你可以平时多训练自己拿到一个业务问题能不能在5分钟内画出指标树如果能笔试业务题就基本稳了。第三环境熟悉度非常影响心态。我第一道Python题在本地写过类似的但在线IDE的代码提示几乎为零导致需要记住所有函数名和参数写法这个对心理素质的要求还挺高的。建议提前把常用的pandas操作语料过一遍比如groupby、merge、pivot_table、fillna、drop_duplicates不能手生。5.2 给后续备考同学的建议如果你是准备投数据分析岗的同学我真诚建议你把复习重点放在三个方面SQL的窗口函数和留存计算、统计学的AB测试和显著性检验、业务分析的结构化表达。SQL这块把“连续N天登录”、“用户留存率”、“复购率”、“TopN问题”这四类问题刷熟基本上能覆盖大部分笔试。统计学这块能把假设检验的流程从头到尾推导一遍明白第一类和第二类错误的关系理解p值的真实含义而不是只会算z值和t值。业务分析这块多看看公开的面经和别人写的数据分析项目案例重点学习怎么把一个问题拆解成可执行的方案。另外有时间的话可以做两个完整的数据分析项目比如电商用户行为分析、内容产品留存分析从数据清洗、探索性分析、可视化到结论输出全流程走一遍。这类项目经历在你笔试和面试时都会派上用场因为面试官问到业务问题时你脑子里确实有画面感。最后再说一点。笔试只是整个求职环节里的一环它考的是你当下的知识储备和应变能力考得好不代表你是一个优秀的数据分析师考砸了也不代表你不是。我见过太多人因为一场笔试否定自己完全没必要。真正重要的是每一次笔试后你能从题目里看清自己缺什么然后花时间去补。数据分析这条路说到底拼的是长期积累而不是某一瞬间的爆发。