校招研发笔试题型深度拆解：编程基础、算法思维与系统知识全攻略

每年到了八九月份校招笔试就像潮水一样涌过来。前几天整理资料的时候翻到自己存的一份“触宝科技2017秋季校招研发笔试题第一批”突然感慨挺多的。触宝这家公司可能很多人第一反应是输入法但它的业务线其实很杂输入法、通讯录、健康助手都做过而且海外市场做得比国内名声还响。当年这批研发笔试题放到现在来看依然很有参考价值因为它考的不是冷门屠龙技而是研发岗最核心的那几板斧编程基础、算法思维、系统知识再加上一些临场处理问题的能力。今天干脆把这套题的整体风格和具体考点拆开聊聊给正在准备校招或者想跳槽进移动互联网公司的朋友做个参考。2017年的校招题和现在相比形式上区别不大仍然是“选择题编程题问答题”的老三样但内容上更看重基础功底的扎实程度。那批题我印象最深的地方在于它并不追求题目有多难多偏而是把很多基础知识点换了个场景去考看似眼熟动起手来却发现有不少坑。这篇文章不会原封不动地把题目贴出来那样意义不大我会把同类型的考点、题型逻辑、容易踩的坑和对应的解题思路完整梳理一遍让你即使拿不到原题也能在笔试现场心里有底。1. 笔试题整体风格与考察逻辑1.1 研发笔试题的三层结构基础、逻辑、实战很多第一次参加校招的同学拿到触宝这类公司的笔试题第一反应是“怎么这么杂”。其实杂是正常的研发岗笔试本质上不是考你某一门课学得多精而是考你在有限时间内能不能稳定输出基础知识、快速理解问题并写出可用代码。我当时看到的这套题可以清晰分成三个层次。第一层是基础知识题覆盖了数据结构、操作系统、计算机网络、数据库。这些题目看着像期末考试选择题但实际风格更偏向“用场景考概念”。比如给你一段代码问输出多少或者在多个网络异常场景里选出TCP会如何处理还会给一个SQL表结构让你挑出查询语句中的错误。这些题考的并不是背诵而是你真正有没有理解底层机制。第二层是逻辑和算法题一般是一两个选择题加一道到两道编程题。编程题往往不是LeetCode原题而是给你一个业务背景然后让你实现某个功能。这种做法挺考验人因为一旦题目包装成“用户输入一段文本需要做统计”你可能半天反应不过来它其实可以简化为哈希表计数问题。第三层是综合问答题通常会涉及系统设计、并发、内存管理或者让你阐述某个模块的实现思路。比如“如果一个功能在低性能手机上崩溃你会怎么排查”“设计一个防止重复点击的装饰器/组件”这类实际问题。这层题目没有绝对标准答案考官想看的是你的分析思路和知识广度。这三层结构其实是国内研发校招笔试的典型配置。触宝作为移动互联网公司特别看重你是否有端侧或者服务端开发的潜质所以题目会明显偏向Android/iOS底层、网络通信、数据存储这些方向。但好消息是它不会上来就考你某某框架的源码还是以计算机基础为根。1.2 为什么很多同学觉得题量不大却做不完触宝这批笔试我记得限时大概是90分钟到120分钟题量看年份不一样第一批大概有20道左右的选择题加两道编程题加一两道问答题。很多同学考完跟我抱怨题目看着都会怎么就是做不完答案往往出在时间分配上。第一选择题里暗藏了大量“变体题”。比如一道关于进程线程的题表面问“以下哪些是线程私有资源”选项中可能混了“文件描述符”“栈”“堆”“寄存器”。如果你只记得“线程共享进程资源”就会掉进坑里多纠结一会儿时间就过去了。这类题往往不是1分钟能解决的它需要你在脑子里做一遍完整推演。第二编程题虽然输入输出格式很常规但测试用例比较刁钻。如果只写核心逻辑不考虑边界可能在示例用例上能跑通但一提交就Fail。很多同学为了一道题反复试探、查错白白耗掉半小时。这在笔试环境中特别吃亏因为笔试不给你编译器报错之外的任何反馈。第三很多人喜欢按题目顺序作答遇到一道卡壳就死磕。笔试不是高考它的题目难度并非严格递增经常是前面选择题里有陷阱后面编程题反而容易拿分。如果你前面耗太久后面的题即使会也没时间写。我自己当年参加类似笔试时养成了一个习惯拿到题先花两分钟浏览全卷把选择题里明显简单和可能耗时的标记出来编程题先选自己有思路的做最后再回头啃硬骨头。这个习惯在面对触宝这类题量适中但思维量大的试卷时非常有效。2. 经典题型的核心思路拆解2.1 编程题限制条件下的优化以字符串压缩为例触宝这类公司笔试编程题不会太魔怔一般能用一个数据结构加一个算法解决。这里我拿一道和2017年风格非常接近的题目举例实现字符串的“压缩”功能。题面类似这样给定一个字符串例如 aaabbc请将其压缩为 a3b2c1。如果压缩后的字符串长度不小于原字符串长度则返回原字符串。要求在原字符串上修改如果空间复杂度超过O(1)则不给分。这道题很有代表性因为它把三个考点揉在一起字符串处理能力、对空间复杂度的敏感度、边界条件处理。第一眼看上去最直接的做法是新建一个新的字符串或列表遍历原字符串并统计连续相同字符的数量拼接结果。但在“原字符串上修改”和“空间复杂度O(1)”的限制下这个做法不可行。如果笔试环境是C语言你可以考虑双指针原地压缩如果是Java或Python字符串本身不可变这时“原字符串上修改”通常是希望你在字符数组层面操作。正确的思路分两步。第一步先遍历一遍计算压缩后的总长度如果长度不小于原串长度直接返回原串这个问题很简单。第二步用两个指针一个读指针从头遍历一个写指针指向当前覆盖位置。每遇到一个连续字符段就在写指针处写入该字符再写入该字符出现的次数注意次数可能多于一位数字需要把数字转字符串后逐个写入。由于写指针永远不超前读指针所以可以在字符数组上原地覆盖。最后在新的写指针位置补上字符串终止符即可。为什么这道题容易卡壳因为很多人只想到用哈希表统计字符总频次把 aaabbc 压缩成 a3b2c1 确实没问题但无法处理 abbbbbbbbbb 这样压缩后反而更长的场景而且如果不计算最终长度就直接覆盖可能读到已经被覆盖的字符。我当时在练习的时候就犯过没考虑多位数次数的错误比如字符连续出现12次把1和2当两个字符写入结果写指针计算错位最终答案全乱。这类题的通用启示是做题先确定限制条件再选数据结构。很多编程题考的不是你有没有思路而是你能不能把思路在约束条件下落地。“先计算再执行”是原地修改类问题的经典手法值得多练。2.2 算法题如何在紧张环境下快速定位最优解触宝笔试题里的算法题很少是纯背板子的题更多是把经典算法包装一下看你能不能识别出底层的算法模型。举一个我印象很深的类型在“循环有序数组”中查找目标值。题面类似一个原本升序排列的数组在某个未知点做了旋转例如 [4,5,6,7,0,1,2]给定一个target要求时间复杂度O(log n)查找目标值。大家一看就知道这是LeetCode上Search in Rotated Sorted Array的变体。但笔试里不会告诉你“这是旋转数组”而是给了一个业务背景比如“某App的消息列表按时间倒序但由于时区异常部分数据发生错位请设计高效查询算法”。需要你自己把表面问题抽象成已知模型。抽象出来之后解法就明确了变形的二分查找。核心思路是在每次二分时判断哪一半是单调有序的。由于旋转数组的两半中至少有一半是有序的比较 mid 和 left 或 right 的值可以确定有序区间。如果 target 落在有序区间内则继续在那个区间二分否则到另一区间。关键在于相等的处理如果 nums[left] nums[mid] 且 target 不是这个值比如数组里有重复元素就需要 left 逐步缩小范围防止死循环。很多同学在笔试时容易忽略重复元素因为示例里没给。但笔试真正跑测试用例时会用大量边界数据。比如 [1,1,1,2,1] 这种target2如果代码里简单判断 nums[mid] nums[right] 就右移很可能误判。触宝这类题也是考的就是你有没有严谨地考虑所有可能分支。我在做题时的习惯是先不急着写代码在草稿纸上手写两个例子一个正常一个带重复值把二分的过程走一遍再动手写。这个步骤花不到两分钟但能帮你避免一半以上的逻辑漏洞。笔试时间虽紧但这步省不了。2.3 计算机网络与操作系统高频易错点除了编程题触宝这类公司非常喜欢考TCP/IP和操作系统的题目毕竟移动端应用跟网络和数据存储深度绑定。这一块选择题和问答题都很常见。TCP的题目是重灾区。比如问“TCP三次握手中第二次握手服务端发送的报文段中SYN和ACK标志位分别是什么”正确答案是SYN1, ACK1。但很多人会误写成SYN0, ACK1因为他们以为第二次握手是“同意连接”所以只有ACK。实际上第二次握手既要同意客户端的连接请求又要发起服务端到客户端的连接所以两个标志位都是1。这种细节就是在考你有没有真正理解握手的双向性。还有一道很经典的网络题为什么TCP建立连接需要三次而断开连接需要四次。很多人只知道答案不知道背后的原因。建立连接需要三次是因为要同步双方的初始序列号并确认双方都有收发能力断开连接需要四次是因为TCP连接是全双工的每一方的关闭都需要单独确认。如果只是死记硬背“SYN、SYNACK、ACK”和“FIN、ACK、FIN、ACK”一换场景就容易露馅。操作系统的考点则集中在进程线程、死锁、虚拟内存、并发控制。常见题目如“多线程程序里哪些数据是线程私有的”答案包括栈、寄存器、线程局部存储而堆、全局变量、静态变量是共享的。很多人会把“栈”和“堆”搞反因为平时写代码时说“new出来的对象在堆上”感觉堆好像也是线程各自的。其实堆是进程内共享的只有栈和寄存器是每个线程独立的。如果笔试里遇到“线程A读取了全局变量x线程B修改了x是否会出现可见性问题”还要顺带考察Java内存模型或者C的atomic/mutex这就要结合语言特性来答。这些知识看着散但复习时完全可以按“高频考点清单”来整理。我会在后面的问题排查部分给出一张速查表方便考前快速过一遍。3. 实操实战手写代码与调试的“隐形得分点”3.1 审题方法先列测试用例再写代码在笔试编程题中最冤枉的丢分不是不会做而是读懂题却做错了。触宝笔试题的题干通常会有两到三段包含输入输出格式、边界条件和示例。很多同学一看示例就开写结果遗漏了题干里“如果压缩后的字符串不短于原串则返回原串”这种关键信息。我的审题方法是先把题目中的输入输出格式用高亮标注然后自己在草稿纸上生成三组测试用例。第一组是普通情况比如 aaabbc 期望输出 a3b2c1第二组是边界情况比如空字符串、单字符、全部相同字符第三组是特殊情况比如压缩后长度反而变长如 abcdefg 应返回原串。用这三组用例来验证题目要求后再开始写代码。这样既能防止理解偏差也能在写完代码后立刻用这三个用例自测。这个方法看着简单但能非常有效地区分“会写代码”和“能写出正确代码”的人。笔试的判分系统本身就是用一堆测试用例来跑你的程序你提前想到的用例越多一次AC的可能性就越大。3.2 代码风格与边界处理别以为笔试判分只看结果实际上很多公司的笔试系统会有代码人工评审环节尤其是触宝这种重视技术社区氛围的团队。代码风格和完整度会影响面试官对你的主观印象。具体来说注意三点。第一变量命名要有意义。有人写二分查找变量名是 i、j、k 三个字母别人一眼看不懂如果你写成 left、right、mid面试官不用注释也能看懂思路。第二逻辑分支不要嵌套太深能提前返回就提前返回这样代码可读性高也不易出错。第三边界处理要稳。比如字符串长度是0、数组长度为1、目标值在开头或结尾这些情况都要有明确的处理分支。这里分享一个我自己写算法题的模板先写 if (输入为空) return 结果; 然后初始化左右指针进入循环时明确循环条件循环结束后处理剩余情况。只要保持这个稳定节奏很多低级错误都能避免。触宝的笔试环境一般支持实时编译运行但不会给你太多测试用例。所以写完代码后一定要自己模拟执行两三遍特别是在脑子里走一遍循环体的前几次和最后几次迭代检查指针是否越界。3.3 时间分配策略90分钟如何安排具体的时间分配因题量而异但以触宝2017第一场的常见配置来看20道选择2道编程1道问答题90分钟左右。我会这样安排前10分钟快速浏览全卷标记出需要动笔计算的题和一眼能看出的题。先做有把握的选择题遇到拿不准的题目暂时跳过不要在草稿纸上死推。选择题部分整体控制在30分钟内预留20分钟给第一道编程题20分钟给第二道编程题问答题留15分钟最后5分钟检查试卷是否有空题。为什么选择题要控制在30分钟因为选择题虽然分多但每道平均也就2分钟左右。如果你在一道选择题上花了5分钟还拿不准基本上说明这个知识点有盲区再纠结下去也不会突然想通。不如先凭第一感觉选一个标记下来如果有时间再回来看。编程题要先做自己有把握的那道。很多同学习惯从第一题按顺序做结果第一题是个复杂的状态机写上半小时还没通过第二题明明很简单却没时间写了。这是校招笔试里最常见的“顺序陷阱”。我在考场上从来都是先扫描两道编程题的难度先做思路清晰的那道确保一道AC再去攻坚另一道。一道完全正确的大题往往比两道都只过了一半用例得分高。问答题虽然不要求写代码但也不能只写一句话。触宝这类公司的问答题喜欢让你讲一个完整的设计思路比如“如何设计一个短链接系统”或“手机App端怎么保证接口请求的幂等性”。这种题考察的是结构化的表达背景-方案-细节-异常处理。你可以在草稿纸上列一个提纲分点作答。哪怕没有标准答案但要让面试官看到你有条理。3.4 在线笔试环境的特殊注意点触宝2017年那会儿用的在线笔试系统跟现在的牛客网、赛码网差别不大。但这些系统的代码编辑器和本地IDE差别很大没有任何自动补全和代码高亮提示有的甚至连括号匹配都没有。如果平时依赖IDE的自动补全上到笔试环境会特别不适。我在考前提醒自己三件事第一提前熟悉在线笔试平台的快捷键比如CtrlEnter提交、切换到下一题不同平台快捷键不一样不要想当然。第二代码里不要依赖外部库或自定义包名笔试系统一般只能支持标准库有些平台还不支持某些语言的特殊功能最好提前看平台说明。第三要注意输入输出的格式特别是多行输入有些题目要求读取到EOF或者逐行读取如果代码里用 readline 少了循环就会只处理第一行数据。这个坑我在真实笔试中踩过当时一道题明明核心逻辑全对就因为少了一层 while 读取循环导致只通过了一部分测试用例。4. 常见问题与排查技巧实录4.1 典型错误和翻车现场每次笔试后我都会让学生把错误复盘出来发现翻车点高度集中。这里我整理几个最典型的一是“数组越界”问题。不管Java还是C/C数组越界都可能导致程序直接崩溃或输出错误。比如二分查找里rightmid-1 后如果 mid 已经为0下一次循环可能 left0, right-1这时访问 nums[mid] 就会出错。解决办法是在循环条件里用 while (left right)并在访问前判断 left 是否合法。很多人写“while (left right)”来避免越界但这样可能会漏掉只有一个元素的情况。二是“空指针/空引用”问题。例如判断字符串是否为空时习惯性调用 s.length()忽略了 s 可能为 null。笔试的测试用例经常故意给 null 或空串。最稳妥的写法是先判断是否为 null再判断长度。如果语言允许安全调用也要先确保语义正确。三是“死循环”问题。多发生在循环条件更新错误的情况下。比如反转链表时把 p p.next 写成了 q p.next结果指针来回跳死循环卡死整个程序。这类错误在笔试平台上的反馈是“Time Limit Exceeded”超时很多同学以为是自己算法太慢其实只是死循环。所以写完循环类代码一定要在脑子里模拟两三轮迭代看指针是否往前推进。四是“类型溢出”问题。如果题目数值范围很大用 int 存结果可能溢出。比如计算数组累加和时有的同学只看了样例数值小便直接用 int但测试数据里可能有一万个数每个都是10^9累加就爆。笔试环境里C的 int 溢出不会报错Java的 int 溢出也不会报错就会输出一个奇怪的负数。这种情况下要么用 long/long long要么在计算过程中取模如果题目要求。我在练习时都会养成一个习惯看题目的数据范围如果数值上限超过2^31-1默认用64位。4.2 智力题/逻辑题如何见招拆招触宝这类公司偶尔也会在笔试题中放一两道智力题或逻辑推理题比如“100层楼两个鸡蛋问题”“如何用天平找出次品”“三盏灯对应三个开关”等。这类题并不是真的要你写代码而是考察你的逻辑思维和归纳能力。我理解很多同学看到智力题就慌因为觉得没见过。但智力题的解题套路其实比算法题更固定。首先遇到问题先尝试从小规模开始递推。以两个鸡蛋100层楼为例如果你只有两个鸡蛋又要最坏情况下次数最少关键不是一层层扔而是构建一个步长递减的搜索过程。第一次从第14层扔如果碎了就逐层试1到13层没碎就第二次从27层扔再碎就在15到26层逐层试以此类推。141312...1 105 100所以14是第一步的最优值。这就是“找临界点”的思路。这种题在笔试中占比不高如果实在没有头绪可以先跳过不要因此影响后面的编程题。等编程题做完再回来用“极端假设法”和“举例归纳法”慢慢推。如果你平时能花点时间刷一下经典智力题的题解考场上的反应速度会快很多。4.3 独家避坑高频考点速查表根据触宝2017秋季校招研发笔试题的考点方向结合历年相同风格公司的笔试内容我总结了一张高频考点速查表考前可以用它快速自查。注意这不是全部范围但覆盖了大部分研发笔试可能出现的重点。知识模块必背核心点常见坑与提示数据结构数组和链表区别栈和队列应用Hash冲突解决二叉树遍历递归转迭代时容易忘栈存储哈希扩容的复杂度算法二分查找变体快排和归并排序DFS/BFS动态规划入门注意重复元素和边界溢出DP要会定义状态与转移方程操作系统进程和线程区别死锁四条件虚拟内存并发同步机制线程私有资源是栈和寄存器线程安全要会写加锁示例计算机网络TCP三次握手四次挥手HTTP状态码TCP和UDP区别第二次握手SYN和ACK都为1GET和POST区别要结合实际场景数据库SQL连接查询索引原理事务ACID范式最左前缀原则索引失效的情况不要只看结果不分析执行计划语言基础变量的作用域参数传递方式垃圾回收机制异常处理Java传值还是传引用要看对象的引用Python默认参数是可变对象时要小心逻辑题递推、反证法、极端假设法染色问题天平分组先假设最简单情况找规律不要上来列方程这张表不需要逐条死记而是在笔试前两小时快速过一遍重点看“常见坑”这一列唤醒你对易错点的记忆。比如看到TCP第二次握手立刻提醒自己SYN和ACK都要置1看到线程私有资源立刻提醒自己栈和寄存器。这种条件反射式的记忆在选择题里尤其好用。4.4 复盘方法从笔试到面试转化的关键笔试结束后不管发挥如何一定要趁热打铁做一次深度复盘。很多同学笔试完就丢到一边下次笔试继续犯同样的错这是最亏的。复盘时不要只看分数要把每道题重新做一遍。选择题要理解每个选项为什么对、为什么错而不只是记住正确答案。编程题如果当场没AC下来后在本地IDE里慢慢调试搞清楚是思路问题还是边界问题。问答题可以找同学或者网上搜类似题目对比自己的答案看漏了哪些要点。把复盘笔记按知识点分类整理比如“链表”“二分”“并发”“网络”等。等积累了三四场笔试的错题你就能看出自己的薄弱模块然后针对性地刷题。我在带学弟学妹时经常说“笔试不是一次性的考核而是一个查漏补缺的工具。”如果能在秋招前把常见的坑都踩一遍之后的笔试会越来越顺。写在最后的小建议看了触宝科技2017秋季校招研发笔试题第一批的题目风格我个人最大的体会是这家公司考的不是智商而是你作为一名研发人员的基本素养——能不能在压力下保持代码的严谨性能不能把学过的基础知识灵活运用到实际问题里。这些能力不是靠考前突击模板就能练出来的需要平时写代码时多思考一步“如果数据是空的怎么办”“如果并发访问怎么办”。如果你能把每个小问题都从原理层面想透那不管笔试题怎么包装你都能识别出它的内核。最后再分享一个小技巧做笔试时遇到不会的知识点可以先把题目里涉及的场景关键词记下来等笔试结束后用这些关键词去搜索往往能找到一线工程师写的踩坑总结比死记硬背课本效率高得多。希望这篇拆解对你有所帮助也祝你后面每一场笔试都能稳定发挥拿到心仪的面试机会。