1. 笔试全景概览一次真实的“数据科学能力体检”2023年腾讯音乐秋招的数据科学岗第二批笔试我是在九月中旬做的。第一批的讨论帖刚过第二批试卷的题型分布和出题风格就出来了不少变化所以当时做完之后我在备忘录里记了不少复盘要点今天整理出来分享给正在准备校招的朋友。先说结论腾讯音乐数据科学岗的笔试不是那种“刷题就能过”的标准化考试。它更像一次“数据科学能力体检”考察的不是你背了多少个公式而是你在真实业务里能不能把数据问题拆清楚、算明白、讲出来。整体试卷的题量中等偏大选择题大约三十道主观题三道限时一百二十分钟。如果你对SQL窗口函数、概率推导、机器学习基础模型不够熟时间会非常紧张。我按记忆把这次笔试的板块分布整理成了下面这张表先让大家对全局有个直观印象题块题型题量主要考察内容数据分析基础单选/多选10题左右描述统计、概率、假设检验、业务指标异动分析数据库与SQL编程题2题窗口函数、留存/复购计算、多表关联与去重机器学习与算法单选/多选10题左右模型评估、过拟合处理、特征工程、常见算法原理Python编程编程题2题pandas数据处理、函数编写、循环与去重逻辑业务案例分析主观题3题指标拆解、策略评估、归因分析、AB实验设计这里要特别提醒一句2023年第二批笔试的主观题占比明显比第一批高。第一批还有不少“给口径、算指标”的送分题第二批基本全是开放性问题考的是数据思维和业务敏感度。如果你只会调用库、跑模型不会从业务目标倒推分析框架主观题会写得非常痛苦。关于推荐复习资料我个人的组合是《SQL必知必会》刷窗口函数章节、李航《统计学习方法》重点看逻辑回归和决策树、以及一份按“业务题高频解法”整理的笔记比如异动归因的经典三步法——确认口径、口径拆解、维度拆解。这套组合应付这场考试的覆盖面已经足够。2. 核心考点逐项剖析这些题到底在考什么2.1 概率统计与业务指标绕不开的“地基题”这批笔试的概率统计题不算难但很“实务”。有一道题我记得特别清楚给了一个音乐App某天的DAU、新增用户数和活跃用户中的听歌人数让判断“听歌渗透率下降”的可能原因。这类题表面是选择题实际在考你有没有“指标异动分析”的框架。拆解这类题目我最常用的思路是三步走先确认分子分母有没有口径变化再拆是“大盘下降影响”还是“结构变化影响”最后落到具体行为指标比如人均听歌时长、人均听歌次数、歌单点击率等等。做选择题时建议直接排除那些“听起来合理但无法用给定数据验证”的选项这种干扰项出现频率极高。概率题里有一道经典变形题从含有若干首周杰伦歌曲和若干首其他歌曲的曲库中随机不放回抽取求抽到第一首周杰伦歌曲的期望次数。这种题看起来简单但它可以往“负超几何分布”方向出难也可以直接考“几何分布期望1/p”的口算。笔试时间紧我的建议是这种基础概率模型别演算直接记结论。另外条件概率和贝叶斯公式也考了一年比一年多。原因很简单推荐系统里“用户点了歌单里的歌有多少概率会收藏歌单”这类问题本质就是条件概率。建议复习时多做几道“先验概率似然概率→后验概率”的题练熟贝叶斯公式的套路化运算不要只停留在背公式层面。2.2 SQL与数据提取能力两刀必过的“硬门槛”SQL题在这次笔试里属于“稳拿分”的部分但拿满分不容易。两题都是常规业务场景一题是计算每个歌单的次日留存率另一题是统计连续三天听歌的用户数。如果你只会GROUP BY和JOIN第一题勉强能做第二题基本写不出来。先看留存率这题。留存率的核心不是“算比例”而是定义清楚“次日留存”。这里我之前踩过坑如果直接用同一张表里的日期字段判断“用户在次日是否再次出现”而没有对用户去重结果会把同一用户当天的多次行为重复计算进去。正确做法是先做一次子查询拿到“每天活跃用户的去重集合”再和次日活跃用户集合做关联最后用COUNT(DISTINCT)来做口径严格的比率计算。再看连续三天听歌那题。它的标准解法是“日期减去行号”的经典套路先用ROW_NUMBER()按用户分组按日期排序然后用“日期 - 行号”构造分组标志最后按用户和分组标志聚合统计每组天数是否达到3。如果你想更稳妥还可以再加一层窗口函数LAG判断“是否连续”效果一样但SQL写起来更直观。我建议考试时优先用“日期减行号”法因为它的思路更简洁也更容易通过用例。这里必须提醒一个关于时间格式的细节这类题目经常给你“听歌时间”字段而不是“听歌日期”字段。如果你忘了先做DATE格式化或DATE_TRUNC后续所有去重和关联都会出问题。笔试环境里通常不允许你打开本地IDE调试所以这类预处理步骤应该在脑子里提前完成。2.3 机器学习基础不考推导但考“工程直觉”选择题中的机器学习部分考察范围就是常见模型的原理解释、使用场景和评估指标。有一道题问“在正负样本极不平衡的情况下以下哪个评估指标更可靠”选项里混着准确率、召回率、精确率和F1。这道题本身不难但它带出一种倾向腾讯音乐这类业务场景中做歌单推荐、热歌捕捉、用户流失预警样本不平衡是常态。做多了实际项目的人几乎不需要思考就能选F1。还有一题考的是“决策树防止过拟合的方法”选项包括预剪枝、后剪枝、降低特征维度、增加训练数据。这题想拿满分不能只知道“剪枝”还要知道“限制最大深度”“限制叶子节点最小样本数”“对特征列采样”都属于预剪枝范畴。我当时差点漏选“对特征列采样”这个选项因为总觉得这是随机森林特有的方法其实单棵决策树也可以用。再往后有几道模型比较题比如“在特征维度较高且稀疏的场景下用逻辑回归还是朴素贝叶斯更合适”以及“GBDT和XGBoost的关系”。这类题没有标准答案考的是工程判断。我建议大家复习的时候不要只看算法推导一定要顺带了解每个模型在稀疏数据、非线性关系、小样本等场景下的优缺点。从“数据科学职业核心能力”这个热点话题来看机器学习考察方向已经从“会调参”转向“会选模型、会评估模型”。所以复习模型时最好给自己做一个“模型选型速查表”逻辑回归适合做什么树模型适合做什么集成模型适合做什么评估时优先看哪个指标。笔试时遇到这类题能省下大量纠结时间。2.4 Python编程题pandas处理能力是“隐藏重头戏”Python编程题这次有两道整体难度中等但坑很多。第一道是用pandas计算每个用户每日的累计听歌时长第二道是给定一个大文件统计播放次数最多的Top N首歌。如果你过去习惯用Python处理小数据集可能意识不到这两道题真正想考的是“数据量大、内存有限”场景下的处理能力。第一道题累计时长听起来简单但如果数据里有重复记录比如用户在第一分钟和第三分钟各有一条“暂停播放”的记录直接用groupby求和会把时长算重。最稳妥的解法是先用drop_duplicates对“用户ID日期歌曲ID”去重再做groupby。如果没有这一步本地跑小用例看不出问题在线判题的大数据用例会直接报错或超时。第二道Top N题我建议优先用collections.Counter或者defaultdict计数不要用“按播放次数排序后取前N”这种粗暴解法。原因是大文件排序非常消耗内存用堆排序或者直接遍历维护一个小顶堆效率会高一个量级。如果你对pandas更熟也可以用value_counts().head(N)但需要注意它在大数据量下的性能表现并不理想。这类考题的考察点说白了就是“工程习惯”有没有考虑数据去重、有没有考虑内存限制、有没有使用合理的数据结构。笔试环境不像面试还能跟面试官解释思路代码一跑超时就是超时所以平时写代码时就养成“数据量大先想方案再做”的习惯特别重要。2.5 业务案例分析题最具区分度的“综合大题”最后三道业务案例分析题是整个笔试里最拉分、也最能体现“数据科学职业核心能力”的部分。三道题大概是第一个是“某歌单的分享率突然下降请设计分析方案”第二个是“评估某个推荐策略改版的效果”第三个是“为音乐人定制一个粉丝增长策略需要用到哪些数据指标”。这类题没有标准答案判分点在“逻辑链完整度”和“指标设计合理性”上。我第一次准备这类题时也很迷茫后面刷了三家公司的历年真题总结出一个通用答题框架先定义目标和口径再拆解影响因素或环节然后给出关键指标和数据分析方法最后落到一个可执行的建议或实验设计。用这个框架去套几乎所有业务分析题都能写出“有头有尾”的回答。关于“归因分析”这部分的考察力度这批笔试明显加强了。有一道题问“用户听歌时长下降如何区分是产品功能问题、内容供给问题还是季节性因素导致”这个其实就是归因分析在日常业务中的落地。我当时答的时候把内容分成了“内部因素”和“外部因素”两大类再进一步拆“产品功能变化”“内容版权流失”“竞品分流”等子维度每一步都写明“用哪个数据指标来验证”。个人觉得这样答比较容易体现出结构化的思维。再提一点写主观题时千万不要只写一句“分析用户行为数据”就收手。阅卷人想看到的是具体指标比如播放完成率、收藏率、转发率、连续收听天数、ARPU变化具体方法比如同期群分析、AB实验、因果推断。你给出的指标越具体越能证明你真的做过类似的分析项目。3. 实战演练从拆题到答法的全过程复盘3.1 题目拆解先理解“出题人想要什么”我拿这次笔试中一道典型主观题来做完整拆解。题目大意是“新歌推广位上线后首页该位置的点击率显著提升但歌单收藏量没有同步上升请分析原因并提出后续优化方案。”拿到题之后的第一反应不是想“我应该写什么”而是想“出题人希望我展示什么”。这道题的核心考点有三个第一你是否能区分“过程指标提升”和“结果指标没变”的矛盾信号第二你是否能建立从点击到收藏的漏斗并定位断点第三你是否能设计对应的优化实验或分析方案。这三点想清楚了答题结构自然就有了。我的答题草稿分了四个部分先定义“点击率提升但收藏量没变”可能意味着什么比如用户被标题吸引但内容不符合预期或者页面跳转链路有阻力或者收藏入口引导不足。接下来从“点击后行为”拆起把用户路径拆成“用户看到推荐位→点击→试听→收藏”四步每一步都列出可能的量化指标。然后我针对“试听到收藏”这个关键断点补充了几个可以做深度下钻的维度用户新老属性、歌曲风格偏好、推荐位上下文、时段差异等。最后给了一个AB实验方案核心是验证“优化收藏引导”和“优化歌曲匹配度”两个假设。因为时间有限我没有把每个维度都写成完整段落而是用“指标数据来源预期判断标准”的方式列了一个清单。这道题我大约花了二十分钟作答写完后剩五分钟检查前面的选择题。实际上第二道主观题“分析某歌单分享率下降的原因”与这个答题框架几乎通用我当时只需要把“收藏”替换成“分享”再补充一些“分享动机”的维度就能复用。这也是为什么我建议大家在备考时不要背题而是练“框架套用”的能力换一个场景框架还成立但具体指标和维度要有相应调整这样答案才有针对性。3.2 数据口径的把握细节直接决定得分高低做业务分析题时数据口径是贯穿始终的问题。笔试里关于“分享率”这个指标我特意在答案开头就写明“本回答中的分享率定义为某个歌单被用户打开后产生分享行为的UV数/打开歌单的UV数”。为什么要多写这一句因为一个指标在口语里可以有多种定义你如果不锁定口径后面的分析就缺乏根基。阅卷人看到你主动定义口径通常会很加分。继续往下在分析“分享率下降”时我建议把影响因素拆成四层用户层、内容层、产品层、外部环境层。用户层要看新老用户占比、核心用户活跃变化内容层要看歌单更新频率、歌曲版权变化、歌单主题热度产品层要看分享入口位置、分享引导策略、是否有弹窗干扰外部环境层则看节假日、竞品动态、社交媒体讨论热度等。每一层下面我都会配一个具体的验证方法比如用户层用同期群分析产品层用AB实验。写到这里我知道很多朋友会问“主观题到底要写多详细”我个人的感觉是不要写成论文只需要每条逻辑后面跟一两个关键指标或者分析动作即可。阅卷人一天要批大量试卷他们更希望看到“框架清晰、落点具体”的答案而不是又臭又长的分析报告。3.3 编程实操一道SQL题的完整推演过程再看SQL题。当时有一道题要求“统计2023年8月每天活跃用户中次日仍活跃的用户占比”。我当时直接在答题框里写了两层结构WITH daily_active AS ( SELECT user_id, date FROM user_play_log WHERE date BETWEEN 2023-08-01 AND 2023-08-31 GROUP BY user_id, date ) SELECT a.date, COUNT(DISTINCT a.user_id) AS active_users, COUNT(DISTINCT b.user_id) AS retained_users, ROUND(COUNT(DISTINCT b.user_id) / COUNT(DISTINCT a.user_id), 4) AS retention_rate FROM daily_active a LEFT JOIN daily_active b ON a.user_id b.user_id AND b.date DATE_ADD(a.date, INTERVAL 1 DAY) GROUP BY a.date ORDER BY a.date;这个写法的关键点在于我先对原始日志做了用户-日期级别的去重把“多次听歌记录”压缩成“每天一次活跃”再进行自连接找次日活跃用户。如果不做这一步直接拿原始表关联同一个用户一天听十首歌就会产生十行关联记录留存率被严重高估。操作意图明确说一下第一步子查询是为了确定“活跃”口径第二步LEFT JOIN是为了保留“今天活跃”的所有用户哪怕他次日没有出现这一步是不可省的。如果你用INNER JOIN留存为零的日子会被丢掉月度留存曲线就会缺失数据。笔试考点基本都藏在这些细节里。3.4 综合答题策略如何分配时间与取舍我这次笔试的时间分配大致是选择题三十五分钟SQL两道题三十分钟Python两道题二十五分钟主观题二十五分钟最后留五分钟检查。因为主观题我提前准备了框架所以写起来很快。如果平时对主观题不熟建议把时间压缩到二十分钟以内把更多时间留给SQL和Python题因为这些题有明确的对错比主观题容易拿分。另外想说一下取舍问题如果在某道SQL题卡了超过十五分钟果断先跳过去做后面会的题。校招笔试不是竞赛及格线附近的差距往往由“会不会做”决定而不是“做得多完美”。我亲眼见过有同学在连续三天那道题上抠了很久结果后面Python大题完全没时间写非常可惜。三个小时内稳定的时间分配比单题突破更重要。4. 高频失分点与避坑清单4.1 笔试中的“经典陷阱”与破解方法根据身边同学复盘和我自己的踩坑记录腾讯音乐这类数据科学笔试里高频失分点集中在以下几个方面第一选择性忽略数据口径。比如“活跃用户”不说明是按设备去重还是按账号去重这就等于埋了一个大坑。破解方法很简单在答案开篇先写清楚自己的口径定义如果题目没给就选一种合理定义并在解释里说明。第二混淆同环比和趋势归因。题目问“这个月DAU为什么涨了”有人直接答“因为新增用户多”却没有任何对比说明这种回答缺乏说服力。应该拆成“环比上月涨了多少”“新老用户贡献分别多大”“各渠道新增贡献的差异”等。第三SQL不会处理空值和重复值。这是所有数据岗笔试的通病。如果题目没明说字段无空值你就应该在SQL里用COALESCE或者WHERE IS NOT NULL处理一下这个细节很加分。第四分析维度单一。主观题只谈“可能内容不行”就完了没有继续拆“是标题不行还是歌曲质量不行还是一线歌手占比下降”。面试官想看到的是“下钻”能力而不是一句正确的废话。第五回答里没有任何“验证”手段。比如写完“可能是收藏入口改版导致收藏量下降”后没有跟着写“可以通过对比改版前后收藏转化率来验证”这在阅卷人眼里等于没写。4.2 备考时间线与资料推荐针对这场笔试如果从零开始准备我建议给自己留三到四周的复习时间。第一周主攻SQL窗口函数和Python pandas高频操作第二周复习机器学习基础知识和统计概率第三周专门练业务案例分析题重点研究“异动归因”和“实验评估”两类题最后一周做真题模拟按照考试时间完整做两到三套卷子训练手速和心态。资料方面我比较推荐以下组合SQL就用《SQL必知必会》和LeetCode数据库题库Python用pandas官方文档加牛客网编程题机器学习看李航《统计学习方法》前七章业务案例看公众号里的“数据分析面试题”以及牛客网的历年面经。“数据科学与大数据技术就业方向”这个话题最近讨论度很高我的看法是数据科学岗位的笔试风格正在从“考理论”转向“考业务落地能力”腾讯音乐这一批试卷就是很好的信号。如果你还在纠结“要不要啃完PRML”或者“要不要死磕SVM推导”我建议尽快把精力转向“如何用数据回答业务问题”这个方向。企业需要的不是只会推公式的数学家而是能把数据变成业务决策依据的数据科学家。4.3 考后复盘如何把一次笔试变成能力提升的阶梯考完笔试不是结束而是复盘和提升的开始。每场笔试结束后我建议花一两个小时做到三件事第一把不会的题整理成错题笔记标注考查的知识点和自己的薄弱环节第二把主观题的高分答法重新写一遍形成一个可复用的答题框架第三查漏补缺针对错题暴露的知识盲区做一次专题复习。我当时在复盘时明显感觉到自己在“业务指标下钻”这块还需要加强所以在之后两周专门补了同期群分析、漏斗分析和归因分析三个专题。后来在一个面试的业务面中刚好遇到类似的题目我直接套用了复盘总结的框架回答得比笔试时流畅很多。所以千万别考完就完事笔试其实是一份非常宝贵的“免费模拟题集”。5. 笔试之后数据科学岗位面试的延续与进阶笔试只是腾讯音乐数据科学岗招聘流程的第一关。通过笔试后通常还有一轮业务面和一至两轮技术面。面试风格很多时候会延续笔试的出题思路面试官手里有你的笔试卷他们往往会针对你答得不太好的主观题追问看你是否真的理解这个业务问题或者给你一个数据集让你现场讲分析思路。因此笔试复盘对面试准备的帮助非常大。我当时面试时面试官就问了一道关于“推荐策略改版评估”的问题几乎就是我笔试第二道主观题的变体。因为事先整理过框架我看到题目时完全不慌直接按“目标→指标→实验设计→预期分析结果”一条线答得清清楚楚。另外如果笔试中选了“判断点击率提升但收藏量未变”这种主观题面试官还可能会追问“如果点击率也下降了该怎么分析”。这个追问考的是你对“用户行为链路”的理解有没有延展性。建议准备时把“曝光→点击→播放→收藏→分享→付费”这条完整链路都过一遍每个环节可以对应哪些核心指标、哪些业务动作最好提前列好一张清单面试时就能随时调用。从“sem数据科学工作流从点击归因到预算优化的闭环实践”这个热点来看现在的数据科学岗位已经非常强调“分析→决策→实验→复盘→优化”的闭环能力。笔试只是检验这个闭环中最前端的一环能不能从数据里发现问题并提出可执行的分析建议。如果你把每一场笔试都当成一个真实的业务分析项目来对待收获的远不止一张面试入场券。最后补充一点关于个人心态的建议。校招是一个漫长又消耗心力的过程笔试做砸了不代表你不适合这一行更不代表之后没有机会。每一场笔试都像一次低成本试错多积累几场自然会形成自己的答题节奏和知识体系。准备下一场腾讯音乐笔试的同学把这篇文章里的框架和细节吃透再配合几轮完整模拟我相信通过率会高不少。