每年这个时候都是秋招笔试最密集的阶段。作为一个连续参加过两届大厂数据科学岗笔试、也陪身边不少学弟学妹复盘过题目的老数据人我对这套腾讯音乐秋招数据科学岗第二批笔试题印象挺深。它的风格很有代表性不搞偏题怪题但非常考验你把统计、机器学习、SQL、业务分析串起来的能力尤其是最后几道业务场景题直接对标真实工作中“从数据到决策”的链路。这篇文章我会完整复盘这套笔试题的核心内容包括我自己的解题思路、踩过的坑以及从面试官角度反推回来的评分点。无论你是正在准备数据科学岗秋招还是想系统补一下数据科学职业核心能力这篇都能给你一个比较落地的参考框架。文章比较长建议先收藏再慢慢看尤其是准备投腾讯、腾讯音乐的这套题的思路复用价值很高。1. 笔试整体复盘与题型分布1.1 这次笔试考了什么四类题型背后的真实筛选逻辑第二批笔试整体分为四个部分统计概率与机器学习基础、SQL与数据处理、业务场景案例分析、编程题。分值占比大概是统计概率和SQL各占30%业务场景占25%编程题占15%左右。整体时间很紧张满分100分的话我体感能稳定做完并检查一遍的人不多多数人会在业务场景题上耗费大量时间。先说题型分布背后的筛选逻辑。四分法看起来常规其实是在测三个维度基础理论的扎实程度、工程落地的熟练度、业务思维的敏感度。统计概率和机器学习基础考的是你有没有建立完整的知识框架——这决定了入职后能不能接住分析类需求SQL和编程题考的是你有没有动手能力——数据科学不是纯算法岗天天要跟数仓打交道业务场景题则是区分度最大的部分它决定了你是“会做分析的人”还是“能解决问题的人”。一个值得注意的细节是这套题的统计题几乎全部带业务背景不是干巴巴地让算概率而是把概率放进用户行为场景里比如“用户连续打开App天数”“推荐流点击概率异常波动”。这一点比较像腾讯系笔试的风格题目本身不难但审题不仔细容易把简单问题复杂化。1.2 时间分配策略先保大分再啃硬骨头75分钟做大概12道题不完全统计可能有微调其中选择题8道左右问答题和编程题4道左右。我身边做完的同学反馈高度一致选择题看似简单但坑很多单题耗时远超预期编程题反而还好因为思路相对固定。我的建议是先快速扫一遍所有题目在卷面上标记出“确定能做对”和“需要思考”两类题。统计概率类选择题如果30秒内没有明确思路先跳不要恋战。业务场景题先读最后一问因为腾讯系的场景题往往最后一问才是核心诉求前面都是铺垫信息带着最终问题回头看材料效率高很多。编程题建议放在业务题前面做因为编程题答案是非对即错的做出来就是满分而业务题写得再好也可能因为踩不到得分点给个中等分。两权相害取其轻先把确定性分数拿到手。2. 统计概率与机器学习基础题详解2.1 经典概率题为什么“贝叶斯更新”在业务里无处不在我印象最深的概率题是这样的某推荐策略迭代后点击率预估从2%提升到3%。假设单次曝光点击与否服从伯努利分布现在要给这个策略算一个“95%置信水平下是否存在显著提升”的结论。选项里给了几个不同的检验方法描述让你选错误的那个。这道题表面是假设检验但选项里埋了贝叶斯方法的干扰项。很多人在这里会犹豫到底该用频率学派还是贝叶斯学派。我的建议是遇到这种描述性选择题优先把每个选项里的“术语定义”和“适用条件”拆开看。比如选项中说“贝叶斯方法不需要先验”这明显是错的然后选项中说“两组样本量不同会影响t检验结果”这就是对的再比如“置信区间包含0代表无显著差异”这对频率学派来说是对的。用排除法选出“错误的描述”比直接判断“哪个正确”容易得多。这题背后其实在考察你对“比率类指标显著性检验”的掌握程度。业务里最常见的就是对比实验——新版策略和旧版策略相比点击率、转化率有没有显著提升。你可能手里只有点击率和样本量两组数这时候两个比例的z检验是标配。如果你了解贝叶斯更新还能用Beta-Binomial共轭结构去做序贯决策这在腾讯系的业务题里很吃香因为音乐推荐场景中用户行为是流式产生的实时更新后验分布是个加分项。实操中可以用一个简单公式快速估算某个策略提升是否显著当两个样本量都在几千以上时如果 |p1 - p2| 1.96 * sqrt(p(1-p) * (1/n1 1/n2))其中p为合并后整体转化率则可以说在95%置信水平下有显著差异。这道题我当时直接用这个逻辑套心里踏实很多。如果实在记不住公式也可以用Python快速跑一下以下为答题时的速算脚本import numpy as np from statsmodels.stats.proportion import proportions_ztest # 对照组10000次曝光200次点击实验组10000次曝光300次点击 n1, x1 10000, 200 n2, x2 10000, 300 p1, p2 x1 / n1, x2 / n2 # 合并比例 p (x1 x2) / (n1 n2) se np.sqrt(p * (1 - p) * (1 / n1 1 / n2)) z (p2 - p1) / se print(fz值约等于{z:.2f}) # 输出大于1.96说明有显著差异这道题给我的启发是笔试不是考你会不会推公式而是考你知不知道“什么场景用什么方法”。数据科学职业核心能力里最重要的一条就是方法工具箱的匹配速度。你不能看到“置信区间”就只想到t分布看到“点击率”就只想到漏斗分析得快速在业务描述里捕捉到“两个比例对比”这个本质。2.2 机器学习基础题从“调包”到“知道为什么调包”机器学习部分的题目比较常规但有一道题很能说明问题——它给了一个用户流失预测的二分类场景正负样本比例大概是1:99问以下哪个方案不能有效缓解类别不平衡问题。选项有对多数类做下采样、对少数类做SMOTE过采样、使用F1作为评估指标、直接使用准确率评估模型。如果用“死记硬背”的思路很多人会选“降低分类阈值”但这个选项根本没出现。实际上这道题最迷惑的地方在于“使用F1作为评估指标”这个选项从模型训练角度F1作为评估指标确实能帮助你选择更好的模型但它本身不会改变正负样本的分布也不能“缓解”类别不平衡本身它只是让评估更合理。而“直接使用准确率”在正负样本1:99的背景下会让模型倾向于把所有样本都预测为负类准确率高达99%却没实际意义这显然是“不能缓解”的反例。所以如果题目问的是“哪个不能”反而要选那个看起来“很合理”的F1选项——这类题的陷阱往往藏在选项的措辞里。这道题我见过太多次了几乎是各家大厂数据岗的标配考法。它实际上在考察你对“类别不平衡处理手段”的完整理解数据层面采样、增广、算法层面代价敏感学习、集成学习、评价层面PR曲线、F1。在腾讯音乐的场景里你可能会做付费预测、流失预警、歌曲热度预测都会遇到正负样本极度不均衡的问题。比如平台里付费用户占比可能不到10%你想用模型找“高潜付费用户”如果直接用准确率评估模型就会偷懒地把所有人判为非付费这是实战中一定会踩的坑。还有一道关于XGBoost和逻辑回归对比的题问的是在特征相关性较高的情况下哪个更稳定。正确答案是逻辑回归更稳定因为树模型在做特征分裂时如果两个特征高度相关会出现“选择哪个特征分裂都能得到相似增益”的情况导致单棵树的特征重要性被随机地分到两个特征上。虽然没有破坏整体预测能力但如果你是通过树模型做特征筛选可能误以为某几个特征没用这会影响后续的特征工程。这道题考察的是模型的机制理解不是简单背结论。真正的数据科学工作流应该包含“模型选型→特征筛选→业务解释”的闭环而这对腾讯音乐这种看重推荐和增长的业务来说尤其重要。我当时在答这道题时还引申了一个点逻辑回归虽然稳定但在特征非线性关系复杂时表达能力有限XGBoost虽然对特征相关性敏感但配合SHAP值能挖掘很多交互效应。笔试答题如果只写“XX更稳定”不会得高分一定要写清楚“在什么条件下更稳定、为什么、对业务有什么影响”这才是数据科学岗和算法工程师岗的区别。2.3 关于AUC、召回率和置信区间的关系题AUC相关题目也出现了而且结合了一个很具体的场景在版权音乐推荐中模型A的AUC略高于模型B但A在头部歌曲的召回率远低于B。题目问你该怎么选。这里考察的核心其实是你是否理解“单点指标不能代表全部”——AUC是全局排序质量的度量它对中间阈值区域的区分能力比较敏感并不会直接告诉你“头部用户最关心的那几十首歌推得准不准”。如果你只盯AUC可能模型全局效果好但核心用户刷了两屏都没听到喜欢的新歌很快就会流失。这类题没有绝对标准的答案但一般会被认可的思路是把“AUC”和“头部召回率”分开看AUC用来衡量整体排序能力头部召回率衡量在高价值内容上的定向能力二者并不冲突。如果你要选的模型是为了提升整体时长选A如果是为了优化核心付费用户的新歌发现体验选B。更聪明的答法是先分析业务指标落在哪个漏斗层级再决定模型选型。比如头部歌曲召回低就要看是不是数据不平衡导致头部歌曲曝光太少或者训练样本中头尾权重没调好甚至可以考虑在损失函数里加上头部样本的权重。能写出这个层面的思考基本就能在这道题上拿高分。3. SQL与数据处理题笔试里的“数据工程底子”3.1 连续登录天数与留存率窗口函数的三种写法对比SQL题里有一道经典的连续登录天数计算。表结构是user_id, login_date要求算出每个用户2023年以来的最大连续登录天数并按连续天数降序输出前10个用户。这道题不算难考的是窗口函数ROW_NUMBER()和“日期减去行号”的技巧。我当时用的解法是WITH t1 AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM user_login WHERE login_date BETWEEN 2023-01-01 AND 2023-12-31 ), t2 AS ( SELECT user_id, DATE_SUB(login_date, INTERVAL rn DAY) AS group_date FROM t1 ) SELECT user_id, MAX(continuous_days) AS max_continuous_days FROM ( SELECT user_id, COUNT(*) AS continuous_days, group_date FROM t2 GROUP BY user_id, group_date ) t3 GROUP BY user_id ORDER BY max_continuous_days DESC LIMIT 10;这个解法的核心逻辑是登录日期和行号同时减去某个基准如果用户是连续登录的减出来的“组标识”相同连续断了组标识就变了。第一次接触这个思路可能觉得绕但多写几次会形成肌肉记忆几乎90%的“连续”类问题都能用这个思路解。做题时要注意一个问题login_date里有没有重复记录如果同一天有多次登录需要先去重。我那次答题时忽略了这一点导致抽样自测时连续天数比预期多了一天。题目虽然没说有重复但明细表通常会有重复访问稳妥起见应该在t1里先SELECT DISTINCT user_id, login_date。这个细节不扣分则已一扣就是整题0分因为后续所有分组都会被带偏。还有一种更进阶的解法用LAG()判断前后日期差值是否为1然后打标记计算连续组。这个思路更适合处理“间隔小于等于N天也算连续”的扩展需求。笔试时我建议用第一种解法因为它逻辑最直观、不容易写错面试被追问扩展需求时再把第二种抛出来会显得你有纵深。3.2 留存率计算日期表关联的九九归一法另一道SQL题是算7日留存和30日留存。给定user_id, register_date, login_date要求输出每日新增用户的次日留存率、7日留存率、30日留存率。这题常见做法是把注册表作为主表左关联登录表再按注册日期聚合。我当时写的是SELECT r.register_date, COUNT(DISTINCT r.user_id) AS new_users, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 1 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d1_retention, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 7 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d7_retention, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 30 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d30_retention FROM new_user_registration r LEFT JOIN user_login l ON r.user_id l.user_id AND l.login_date IN ( DATE_ADD(r.register_date, INTERVAL 1 DAY), DATE_ADD(r.register_date, INTERVAL 7 DAY), DATE_ADD(r.register_date, INTERVAL 30 DAY) ) GROUP BY r.register_date;这里有个很重要的点LEFT JOIN的关联条件里同时放“时间窗口”和“用户ID”能极大减少中间结果的数据量。很多人习惯先全部join再where筛选这在数据量大的时候容易把中间表撑爆笔试虽不考性能但面试官看到你的join条件写得干净会加分不少。另一个容易被忽略的点留存率的分子和分母都要加DISTINCT防止用户在同一天有多条访问记录导致重复计数。尽管很多公司数仓里的登录表做了去重但从严谨角度讲DISTINCT是数据科学岗的职业习惯。3.3 会话切分用户行为序列处理的前置技能SQL第三题是算会话数。给定user_id, event_time, event_name定义同一个用户相邻两条行为事件时间差超过30分钟则标记为一次新会话计算每个用户一天内的会话数。这个问题的标准解法是用LAG()取上一个事件时间然后比较差值WITH t1 AS ( SELECT user_id, event_time, LAG(event_time) OVER(PARTITION BY user_id ORDER BY event_time) AS prev_time FROM user_events WHERE DATE(event_time) 2023-09-01 ) SELECT user_id, COUNT(*) AS session_count FROM ( SELECT user_id, event_time, SUM( CASE WHEN prev_time IS NULL OR TIMESTAMPDIFF(MINUTE, prev_time, event_time) 30 THEN 1 ELSE 0 END ) OVER(PARTITION BY user_id ORDER BY event_time) AS session_id FROM t1 ) t2 GROUP BY user_id;这道题看似是写SQL其实在考察你处理“行为序列数据”的基本功。真实业务中你在做用户路径分析、异常行为识别、推荐效果评估时第一步功夫就是把原始埋点切成有意义的会话。还以腾讯音乐为例一个用户可能早中晚各打开一次App每次包含十几条操作日志只有正确切分会话才能算出“人均session数”“单session点赞率”“session内跳转路径”这些高级指标。如果这一步就有bug后面所有分析都是谬之千里。我见过很多候选人简历上写着“精通SQL熟悉Hive”但真正写到这种稍微需要一点的逻辑题就卡壳。本质问题是平时只做简单的SELECT, WHERE, GROUP BY很少接触窗口函数。这批笔试题里SQL部分整体难度中等但它会暴露你平时在数仓里到底干的是“取数”还是“做分析”。4. 业务场景案例分析数据科学工作流的完整闭环4.1 从点击归因到预算优化的闭环实践一道完整的SEM场景题这次笔试的业务场景题出了一道和广告相关的综合大题背景相当贴近真实业务某音乐平台在外部渠道投放广告包含社交媒体、短视频、搜索等渠道用户点击广告后可能当天就下载App也可能隔几天才下载。现在需要做两件事第一设计一个归因模型决定每个渠道应该获得多少下载转化功劳第二基于归因结果优化各渠道预算分配使整体获客成本最低。这就是热词里说的“SEM数据科学工作流从点击归因到预算优化的闭环实践”。一开始看到这道题我愣了一下因为市面上大多数分析课程只讲“归因”或只讲“预算分配”很少把两者串起来。但实际业务里这确实是一个闭环归因看清楚每个渠道贡献了多少转化是预算分配把钱花到最有效的渠道的输入而预算调整后反馈回来的新数据又会重新影响归因结果。如果你只是在笔试里写“用Shapley值做归因”或者“用线性规划做预算分配”而不提闭环带来的数据反馈问题说明你还停留在方法论层面。我当时的答题思路是这样的首先明确归因目标不是“看个热闹”而是为了指导预算调整所以归因模型的选择要考虑可解释性和稳定性。第一梯队推荐用基于Shapley值的多触点归因——在渠道数少于10个时这个方法很实用它能把“每个渠道在不同组合下的边际贡献”平均化得到稳定且公平的贡献度。第二梯队是可解释的机器学习模型比如带线性项的LightGBM或逻辑回归直接把渠道曝光量或点击量作为特征预测最终转化概率然后用特征重要性近似归因。但缺点是树模型的特征重要性只代表“预测贡献”不代表“因果贡献”容易受到渠道曝光量本身大小的影响。预算分配部分普通答法是“把钱投给ROI最高的渠道”这个答案只能拿基础分。更好的答法是引入预算弹性约束假设渠道曝光量翻倍时转化率不一定翻倍而是服从一个递减的边际曲线然后在这个约束下求最优分配。笔试时间有限不需要真正解出数值重点是写出约束条件和目标函数。我当时给的是类似这样的思路假设第i个渠道的获客量 f_i(x_i)其中x_i为该渠道预算f_i为单调递增且边际递减的函数。我们的目标是minimize 总获客成本 Σ x_i / Σ f_i(x_i) subject to Σ x_i B总预算固定 x_i ≥ 0同时考虑频次控制和跨渠道协同同一用户可能既看了信息流广告又点了搜索广告如果直接按各个渠道独立优化会造成预算浪费和归因过度重叠。更扎实的做法是引入“转化路径”级别的建模把用户看到广告的序列当成一个整体用马尔可夫链三明治法求每个渠道在整条路径中的平均移除贡献。马尔可夫链的想法很直接把用户转化路径看成状态转移移除某个渠道后如果整体转化率明显下降说明该渠道很重要把所有渠道的“影响值”归一化就是每个渠道的贡献权重。这道题写的篇幅最长也是我认为整套卷子最有区分度的地方。能独立写出“归因-预算-反馈”链条的人哪怕细节不完美面试官也大概率愿意给高分因为这说明你做过真实的增长分析而不是只会套模板。4.2 指标异动排查DAU下降了你第一步做什么业务场景题还有一道很经典的某音乐App的日活用户数连续三天下降2%但同期新用户数稳定问你怎么排查原因。这道题没有代码要求纯粹考察分析框架也是我见过最多次的面试题变种。答这种题一定要有结构和优先级不能胡子眉毛一把抓。我当时按“拆分母→拆维度→验因果”三步走写的。第一步确认DAU的定义有没有变化是不是修正了渠道归因导致某些设备不再计数是不是改版后埋点上报策略变了导致部分老版本客户端数据缺失这听起来很基础但真实情况下很多指标异动到最后查出来都是口径变化而不是业务恶化。第二步DAU 新增用户 老用户回流 存量用户活跃。新增用户稳定那重点看老用户回流和存量活跃。需要按平台、版本、地区、渠道拆解定位下降集中在前端还是后端。比如是否只有iOS端下降是否只有某个老版本下降是否只在某几个省份下降这里建议再拆一层“活跃质量”比如人均使用时长有没有同步下降如果时长没降只是人数降可能是部分低活跃用户被淘汰会影响不太大如果时长和人数一起降那就是核心用户体验出了问题。第三步因果验证。罗列可能的假设比如七夕等活动结束导致回落、热门歌曲独家版权到期、竞品大促分流、推送策略限制等一个个用数据验证。比如若怀疑某头部歌曲版权到期就查这首歌的播放量趋势和贡献DAU若怀疑推送策略调整就查推送到达率和点击率变化。最后给出结论和监控建议建立核心指标的异常预警规则类似“DAU连续N天下降超过X%且偏离历史波动范围”自动触发日报。这道题其实在考察数据科学职业核心能力里的“业务定义能力”和“假设驱动思维”。很多新手容易犯的错误是一上来就做复杂的用户分层、机器学习预测忘了先看分母和口径。真正的数据科学工作流应该永远从业务问题出发而不是从模型出发。4.3 推荐系统面试题离线评估和线上指标不一致怎么办还有一个问答题稍微偏推荐方向离线AUC涨了线上点击率却跌了可能是什么原因这题也不属于纯笔试中的“客观题”范畴但基本每年都会出现。我归纳了四个最可能的方向笔试时可以从这四个角度展开每个方向补充一个例子基本就能拿满。第一离线在线特征不一致。模型上线后如果特征拼接链路出错比如离线用了某个昨日特征线上却用了实时默认值模型效果一定崩。这类问题在推荐、广告系统里最隐蔽排查也需要核对特征日志和上线配置。第二样本选择偏差。离线训练时用的是“有曝光才有反馈”的样本但线上模型会给新内容打分会带来“新的曝光机会”这些新曝光的行为分布和训练分布不一样自然会导致离线/在线差异。第三评估指标本身的问题。离线AUC衡量的是排序正确率线上点击率是偏绝对值的指标两者并不线性等价。一个模型可能把排序整体做得更好了但因为推荐列表头部的旧爆款被换掉导致用户第一屏的点开意愿反而下降这在短时数据上可能表现为点击率下跌。第四时间窗口的不一致。离线评估如果用的是和线上不一致的样本时间窗口比如离线用了过去30天训练并验证模型线上策略只上线了3天新模型还没来得及适配近期热度和用户兴趣的短期变化效果容易出现波动。这题的答题思路能直接反映你有没有真正做过推荐相关项目。如果你只在Kaggle上跑过模型而没有接触过线上系统大概率只答得出“数据泄露”“过拟合”这类常规答案很难答到“特征链路一致性和评估指标错位”这种层面。5. 编程题思路与笔试准备建议5.1 编程题考察点不是算法竞赛是工程思维编程题一共两题第一题是动态规划给定一个数组求连续子数组最大和。经典到不能再经典但限制条件不能使用额外数组只允许O(1)空间。这道题应该所有人都会做核心就是Kadane算法def max_subarray_sum(arr): if not arr: return 0 current_max global_max arr[0] for num in arr[1:]: current_max max(num, current_max num) global_max max(global_max, current_max) return global_max这题考察的不是算法技巧而是你在紧张状态下还能不能写出无bug的边界条件。比如空数组、全负数数组这些边界值很多人一紧张就忽略。递推公式是dp[i] max(dp[i-1] arr[i], arr[i])但更关键的是理解为什么空间可以压缩到O(1)——因为当前状态只依赖前一个状态不需要记录整个dp数组。第二题是基于“好友关注关系”的推荐题给一组关注关系[follower_id, followee_id]找出“可能认识的人”——即你和某个人有两个以上共同关注的人但你们尚未互相关注按共同关注人数降序输出。这个题我在笔试时用的解法是构造“用户→关注列表”映射然后暴力两两比较因为笔试数据量不会太大。更高效的方法是用倒排索引先建“被关注者→关注者列表”的倒排表然后遍历每个用户的关注列表两两组合计数。这个思路和计算共同好友、商品协同过滤、歌曲协同过滤是同一个套路。def recommend_friends(follow_relations): follow_map {} for follower, followee in follow_relations: follow_map.setdefault(follower, set()).add(followee) follow_map.setdefault(followee, set()) suggestions {} for user in follow_map: followed follow_map[user] for followee in followed: for candidate in follow_map.get(followee, set()): if candidate ! user and candidate not in followed: common len(followed follow_map[candidate]) if common 2: key (user, candidate) suggestions[key] common result sorted(suggestions.items(), keylambda x: x[1], reverseTrue) return [(a, b, cnt) for (a, b), cnt in result]这道题的本质和音乐平台的“相似用户推荐”“歌单协同过滤”非常接近。如果你在简历里写过推荐相关的项目面试官看向你的眼神都会不一样因为这表明你具备把推荐算法落到工程代码里的能力而不只是会用现成的库。5.2 备考建议围绕数据科学职业核心能力做刻意练习我整理了大概三周的备考计划基于腾讯音乐这批真题做专项训练。第一周主攻统计概率和机器学习基础重点是二项分布、正态分布、假设检验、贝叶斯公式、常见模型对比LR、树模型、KNN、朴素贝叶斯。资料上推荐《统计学习方法》前几章加StatQuest的视频两者配合效率高。第二周集中刷SQL窗口函数题每天至少5道覆盖连续性问题、TopN问题、留存率、会话切分、行列互转直接在LeetCode数据库题库里找中等难度的题。第三周做业务场景模拟从“某个指标下降”开始练习排查框架再自己找几个公开数据集做简单的归因分析或预算分配建模。对于“数据科学与大数据技术就业方向”这个热词我也多说一句这个方向的毕业生如果目标是大厂数据科学岗最需要补的不是建模能力而是SQL和业务思维的衔接。算法岗位门槛高、需求量少、竞争激烈数据科学岗位更看重你是否有能力把业务问题转化成数据问题再把数据结论翻译回业务语言。腾讯音乐这套笔试的题型分布其实已经暗示了它们更看重的还是“扎实基本功清晰业务逻辑”。一个比较实用的备考技巧是每次做完一套真题都把错题按“知识盲区”“审题失误”“速度不够”三类归类而不是笼统改成“学习不够”。知识盲区需要系统补课审题失误需要平时练题时强迫自己圈出关键词速度不够则需要专项限时刷题。这套方法坚持两周提分效果明显。笔试前也可以多去了解目标公司的业务形态。比如投腾讯音乐就应该提前了解它的产品矩阵、核心指标月活、日活、付费率、播放时长等、主要推荐场景每日推荐、歌单推荐、搜索、直播以及会员转化路径。业务场景题给你的材料可能没有具体数字但如果你对业务足够熟就能答出更有针对性的建议而不是泛泛而谈“提高用户粘性”。6. 这批笔试题的隐藏考点从做题到做事的思维升级6.1 为什么说“归因-预算-反馈”是整场笔试的分水岭前面说了很多具体题目现在想脱离题目本身聊聊这套笔试隐含的“职级思维”。腾讯音乐这套题里SQL题和概率题解决的是“能不能干活”的问题而场景题中的归因预算题解决的是“能不能扛事”的问题。一个只会写SQL、调参、跑模型的人和一个能独立负责业务指标、给出决策建议的人在职级上可能就是P5和P7的差别。归因预算这道题之所以是分水岭是因为它同时考察了你三种能力归因模型选型与计算的落地能力、预算优化问题中约束条件的拆解能力、以及“数据-决策-数据”闭环的复盘意识。如果你能在这个题里主动提到“归因结果影响预算分配预算调整后各渠道的用户质量发生变化需要重新校准归因模型”哪怕算法细节写得不够完美面试官也会觉得你具备较强的业务闭环意识。反过来如果你只把归因和预算当成两个独立模块去写就说明你还没有真正在业务中做过“数据驱动增长”的完整项目。6.2 一个可能被忽略的细节渠道曝光量与归因的因果偏差最后再补充一个容易被绝大多数候选人忽略的点在归因预算这类题目里如果你推荐用机器学习模型做归因一定要提“曝光量对模型归因的干扰”。举个具体例子短视频渠道的曝光量可能远大于搜索渠道树模型在训练时会把“曝光量”当成一个强特征于是误以为短视频渠道贡献最大。但实际情况可能是搜索渠道来的用户搜索意图更强、付费意愿更高只是因为搜索曝光量基数小总贡献看起来不如短视频。这就是典型的“popularity bias”。怎么缓解可以从样本权重或特征构造角度回答在归因模型训练时对渠道曝光做某种降权处理或者构造“点击率/曝光量”这样的比值特征而不是把曝光量的绝对值直接放进模型。这个层次的答案能立刻拉开你和普通候选人的差距因为它说明你不是只会拿现成模型跑数据而是能理解数据背后的业务逻辑和潜在偏差。这种“偏差意识”在数据科学职业核心能力里被反复强调但在实际工作中很多人一遇到业务指标波动就开始盲目建模忽略了数据本身的生成机制。一个合格的数据科学从业者应该像侦探一样首先怀疑数据的生成过程而不是直接跳进模型调参。6.3 关于时间分配和答题策略的再思考整套题做下来我最大的遗憾是在概率选择题上花的时间略多导致编程题写得比较赶。如果能重来一次我会严格遵循“每个选择题最多3分钟超过就标记跳过”的策略。数据科学岗笔试不是要把每道题都做对而是要在有限时间拿到最多加权分。题目的分值分布通常不会明确标出但可以根据题型推断一个大致权重选择题数量多、主观题数量少。如果你时间紧张优先保证主观题有完整思路和清晰表达比死磕一道选择题值钱得多。因为单选、多选是零分或满分而主观题只要你踩中得分点哪怕没有最终数值也能拿到不少过程分。另外给一个小技巧如果笔试平台允许返回修改一般在交卷前都可以第一遍把所有题快速过一遍把自己确定能拿分的题先答完第二遍再回头啃没做出来的。很多平台会显示“未答题数”看着那个红色数字压力会很大但越到这时候越要先保分再攻坚。写在最后一次笔试暴露的数据科学能力全景我个人复盘完这套题的最大感受是腾讯音乐这批秋招笔试题难得不在具体某个知识点而在它把所有知识点都放到了真实业务场景里。这不是一套刷题刷出来的题而是一套“做事做出来的题”。如果你平时只是刷Kaggle、背面试题、看机器学习课程你会发现每一道题都眼熟但就是答不透。反过来如果你做过真实的用户分析、广告归因、推荐评估项目这套题答起来会顺很多。腾讯音乐的数据科学岗业务侧重很明显内容推荐、用户增长、商业化变现三大方向。所以准备笔试时别只盯着机器学习算法推导多花时间想想“指标为什么涨跌”“模型评估和线上效果为什么不一致”“预算怎么花才能带来更多确定性增长”。数据科学岗真正值钱的地方从来不是算法本身而是用数据帮业务做决策的能力。这套笔试就是一面照妖镜把你的真实水平照得明明白白。 腾讯音乐秋招数据科学岗笔试题复盘：从统计概率到业务闭环
每年这个时候都是秋招笔试最密集的阶段。作为一个连续参加过两届大厂数据科学岗笔试、也陪身边不少学弟学妹复盘过题目的老数据人我对这套腾讯音乐秋招数据科学岗第二批笔试题印象挺深。它的风格很有代表性不搞偏题怪题但非常考验你把统计、机器学习、SQL、业务分析串起来的能力尤其是最后几道业务场景题直接对标真实工作中“从数据到决策”的链路。这篇文章我会完整复盘这套笔试题的核心内容包括我自己的解题思路、踩过的坑以及从面试官角度反推回来的评分点。无论你是正在准备数据科学岗秋招还是想系统补一下数据科学职业核心能力这篇都能给你一个比较落地的参考框架。文章比较长建议先收藏再慢慢看尤其是准备投腾讯、腾讯音乐的这套题的思路复用价值很高。1. 笔试整体复盘与题型分布1.1 这次笔试考了什么四类题型背后的真实筛选逻辑第二批笔试整体分为四个部分统计概率与机器学习基础、SQL与数据处理、业务场景案例分析、编程题。分值占比大概是统计概率和SQL各占30%业务场景占25%编程题占15%左右。整体时间很紧张满分100分的话我体感能稳定做完并检查一遍的人不多多数人会在业务场景题上耗费大量时间。先说题型分布背后的筛选逻辑。四分法看起来常规其实是在测三个维度基础理论的扎实程度、工程落地的熟练度、业务思维的敏感度。统计概率和机器学习基础考的是你有没有建立完整的知识框架——这决定了入职后能不能接住分析类需求SQL和编程题考的是你有没有动手能力——数据科学不是纯算法岗天天要跟数仓打交道业务场景题则是区分度最大的部分它决定了你是“会做分析的人”还是“能解决问题的人”。一个值得注意的细节是这套题的统计题几乎全部带业务背景不是干巴巴地让算概率而是把概率放进用户行为场景里比如“用户连续打开App天数”“推荐流点击概率异常波动”。这一点比较像腾讯系笔试的风格题目本身不难但审题不仔细容易把简单问题复杂化。1.2 时间分配策略先保大分再啃硬骨头75分钟做大概12道题不完全统计可能有微调其中选择题8道左右问答题和编程题4道左右。我身边做完的同学反馈高度一致选择题看似简单但坑很多单题耗时远超预期编程题反而还好因为思路相对固定。我的建议是先快速扫一遍所有题目在卷面上标记出“确定能做对”和“需要思考”两类题。统计概率类选择题如果30秒内没有明确思路先跳不要恋战。业务场景题先读最后一问因为腾讯系的场景题往往最后一问才是核心诉求前面都是铺垫信息带着最终问题回头看材料效率高很多。编程题建议放在业务题前面做因为编程题答案是非对即错的做出来就是满分而业务题写得再好也可能因为踩不到得分点给个中等分。两权相害取其轻先把确定性分数拿到手。2. 统计概率与机器学习基础题详解2.1 经典概率题为什么“贝叶斯更新”在业务里无处不在我印象最深的概率题是这样的某推荐策略迭代后点击率预估从2%提升到3%。假设单次曝光点击与否服从伯努利分布现在要给这个策略算一个“95%置信水平下是否存在显著提升”的结论。选项里给了几个不同的检验方法描述让你选错误的那个。这道题表面是假设检验但选项里埋了贝叶斯方法的干扰项。很多人在这里会犹豫到底该用频率学派还是贝叶斯学派。我的建议是遇到这种描述性选择题优先把每个选项里的“术语定义”和“适用条件”拆开看。比如选项中说“贝叶斯方法不需要先验”这明显是错的然后选项中说“两组样本量不同会影响t检验结果”这就是对的再比如“置信区间包含0代表无显著差异”这对频率学派来说是对的。用排除法选出“错误的描述”比直接判断“哪个正确”容易得多。这题背后其实在考察你对“比率类指标显著性检验”的掌握程度。业务里最常见的就是对比实验——新版策略和旧版策略相比点击率、转化率有没有显著提升。你可能手里只有点击率和样本量两组数这时候两个比例的z检验是标配。如果你了解贝叶斯更新还能用Beta-Binomial共轭结构去做序贯决策这在腾讯系的业务题里很吃香因为音乐推荐场景中用户行为是流式产生的实时更新后验分布是个加分项。实操中可以用一个简单公式快速估算某个策略提升是否显著当两个样本量都在几千以上时如果 |p1 - p2| 1.96 * sqrt(p(1-p) * (1/n1 1/n2))其中p为合并后整体转化率则可以说在95%置信水平下有显著差异。这道题我当时直接用这个逻辑套心里踏实很多。如果实在记不住公式也可以用Python快速跑一下以下为答题时的速算脚本import numpy as np from statsmodels.stats.proportion import proportions_ztest # 对照组10000次曝光200次点击实验组10000次曝光300次点击 n1, x1 10000, 200 n2, x2 10000, 300 p1, p2 x1 / n1, x2 / n2 # 合并比例 p (x1 x2) / (n1 n2) se np.sqrt(p * (1 - p) * (1 / n1 1 / n2)) z (p2 - p1) / se print(fz值约等于{z:.2f}) # 输出大于1.96说明有显著差异这道题给我的启发是笔试不是考你会不会推公式而是考你知不知道“什么场景用什么方法”。数据科学职业核心能力里最重要的一条就是方法工具箱的匹配速度。你不能看到“置信区间”就只想到t分布看到“点击率”就只想到漏斗分析得快速在业务描述里捕捉到“两个比例对比”这个本质。2.2 机器学习基础题从“调包”到“知道为什么调包”机器学习部分的题目比较常规但有一道题很能说明问题——它给了一个用户流失预测的二分类场景正负样本比例大概是1:99问以下哪个方案不能有效缓解类别不平衡问题。选项有对多数类做下采样、对少数类做SMOTE过采样、使用F1作为评估指标、直接使用准确率评估模型。如果用“死记硬背”的思路很多人会选“降低分类阈值”但这个选项根本没出现。实际上这道题最迷惑的地方在于“使用F1作为评估指标”这个选项从模型训练角度F1作为评估指标确实能帮助你选择更好的模型但它本身不会改变正负样本的分布也不能“缓解”类别不平衡本身它只是让评估更合理。而“直接使用准确率”在正负样本1:99的背景下会让模型倾向于把所有样本都预测为负类准确率高达99%却没实际意义这显然是“不能缓解”的反例。所以如果题目问的是“哪个不能”反而要选那个看起来“很合理”的F1选项——这类题的陷阱往往藏在选项的措辞里。这道题我见过太多次了几乎是各家大厂数据岗的标配考法。它实际上在考察你对“类别不平衡处理手段”的完整理解数据层面采样、增广、算法层面代价敏感学习、集成学习、评价层面PR曲线、F1。在腾讯音乐的场景里你可能会做付费预测、流失预警、歌曲热度预测都会遇到正负样本极度不均衡的问题。比如平台里付费用户占比可能不到10%你想用模型找“高潜付费用户”如果直接用准确率评估模型就会偷懒地把所有人判为非付费这是实战中一定会踩的坑。还有一道关于XGBoost和逻辑回归对比的题问的是在特征相关性较高的情况下哪个更稳定。正确答案是逻辑回归更稳定因为树模型在做特征分裂时如果两个特征高度相关会出现“选择哪个特征分裂都能得到相似增益”的情况导致单棵树的特征重要性被随机地分到两个特征上。虽然没有破坏整体预测能力但如果你是通过树模型做特征筛选可能误以为某几个特征没用这会影响后续的特征工程。这道题考察的是模型的机制理解不是简单背结论。真正的数据科学工作流应该包含“模型选型→特征筛选→业务解释”的闭环而这对腾讯音乐这种看重推荐和增长的业务来说尤其重要。我当时在答这道题时还引申了一个点逻辑回归虽然稳定但在特征非线性关系复杂时表达能力有限XGBoost虽然对特征相关性敏感但配合SHAP值能挖掘很多交互效应。笔试答题如果只写“XX更稳定”不会得高分一定要写清楚“在什么条件下更稳定、为什么、对业务有什么影响”这才是数据科学岗和算法工程师岗的区别。2.3 关于AUC、召回率和置信区间的关系题AUC相关题目也出现了而且结合了一个很具体的场景在版权音乐推荐中模型A的AUC略高于模型B但A在头部歌曲的召回率远低于B。题目问你该怎么选。这里考察的核心其实是你是否理解“单点指标不能代表全部”——AUC是全局排序质量的度量它对中间阈值区域的区分能力比较敏感并不会直接告诉你“头部用户最关心的那几十首歌推得准不准”。如果你只盯AUC可能模型全局效果好但核心用户刷了两屏都没听到喜欢的新歌很快就会流失。这类题没有绝对标准的答案但一般会被认可的思路是把“AUC”和“头部召回率”分开看AUC用来衡量整体排序能力头部召回率衡量在高价值内容上的定向能力二者并不冲突。如果你要选的模型是为了提升整体时长选A如果是为了优化核心付费用户的新歌发现体验选B。更聪明的答法是先分析业务指标落在哪个漏斗层级再决定模型选型。比如头部歌曲召回低就要看是不是数据不平衡导致头部歌曲曝光太少或者训练样本中头尾权重没调好甚至可以考虑在损失函数里加上头部样本的权重。能写出这个层面的思考基本就能在这道题上拿高分。3. SQL与数据处理题笔试里的“数据工程底子”3.1 连续登录天数与留存率窗口函数的三种写法对比SQL题里有一道经典的连续登录天数计算。表结构是user_id, login_date要求算出每个用户2023年以来的最大连续登录天数并按连续天数降序输出前10个用户。这道题不算难考的是窗口函数ROW_NUMBER()和“日期减去行号”的技巧。我当时用的解法是WITH t1 AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM user_login WHERE login_date BETWEEN 2023-01-01 AND 2023-12-31 ), t2 AS ( SELECT user_id, DATE_SUB(login_date, INTERVAL rn DAY) AS group_date FROM t1 ) SELECT user_id, MAX(continuous_days) AS max_continuous_days FROM ( SELECT user_id, COUNT(*) AS continuous_days, group_date FROM t2 GROUP BY user_id, group_date ) t3 GROUP BY user_id ORDER BY max_continuous_days DESC LIMIT 10;这个解法的核心逻辑是登录日期和行号同时减去某个基准如果用户是连续登录的减出来的“组标识”相同连续断了组标识就变了。第一次接触这个思路可能觉得绕但多写几次会形成肌肉记忆几乎90%的“连续”类问题都能用这个思路解。做题时要注意一个问题login_date里有没有重复记录如果同一天有多次登录需要先去重。我那次答题时忽略了这一点导致抽样自测时连续天数比预期多了一天。题目虽然没说有重复但明细表通常会有重复访问稳妥起见应该在t1里先SELECT DISTINCT user_id, login_date。这个细节不扣分则已一扣就是整题0分因为后续所有分组都会被带偏。还有一种更进阶的解法用LAG()判断前后日期差值是否为1然后打标记计算连续组。这个思路更适合处理“间隔小于等于N天也算连续”的扩展需求。笔试时我建议用第一种解法因为它逻辑最直观、不容易写错面试被追问扩展需求时再把第二种抛出来会显得你有纵深。3.2 留存率计算日期表关联的九九归一法另一道SQL题是算7日留存和30日留存。给定user_id, register_date, login_date要求输出每日新增用户的次日留存率、7日留存率、30日留存率。这题常见做法是把注册表作为主表左关联登录表再按注册日期聚合。我当时写的是SELECT r.register_date, COUNT(DISTINCT r.user_id) AS new_users, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 1 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d1_retention, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 7 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d7_retention, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 30 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d30_retention FROM new_user_registration r LEFT JOIN user_login l ON r.user_id l.user_id AND l.login_date IN ( DATE_ADD(r.register_date, INTERVAL 1 DAY), DATE_ADD(r.register_date, INTERVAL 7 DAY), DATE_ADD(r.register_date, INTERVAL 30 DAY) ) GROUP BY r.register_date;这里有个很重要的点LEFT JOIN的关联条件里同时放“时间窗口”和“用户ID”能极大减少中间结果的数据量。很多人习惯先全部join再where筛选这在数据量大的时候容易把中间表撑爆笔试虽不考性能但面试官看到你的join条件写得干净会加分不少。另一个容易被忽略的点留存率的分子和分母都要加DISTINCT防止用户在同一天有多条访问记录导致重复计数。尽管很多公司数仓里的登录表做了去重但从严谨角度讲DISTINCT是数据科学岗的职业习惯。3.3 会话切分用户行为序列处理的前置技能SQL第三题是算会话数。给定user_id, event_time, event_name定义同一个用户相邻两条行为事件时间差超过30分钟则标记为一次新会话计算每个用户一天内的会话数。这个问题的标准解法是用LAG()取上一个事件时间然后比较差值WITH t1 AS ( SELECT user_id, event_time, LAG(event_time) OVER(PARTITION BY user_id ORDER BY event_time) AS prev_time FROM user_events WHERE DATE(event_time) 2023-09-01 ) SELECT user_id, COUNT(*) AS session_count FROM ( SELECT user_id, event_time, SUM( CASE WHEN prev_time IS NULL OR TIMESTAMPDIFF(MINUTE, prev_time, event_time) 30 THEN 1 ELSE 0 END ) OVER(PARTITION BY user_id ORDER BY event_time) AS session_id FROM t1 ) t2 GROUP BY user_id;这道题看似是写SQL其实在考察你处理“行为序列数据”的基本功。真实业务中你在做用户路径分析、异常行为识别、推荐效果评估时第一步功夫就是把原始埋点切成有意义的会话。还以腾讯音乐为例一个用户可能早中晚各打开一次App每次包含十几条操作日志只有正确切分会话才能算出“人均session数”“单session点赞率”“session内跳转路径”这些高级指标。如果这一步就有bug后面所有分析都是谬之千里。我见过很多候选人简历上写着“精通SQL熟悉Hive”但真正写到这种稍微需要一点的逻辑题就卡壳。本质问题是平时只做简单的SELECT, WHERE, GROUP BY很少接触窗口函数。这批笔试题里SQL部分整体难度中等但它会暴露你平时在数仓里到底干的是“取数”还是“做分析”。4. 业务场景案例分析数据科学工作流的完整闭环4.1 从点击归因到预算优化的闭环实践一道完整的SEM场景题这次笔试的业务场景题出了一道和广告相关的综合大题背景相当贴近真实业务某音乐平台在外部渠道投放广告包含社交媒体、短视频、搜索等渠道用户点击广告后可能当天就下载App也可能隔几天才下载。现在需要做两件事第一设计一个归因模型决定每个渠道应该获得多少下载转化功劳第二基于归因结果优化各渠道预算分配使整体获客成本最低。这就是热词里说的“SEM数据科学工作流从点击归因到预算优化的闭环实践”。一开始看到这道题我愣了一下因为市面上大多数分析课程只讲“归因”或只讲“预算分配”很少把两者串起来。但实际业务里这确实是一个闭环归因看清楚每个渠道贡献了多少转化是预算分配把钱花到最有效的渠道的输入而预算调整后反馈回来的新数据又会重新影响归因结果。如果你只是在笔试里写“用Shapley值做归因”或者“用线性规划做预算分配”而不提闭环带来的数据反馈问题说明你还停留在方法论层面。我当时的答题思路是这样的首先明确归因目标不是“看个热闹”而是为了指导预算调整所以归因模型的选择要考虑可解释性和稳定性。第一梯队推荐用基于Shapley值的多触点归因——在渠道数少于10个时这个方法很实用它能把“每个渠道在不同组合下的边际贡献”平均化得到稳定且公平的贡献度。第二梯队是可解释的机器学习模型比如带线性项的LightGBM或逻辑回归直接把渠道曝光量或点击量作为特征预测最终转化概率然后用特征重要性近似归因。但缺点是树模型的特征重要性只代表“预测贡献”不代表“因果贡献”容易受到渠道曝光量本身大小的影响。预算分配部分普通答法是“把钱投给ROI最高的渠道”这个答案只能拿基础分。更好的答法是引入预算弹性约束假设渠道曝光量翻倍时转化率不一定翻倍而是服从一个递减的边际曲线然后在这个约束下求最优分配。笔试时间有限不需要真正解出数值重点是写出约束条件和目标函数。我当时给的是类似这样的思路假设第i个渠道的获客量 f_i(x_i)其中x_i为该渠道预算f_i为单调递增且边际递减的函数。我们的目标是minimize 总获客成本 Σ x_i / Σ f_i(x_i) subject to Σ x_i B总预算固定 x_i ≥ 0同时考虑频次控制和跨渠道协同同一用户可能既看了信息流广告又点了搜索广告如果直接按各个渠道独立优化会造成预算浪费和归因过度重叠。更扎实的做法是引入“转化路径”级别的建模把用户看到广告的序列当成一个整体用马尔可夫链三明治法求每个渠道在整条路径中的平均移除贡献。马尔可夫链的想法很直接把用户转化路径看成状态转移移除某个渠道后如果整体转化率明显下降说明该渠道很重要把所有渠道的“影响值”归一化就是每个渠道的贡献权重。这道题写的篇幅最长也是我认为整套卷子最有区分度的地方。能独立写出“归因-预算-反馈”链条的人哪怕细节不完美面试官也大概率愿意给高分因为这说明你做过真实的增长分析而不是只会套模板。4.2 指标异动排查DAU下降了你第一步做什么业务场景题还有一道很经典的某音乐App的日活用户数连续三天下降2%但同期新用户数稳定问你怎么排查原因。这道题没有代码要求纯粹考察分析框架也是我见过最多次的面试题变种。答这种题一定要有结构和优先级不能胡子眉毛一把抓。我当时按“拆分母→拆维度→验因果”三步走写的。第一步确认DAU的定义有没有变化是不是修正了渠道归因导致某些设备不再计数是不是改版后埋点上报策略变了导致部分老版本客户端数据缺失这听起来很基础但真实情况下很多指标异动到最后查出来都是口径变化而不是业务恶化。第二步DAU 新增用户 老用户回流 存量用户活跃。新增用户稳定那重点看老用户回流和存量活跃。需要按平台、版本、地区、渠道拆解定位下降集中在前端还是后端。比如是否只有iOS端下降是否只有某个老版本下降是否只在某几个省份下降这里建议再拆一层“活跃质量”比如人均使用时长有没有同步下降如果时长没降只是人数降可能是部分低活跃用户被淘汰会影响不太大如果时长和人数一起降那就是核心用户体验出了问题。第三步因果验证。罗列可能的假设比如七夕等活动结束导致回落、热门歌曲独家版权到期、竞品大促分流、推送策略限制等一个个用数据验证。比如若怀疑某头部歌曲版权到期就查这首歌的播放量趋势和贡献DAU若怀疑推送策略调整就查推送到达率和点击率变化。最后给出结论和监控建议建立核心指标的异常预警规则类似“DAU连续N天下降超过X%且偏离历史波动范围”自动触发日报。这道题其实在考察数据科学职业核心能力里的“业务定义能力”和“假设驱动思维”。很多新手容易犯的错误是一上来就做复杂的用户分层、机器学习预测忘了先看分母和口径。真正的数据科学工作流应该永远从业务问题出发而不是从模型出发。4.3 推荐系统面试题离线评估和线上指标不一致怎么办还有一个问答题稍微偏推荐方向离线AUC涨了线上点击率却跌了可能是什么原因这题也不属于纯笔试中的“客观题”范畴但基本每年都会出现。我归纳了四个最可能的方向笔试时可以从这四个角度展开每个方向补充一个例子基本就能拿满。第一离线在线特征不一致。模型上线后如果特征拼接链路出错比如离线用了某个昨日特征线上却用了实时默认值模型效果一定崩。这类问题在推荐、广告系统里最隐蔽排查也需要核对特征日志和上线配置。第二样本选择偏差。离线训练时用的是“有曝光才有反馈”的样本但线上模型会给新内容打分会带来“新的曝光机会”这些新曝光的行为分布和训练分布不一样自然会导致离线/在线差异。第三评估指标本身的问题。离线AUC衡量的是排序正确率线上点击率是偏绝对值的指标两者并不线性等价。一个模型可能把排序整体做得更好了但因为推荐列表头部的旧爆款被换掉导致用户第一屏的点开意愿反而下降这在短时数据上可能表现为点击率下跌。第四时间窗口的不一致。离线评估如果用的是和线上不一致的样本时间窗口比如离线用了过去30天训练并验证模型线上策略只上线了3天新模型还没来得及适配近期热度和用户兴趣的短期变化效果容易出现波动。这题的答题思路能直接反映你有没有真正做过推荐相关项目。如果你只在Kaggle上跑过模型而没有接触过线上系统大概率只答得出“数据泄露”“过拟合”这类常规答案很难答到“特征链路一致性和评估指标错位”这种层面。5. 编程题思路与笔试准备建议5.1 编程题考察点不是算法竞赛是工程思维编程题一共两题第一题是动态规划给定一个数组求连续子数组最大和。经典到不能再经典但限制条件不能使用额外数组只允许O(1)空间。这道题应该所有人都会做核心就是Kadane算法def max_subarray_sum(arr): if not arr: return 0 current_max global_max arr[0] for num in arr[1:]: current_max max(num, current_max num) global_max max(global_max, current_max) return global_max这题考察的不是算法技巧而是你在紧张状态下还能不能写出无bug的边界条件。比如空数组、全负数数组这些边界值很多人一紧张就忽略。递推公式是dp[i] max(dp[i-1] arr[i], arr[i])但更关键的是理解为什么空间可以压缩到O(1)——因为当前状态只依赖前一个状态不需要记录整个dp数组。第二题是基于“好友关注关系”的推荐题给一组关注关系[follower_id, followee_id]找出“可能认识的人”——即你和某个人有两个以上共同关注的人但你们尚未互相关注按共同关注人数降序输出。这个题我在笔试时用的解法是构造“用户→关注列表”映射然后暴力两两比较因为笔试数据量不会太大。更高效的方法是用倒排索引先建“被关注者→关注者列表”的倒排表然后遍历每个用户的关注列表两两组合计数。这个思路和计算共同好友、商品协同过滤、歌曲协同过滤是同一个套路。def recommend_friends(follow_relations): follow_map {} for follower, followee in follow_relations: follow_map.setdefault(follower, set()).add(followee) follow_map.setdefault(followee, set()) suggestions {} for user in follow_map: followed follow_map[user] for followee in followed: for candidate in follow_map.get(followee, set()): if candidate ! user and candidate not in followed: common len(followed follow_map[candidate]) if common 2: key (user, candidate) suggestions[key] common result sorted(suggestions.items(), keylambda x: x[1], reverseTrue) return [(a, b, cnt) for (a, b), cnt in result]这道题的本质和音乐平台的“相似用户推荐”“歌单协同过滤”非常接近。如果你在简历里写过推荐相关的项目面试官看向你的眼神都会不一样因为这表明你具备把推荐算法落到工程代码里的能力而不只是会用现成的库。5.2 备考建议围绕数据科学职业核心能力做刻意练习我整理了大概三周的备考计划基于腾讯音乐这批真题做专项训练。第一周主攻统计概率和机器学习基础重点是二项分布、正态分布、假设检验、贝叶斯公式、常见模型对比LR、树模型、KNN、朴素贝叶斯。资料上推荐《统计学习方法》前几章加StatQuest的视频两者配合效率高。第二周集中刷SQL窗口函数题每天至少5道覆盖连续性问题、TopN问题、留存率、会话切分、行列互转直接在LeetCode数据库题库里找中等难度的题。第三周做业务场景模拟从“某个指标下降”开始练习排查框架再自己找几个公开数据集做简单的归因分析或预算分配建模。对于“数据科学与大数据技术就业方向”这个热词我也多说一句这个方向的毕业生如果目标是大厂数据科学岗最需要补的不是建模能力而是SQL和业务思维的衔接。算法岗位门槛高、需求量少、竞争激烈数据科学岗位更看重你是否有能力把业务问题转化成数据问题再把数据结论翻译回业务语言。腾讯音乐这套笔试的题型分布其实已经暗示了它们更看重的还是“扎实基本功清晰业务逻辑”。一个比较实用的备考技巧是每次做完一套真题都把错题按“知识盲区”“审题失误”“速度不够”三类归类而不是笼统改成“学习不够”。知识盲区需要系统补课审题失误需要平时练题时强迫自己圈出关键词速度不够则需要专项限时刷题。这套方法坚持两周提分效果明显。笔试前也可以多去了解目标公司的业务形态。比如投腾讯音乐就应该提前了解它的产品矩阵、核心指标月活、日活、付费率、播放时长等、主要推荐场景每日推荐、歌单推荐、搜索、直播以及会员转化路径。业务场景题给你的材料可能没有具体数字但如果你对业务足够熟就能答出更有针对性的建议而不是泛泛而谈“提高用户粘性”。6. 这批笔试题的隐藏考点从做题到做事的思维升级6.1 为什么说“归因-预算-反馈”是整场笔试的分水岭前面说了很多具体题目现在想脱离题目本身聊聊这套笔试隐含的“职级思维”。腾讯音乐这套题里SQL题和概率题解决的是“能不能干活”的问题而场景题中的归因预算题解决的是“能不能扛事”的问题。一个只会写SQL、调参、跑模型的人和一个能独立负责业务指标、给出决策建议的人在职级上可能就是P5和P7的差别。归因预算这道题之所以是分水岭是因为它同时考察了你三种能力归因模型选型与计算的落地能力、预算优化问题中约束条件的拆解能力、以及“数据-决策-数据”闭环的复盘意识。如果你能在这个题里主动提到“归因结果影响预算分配预算调整后各渠道的用户质量发生变化需要重新校准归因模型”哪怕算法细节写得不够完美面试官也会觉得你具备较强的业务闭环意识。反过来如果你只把归因和预算当成两个独立模块去写就说明你还没有真正在业务中做过“数据驱动增长”的完整项目。6.2 一个可能被忽略的细节渠道曝光量与归因的因果偏差最后再补充一个容易被绝大多数候选人忽略的点在归因预算这类题目里如果你推荐用机器学习模型做归因一定要提“曝光量对模型归因的干扰”。举个具体例子短视频渠道的曝光量可能远大于搜索渠道树模型在训练时会把“曝光量”当成一个强特征于是误以为短视频渠道贡献最大。但实际情况可能是搜索渠道来的用户搜索意图更强、付费意愿更高只是因为搜索曝光量基数小总贡献看起来不如短视频。这就是典型的“popularity bias”。怎么缓解可以从样本权重或特征构造角度回答在归因模型训练时对渠道曝光做某种降权处理或者构造“点击率/曝光量”这样的比值特征而不是把曝光量的绝对值直接放进模型。这个层次的答案能立刻拉开你和普通候选人的差距因为它说明你不是只会拿现成模型跑数据而是能理解数据背后的业务逻辑和潜在偏差。这种“偏差意识”在数据科学职业核心能力里被反复强调但在实际工作中很多人一遇到业务指标波动就开始盲目建模忽略了数据本身的生成机制。一个合格的数据科学从业者应该像侦探一样首先怀疑数据的生成过程而不是直接跳进模型调参。6.3 关于时间分配和答题策略的再思考整套题做下来我最大的遗憾是在概率选择题上花的时间略多导致编程题写得比较赶。如果能重来一次我会严格遵循“每个选择题最多3分钟超过就标记跳过”的策略。数据科学岗笔试不是要把每道题都做对而是要在有限时间拿到最多加权分。题目的分值分布通常不会明确标出但可以根据题型推断一个大致权重选择题数量多、主观题数量少。如果你时间紧张优先保证主观题有完整思路和清晰表达比死磕一道选择题值钱得多。因为单选、多选是零分或满分而主观题只要你踩中得分点哪怕没有最终数值也能拿到不少过程分。另外给一个小技巧如果笔试平台允许返回修改一般在交卷前都可以第一遍把所有题快速过一遍把自己确定能拿分的题先答完第二遍再回头啃没做出来的。很多平台会显示“未答题数”看着那个红色数字压力会很大但越到这时候越要先保分再攻坚。写在最后一次笔试暴露的数据科学能力全景我个人复盘完这套题的最大感受是腾讯音乐这批秋招笔试题难得不在具体某个知识点而在它把所有知识点都放到了真实业务场景里。这不是一套刷题刷出来的题而是一套“做事做出来的题”。如果你平时只是刷Kaggle、背面试题、看机器学习课程你会发现每一道题都眼熟但就是答不透。反过来如果你做过真实的用户分析、广告归因、推荐评估项目这套题答起来会顺很多。腾讯音乐的数据科学岗业务侧重很明显内容推荐、用户增长、商业化变现三大方向。所以准备笔试时别只盯着机器学习算法推导多花时间想想“指标为什么涨跌”“模型评估和线上效果为什么不一致”“预算怎么花才能带来更多确定性增长”。数据科学岗真正值钱的地方从来不是算法本身而是用数据帮业务做决策的能力。这套笔试就是一面照妖镜把你的真实水平照得明明白白。