收到腾讯音乐娱乐（TME）2023暑期实习生招聘技术类笔试（I）的邀请邮件，是在一个工作日的下午。我当时正在图书馆里刷LeetCode，看到邮箱提醒弹出来，第一反应是确认考试时间，第二反应是有点懵：邮件里没有给具体的题目范围，只写了时长、若干选择题和四道编程题。我投递的是后端开发岗，在此之前也参加过其他几家的笔试，但TME这套题给我的整体感觉是：不偏不怪，但很考基础，尤其考你在有限时间内能不能把思路转化成可运行的代码。
这篇复盘我拖了半年才写，主要是想把笔试中暴露出来的问题记下来。如果你正在准备TME或者同类大厂的技术类暑期实习，这篇内容可以帮你快速了解笔试大概长什么样、哪些坑值得提前避开，以及考完到面试之间该怎么衔接。要提前说明的是，每批次题目大概率不一样，我更想讲的是思路和方法，而不是让你背题。笔试本身只是整个流程的一环，真正决定能不能进面试的，往往是你能不能在有限时间里稳定输出。
1. 从投递到开考：这次笔试的时间线与准备清单
1.1 投递渠道、岗位选择与时间线
我是在五月底通过腾讯音乐娱乐招聘官网投递的后端开发暑期实习岗位，没有走内推。投完之后大概两周没有动静，中间一度觉得自己简历初筛没过。7月初收到笔试（I）的通知时，距离投递已经过了一个多月，所以如果你投完简历后暂时没消息，不必太早放弃，大厂流程就是会有一段静默期。
身边一起准备的同学，有走内推的，也有在第三方招聘平台投递的，普遍反馈是：投递渠道会影响收通知的速度，但不会影响笔试内容。内推同学的状态更新更及时，仅此而已。TME的技术类笔试面向的岗位很宽，后端、前端、客户端、测试开发、算法等都可能在同一套卷子里，部分方向可能有附加题或者选做题。我是投后端的，以下内容基本以后端视角为主，但选择题部分对所有技术方向应该是通用的。
1.2 考前一周我做的三件事
由于不知道笔试具体考什么，我把考前一周押在了最稳的三件事上。
第一，集中刷高频题型。我在LeetCode上按“数组、字符串、链表、二叉树、动态规划、二分查找”这几个标签刷题，每天四到五道，不求难题偏题，只求常见套路熟练。事后证明这个方向是对的，TME的编程题没有出怪题，几乎都在这些经典题型的变形范围内。
第二，过了一遍计算机基础高频题。这部分是为了应对选择题里占比不小的操作系统、网络和数据库考点。我没有重新啃书，而是直接看面经里经常出现的知识点：进程线程区别、死锁条件、TCP握手挥手、索引失效场景、事务隔离级别等。目标不是背答案，而是做到看到一个选项能快速判断对错。
第三，抽了一个晚上熟悉在线笔试平台的输入输出。这一点很多人都忽略了。本地跑代码和在线判题完全是两回事，尤其是多行输入、多组测试用例的情况，不提前练一下，考场上很容易在IO上浪费二十分钟。
1.3 笔试邮件里最容易忽略的两条信息
邮件里最重要的信息往往不在正文标粗的“考试时间”里，而在后面的注意事项。
我这场明确写了需要开启摄像头监控，并且浏览器不能切出考试页面太多次。具体次数标准没有公开，但根据以往经验，频繁切换窗口很可能被判违纪，或者至少会收到后台警告。所以我才在考前把常用模板提前复制到在线编辑器的草稿区，避免考试时反复拷贝粘贴。
另一条容易被忽略的是考试时间跨度和可进入时间。有的笔试允许你在某个时间段内任意时间开始，但计时从你点击“开始答题”起算。这就意味着你可以晚点进，但进去之后时间就固定了。我习惯提前十五到二十分钟登录，把身份证件放在旁边，网络、电源、耳机全部检查一遍再点开始，避免因为设备问题浪费宝贵的答题时间。
2. 笔试题型全景：题量、分值与我实际的时间分配
2.1 我这场笔试的题型构成
进入考试页面之后，系统会先展示一个总体说明。我这场的情况大致是：总时长120分钟，前面是一批选择题，后面是四道编程题。选择题涵盖单选和多选，混合在一起，数量大概在30到40道之间。编程题分值占比更高，总体来看，笔试过线的关键在于编程题，而选择题决定你能不能稳过。
选择题覆盖的知识面很广，我粗略统计了一下，数据结构、操作系统、计算机网络、数据库、编程语言基础均有涉及，偶尔还有一两道Linux命令和编译原理相关题。深度不算大，基本都是概念辨析和简单推导，比如给一段代码问输出结果、给一个场景问该用什么数据结构、给一个数据库索引问是否会命中。这些题单看难度都不高，但放在一起考的是知识宽度。
编程题四道，由易到难排列，难度曲线非常明显。第一道是字符串处理，第二道是动态规划，第三道是二叉树相关，第四道需要二分解法。前两道属于“只要思路对了很快能写出来”的题，第三道考基础扎实程度，第四道需要多想一步。
2.2 时间分配方案：先扫题再定顺序
我的时间分配策略是：打开试卷后，先不急着做任何题，用三到五分钟把四道编程题全部看一遍。这件事很重要，它可以让你在还没进入做题状态前就掌握全局，知道哪道题是送分题、哪道题需要留足时间。看完之后，我决定先做选择题，再做编程题，因为选择题卡壳的概率更高，把它放在精力最充沛的前半段是最好的。
选择题我给自己定的预算是40分钟，平均每道题一分钟左右。遇到一眼看不出答案的题，先用排除法筛掉明显错的选项，然后立刻标记，不做过多纠缠。40分钟一到，不管还剩几道，直接切到编程题。编程题四道总共留了约75分钟，剩余时间机动分配。最后留五分钟左右检查提交状态，确保每道题都提交成功，而不是只“保存了代码”。
这里特别想提醒一点，不要把选择题全部做完再做编程题。选择题里很容易出现一道你刚好“有点印象但记不牢”的题，你会忍不住花五分钟去回忆，但五分钟在编程题里可能就够多调试一个测试用例了。我在考场上给自己定的硬规则是：一道选择题超过两分钟没做出来，立刻跳过，绝不死磕。
2.3 如果遇到不会的题：止损与得分最大化
笔试最容易出现的心理崩盘，是卡在第二道题上，后面明明会做的题也没时间做了。我的做法是：先把所有编程题看一遍，标记出“一定会写”和“有机会写”的题，从最有把握的开始做。如果某道题思路卡住超过15分钟，果断停笔，换下一道，等做完其他所有能拿的分，再回头想这道题。
编程题通常按通过率给分，不是非黑即白。所以就算你只想到了暴力解法，也要写上去。很多时候暴力解能过一半甚至更多的测试用例，这个分数比空着强太多了。我印象中第四道题一开始只写了二分框架，边界条件还没调完，但我先把一个O(n*m)的暴力版本提交了，至少保证有基础分，然后再继续优化。这种“先保底再优化”的思路，在时间紧的笔试里比追求完美解法重要得多。
3. 四道编程题复盘：思路、代码和交卷前的检查点
3.1 字符串题：删除一个字符后判断两串相等
第一道编程题让我印象挺深，因为它虽然简单，但暗含一个很容易写错的细节。题目大意是：给定两个字符串，判断能否通过删除其中一个字符串里的一个字符，让两个字符串相等。如果两个字符串本身已经相等，也算通过。
我的第一反应是双指针：两个指针分别指向两个字符串开头，从左往右逐个字符比较。遇到不同字符时，理论上可以有两种操作，要么删掉第一个串里还没匹配的字符，要么删掉第二个串里还没匹配的字符。问题在于，如果两个字符串长度差大于1，那不管怎么删都肯定不相等，可以先返回false。如果长度差刚好是1或者0，就需要在遇到第一次不匹配时，尝试往前跳一次，后面必须完全匹配。
这类题最容易踩的坑是：只考虑“跳过长串的一个字符”，没有考虑两个串长度相等时，其实不能靠删除一个字符来让它们相等。因为删除一个字符会让长度差变成1，所以如果原串长度相等，唯一能通过的情况只有两个串已经完全相同。我不小心把这种情况也当成“删一个字符”来处理了，好在本地测试用例提前暴露了这个问题。
def can_be_equal_by_one_deletion(s: str, t: str) -> bool: if s == t: return True if abs(len(s) - len(t)) != 1: return False i, j = 0, 0 deleted = False while i < len(s) and j < len(t): if s[i] == t[j]: i += 1 j += 1 else: if deleted: return False deleted = True if len(s) > len(t): i += 1 else: j += 1 return True这道题的时间复杂度是O(n)，空间复杂度是O(1)。交卷前我特意检查了那几个边界：两个串完全相同、第一个串比第二个串长、第二个串比第一个串长、差异出现在最后一个字符。批量过一遍之后，我才提交。
3.2 动态规划题：环形数组的最大不相邻子序列和
第二道编程题是“打家劫舍”的变体，但加了一个环形限制。题目大意是一个环形排列的数组，相邻两个元素不能同时选，问能选出的最大和是多少。经典线性版本大家应该都很熟，使用两个状态变量滚动更新就行。环形版本需要额外考虑“首尾不能同时选”的限制。
当时的思考过程是：环形问题最常见的处理方式就是分类讨论，分两种情况分别调用线性版本。第一种情况不选第一个元素，第二种情况不选最后一个元素，取两种情况的最大值。因为我投的是后端岗，所以选择用Python写，思路会更直白。
def rob_linear(nums: list[int]) -> int: not_rob, rob = 0, 0 for num in nums: new_not_rob = max(not_rob, rob) new_rob = not_rob + num not_rob, rob = new_not_rob, new_rob return max(not_rob, rob) def rob_ring(nums: list[int]) -> int: if len(nums) == 1: return nums[0] if len(nums) == 2: return max(nums[0], nums[1]) return max(rob_linear(nums[1:]), rob_linear(nums[:-1]))这种方法的时间复杂度是O(n)，空间复杂度O(1)。我写完后特意试了长度为1和长度为2的数组，因为环形拆分的边界条件最容易在这两个最小长度上出错。另外还要注意，如果数组元素全部都是非负数，这道题会比较友好，但如果出现负数，那么“不选”状态的结果要保证不会被负数拖低，滚动更新里的max就起到了这个作用。
考场上我一开始犯了个错，把rob_linear(nums[1:])写成了rob_linear(nums)，忽视了环形首尾相邻的限制。虽然示例用例不明显，但自己补了一个[2, 3, 2]的用例立刻暴露了问题，正确答案是3而不是4。这种细节靠检查代码逻辑很难发现，最有效的方式就是多跑几个自己构造的边界例子。
3.3 二叉树题：校验二叉搜索树
第三道编程题是：给定一棵二叉树，判断它是否是一棵合法的二叉搜索树。所谓合法，是指对于每个节点，左子树的所有节点值都严格小于它，右子树的所有节点值都严格大于它。我当时很快就想到了中序遍历，因为二叉搜索树的中序遍历结果一定是严格递增序列。只要在中序遍历过程中维护一个“上一个访问到的值”，如果当前值不大于上一个值，就判定不合法。
我选择用迭代版中序遍历实现，因为笔试环境里递归可能遇到栈深度问题，而且迭代版也不难写。
def is_valid_bst(root) -> bool: stack = [] prev = None while stack or root: while root: stack.append(root) root = root.left root = stack.pop() if prev is not None and prev.val >= root.val: return False prev = root root = root.right return True这里特别要注意一个约定：题目里如果强调“严格小于/严格大于”，那么相等也必须返回false。我印象里TME这道题题干明确说了“strictly less than”，所以我在prev.val >= root.val里用了大于等于。如果你的题目没有明说，建议在答题前先写注释确认，或者用测试用例试探。这道题leetcode上的变体版本为简化使用>=，但如果要求不严格递增，就得改成>。
这种题在笔试里出现频率很高，因为它同时考了二叉树遍历、递归/栈的使用，以及对二叉搜索树定义的准确理解。我的检查点是：空树是否返回true、单节点树是否返回true、是否考虑了重复值、是否考虑了大整数边界。全部过一遍之后，我提交了。
3.4 二分答案题：分割数组的最小化最大值
第四道编程题难度明显上来了，题目大意是：给定一个非负整数数组和一个整数m，要求将数组分成连续的m段，问这m段各自的和中，最大值最小可以是多少。这是一个非常经典的“二分答案”题，但第一次见的话，思路不一定能立刻转过来。
我一开始也想过动态规划，但一看数据范围比较大，动态规划的O(n^2m)复杂度很可能过不了。于是立刻切换思路：能不能二分“每段和的最大值limit”，然后判断在这个限制下，是否能将数组分成不超过m段。判断的逻辑很简单，贪心地从左到右扫描，当前段累加和超过limit就新起一段，最后统计段数是否小于等于m。
def can_split(nums: list[int], m: int, limit: int) -> bool: segments = 1 cur_sum = 0 for num in nums: if cur_sum + num > limit: segments += 1 cur_sum = num if segments > m: return False else: cur_sum += num return True def split_array(nums: list[int], m: int) -> int: left = max(nums) right = sum(nums) while left < right: mid = (left + right) // 2 if can_split(nums, m, mid): right = mid else: left = mid + 1 return left二分下界是数组中的最大值，因为每个元素至少要单独成一段；上界是整个数组的和。整个算法的时间复杂度是O(n * log(sum))，空间复杂度O(1)。这道题我检查时的重点有几个，一个是can_split的初始段数应该设为1而不是0，另一个是单个元素大于limit的情况。如果数组中出现某个元素本身大于limit，贪心算法里的cur_sum + num > limit会直接把段数累加，但更稳妥的方式是在贪心前先判断max(nums) > limit直接返回false，不过我这里利用左边界是max(nums)，所以二分过程中limit不会小于最大值。
交卷前我还注意了一个点：mid的向下取整在left < right的循环里不会造成死循环，因为当can_split为true时，right = mid缩小范围；为false时，left = mid + 1也缩小范围。检查完边界，这道题才算是稳了。
4. 选择题覆盖的六个知识域，以及我记忆最深的易错点
4.1 数据结构与算法
选择题考数据结构的部分比较基础，重点集中在数组、链表、栈、队列、哈希表、堆和图。让我印象最深的一道题是问数组和链表的区别，看起来太简单，但选项里有一条“数组可以在O(1)时间内删除任意一个元素”，这个表述是错的，因为数组删除元素需要移动后续元素，平均是O(n)。这种题就是考察你是否真的理解，而不是背过“数组适合随机访问，链表适合插入删除”的口诀。
堆相关也考了一道：向一个大小为n的二叉堆中插入一个元素，平均时间复杂度和最坏时间复杂度分别是多少。答案分别是O(1)和O(log n)。很多人容易忽略平均情况，因为堆的插入通常先放到最后，然后上浮，很多情况下上浮次数很少。
哈希表考了冲突处理方法，问链地址法和开放地址法的区别。这类题不难，但需要记得线性探测的“聚集”现象，以及链地址法在负载因子过高时会退化为链表。
4.2 操作系统
操作系统这块选择题占比不低。考到进程和线程的区别，这是高频题。有一道选项说“同一进程内的多个线程共享独立的栈”，这明显是错的，进程内的线程共享堆和代码段，但每个线程有自己的栈。
死锁的四个必要条件也考了，迷惑选项是把“资源剥夺”写成必要条件。实际上剥夺是多用于死锁预防的一种方法，死锁必要条件包括互斥、持有并等待、不可剥夺、循环等待四个，缺一不可。
页面置换算法也出现了一道，问LRU算法在缓存大小为3、访问序列为某串时缺页次数是多少。这类题只要耐下心模拟一遍就不会错，但考试时容易因为紧张算错。我的经验是：在草稿纸上画一个三格窗口，每访问一个页面更新一次，同时记录缺页次数，不要心算。
4.3 计算机网络
网络的选择题集中在TCP和HTTP。TCP的三次握手和四次挥手是必考点，题目会问，第三次握手失败时两端分别处于什么状态；或者四次挥手中TIME_WAIT状态出现在主动关闭连接的那一方。这类题不太难，但需要记得TIME_WAIT的持续时间是2MSL。
HTTP状态码也考了一两个，比如301和302的区别：301是永久重定向，302是临时重定向。还有一个选项比较坑，“404表示服务器内部错误”，这显然不对，500才是内部错误。网络这块整体感觉偏向基础概念，不涉及太深的协议源码。
4.4 数据库
数据库考了事务隔离级别和索引失效场景。脏读、不可重复读、幻读三者对应的隔离级别，属于经典中的经典。有一道题给出了一个场景：同一个事务内两次查询同一范围的数据，得到的结果集不同，问这是哪种问题。答案是不可重复读还是幻读，要看题干描述的是“某一条数据值变了”还是“多出了几行”。我做的时候差点选错，还好题干里写的是“结果集行数发生变化”，那就应该选幻读。
索引失效考了一道非常常见的：在索引列上进行函数运算，比如WHERE YEAR(create_time) = 2023，这个情况下索引会失效。另一个选项是对索引列进行了隐式类型转换，也会失效。这类题没什么技巧，只能把常见失效场景记住。
4.5 编程语言特性
语言相关题目，后端方向主要考C++和Java类的题。我印象比较深的一道是关于C++的static关键字，选项覆盖了静态局部变量、静态全局变量、静态成员函数和静态成员变量的特性。其中“静态成员函数可以直接访问静态成员变量，也可以直接访问普通成员变量”是错的，静态成员函数没有this指针，不能直接访问非静态成员。
Java则考了volatile和synchronized的区别，选项里说“volatile可以保证原子性”是错的。volatile只能保证可见性和有序性，不能保证复合操作的原子性。还有一道问Java垃圾回收的finalize机制，这一块我平时接触不多，属于靠排除法猜的。
4.6 其他零星考点：Linux、编译原理与计算机组成
选择题里还零星出现了Linux命令和编译原理的题。Linux考了chmod的数字权限，比如chmod 755表示文件所有者可读可写可执行，用户组和其他用户只读只执行。还有一个选项是关于kill -9和kill -15，前者是强制终止，系统不会给进程清理资源的机会，后者是通知进程自行退出。这类题属于知道就会，不知道就只能蒙。
编译原理考了一道针对“中间代码生成”的描述，问三地址码的作用。我印象比较深是因为这道题让我意识到，基础知识复习不能只盯三大件，编译原理和计组虽然频次不高，但确实会出现在试卷里。时间充足的话，至少把词法分析、语法分析、中间代码、目标代码生成这些概念过一遍。
5. 在线笔试里的非技术坑：平台、输入输出和切屏
5.1 平台环境与本地IDE的搭配
技术类笔试一般有两种环境：一种是纯在线编辑器，不让你用本地IDE；另一种是允许使用本地编译器，但是由在线监控插件盯着。我这场是允许开本地IDE的，看起来很方便，但它同时监控切屏次数。也就是说，如果你频繁在浏览器和本地IDE之间切换，后台会记录风险操作。
我的做法是：把本地IDE当成“草稿纸”，主要在里面调试逻辑，调试通过后再手动粘贴到在线编辑器。为了减少切屏次数，我会在考试开始前把输入输出模板、常用库的import语句都提前写在在线编辑器里，这样切一次就能粘贴完整代码，不用来回切。
如果你参加的那场不允许本地IDE，那就要提前习惯在线编辑器的补全能力。很多在线编辑器的自动补全很弱，没有代码格式化，也没有错误提示，写C++时容易漏掉分号。提前用平台模拟题练一次，能明显降低这种场外因素影响。
5.2 输入输出格式带来的真实翻车现场
笔试翻车最高发的地方，就是本地跑通了，提交却一直报错。我第一道编程题就差点栽在这里：本地我用的是sys.stdin.read()一次性读取，但在线判题需要按行读取多组测试用例，如果用例数量不固定，一次性读取的写法可能把多个用例混在一起。
我常见的输入模式有这几种：第一行一个整数表示测试组数T，接下来T组数据；或者整个文件只有一组数据；又或者多组数据直到文件结束。你必须在做题前先搞清楚输入模式，否则代码处理的第一行就可能出错。一个比较稳妥的做法是：用sys.stdin.read().split()拿到所有token之后，再根据题意相邻消费，这样能兼容大多数输入场景。
输出格式也一样。题目如果要求“每个结果占一行”，你就老老实实拼接到一个list里最后统一print，不要在循环里print带额外空格。有些题甚至要求每组之间有一个空行，容易被忽略。交卷前务必重新读一遍题目最后的输出说明。
5.3 做题顺序与最后检查的微操
在线笔试的时间管理，其实在交卷前五分钟最能看出差距。我的习惯是：留出最后五分钟，逐一点开四道编程题，确认每一道都处于“已提交”状态，而不是“草稿”状态。听起来很傻，但确实有人因为只保存了代码没点提交，整道题零分。
还有一个小技巧：把每道题里自己写的关键测试用例注释在代码块开头，方便检查时快速回忆思路。比如我写了几个边界用例在注释里，如果交卷前还有时间，就重新跑一遍，看是否仍是预期输出。这样既不会增加提交内容，也能让自己安心。
选择填空部分，我会把拿不准的题号记在草稿纸上，最后有时间就回来看。但这里有个限制：如果切屏次数有风险，尽量不要反复跳转回选择题。所以我的策略是，选择题做完一遍之后，除非有明显思路了，否则绝不回头看。
6. 笔试结束后的三天：自评、补漏与面试衔接
6.1 交卷后的第一件事：趁热复盘
交卷后的一两个小时，记忆还热乎着，是复盘的最好时机。我不会立刻对答案，而是先把四道编程题的思路和代码重新写进本地笔记，尽量还原自己在考场上的版本。哪怕题目记不全，至少把核心解法、卡住的点、优化方向记录下来。这份记录在后面的面试阶段非常有用，因为面试官如果看到你的简历，可能会问你笔试里印象最深的题是怎么做的。
还有一个容易被忽略的动作：记录每道题花了多长时间。我事后统计了一下，第一道字符串题花了12分钟，第二道动态规划花了18分钟，第三道二叉树花了20分钟，第四道二分答案花了35分钟，合计85分钟，基本和计划吻合。有了这个数据，后续再笔试或者面试手撕代码时，就能更准确地判断自己的速度是否合格。
6.2 查漏补缺：选择题错题对应的知识块
笔试结束后，我还把印象中不太确定的选择题整理成了清单。按照知识域分类之后发现，我的主要漏洞集中在数据库的隔离级别、操作系统LRU模拟题、以及编译原理的概念题。这些东西单个来看都是小点，但放在笔试里就是一道实实在在的扣分题。
我当时用了两天时间，把数据库事务隔离级别彻底搞清楚了，画了一个表对比各种隔离级别下的脏读、不可重复读、幻读是否存在；顺手把LRU的模拟过程在纸上跑了十几遍。这种查漏补缺不只为这场笔试，更是在为接下来的面试打基础。果然，后来的几场面试里，这些问题反复出现，尤其是数据库隔离级别，几乎必考。
6.3 从笔试到面试：更重要的几件事
笔试过后，一般两三天内会收到结果。等待期间我只做两件事：一是复习项目，把简历上写过的每个项目，从背景、难点、技术选型到最终效果，全部用STAR法则梳理一遍，准备给面试官讲15分钟版本和3分钟版本；二是保持每天两三道算法题的手感，重点练二叉树、动态规划、数组类题目，因为这几类是面试手撕代码的重灾区。
说实话，笔试通过与否并不能完全代表你的真实水平，但它决定了你能不能拿到面试的入场券。我自己的感受是，TME这套笔试题不会故意刁难人，它考的是基础、稳定和应变能力。如果你能把常见题型的套路练熟，把基础概念理解透，再把IO和平台细节处理好，通过的希望是很大的。
有个细节我一直觉得很有用：笔试结束后，不管结果如何，我都没有删掉那晚的本地调试代码。后来面试复盘时，我甚至把其中一道二分答案题又优化了一版，举一反三写成了一个小工具。这种“一次笔试，持续沉淀”的习惯，可能是整个求职季给我最大的帮助。
