2023年腾讯音乐秋招数据科学岗的笔试我是在线上完成的。整个笔试120分钟题量不算少题型分三大块统计与机器学习客观题、SQL编程题、业务案例分析题。说实话这套题的风格和我之前刷过的互联网大厂数据岗笔试差别挺大它不怎么考死记硬背的模型公式更多是给你一个音乐业务场景让你用统计和数据思维去解决实际问题。如果你正在准备数据科学方向的秋招或者想知道腾讯音乐这类内容平台的数据科学岗到底考察什么这篇复盘应该对你有用。1. 笔试整体定位这个岗位要的不是纯算法工程师1.1 岗位画像懂统计、会写SQL、能听懂业务先说结论腾讯音乐的数据科学岗定位更接近数据科学与策略分析的交叉角色而不是纯粹的算法工程师。这点从笔试题目就能看出来。它几乎不考深度学习、也不考大规模分布式计算整张卷子的重心压在三个能力上统计推断与实验设计能不能设计一个严谨的AB实验能不能正确解读p值和置信区间结构化查询与数据处理给一张听歌记录表能不能写出正确的SQL拿到指标业务问题拆解音乐推荐的指标波动、会员付费的转化漏斗你能不能把它拆成可分析的数据问题我印象很深的是单选和多选里有两道题都涉及实验分流和假设检验。这在数据科学岗笔试里太正常了——任何以科学命名的数据岗位实验能力都是底线。推荐系统、搜索、广告、内容生态所有业务动作的上线都需要AB测试来验证所以笔试里反复出现样本量计算、显著性水平、多重比较这类考点一点都不意外。从就业方向的角度看数据科学岗位在互联网公司大致分两类一类偏算法工程核心是模型训练上线另一类偏策略分析核心是实验评估和业务洞察。腾讯音乐这个笔试明显侧重后者但同时又要求你有一定的编码功底。1.2 题型分布与分值节奏时间分配是第一道坎我在做题前先把整张卷子扫了一遍大致摸清了题型分布题型数量分值占比建议耗时单选/多选统计机器学习约15题30%25分钟SQL编程题2题25%30分钟Python数据处理/算法题1题15%20分钟业务案例分析1大题含3小问30%40分钟这个节奏很重要。很多同学挂在笔试上不是因为不会做而是因为前面客观题纠结太久后面SQL没时间跑通、案例分析只能草草写几句。我给自己定的策略是客观题限时25分钟不会的先用排除法实在拿不准就标记跳题绝不恋战。最后留40分钟给案例分析因为那道题分值最高而且文字作答你至少可以写出分析框架比空着强太多。如果你经历过2023年的大厂秋招应该能感受到一个趋势笔试题目越来越场景化即使客观题也会给你一段业务背景。腾讯音乐这场的统计题就是如此——它不会直接问哪个检验方法适合两组率的比较而是给你一个会员歌曲解锁功能上线前后周活跃用户听歌时长变化的表格再让你选择正确的检验方式和结论。2. 统计与机器学习客观题考点集中在实验与评估2.1 AB实验的隐性考点多重比较、样本量、新颖效应我抽到的题目里有一道多人问过的题是一个推荐策略调整实验对10个音乐风格子群分别做了显著性检验结果有两个子群p值小于0.05问能不能说明新策略在这两个风格上显著有效。大部分人选了可以因为p值达标但正确答案是不能需要做多重比较校正。这个考点我在准备时专门复习过。你在10个子群上做假设检验每个检验的显著性水平是0.05理论上即使策略完全无效每个子群都有5%的概率出现假阳性。10个子群全部无效果时至少出现一个显著结果的概率是1减0.95的10次方约等于40%。所以如果不做Bonferroni校正或FDR控制很容易被噪声骗了。建议准备任何数据岗笔试前把p值误读、多重比较、置信区间含义、第一类第二类错误这四个概念彻底吃透。它们几乎年年出现换着场景考。另外一道是问新功能上线后观察一周发现指标涨了是否可以判定功能有效。这里面的坑就是新颖效应——用户看到新功能时出于好奇心短期行为改变不代表长期价值。这对音乐产品尤其明显新风格推荐、新会员权益、新播放器界面上线初期都有一波好奇心红利。腾讯音乐这种内容型产品用户对产品变化的感知很直接所以笔试考新颖效应非常合理。2.2 机器学习题的考察深度模型选择与效果评估机器学习部分的单选题难度大概在能理解模型核心思想并做对比选择的水平没到要求手推公式的程度。我记得有考到推荐系统中协同过滤的冷启动问题怎么缓解正确答案偏向引入内容特征或热门物品回退而不是传统的矩阵分解。因为矩阵分解在用户交互数据极少时学不出可靠的隐向量决策树和逻辑回归在特征处理上的差异逻辑回归需要归一化/标准化决策树不需要逻辑回归能在线性边界下给出概率输出决策树擅长非线性切分回归模型评估指标的选择在存在极端值的情况下MAE比MSE更鲁棒但如果你要放大较大误差的惩罚MSE更合适聚类算法的适用场景K-Means适合凸形簇DBSCAN能处理任意形状且不需预先指定簇数热词里提到的数据科学职业核心能力放到笔试上就是这类题的考察逻辑不是在考你记忆了多少个算法而是考你在真实约束下能不能选对工具。数据科学的价值不是把最新最强的模型堆上去而是找到当前业务问题最恰当、最可解释、最稳定的解法。3. SQL编程题两张业务表三个查询逻辑3.1 表结构与题目要求腾讯音乐的SQL题给的是两张表场景是用户听歌行为分析。表结构大概这样用户信息表user_idreg_datevip_level普通用户/豪华绿钻会员city听歌记录表user_idsong_idplay_dateplay_cntlike_flag是否点赞题目拆成三个小问统计每个城市的月活跃用户数活跃定义当月有听歌记录计算每个用户的连续听歌天数并找出连续听歌天数最长的Top 10用户统计豪华绿钻会员和普通用户在一周内的日均听歌时长差异并给出一个简单的显著性检验SQL逻辑第一问很简单date_format按月份分组count(distinct user_id)即可。第二问考的是连续活跃天数这是互联网大厂SQL笔试里的高频题。核心思路是用窗口函数对每个用户的听歌日期去重后排序然后用日期减排序序号得到一个分组标记。连续听歌的日期减去连续的序号序列得到的日期是一样的按这个标记做分组计数。第三问有点意思了它不只是考SQL还考统计知识。你得写出计算两组成员听歌时长的逻辑然后提示说可以选用t检验判断差异显著性这时候你需要在注释或回答里把检验思路写清楚。说明腾讯音乐很在意你能不能把SQL取数和统计检验结合起来——这其实就是数据科学日常工作的缩影。3.2 怎么写第二问的连续天数SQL给大家看一下第二问的参考写法MySQL 8.0窗口函数语法WITH user_play_dedup AS ( SELECT DISTINCT user_id, play_date FROM play_log WHERE play_date BETWEEN 2023-08-01 AND 2023-08-31 ), user_play_ranked AS ( SELECT user_id, play_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY play_date) AS rn FROM user_play_dedup ), user_play_group AS ( SELECT user_id, play_date, DATE_SUB(play_date, INTERVAL rn DAY) AS group_date FROM user_play_ranked ), user_play_streak AS ( SELECT user_id, group_date, COUNT(*) AS streak_days FROM user_play_group GROUP BY user_id, group_date ) SELECT user_id, MAX(streak_days) AS max_streak_days FROM user_play_streak GROUP BY user_id ORDER BY max_streak_days DESC LIMIT 10;这个思路的巧妙之处在于连读的日期序列减去它们的计数序号一定得到同一个日期。比如用户8月1日、2日、3日连续听歌rn分别为1、2、3date_sub后都是7月31日。如果中间断了一天比如5日也听了rn就是4date_sub后得到8月1日就和前面断开了。这类SQL题型在数据科学笔试里的出镜率极高因为它是留存分析、活跃分析、用户粘性分析的基础操作。备考时我建议把以下这些窗口函数模式练熟连续N天活跃上面的思路各渠道首单后的次周留存率lag或者join min计算首次行为时间分组TopNrow_number over partition by同比环比lag over order by3.3 第一问和第三问的踩坑点第一问看起来简单坑在月活跃的定义。题目给的听歌记录表里如果用户一天内有多条记录直接用count(*)会重复计算。必须用count(distinct user_id)。我在自测时测试过不加distinct的结果数字虚高得很离谱。这种小地方恰恰是阅卷系统判定对错的依据。第三问的显著性检验我写的核心思路是这样的-- 先按用户分组聚合出一周内的听歌时长 SELECT user_id, MAX(vip_level) AS vip_level, SUM(TIMESTAMPDIFF(MINUTE, play_start_time, play_end_time)) AS total_play_minutes FROM play_log WHERE play_date BETWEEN 2023-08-07 AND 2023-08-13 GROUP BY user_id;这个子查询的结果就是每个用户的一周总听歌时长然后你在外层按vip_level分组计算两个组的均值、标准差、样本量接下来就可以套两独立样本t检验的公式了。这里有一个细节很容易被忽略在做检验之前要看两组方差是否齐性。如果方差不齐要用Welch校正。笔试时不要求你真去跑一遍完整计算但你在回答里若能提到先做方差齐性检验若方差不齐则使用Welch t检验这个细节会帮你拉开和其他人的差距。4. Python数据处理题一题考出工程习惯4.1 题目背景与考点分析Python题给的是一个音频内容运营的数据集包含每日各歌单的曝光量、点击量、收藏量、转发量和播放完成率要求基于这组数据构建一个简单的歌单质量评分模型并输出评分Top 20的歌单ID。这道题表面上是写评分函数其实考察的是数据科学工程中的几个基本素养数据读取与清洗有没有处理空值、异常值的意识特征构造原始字段之间如何组合出有信息量的指标代码可读性是不是写出了一坨只有自己能懂的代码结果可复现性有没有使用固定随机种子如果需要或者提供明确的运行方式我当时写的大致方案是用pandas读取csv先看缺失值和describe构建三个特征点击率click/impression、收藏率favorite/click、播放完成率直接用原始字段对特征做min-max归一化加权求和得到综合分按综合分排序取前20输出到新csv4.2 核心代码与评分逻辑import pandas as pd df pd.read_csv(playlist_metric.csv) print(df.info()) print(df.describe()) # 处理缺失值如果曝光量为0或缺失点击率无法计算直接填充0 df[click_rate] df[click_cnt] / df[impression_cnt].replace(0, np.nan) df[click_rate] df[click_rate].fillna(0) df[favorite_rate] df[favorite_cnt] / df[click_cnt].replace(0, np.nan) df[favorite_rate] df[favorite_rate].fillna(0) # 播放完成率已经在0-1之间不需要额外归一化 from sklearn.preprocessing import MinMaxScaler scaler MinMaxScaler() df[click_rate_norm] scaler.fit_transform(df[[click_rate]]) df[favorite_rate_norm] scaler.fit_transform(df[[favorite_rate]]) # 加权综合评分 w1, w2, w3 0.4, 0.3, 0.3 df[quality_score] (w1 * df[click_rate_norm] w2 * df[favorite_rate_norm] w3 * df[play_finish_rate]) top20 df.nlargest(20, quality_score)[[playlist_id, quality_score]] top20.to_csv(top20_playlist.csv, indexFalse)我为什么用点击率、收藏率、播放完成率这三个特征因为它们对应了音乐歌单消费漏斗的不同环节曝光到点击是吸引力点击到收藏是认可度播放完成率是内容质量。这三个指标从三个维度衡量一首歌单的质量比单一指标全面得多。权重方面我给了点击率0.4收藏率0.3播放完成率0.3。这个权重不是随便拍的点击率的样本量最大最稳定而收藏率的噪声比点击率大毕竟点击后收藏的比例通常很低受用户习惯影响大所以权重稍微低一点。注意这道题官方没有公布标准答案评分系统大概率是看你的代码能否正确运行、Top20输出是否合理。但这里有一个隐藏分如果你能解释为什么选这三个特征、为什么不直接把原始字段加权而是先做归一化和比率化你的答案会比只写代码的同学高出一个档次。4.3 我踩过的一个坑收藏率的分母处理刚开始我写收藏率的代码时分母用的是impression_cnt后来检查数据发现收藏行为只能发生在点击之后用曝光做分母会把很多高点击但低转化率的歌单错误地压分。比如一个歌单曝光10000次、点击5000次、收藏5次用曝光做分母收藏率是0.05%另一个歌单曝光100次、点击50次、收藏5次用曝光做分母是5%。但实际上两个歌单在点击后收藏这个环节的表现是一样的都是1%。**做特征工程时要先想清楚业务漏斗的逻辑再决定分子分母。**这是数据科学和纯代码开发最不一样的地方——你写的每一行计算背后都有业务含义这就是数据科学职业核心能力里的业务理解力。笔试里能看出这一层的同学不多但阅卷人一定能看出来。5. 业务案例分析题从归因分析到预算优化的完整思路5.1 案例题原文复盘记忆版这道题占了整张试卷30%的分值题目的场景是腾讯音乐旗下的某个产品在推广新的会员服务运营侧在各个渠道投放了引流广告。现在需要你回答三个问题如果各渠道都存在曝光-点击-注册-购买的多层转化路径如何评估每个渠道对最终会员购买的贡献请给出你的归因分析思路在预算有限的情况下如何根据归因结果优化各渠道的预算分配请给出你的优化方案如果渠道A带来了大量点击但购买转化率很低你会如何分析可能的原因并提出改进建议这个case出得很讲究它把归因和预算优化串成了一条完整的闭环和行业里常说的从点击归因到预算优化的闭环实践是一回事。5.2 第一问多触点归因的建模方案我的回答思路是这样的先说明背景用户的实际转化路径很少是单一触点。一个用户可能先在信息流看到广告没点过了两天在短视频平台又刷到点了然后去搜索品牌词最后通过官网注册并购买。这种情况下如果只把功劳记在最后一次点击的渠道上会导致早期种草渠道的贡献被严重低估。然后给出分阶段的方案第一阶段用规则归因做快速上线。常见规则有末次点击归因、首次点击归因、线性归因所有触点均分、时间衰减归因离转化越近权重越高。如果公司内部没有成熟的归因系统先从末次点击归因做起因为它实现成本最低、口径最容易对齐但必须知道它的偏差在哪里。第二阶段用算法归因做精细化。可以参考Shapley值的思路把每个渠道看作合作博弈的参与者计算它在所有渠道组合中的边际贡献平均值。这样可以更公平地把转化功劳分配给各触点。我还在回答里列了一下Shapley值的直觉理解假设有渠道A和B最终转化100单。先看只投A能转化多少、只投B能转化多少、A和B都投能转化多少。A的贡献就是在没有A的世界和有A的世界之间的增量而且要考虑B加入顺序不同带来的影响。Shapley值就是把这些边际贡献在所有可能的渠道加入顺序上取平均。5.3 第二问预算优化的数学建模预算优化部分我的回答聚焦在转化率和边际收益上。核心逻辑是每个渠道投放预算与转化量之间不是线性关系而是边际递减的。第一个1万块投下去可能带来500个转化第二个1万块可能只带来300个转化。所以在预算有限的情况下应该把钱投到边际转化率最高的那个渠道直到它的边际收益降到和其他渠道持平这就是经济学里的等边际原则。我给出的实操步骤是第一步根据历史数据拟合每个渠道的预算-转化量曲线可以用简单一点的方法把近几个月的预算和转化数据按周聚合画散点图尝试用对数曲线y a b * ln(x)拟合第二步对拟合曲线求导得到边际转化率函数第三步按边际转化率从高到低排序分配预算每分一笔就更新一次剩余预算和边际转化率第四步直到预算分配完最终各渠道的边际转化率会趋向一致这个思路最大的好处是即使没有复杂的最优化求解器用Excel或Python也能算完。数据科学在业务落地时永远不要追求数学上的绝对最优解而要追求在现有工程资源下能算出来、能解释得清、业务方愿意用的足够好的解。我在回答里直接写了一个简单的Python示例代码import numpy as np from scipy.optimize import minimize_scalar # 假设三个渠道的预算-转化拟合函数y a * ln(1 x) channels { A: {a: 800, spend: 0}, B: {a: 500, spend: 0}, C: {a: 300, spend: 0}, } budget 100000 allocated 0 while allocated budget: marginal {} for ch, info in channels.items(): # 简化边际转化率 a / (1 spend)即对数函数求导 marginal[ch] info[a] / (1 info[spend]) # 找出边际转化率最高的渠道分配1000元 best_ch max(marginal, keymarginal.get) channels[best_ch][spend] 1000 allocated 1000 for ch, info in channels.items(): print(f渠道{ch} 分配预算: {info[spend]:.0f})这个例子是高度简化的但基本逻辑是对的每次迭代都把下一笔预算给到边际收益最高的渠道最后各渠道的边际收益收敛到同一水平。5.4 第三问渠道A点击多、转化低的归因排查第三问是一个很典型的指标异动归因题考察的是数据科学家的排查思路。我的回答分四步第一步先确认数据口径没问题。渠道A的点击定义和转化归因窗口期是不是和其他渠道一致比如渠道A的点击统计包含了恶意点击或重复点击或者转化数据的归因窗口期设置得太短导致很多看了但没立即买、过两天才买的用户被排除在归因之外。在做任何分析之前先花20%的精力排除数据质量问题能避免后面80%的分析白做。第二步分环节定位流失点。把渠道A的用户从点击到购买的完整漏斗拆开点击率、落地页加载率、注册率、试听率、购买率。逐层对比渠道A和其他渠道的差异找到流失最严重的环节。如果注册率很低问题可能出在落地页体验或目标用户匹配度上如果试听率低问题可能出在内容吸引力上。第三步看用户质量。渠道A的流量来源可能偏泛拉来大量非目标用户。这时候要看用户画像、设备分布、地域分布和转化好的渠道做对比。比如渠道A如果大量来自低线城市的大龄用户而产品本身偏年轻化那转化率低就是流量质量不匹配的自然结果。第四步做归因窗口期敏感性分析。看不同窗口期1天、3天、7天、14天下渠道A的转化率变化判断渠道A是否是慢转化渠道。某些渠道用户从接触到付费需要更长的决策周期比如搜索渠道的用户目的明确转化快而泛娱乐渠道的用户需要多次触达才能转化。如果窗口期设短了会误判渠道价值。这一问表面上问的是分析可能原因其实考的是你有没有一套系统化的异动排查框架。建议所有准备数据科学面试的同学把数据校验、漏斗拆解、人群对比、外部因素排查这套框架内化成肌肉记忆。6. 备考复盘数据科学岗笔试的核心能力图谱6.1 数据科学与大数据技术方向看重什么2023年的秋招环境下数据科学方向的竞争烈度比前两年高了不少。从腾讯音乐这场笔试可以看出一个趋势笔试正在从考知识点转向考工作场景。统计知识不再直接问定义而是放在AB实验的场景里问你哪个结论靠谱 SQL不再考简单的select join而是考连续活跃、留存率、漏斗分析这类真实业务指标 Python题不再考力扣原题而是让你对一份业务数据做特征工程和评分建模 业务题更是把归因和预算优化串成了闭环。这背后对应的是数据科学与大数据技术专业的就业方向变化企业对初级数据工程师的纯技术需求在收缩对数据业务策略复合型人才的需求在增加。一个合格的数据科学候选人至少要具备四层能力第一层是数据处理能力SQL、Python、数据清洗、特征构造这是安身立命的基础第二层是统计与实验能力假设检验、AB实验、因果推断这是科学二字的体现第三层是业务理解能力看得懂漏斗、拆得开指标、找得到问题的关键环节第四层是沟通表达能力笔试通过后还有面试你能不能把自己的分析讲成一个业务方能听懂的故事6.2 这套题对2024届及之后求职者的准备建议如果你明年也要参加类似的数据科学岗笔试我给几点亲身验证过的建议第一统计知识别只背结论要会结合场景解释。每天问自己一个问题如果业务方问我p值是什么我能不能不用数学公式就让他听懂答案是能你才算真懂了。我推荐用无罪推定的类比——p值就是在假设被告无罪的前提下观察到当前这么极端的证据的概率。第二SQL窗口函数是必考项提前练熟。连续活跃、分组TopN、同比环比、留存率这些题型每题都要能手写出来。我备考时用LeetCode的数据库题库加上牛客网的SQL题库各刷了50题左右覆盖了所有常用窗口函数写法考场遇到第二问就很从容。第三案例分析题要有自己的结构化模板。比如归因分析先分规则归因和算法归因预算优化先做边际分析再谈分配指标异动先排除数据问题再拆漏斗再比人群。框架不需要多复杂但要形成条件反射考试时间有限临场想框架大概率会漏点。第四代码要干净注释要写清楚。笔试系统是机器阅卷人工抽检你的代码能不能跑通、结果合不合理是机器判断的但你的思路是否清晰、考虑是否周全是后续面试官看试卷时会留意的。我见过太多人代码能跑通但变量名全是a、b、c没有任何注释这样的代码即使结果对了也很难让面试官对你产生好感。6.3 我个人觉得这套笔试最有价值的地方复盘完这套题我最深的体会是它不考偏题怪题所有考察点都是数据科学日常工作中真正会用到的东西。AB实验是策略上线前必须做的连续活跃分析是用户运营最常用的归因和预算优化是投放团队天天在算的。换个角度说笔试筛的不是知识面最广的人而是基本功最扎实、业务感最好的人。准备2024届及以后秋招的朋友我的建议是不用过度钻研太偏门的算法题把时间花在统计推断、SQL窗口函数、业务case这三件事上投入产出比最高。腾讯音乐这类内容平台的数据科学岗要的就是一个能在音乐推荐、会员增长、内容运营这些场景里把数据问题定义清楚、分析透彻、给出可落地建议的人。笔试只是第一关但这一关已经把很多人挡在门外了。希望我的复盘能帮你少走一点弯路。