2023年春招腾讯音乐的数据工程岗笔试放在第一批说实话这个时间点挺考验人的。大部分人的春招节奏还停留在“过完年再说”的状态结果招聘流程说开就开不少人是在完全没准备的情况下被拉进考场的。我身边就有朋友考完出来直摇头说题目看着不难但时间根本不够用SQL刚写完一大半编程题还没碰就交卷了。这篇文章我就结合那批笔试的实际考察逻辑聊聊数据工程岗的笔试到底在筛什么人、题目背后考的是什么能力、以及怎么在有限时间内把分拿满。如果你现在正在准备大厂数据工程岗的校招笔试或者之后打算投腾讯音乐相关的数据岗位这篇文章会把整个笔试的考察框架、实战策略和容易忽略的细节拆开讲清楚帮你少走弯路。1. 数据工程笔试和普通后端/算法笔试筛选逻辑完全不一样很多人在准备数据工程岗笔试的时候容易犯一个方向性的错误照着后端开发岗或算法岗的题库刷。结果就是选择题里的JVM调优、红黑树旋转看得一头雾水编程题死磕动态规划最后真正该拿分的SQL反而没有时间练。1.1 数据工程岗考核的三个层次数据工程岗日常做什么本质上就三件事把数据从A点搬到B点过程中保证数据不丢不重不错把杂乱的数据加工成可分析的形态让整个数据链路跑得稳、跑得快。因此笔试考的不是某个单一技能而是围绕这三件事分层次考察。第一层是数据基础能力。SQL是绝对的核心这几乎是所有数据工程岗笔试的共识腾讯音乐也不例外。它考的不只是会不会写select、join而是能不能处理真实业务里常见的复杂查询场景比如连续登录、留存计算、同环比、窗口函数排序。第二层是大数据生态的知识广度。数据工程离不开分布式计算框架所以Hadoop、Spark、Flink、Kafka这些组件会被反复提及。这个层次的考察方式通常是选择题或简答题重点看你是否理解这些组件的基本原理、适用场景和常见问题的排查思路。第三层是编程与工程能力。毕竟数据工程师也写代码尤其是写数据处理逻辑。笔试里的编程题一般不会出特别偏难怪的算法更多是考察你用代码解决实际数据问题的能力比如解析日志、实现一个简单的聚合逻辑。1.2 腾讯音乐笔试的风格特点腾讯音乐的笔试整体风格偏向务实或者说“业务导向”。同一套题里可能会出现某个音乐App的真实业务场景比如统计某首热门歌曲的播放量、分析用户听歌时长分布让你在熟悉的业务背景里完成数据处理任务。这种出题方式的好处是它不是死板地考语法而是考你面对真实业务需求时能不能快速转化成可执行的查询逻辑。另一个特点是时间紧凑。整个笔试时间一般控制在90到120分钟但题量并不算少要涵盖选择题、SQL题、编程题有时还会有简答题。如果你在某道SQL题上纠结太久后面的编程题很可能来不及写。1.3 岗位JD与笔试内容的对应关系投递岗位的时候可以留意一下JD里的关键字。腾讯音乐数据工程岗的JD里往往会出现“数据仓库”“ETL”“数据质量”“Spark”“Flink”这些词这些关键字基本预告了笔试的重点。如果JD重点提了数据仓库那SQL题大概率考数仓建模相关的内容比如维度建模、拉链表设计如果重点提了实时计算那Flink相关的知识点肯定会出现在选择题里。拿着JD去反推笔试范围比漫无目的地刷题高效得多。2. 题型盘点选择题、SQL题、编程题和场景题各自的考察重点根据那批笔试的反馈来看题型基本固定但每个题型的侧重点和平时刷题的感觉不太一样。我先逐类拆一遍。2.1 选择题大数据组件原理和基础知识覆盖面广选择题大概占30%左右的分值覆盖面非常广。我印象比较深的几个方向是这样Hadoop相关问得最多的就是HDFS读写流程、NameNode和DataNode的角色分工、MapReduce的Shuffle过程。比如“HDFS默认副本数是多少”这种基础题基本属于送分题但“MapReduce中Shuffle阶段的作用是什么”这种题就需要你真正理解整个计算流程。Spark是选择题里的重头戏。RDD、DataFrame、Dataset三者的区别宽依赖和窄依赖的判断Stages划分机制Spark作业提交流程Client模式与Cluster模式的区别这些问题反复出现。建议准备的时候重点搞懂“宽依赖和窄依赖如何影响Stage划分”这个点因为它是很多Spark相关题目的底层逻辑。Flink在腾讯音乐的笔试里出现频率也不低毕竟音乐平台的实时推荐、实时榜单都离不开Flink。状态管理、Checkpoint机制、事件时间与处理时间的区别、Watermark的作用这几个知识点要熟练。有一个很容易考的点是“Flink如何保证精确一次语义”要能说清楚Checkpoint和两阶段提交配合的原理。消息队列Kafka同样绕不开。分区与副本的概念、消费者组如何管理位移、消息会不会丢失生产者、Broker、消费者三个层面分别怎么保证这些需要理解到位。还有一个容易被忽视的点是基础数据结构和计算机网络。我见过有选择题考到TCP三次握手、HTTP状态码的含义如果你大学学的东西忘得差不多了建议考前快速过一遍不用太深但基本概念得捡起来。2.2 SQL题笔试题的拉分项也是刷人最狠的部分SQL题往往是整张卷子里分值占比最高的单项而且一旦写错几乎没有蒙对的概率。那批笔试的SQL题大概有3到4道难度从入门到进阶递进。入门题一般是单表查询或简单的两表连接考最基本的语法比如按某个字段分组统计、过滤条件组合。这类题是送分题但要注意别在细节上丢分比如COUNT和COUNT(DISTINCT)的区别、NULL值的处理方式。进阶题就开始上难度了。窗口函数是必考的ROW_NUMBER()、RANK()、DENSE_RANK()三兄弟的区别、SUM() OVER()跑批计算、LAG()和LEAD()取前后行数据这些是最基础的窗口函数操作。考法通常是这样的给你一张用户听歌记录表让你统计每个用户听歌时长的累计值或者找出每个用户听得最多的前三首歌。还有一个常考的题型是连续问题比如统计连续登录N天的用户。这种题用窗口函数做非常方便核心思路是用日期减去ROW_NUMBER()的序号得到一个分组标识然后按这个标识分组统计。我第一次见到这个思路的时候觉得非常巧妙理解了之后SQL能力会有一个明显提升。那批笔试里还出现了一道被很多人讨论的题统计每分钟在线听歌人数的峰值。这类问题本质上是个时间区间重叠问题思路是把每条记录拆成开始事件和结束事件然后用SUM() OVER()做事件流累加峰值就是累加过程中的最大值。这类题在LeetCode上叫“会议室II”或者“卡车占用车位”但套上听歌场景之后对数据工程岗来说更贴切。2.3 编程题难度适中重在实际问题的解决编程题一般有两道左右可以用Python或Java写。和算法岗动辄困难难度的动态规划题不同数据工程岗的编程题更偏向“用代码处理实际数据”考法通常是给定某种格式的日志文件或数据流让你写代码完成某个统计任务。比如给定一个包含用户ID、歌曲ID、播放时间戳的日志列表统计每首歌的独立播放用户数或者给定一批包含开始时间和结束时间的记录找出所有存在冲突的时间段。这种题要求你熟悉Python里字典、集合、列表的基本操作能快速把思路转化成代码。还有一类题是自选实现某种数据结构比如手写一个带过期时间的缓存、实现一个简单的LFU缓存这其实是在考察你对生产环境中常见问题的理解比如需要缓存热点歌单数据时怎么处理过期和淘汰。需要注意编程题的判题环境一般比较严格你要自己处理输入输出格式。很多人不是思路不对而是卡在了输入输出的解析上这在平时用LeetCode刷题时不太容易暴露因为LeetCode已经把输入输出处理好了。2.4 场景题/设计题隐藏在简答里的加分项有些场次会包含一两道简答或场景设计题比如让你设计一个音乐播放量实时统计方案或者问你“如果数据仓库里某张表的任务失败了你如何排查”。这类题看起来开放但其实考察的是你对完整数据链路的理解。设计实时统计方案时可以从数据接入Kafka、实时计算Flink、结果存储Redis或ClickHouse三个层面回答每一步说清楚用的组件和原因。任务失败排查则可以从调度日志、上游依赖、数据倾斜、资源不足几个方向展开。开放题没有标准答案但一定要展示出结构化的思维——分步骤、分模块地组织你的回答让面试官能通过笔试看到你解决问题的思路这本身就是一种能力证明。3. 做题顺序和时间分配决定你能否把会做的题都做完那批笔试最大的坑不是题目难而是时间不够用。很多人栽在“先做选择题再做SQL最后做编程题”这个顺序上结果选择题消耗了太多精力SQL没写透编程题直接空白。这里我分享一套经过验证的时间分配策略。3.1 拿到试卷先花3分钟看全貌不要上来就埋头做题。先花两三分钟把整张试卷从头到尾翻一遍搞清楚每类题有多少道、每道题大概多少分、难度感觉如何。这能帮你在心理上建立一个全局观知道哪些题是稳拿分的、哪些题需要冲刺。一套比较合理的分配方案参考下面这个表格题型建议用时做题策略选择题20-25分钟会做的直接选不会的先跳过每道题不超过1分钟SQL题35-45分钟先写有把握的题难题留到最后编程题25-35分钟至少保证一题完整提交另一题写出核心思路检查5-10分钟重点检查SQL字段名、表名、边界条件3.2 做题顺序先做最优性价比的题我的建议是如果试卷整体题量较大先用几分钟快速扫一遍所有SQL题和编程题判断哪些是自己有把握的优先做这些。原因是SQL题和编程题分值高、区分度强是决定你能否进入面试环节的关键。选择题就算全对如果SQL和编程拉胯总分也不会好看。反过来如果SQL和编程答得不错选择题错几道影响不大。具体操作可以这样优先做所有你一看就有思路的SQL题再回头做选择题中会做的题接着做编程题里最有把握的那道最后利用剩余时间去磕难题。这个顺序看起来跳来跳去但确实能在有限时间里拿到最多分数。3.3 编程题的保底策略不追求满分追求有提交编程题如果完全没写基本等于直接放弃一整块的分。哪怕时间再紧也要保证至少一道题有一个能跑通的版本。一个很实用的保底策略是先把暴力解法写出来并确保它能正确计算小规模输入。很多时候暴力解法能帮你拿到一部分测试用例的分数而且能在写的过程中慢慢优化思路。另一个策略是如果某道编程题完全没思路就把你能够想到的步骤用伪代码或者注释写出来同时给出你的基本思路。这在人工阅卷的情况下有一定概率拿到过程分。我这么说吧笔试不是竞赛不是为了拿满分而是为了在有限时间内证明你具备基本的数据处理能力。一道能跑通的简单题远比一道写了一半的难题有价值。4. 几类高频SQL题的破题思路从听懂到能写对SQL题考来考去翻来覆去就是那几类经典题型。这里我挑了几个高频方向把核心思路完整拆解一遍你如果能把这些题型的代码熟练掌握笔试的SQL部分基本稳了。4.1 窗口函数不只是会写要理解它的执行逻辑窗口函数是数据工程岗SQL题的核心工具。很多看起来复杂的SQL问题一旦想到用窗口函数解法就变得非常简洁。窗口函数的执行顺序要牢记先WHERE过滤再GROUP BY分组然后窗口函数计算最后ORDER BY排序。注意WHERE在窗口函数之前执行所以你不能在WHERE里直接使用窗口函数的别名。以“统计每个用户听歌时长的累计值”为例SELECT user_id, song_id, play_ts, SUM(play_duration) OVER (PARTITION BY user_id ORDER BY play_ts ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_duration FROM play_log;这里面有几个关键点PARTITION BY表示按用户分组ORDER BY表示组内排序ROWS BETWEEN...AND...定义了窗口的范围。理解这三者的组合关系你就能写出从累计求和到移动平均的各种查询。4.2 连续问题日期减去序号这一步是关键“统计连续登录N天的用户”是SQL题里的常青树它表面上考的是连续判断实际考的是你能否用一个巧妙的转换把连续问题变成分组问题。核心思路(1) 先用窗口函数ROW_NUMBER()按用户分组、按日期排序得到每个用户每个登录日期的序号(2) 用登录日期减去序号得到一个日期值(3) 如果日期是连续的日期减序号的差值会保持不变所以这个差值就可以作为分组标识。WITH t AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY) AS grp FROM login_log ) SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS consecutive_days FROM t GROUP BY user_id, grp HAVING COUNT(*) 3;这个技巧看着简单但是假如你之前没接触过考场上临时想是很费时间的。建议把它当成一个固定套路来记。4.3 每日活跃/留存率把握住“去重”和“时间偏移”两个核心统计DAU日活跃用户的题目在笔试里非常常见因为它直接对应业务里的核心指标。做题的时候要注意两点一是去重逻辑同一用户同一天产生多条记录应该只算一次二是时间维度的处理按天统计需要注意日期格式的转换。留存率的计算是另一个高频题型。以“次日留存率”为例核心方法是把同一用户的登录记录按日期错位连接找到第T天登录且第T1天也登录的用户数。SELECT a.login_date, COUNT(DISTINCT b.user_id) / COUNT(DISTINCT a.user_id) AS retention_rate FROM login_log a LEFT JOIN login_log b ON a.user_id b.user_id AND b.login_date DATE_ADD(a.login_date, INTERVAL 1 DAY) GROUP BY a.login_date;如果把DATE_ADD(a.login_date, INTERVAL 1 DAY)改成INTERVAL 7 DAY或INTERVAL 30 DAY就能分别得到7日留存和30日留存。这类题目不复杂但细节很关键比如JOIN条件里必须限定日期偏移否则会出现数据膨胀的问题。4.4 时间区间重叠峰值在线人数的经典解法统计“在线用户峰值”或“会议室最大使用数量”这类问题在数据工程笔试里被改编成“每分钟在线听歌人数峰值”出现的概率很高。这类题的核心解法非常巧妙把每一条记录拆成两个事件一个开始事件1一个结束事件-1然后按时间顺序做累计求和。WITH events AS ( SELECT user_id, start_time AS ts, 1 AS delta FROM play_log UNION ALL SELECT user_id, end_time AS ts, -1 AS delta FROM play_log ) SELECT ts, SUM(delta) OVER (ORDER BY ts) AS concurrent_cnt FROM events ORDER BY ts;然后再取出concurrent_cnt的最大值就是峰值。这个思路在很多真实场景里都能用到比如并发任务数统计、直播间同时在线人数等。理解了事件流累加这个底层逻辑这类题就都通了。5. 踩坑记录和复盘方法细节决定最终成绩最后这部分我想聊聊那些容易被忽略、但实际考试中非常致命的细节。这些内容没有多少技术含量可一旦踩中很可能让你前功尽弃。5.1 环境准备笔试平台的隐藏坑笔试用的在线OJ平台和本地IDE差别很大。第一个坑是代码自动补全的缺失。在本地IDE里写SQL习惯了自动提示表名和字段名到了在线平台手写SQL经常会因为拼错字段名而报错。第二个坑是本地验证和在线评判的差异。平台一般提供本地自测用例但通过自测不代表最终能拿满分因为测试数据里会有一些你没考虑到的边界情况。一个值得养成的习惯是在正式笔试前用牛客网或赛码网刷几套在线编程题提前适应这些平台的输入输出格式和评判规则。尤其是输入输出解析不同平台之间的规范可能不太一样但一旦适应了就不至于在考场上纠结“这行字符串到底要不要去掉末尾的回车”。5.2 做题过程中的低级错误SQL题最容易犯的低级错误包括JOIN条件漏写、GROUP BY字段不完整、COUNT和SUM的语义混淆、NULL值处理不当。这些错误在本地试数据量小的时候不容易暴露一旦跑到全量数据上就会出现结果偏差。编程题更容易栽在边界条件上比如空列表输入、单元素列表、数字溢出等。写代码的时候可以给自己一分钟的时间专门想想“如果输入是空的我这代码跑不跑得通”这个习惯能帮你避免很多无谓的失分。另外读题一定要读完整特别是题目最后几行对输出格式的要求。每年都有人因为输出格式不符合要求而丢掉一整道题的分数格式问题最可惜。5.3 考后一定要复盘笔试结束不等于学习结束。无论这次笔试的结果如何考后复盘都是提升能力最有效的方式。建议趁热打铁把考场上没能做出来的题重新做一遍对照题目回忆自己的思路卡在哪里是知识点没掌握还是时间分配出了问题。复盘时可以把所有错题按题型归档比如“SQL-连续问题”“SQL-留存率”“编程-区间重叠”“选择题-Flink”。春招期间要投的公司往往不止一家腾讯音乐的笔试真题就是最好的练兵场把每场笔试里的错题都变成自己的弹药库下一场笔试的胜算才会明显提升。根据我自己的经验数据工程岗的笔试到最后拼的其实不是智商而是你是否对常见题型足够熟悉。熟练度这东西只能在反复练习中积累。把高频题型的套路吃透再养成规范的做题习惯拿到面试机会并没有想象中那么难。