腾讯音乐数据科学岗笔试复盘：从统计基础到业务分析全解析

2023年春招那阵子我投了腾讯音乐的数据科学岗赶上的是第二批笔试。第一批我身边有同学参加反馈是基础题偏多、业务题偏少所以我原本以为第二批差不多也是那个路数结果一开场就发现事情没那么简单——这一批明显在统计基本功之外加了不少和音乐产品生态绑得很死的业务场景题尤其是听歌行为分析、付费转化归因和社区内容推荐这几块。整套卷子做下来与其说是在考你会不会建模不如说是在考你能不能把数据变成业务决策。这篇文章把那次笔试的完整复盘写下来包括题型分布、核心考点、几道代表性题目的解法推演以及我踩过的坑和备考建议。准备投腾讯音乐或者其他大厂数据科学岗的同学无论你是春招还是暑期实习这篇应该都能给你一些实际的参考。1. 笔试整体感知题型分布与考察逻辑1.1 笔试形式和基本盘先交代一下大环境。腾讯音乐的数据科学岗实际上是按业务线来分的音乐推荐、用户增长、版权内容、商业化都有数据科学家的需求所以笔试一般不会只考一个方向的内容而是通用基础 业务场景的组合卷。我参加的第二批笔试是在线上完成的用的第三方测评系统总时长120分钟题量不算特别大但信息密度很高。从题型来看大致是这么四块单选题和多选题大概15-20道覆盖概率统计、机器学习基础、Python语法、SQL语义理解。SQL编程题2道左右给定表结构要求写出查询实现某个业务指标。编程题1道Python实现偏向数据结构和简单算法偶尔会结合pandas。主观业务案例题2道左右给一个音乐产品的业务场景要求给出分析思路、指标体系或排查方案。这个结构本身不算意外但我注意到一个细节多选题的比例比第一批高而且多选里面夹杂了不少因果推断和实验设计的考点。这说明腾讯音乐的数据科学团队在日常工作中不只是做预测模型还承担了大量的实验评估和因果归因工作。1.2 第二批笔试的定位差异第二批笔试和第一批有什么不同从我拿到的信息和实际体验来看主要有三点。第一第二批的时间点更靠后很多hc其实已经发了一部分offer剩下的是补录或者部分团队的定向招聘。这意味着筛选标准不会降低甚至可能更严格因为团队知道自己缺什么样的人。第二业务题的比重更高。第一批还有纯考理论的选择题第二批的主观题几乎全部绑定到音乐产品的实际场景比如推荐位调整后如何设计评估方案如何从收听行为中识别高潜付费用户这类问题。这其实是在提前筛选那些对音乐产品有理解、有业务sense的候选人。第三SQL题的复杂度上了一个台阶。第一批的SQL基本是单表查询和简单聚合第二批直接上了窗口函数、多表关联和留存计算的组合还要求考虑数据去重和空值处理。这一点后面会详细展开。说到底腾讯音乐的笔试考察逻辑是清楚的他希望招进来的人一上来就能跟上业务节奏而不是还要花几个月补业务认知。所以笔试不仅仅是技术筛选更是一场业务匹配度的测试。2. 核心考点拆解数据科学岗究竟在考什么2.1 统计学与概率论永远绕不开的基本功统计学和概率论在笔试里的地位非常稳固。我印象里有几道题很有代表性。一道题考的是贝叶斯定理大致背景是推荐系统的推送概率曲库里用户真正喜欢的歌占一定比例算法推歌的命中率和一个条件概率挂钩问用户收到一首歌且点击了这首歌是用户真正喜欢的概率是多少。这类题不难核心是能不能识别出需要套贝叶斯公式以及能不能在紧张状态下把分子分母算对。平时练习的时候我建议大家把先验概率、似然概率、后验概率这三者的定义反复捋清楚不要只记公式。还有一道题考假设检验问的是A/B实验里p值小于0.05能不能直接下结论说实验组显著优于对照组。这个题表面上是考p值的定义实际上在考察你对多重比较辛普森悖论数据窥探这些概念有没有认知。我当时选答案的时候反复斟酌因为选项里好几个都是统计学教材里的经典陷阱。另外还有一道关于概率分布的题给了场景问最合适的分布——大致是一个音乐人一周内被播放次数的建模类似的问题正确答案是泊松分布因为这类计数数据通常符合泊松分布的特征。这种题本身不难但如果你只看课本没做过实际数据分析可能会在泊松和负二项之间犹豫。统计学这部分我的体会是不要只背公式一定要理解每个统计概念是在什么业务场景下被提出来的。你理解了为什么要有假设检验自然就知道p值是什么也就不会被几个绕来绕去的选项带偏。2.2 SQL与数据提取业务场景下的硬功夫SQL是数据科学岗笔试里最实务的考察项。第二部分我就重点谈谈这次笔试在SQL上给我留下的几个印象。首先是窗口函数。笔试里有一道题要求按照用户分组计算每次收听距离上次收听的时间间隔这必须用LAG函数。如果你只会GROUP BY和JOIN面对这种题基本没戏。所以大家在准备数据科学岗笔试的时候窗口函数的几个核心用法——ROW_NUMBER、RANK、DENSE_RANK、LAG、LEAD、SUM OVER——一定要练到手熟。其次是留存计算的写法。业务上经常要算新用户次日/7日/30日留存笔试就直接让你写SQL。这个题需要你处理好首次行为日期这个基础逻辑然后用日期差判断是否在观察窗口内回访。这个题目不难但涉及多表关联、去重、日期函数一不小心就会写错连接的逻辑。第三是空值和重复值的处理。有一道题要求在统计用户收藏歌曲数量时排除掉没有收藏行为的用户还要处理同一首歌被多次收藏的重复记录。这种问题在实际工作中非常常见但如果平时写SQL习惯不好很容易在笔试里翻车。这里我分享一个心得笔试的SQL题通常不会考你特别冷门的语法它考的是你对业务指标定义的理解。比如留存率到底怎么定义分子分母是什么观察窗口怎么算这些都清楚了SQL写起来就顺理成章。反过来如果你业务指标定义不清SQL写得再漂亮也拿不到分。2.3 机器学习基础从背公式到选模型机器学习部分没有出现复杂的推导题更多的是给你一个业务场景让你选模型或者给你一组模型评估结果让你判断问题出在哪。有一道选择题印象比较深在用户听歌时长预测任务中特征包括用户历史收听时长、歌曲时长、歌手热度、时段特征问题是如果用线性回归哪些特征需要做标准化处理。这个题的考点在于线性回归的梯度下降过程对特征尺度敏感如果不做标准化收敛会很慢甚至不收敛而树模型比如XGBoost本身对特征尺度不敏感。很多人只记住了要标准化却不理解为什么这种题就会犹豫。还有一道多选题考的是模型评估指标在预测用户是否会成为付费会员这个二分类任务里正负样本比例严重失衡问哪些指标比准确率更合适。答案是AUC、召回率、F1这些都是不平衡分类场景下的常规选择。这道题算送分题但它提醒我一个事情数据科学岗的笔试不会让你脱离业务去聊算法任何模型考题都会套一个业务外壳。关于过拟合也有一道题考了正则化的作用L1和L2的区别是什么什么时候用L1。这属于机器学习基础里的高频考点基本上准备过大厂数据岗笔试的人都见过。不过腾讯音乐的考题好就好在它会在题干里给你一个小背景比如特征数量很多但样本有限希望做特征选择这样你就能判断出应该选L1。这说明复习的时候还是要带着业务目的去理解算法。2.4 业务案例分析区分度最大的部分如果说前面那些题是基本盘那业务案例分析就是这次笔试真正拉开差距的地方。我印象里有两道主观题一道是推荐场景的指标评估设计另一道是关于会员付费转化的归因分析。推荐场景那道题大致是这样产品团队在推荐页做了一个新的排序策略全量上线后用户点击率提升了但人均收听时长反而下降了让你分析可能的原因并设计一套评估方案。这道题考察的东西是全方位的既要懂推荐系统的业务逻辑又要会设计实验还要有数据分析的排查思路。一个合格的分析思路应该包括先确认数据口径点击率提升是否伴随了点击的质量下降比如用户点了但没听几秒就退出再看实验设计如果这不是A/B实验而是全量上线那就需要做时间序列对比、效果回溯分析从用户维度拆解提升点击率的主要是哪些用户时长下降的又是哪些用户可能是新老用户之间的差异被平均掩盖了。我当时答题的时候特意强调了不能只看单一指标要多指标联合评估并且给出了一个包含点击率、完播率、收听时长、次日留存、人均听歌数的指标体系。这种回答方式即使不完美也能让面试官看到你具备多维度审视问题的能力。另一道会员付费转化的题目更偏归因大致是从免费用户到付费会员的转化率最近一个月下降了数据层面怎么排查业务层面怎么优化。这就是典型的点击归因到优化策略的思维链路先看漏斗各环节的转化率变化定位是曝光-点击环节流失还是点击-支付环节流失再看用户群体是新增用户转化降低还是存量用户复购降低最后结合内容侧和策略侧的变动推断原因并给出优化方向。这种题没有标准答案但答得好不好一眼就能看出来。只会背模型的候选人答起来通篇都是空话真正做过业务的人会给出具体的分析路径和落地的指标建议。所以我在笔试之前特意刷了一些业务分析案例把归因分析的思维链路捋顺了考场上才不至于卡壳。3. 实战题目复盘从读题到答题的完整推演3.1 一道留存分析SQL题的完整解法这次笔试的SQL题里有一道留存题大致场景是给定两张表一张是歌曲信息表一张是用户收听记录表要求计算2023年1月内每个自然周新增用户即该周第一次产生收听行为的用户的7日留存率。这里我要说明一下题目细节凭记忆复述表和字段名做了脱敏处理但核心逻辑是完整的。如果你在笔试中遇到类似的题可以按下面的思路来解。先梳理表结构两个表大概是-- 歌曲信息表 CREATE TABLE songs ( song_id STRING, song_name STRING, singer_id STRING, publish_date DATE ); -- 用户收听记录表 CREATE TABLE listen_log ( user_id STRING, song_id STRING, listen_date DATE, listen_duration INT );计算自然周新增用户的7日留存率核心难点在于你需要先定义新增用户——这位用户在观察周期内的第一条收听记录所在的那一周就是他的新增周然后看他在这周之后的7天内是否又产生了收听行为。满打满算一个完整的三步逻辑找首听日期、判断是否在1月内、算7日回访率。我当时写的SQL大致是这样的WITH first_listen AS ( SELECT user_id, MIN(listen_date) AS first_date FROM listen_log WHERE listen_date BETWEEN 2023-01-01 AND 2023-01-31 GROUP BY user_id ), week_base AS ( SELECT user_id, first_date, YEARWEEK(first_date, 1) AS first_week FROM first_listen ), retention_flag AS ( SELECT w.user_id, w.first_week, COUNT(DISTINCT l.user_id) AS is_retained FROM week_base w LEFT JOIN listen_log l ON w.user_id l.user_id AND l.listen_date w.first_date AND l.listen_date DATE_ADD(w.first_date, INTERVAL 7 DAY) GROUP BY w.user_id, w.first_week ) SELECT first_week, COUNT(*) AS new_users, SUM(is_retained) AS retained_users, ROUND(SUM(is_retained) / COUNT(*), 4) AS retention_rate FROM retention_flag GROUP BY first_week ORDER BY first_week;这里有几个关键点需要重点解释。第一为什么用LEFT JOIN而不是INNER JOIN因为我要保留所有新增用户包括那些7天内没有回访的用户。如果用INNER JOIN这些没回访的用户会被直接过滤掉留存率分母就错了。第二为什么COUNT里要加DISTINCT因为一个用户7天内可能多次收听如果不做去重一个人可能计多次留存率会虚高。但要注意这里我用的是COUNT(DISTINCT l.user_id)在LEFT JOIN后如果用户没有回访记录l.user_id是NULLCOUNT(DISTINCT NULL)不会计入所以这个写法没问题。第三这里用了YEARWEEK函数按周聚合需要注意周起始日是周一还是周日不同的平台函数可能不同。笔试环境里如果题目说自然周我一般默认周一到周日所以用YEARWEEK的第二个参数指定。这个细节宁可多写注释也别含糊。这道题写完以后我检查了边界情况2023年1月的前几天可能是上一年的最后一周所以YEARWEEK出来的周编号可能不是1这不影响逻辑因为我们是按周编号分组而不是按第几周。另外7日留存的定义是首次行为后7个自然日所以区间是(first_date, first_date 7]注意首听当天不算如果算当天就是8日留存了这个要看题目定义别想当然。3.2 一道概率统计题的临场推演接下来复盘一道概率题题目背景是推荐系统。大致是这样某个音乐App的推荐算法从曲库中挑选歌曲推给用户。曲库中用户真正喜欢的歌占20%。算法推送行为有一个特性如果一首歌是用户喜欢的它有70%的概率被推给用户如果用户不喜欢它有30%的概率被推给用户。现在用户在首页看到了一首系统推送的歌请问这首歌是用户真正喜欢的概率是多少这个题就是典型的贝叶斯定理设事件A为用户喜欢这首歌事件B为这首歌被系统推送。我们需要求P(A|B)。P(A|B) P(B|A) * P(A) / [P(B|A) * P(A) P(B|非A) * P(非A)]代入数字P(A) 0.2P(非A) 0.8P(B|A) 0.7P(B|非A) 0.3P(A|B) 0.7 * 0.2 / (0.7 * 0.2 0.3 * 0.8) 0.14 / (0.14 0.24) ≈ 0.368也就是说即使这首歌被算法推给了用户它真正被用户喜欢的概率也只有大约36.8%远不是直觉里想象的那么高。这个结果其实很有业务含义推荐系统的precision不高时用户会不断看到不感兴趣的歌曲对推荐质量的感知会明显下降。所以这道题表面在考概率公式实际上是希望候选人能理解先验概率对后验概率的影响。这类题在笔试中几乎年年出现我建议大家把贝叶斯定理的几种常见套路都练熟尤其是用一个检测手段去判断一个稀有事件是否发生的场景这类题的数字通常设计得让你第一眼误以为概率很高算完才发现不是那么回事。3.3 一道推荐业务场景题的框架拆解最后复盘一下那道让我觉得最有区分度的业务题。题目大意推荐页的点击率连续两周下降从8%降到了6.5%但全平台日均收听时长基本稳定。请分析可能原因并给出排查思路。我当时是这么拆解的写出来供大家参考。第一步先定口径。点击率是怎么算的是点击曝光量还是点击用户量推荐位有没有改版埋点有没有变动版本发布有没有引入AB实验分流这些口径问题不确认后面的分析都是空中楼阁。我见过太多业务方拿着两个口径不一致的数字来问为什么下降所以我的答题第一步永远是确认口径。第二步做维度拆解。把点击率的下降拆到各个维度去看分端口iOS/Android/PC端分别什么趋势分版本新版本和老版本有什么差异分用户群新用户、老用户、高活用户、低活用户哪个群体的点击率变化最大分推荐位是所有推荐位都降还是只有首页推荐位降这一步的目的是缩小排查范围把整体下降变成某个群体、某个场景下的下降。第三步结合内容供给变化来分析。点击率下降可能不是策略变差了而是内容供给出了问题。比如近期热门新歌发布少或者推荐的歌曲用户已经听腻了都会导致点击率下降。建议拉一下每日新歌上架量推荐池歌曲的新鲜度这些指标做相关性分析。第四步给出验证方向和后续方案。可以用AB实验来验证新的排序策略能否恢复点击率也可以从点击率下降是否影响了核心指标来判断这个问题的优先级。题目里说日均收听时长稳定这很关键——说明点击率下降可能只是浅层指标变化用户的实际消费没有受影响可能只是用户对推荐内容的点击偏好变了比如变得更挑剔只点自己确有兴趣的内容。如果是这样没必要过度紧张。这道题我答了大概700字核心思路就是先看定义再拆维度再找原因最后给方案。面试官要的不是一个标准答案而是你面对模糊业务问题时的结构化推理能力。4. 踩坑记录、时间分配与备考建议4.1 我踩过的几个坑先说第一个坑多选题的漏选。腾讯音乐笔试的多选题是少选得部分分错选不得分还是少选不得分这个规则在正式作答前一定要看清楚。我第一批听说的是少选不得分所以第二批做多选时非常谨慎不确定的选项宁可少选。但有的人可能没注意规则变化看到多选题就恨不得把每个选项都分析一遍反而选多了丢分。第二个坑是SQL题的表字段没看仔细。第一道SQL题里有一个listen_log表里面有个字段是listen_duration收听时长但题目让算的是留存这个字段根本用不上。我一开始做题时还以为要用收听时长做某种加权浪费了几分钟。后来才发现这个字段纯粹是用来干扰你的。记住笔试里出现的每个字段不一定都有用一定要先读清楚题目要求再看表结构。第三个坑是时间分配失衡。我刚开始做选择题时比较谨慎有几道多选纠结了很久结果做到后面发现SQL题和业务题才是重头戏时间已经不够了。最后一道业务题我写得比较仓促框架感不够。这是一个很大的教训数据分析的能力最终还是体现在完整输出上前面的选择题再纠结也就一两分业务题一题可能顶好几道选择。第四个坑是没有提前熟悉笔试系统的代码编辑环境。腾讯音乐用的是在线笔试平台SQL题和Python题在网页上写代码没有本地IDE的自动补全和语法高亮缩进也很容易出错。我平时用本地IDE习惯了到了网页编辑器上写Python时缩进出过问题。建议大家在笔试前至少用一个在线代码编辑器练几道题熟悉那个手感。4.2 时间分配方案与做题顺序结合我自己的教训我给大家一个建议的时间分配方案。假设总分120分钟大致可以这样分前20分钟做选择题和判断题尽量快速过不纠结。40分钟做SQL题每道题20分钟先写主逻辑再处理边界。20分钟做Python编程题一般不会太难注意处理输入输出和边界条件。35分钟做业务案例分析题每道题15-20分钟要写结构化答案。最后5分钟检查关键题目的答案尤其确认SQL的逻辑没有明显bug。不过这里有个侧重点要提醒如果你对业务题比较擅长可以从业务题开始做。因为业务题是笔试中最值钱的部分而且答得好不好更多取决于思路而非代码准确性。先把这类题的打满再做技术题心态会更稳。做题顺序上我的建议是先做自己最有把握的部分。比如你SQL很强就先把SQL题写完建立信心你业务分析很擅长就先攻业务题。总之不要死板按照题目顺序一路做下来灵活调整往往能多拿不少分。4.3 数据科学岗位的核心能力图谱与备考建议准备腾讯音乐这种大厂的数据科学岗不能只刷题要从数据科学职业核心能力这个角度去构建自己的知识体系。这个岗位看重的核心能力结合这次笔试我总结了一下大概有四块。第一块是数据处理能力。包括SQL、Python、数据清洗、数据建模这些硬技能。笔试里SQL占比很大而且要结合业务场景来写。这块能力其实没有捷径只有多写多想把窗口函数、复杂查询、数据去重这些高频场景练熟。第二块是统计建模能力。统计学基础、概率论、机器学习算法、实验设计、因果推断这些都是数据科学家的基本功。笔试不会考太深的推导但会考你对概念的理解和在不同场景下的选择。建议复习时把假设检验流程贝叶斯定理常见模型对比这些内容用思维导图过一遍确保看到题目能快速定位考点。第三块是业务理解能力。我把这点称之为数据科学岗和算法工程师岗的差别。数据科学岗更强调把数据转化为业务决策所以你对推荐系统、用户增长、商业化这些业务逻辑要有基本认知。如果你平时会关注行业里的数据科学工作流比如从点击归因到预算优化的闭环实践这类方法论你的业务分析题会答得明显更有内容深度。这类内容刷起来并不枯燥本质上是在培养用数据说话的商业直觉。第四块是沟通与结构化表达能力。笔试里的主观题本质上就是考察你能不能把复杂分析思路用文字清晰表达出来。建议平时练习时每次分析完一个案例都用定义问题-拆解维度-推断原因-给出方案的四段式结构写一遍答案形成肌肉记忆。备考资料的选取上我建议基础阶段的同学以SQL题集和各厂大数据笔试题为主多练多总结有一定经验的同学可以重点精读一些业务案例分析类的资料多积累从指标异常到归因分析的思维链路。此外还要多关注目标公司的产品动态比如你想投腾讯音乐至少要知道QQ音乐和酷狗音乐的产品形态、核心功能、推荐策略大概长什么样。最后再分享一个小技巧笔试结束后当天立刻把遇到的题目回忆一遍整理成笔记。不管有没有通过这份笔记都是你后续面试准备的重要素材。我这次就是因为及时做了复盘才能在面试阶段更清晰地讲出自己对于数据科学岗位的理解。数据科学这条路的面试是一环扣一环的笔试阶段积累的每一道题都可能成为你下一轮面试里的谈资。