每年秋招季都会有一批经典笔试题在技术社区里被重新翻出来。小米2014校招研发工程师笔试卷A就是其中之一那会儿正是移动互联网最热的时候小米的笔试风格在求职圈里出了名的硬核题目不算偏但覆盖面极广从C语言指针到Linux操作从算法到系统设计都能见到。很多人考完出来第一反应是“我没复习到位”但仔细想想其实是“基础不够牢”。这份试卷的核心价值不在于考倒你而在于用一套组合拳把计算机专业的地基——内存、数据结构、操作系统、网络——全部扫一遍。对今天正在准备大厂校招的人或者想系统补一遍计算机基础的开发者来说它依然是一份非常值得翻出来练手的材料。当年我也参加过类似的笔试后来自己也开始帮团队出题、改卷慢慢看出一些门道这类试卷的每一道题都不是随便出的背后对应着出题人对一名合格研发工程师的定位和理解。下面我就把这套笔试卷的考察逻辑拆开按模块聊聊考点背后的思路、答题技巧以及我踩过的坑。1. 这份试卷背后的时代烙印1.1 为什么2014年的笔试题值得翻出来看2014年是移动互联网的爆发期智能手机出货量节节攀升各大厂商都在疯狂扩招。小米那一年正处于高速扩张阶段MIUI、米聊、手机硬件多条线并行对研发人才的需求量很大。但需求量大不代表门槛低恰恰因为要快速招到能上手的人笔试题目非常看重基础功底而不是简历上写了多少项目。那时候的校招笔试普遍是纸质试卷时间大概两小时题量不小。小米这套A卷的风格和BAT有相似之处但也带着自己的特点会更贴近实际工程场景比如把操作系统知识和移动端的资源限制结合起来考察。这和大厂“招来就能干活”的思路一脉相承也解释了为什么今天看这份试卷依然有参考价值——它考的不是框架API而是那些你换多少家公司、换多少门语言都绕不开的底层知识。另外一个值得翻出来的原因是现在很多笔试题目都变成了在线编程题只考算法反而把基础知识的选择题、简答题弱化了。但实际工作中真正拉开差距的往往就是基础知识的深度。2014年这套卷子放在今天相当于帮助你把校招笔试的“全维度考察”重新体验一遍——算法、数据结构、操作系统、网络、Linux、逻辑推理一个都不少。把这套卷子吃透比盲目刷一百道LeetCode对基础能力的提升更扎实。1.2 出题人到底想筛什么样的人一份笔试卷的命题思路本质上反映的是岗位画像。小米2014年招聘的研发工程师工作内容横跨ROM开发、应用开发、底层优化、服务端开发等多个方向所以笔试不可能针对某一个具体技术栈出太深的题而是筛选具备以下三种素质的人第一是基本功扎实。指针、内存布局、链表操作这类题目看起来简单但能在半小时内写得滴水不漏的人并不多。出题人很清楚基础题不是送分题而是筛选器——如果连内存分配和释放的时机都说不清楚很难胜任底层开发工作。第二是逻辑严谨。试卷里经常出现边界条件、溢出问题、异常分支。比如考察排序算法时不只说“快排的原理”而是追问“什么时候快排会退化”“如何避免退化”。这考察的是写代码时有没有考虑极端情况的习惯而不仅仅是背答案的能力。第三是工程意识。2014年前后服务器的并发模型、移动端的性能瓶颈都是热门话题。试卷里会出现进程和线程的区别、多线程同步、TCP状态变迁这类题目出题人希望你具备“写出来的代码要在真实环境里能跑”的意识而不是只会写玩具程序。说白了出题人想筛的是“计算机科班基础过关、有工程直觉、遇到问题能自己推演”的人。抱着“背几道题就能过”的心态去参加大概率要翻车。2. 计算机基础笔试的压舱石2.1 C/C与内存管理永远绕不开的指针题不管哪个大厂的研发岗笔试试卷C/C都是标配小米这套卷子也不例外。原因很简单C/C是离硬件最近的高级语言考察它能同时测出你对内存模型、编译原理、操作系统地址空间的理解程度。这套试卷里常见的C语言题目有这样几类指针与数组的关系int a[10]; int *p a;问sizeof(a)和sizeof(p)分别是多少以及p[5]和*(a5)是否等价。这类题考的是指针与数组的本质区别——数组名在表达式里会退化为指针但sizeof是编译期操作符它保留了数组的完整类型信息。如果没有深入理解过编译器的类型系统很容易踩坑。内存分配与释放malloc和free配对new和delete配对。常考的坑是只释放了指针指向的内存却忘了指针本身可能是局部变量或者释放之后没有置空造成悬垂指针。更进阶一点会问free之后为什么还要把指针置为NULL因为如果不置空后续如果误用了这个指针你无法判断它指向的内存是否还有效这种bug在大型项目里极难排查。结构体对齐与内存布局struct里char、int、double的排列顺序不同sizeof的结果也不同。这牵扯到编译器的内存对齐规则以及CPU访问内存的效率。我在实际改代码时见过因为结构体字段排列不当导致整个结构体凭空多出8字节内存占用在嵌入式环境里这就是致命的。字符串操作strcpy、strcat、sprintf这类不安全函数为什么不推荐用因为不检查目标缓冲区长度很容易栈溢出。笔试常考的就是让你指出这段代码哪里溢出或者让你手写一个安全的字符串拷贝函数。经验之谈这类C语言题靠考前突击是最没用的。最好的准备方式是打开一本《C语言深度剖析》或者《深入理解计算机系统》的第三章把指针、数组、结构体、栈帧相关的章节彻底过一遍然后自己在Linux环境下用gdb逐步调试几段带有内存问题的代码看寄存器和内存地址的变化。纸上谈兵一百遍不如亲手print一遍地址来得直观。2.2 数据结构链表、栈、队列的变体考察数据结构是笔试的重头戏而链表又是重中之重。为什么要反复考链表因为在嵌入式、内核、底层存储引擎里链表的使用频率远超你的想象而且链表相关的操作对指针的理解要求极高稍有不慎就出现段错误。这套试卷里链表相关题目常常以这样几种形态出现单链表逆置头插法或者递归法都能实现。考这个题的目的不在于你能否背下代码而在于考察你能不能在纸上把“当前节点、前驱节点、后继节点”三个指针的移动过程画清楚。我见过很多候选人代码写得飞快但一问“为什么需要保存后继节点”就卡壳这说明他只是背了模板没有真正理解指针之间的指向关系。判断链表是否有环经典的快慢指针法一个走一步一个走两步如果相遇则有环。追问环节通常会问为什么快指针一定要走两步走三步行不行答案是可以但两步最简单保证慢指针不会“跳过”快指针所在的节点。这种追问才是真正的分水岭。删除链表倒数第N个节点双指针法一个指针先走N步然后两个指针同步移动先走的指针到达末尾时后走的指针正好指向目标节点的前驱。边界条件是链表长度为N时直接删除头节点。两个链表的第一个公共节点先分别遍历两个链表得到长度差然后让较长的链表先走差值的步数再同步遍历找到第一个相同的节点。这类题考察的是对“长度差”这个隐藏条件的敏感度。除了链表栈和队列的变体也很常见。比如用两个栈实现队列用两个队列实现栈。前者是所有“实现题”里的经典思路是入队时往stack1压出队时如果stack2为空就把stack1的元素全部倒到stack2再从stack2弹出。后者则是反过来入栈时往queue1入队出栈时把queue1除队尾外的元素全部搬到queue2然后弹出剩下的队尾元素再交换两个队列的角色。这类题考察的核心其实是“数据结构之间的等价转换能力”。在工作中当你需要在一个不支持某种数据结构的语言环境里实现一个抽象结构时这种能力就会直接派上用场。我在做嵌入式开发时经常因为没有现成的队列库就得用手写数组模拟环形队列原理和“用数组实现栈”完全一脉相承。3. 算法与思维题真正的分水岭3.1 排序与Top K大数据场景下的经典考法在2014年那份试卷里排序算法的考察几乎是必然的而且很少只考“请写出快排代码”这种直球更多是结合应用场景追问。比如托普K问题的经典考法在10亿个数中找出最大的100个数内存只有1GB怎么做这道题的标准解法是用一个大小为100的小根堆遍历所有数据每次比较当前元素和堆顶堆中最小的元素。如果当前元素大于堆顶就替换堆顶并重新调整堆。这样堆中始终维持着遍历到目前为止最大的100个数。时间复杂度是O(N log K)而N是10亿K是100log K可以忽略不计所以效率非常高。面试官在这个基础上通常会追加几个问题为什么不直接用快速排序然后取前100个因为快排需要把所有数据都载入内存10亿个数如果每个占4字节就是40GB显然放不进1GB内存而且快排的时间复杂度是O(N log N)在10亿这个规模下远大于O(N log K)。为什么用堆而不用数组因为数组需要频繁移动元素堆的插入和调整都是O(log K)性能稳定。如果数据分布在多台机器上怎么办这时可以先用每台机器内的局部Top K再在归并阶段把所有局部结果汇总重新建堆选出全局Top K。这就是MapReduce里“分治归并”的思路雏形。再比如经典的手写快排考的不只是代码本身还有对退化情况的理解。快排在完全有序数组上的时间复杂度会退化成O(N²)原因是每次选择的基准都是最大或最小值划分极度不平衡。优化的方式是三数取中首、尾、中间三个元素的中位数作为基准或者递归到小规模子数组时改用插入排序。能讲出这一层的候选人在算法上才算真的过关。3.2 字符串与状态机考的是严谨字符串相关题目在校招笔试里的出现频率极高因为字符串处理非常容易出边界问题是检验细心程度的好工具。这份试卷里可能出现的长相有字符串反转但要求原地操作、O(1)额外空间。思路是用两个指针一个从前往后一个从后往前交换字符并向中间移动。坑在于字符指针的\0结尾交换时不要把结束符也交换了。统计字符串中每个字符出现的次数。最简单的方式是用一个长度为256的数组做哈希遍历字符串的同时计数。追问是如果字符集不是ASCII而是Unicode怎么办这时就不能用固定长度的数组了需要用哈希表或者根据编码规则做解码后再统计。实现atoi函数或者写一个字符串转整数的函数。这道题的考察点非常密集要处理前导空格、正负号、数字越界、非法字符以及空指针——在任何时候一个稳健的atoi都不应该因为意外输入而崩溃。我看过很多候选人在这道题上跌跟头原因不是思路不对而是处理INT_MAX和INT_MIN这两个边界值时丢三落四比如-2147483648这个数正数部分已经溢出int必须先按负数逻辑处理再转换符号。字符串题目背后还隐藏着一类“状态机”思维。比如判断一个字符串是否是合法的IP地址最严谨的做法是先定义状态数字开始、数字中间、遇到点号切换到下一段、四段都结束且最后没有多余字符才判定合法。用状态机的思路去写就不会漏掉“1.1.1.01”这种不合法的输入因为01不是合法表示。我后来自己在写网络协议解析器时发现这种“先定义状态再写逻辑”的方式能避免大量if-else堆叠带来的混乱。3.3 智力题逻辑和边界思维的检验很多研发岗笔试试卷里都会带几道所谓的“智力题”小米这套卷子也不例外。常见的类型包括烧绳子计时、老虎过河、天平找假币、100层楼扔鸡蛋之类的变体。很多人觉得智力题是“脑筋急转弯”其实不然。以天平找假币为例有12枚硬币其中1枚是假的不知轻重用无砝码天平称3次找出假币并说明轻重。这道题的关键是“每次称量获得的信息量是有限的”——天平每次有三种结果左重、右重、平衡所以3次最多能区分3³27种情况而12枚硬币可能的状态是24种12乘以不知轻重在信息论上是可行的。解题的核心策略是让每次称量的结果尽量“均匀分布”不要把硬币分成6和6——因为如果左右平衡剩下的可能性太多更好的分法是4、4、4三组结果都能覆盖大约1/3的情况。智力题本质上考察的是建模能力和分治思想。如果做题时只想着“试出来”而不去思考“为什么这一步能缩小范围”那刷多少智力题都没有用。这类题一旦掌握思路反倒是最容易在笔试里拿分的部分因为套路固定变化有限。4. 操作系统、网络与系统设计4.1 进程线程与并发从理论到案例操作系统是研发工程师笔试的另一座大山。2014年的试卷里进程和线程的区别几乎是必考。常规答案大家都知道进程是资源分配的基本单位线程是CPU调度的基本单位同一进程内的线程共享地址空间而进程之间地址空间相互独立。但这类题目拉开差距的地方在于追问。比如问线程之间共享什么不共享什么共享的包括堆、全局变量、文件描述符、信号处理器不共享的有栈、寄存器上下文、程序计数器。再比如问进程间通信有哪些方式经典答案为管道、消息队列、共享内存、信号量、套接字、信号。关键在于能够解释各自的适用场景管道适合父子进程之间的简单单向通信共享内存适合大数据量高频通信但需要解决同步问题套接字适合跨机器通信。多线程同步和死锁也是高频考点。一个常考的问题是死锁产生的四个必要条件是什么互斥、占有且等待、不可剥夺、循环等待。缺一不可所以打破其中任意一个条件就能预防死锁。工程上最常见的做法是破坏“循环等待”比如让所有线程按同一个全局顺序来获取锁。我在实际项目里遇到过无数次因为两个线程以不同顺序加锁而导致的偶发性死锁这种bug极其隐蔽复现概率低排查成本高。所以笔试里考死锁其实是在考察你有没有在代码设计之初就考虑并发安全性的习惯。信号量、互斥锁、条件变量之间的区别也常被拿来比较。互斥锁是线程间互斥访问共享资源信号量不仅能做互斥还能做同步条件变量则用于等待某个条件满足后再继续执行。笔试常考“生产者-消费者”模型用哪种同步原语实现——标准答案是互斥锁保护共享队列条件变量在队列空时让消费者睡眠生产者往队列里放数据后唤醒消费者。能把这个模型写清楚并发编程这块基本就过关了。4.2 网络协议TCP三次握手之外的追问网络协议里最常考的是TCP三次握手和四次挥手。基础版本是画出状态变迁图说清楚SYN、ACK、FIN各在什么阶段出现。进阶版本是追问为什么建立连接需要三次而释放连接需要四次三次握手的原因是通信双方要确认“自己的发送能力”和“对方的接收能力”都正常。第一次握手客户端发送SYN服务端确认客户端的发送能力第二次握手服务端发送SYNACK客户端确认服务端的发送能力和自己的接收能力第三次握手客户端发送ACK服务端确认客户端的接收能力。三次之后双方都确认了“我发你收、你发我收”都畅通。四次挥手则是由于TCP连接是全双工的关闭时每个方向都必须独立关闭。主动关闭方发送FIN被动关闭方回复ACK被动关闭方再发送自己的FIN主动关闭方回复ACK。中间那个“被动关闭方回复ACK”和“发送FIN”之间可能隔着一段数据处理时间所以不能合并成一次这就是为什么挥手比握手多一次。试卷里还可能涉及TCP和UDP的区别、HTTP和HTTPS的区别。HTTP是应用层协议基于TCPHTTPS在HTTP和TCP之间加了一层TLS/SSL加密。笔试常问HTTPS握手过程中证书验证的流程客户端拿到服务端证书用CA公钥验证证书签名确认服务端身份后双方通过非对称加密协商出一个对称密钥之后的数据传输都用对称加密。这个流程的细节很多能讲清楚“数字签名”“非对称加密协商会话密钥”这两个关键步骤基本就算吃透了。4.3 结合业务场景的小设计题小米的试卷有一个特点会出一些贴近自身业务的小设计题。比如“如果让你设计一个图片加载框架你会怎么做”“如何统计一个App的日活用户”这类问题。这种题目考的不是你到底有没有做过具体项目而是你有没有把操作系统、网络、数据结构的知识串起来用。以图片加载框架为例合理的思路是内存缓存用LRU最近最少使用算法维护一个有限大小的图片缓存超过上限就把最久没用的图片淘汰。磁盘缓存内存不够时把图片文件缓存在本地存储里同样需要设定容量上限。网络加载通过URL发起HTTP请求获取图片数据在子线程完成避免阻塞UI。解码与缩放拿到原始图片数据后根据目标控件的尺寸进行采样压缩避免OOM。这个小设计题几乎把数据结构哈希表双向链表实现LRU、操作系统内存管理、网络HTTP全部串起来了。我在面试别人时发现能答出第一层内存缓存的人很多但能自然而然地想到磁盘缓存和解码压缩的人寥寥无几这往往是实战经验多寡的体现。5. 答题策略与后悔药5.1 笔试现场的时间分配两小时做一套综合卷时间其实很紧张。我的经验是不要按试卷顺序从头做到尾而是先把卷子翻一遍把题目按难易程度分成三档第一档是会做的题先拿拿稳的分。比如选择题、填空题、自己非常有把握的简答题快速扫一遍尽量别失分。第二档是有点思路但需要动笔计算的题比如算法题、数据结构实现题。留出完整的连续时间块来写写之前先在草稿纸上画一画数据结构的变化过程确认逻辑通顺再落笔避免返工。第三档是完全没有思路的题先跳过等全部做完再回头啃。笔试里的每一分都值钱与其在一道15分的难题上耗20分钟不如先用5分钟把后面一道10分的基础题分拿到。常见的翻车现场是在“实现一个字符串反转”这种简单题上纠结于“用循环还是用递归”浪费了大量时间导致后面操作系统和网络的大题来不及写。记住笔试追求的是“总分最大化”不是“每一题都完美”。5.2 我见过的高分卷与低分卷我后来参与校招阅卷时观察到一个规律高分卷和低分卷的区别往往不在会不会做难题而在基础题的正确率。低分卷的典型画像算法题写得洋洋洒洒但指针题里sizeof判断错误进程线程区别回答得模棱两可TCP三次握手少画了一次ACK甚至出现代码缩进混乱、变量名随意这种“看着就不想细看”的问题。高分卷的典型画像基础选择题几乎全对简答题条理清晰算法题即使没有完全跑通也会在注释里写出自己的思路和遇到的边界情况让阅卷人能看出“这个人就算这里没写好也知道正确的方向是什么”。特别要注意卷面。不要把代码写得密密麻麻在纸上写代码时留出足够的行间距方便自己后续修改也方便阅卷人阅读。字迹不一定漂亮但必须清楚——如果你连自己的变量名都认不出来阅卷人更不可能帮你脑补正确的逻辑。还有一个容易忽略的细节算法题如果一时想不出最优解先写一个暴力解再在注释里补充“这个解法的问题在于复杂度太高优化方向是XXXX”。这种做法有两个作用一是保证你至少拿到底分二是让阅卷人看到你有优化意识。相反留白不写的题阅卷人想给分都给不了。5.3 备考时最容易踩的坑针对这份试卷的风格我在备考建议上特别想强调三个坑第一不要只看知识点不写代码。很多人复习操作系统、网络时纯靠背书觉得理解了就行。但笔试卷是要求你写代码的你理解指针是一回事让你在白纸上手写一个链表逆置是另一回事。我建议准备一个白纸本每天手写3-5个算法题或者数据结构操作题写完之后对照标准答案检查边界条件。第二不要只刷算法题忽略其他模块。现在的LeetCode文化让大家把80%的精力都放在了算法题上但类似小米这套卷子的综合笔试算法题通常只占三分之一左右的分数。操作系统、网络、数据库这些基础模块的分同样重要。如果只顾刷题不管其他卷面总分天花板会很低。第三不要眼高手低基础题不等于是送分题。最简单的“进程和线程的区别”很多人答不全包括线程共享进程的地址空间所以线程间通信成本低但代价是一个线程崩溃可能导致整个进程退出而多进程之间互相隔离单个进程崩溃不会拖垮其他进程。这些隐藏在基础概念背后的工程权衡才是阅卷人希望看到的深度。6. 这套卷子对今天还有没有参考价值有人可能会问都过去这么多年了这套2014年的笔试题目还有什么参考价值技术圈变化这么快当年考的Android、iOS知识早就迭代好几轮了。我的看法是框架和语言会过时但计算机基础不会。2024年的大厂校招笔试题照样考TCP三次握手照样考链表操作照样考进程线程区别照样考Top K问题。变化的只是载体——以前是纸质试卷现在是在线OJ以前要手写函数实现现在要处理ACM风格的输入输出。但底层的知识点和考察目标始终是一致的验证你有没有把一个计算机专业毕业的人应该掌握的地基打牢。如果你正在准备校招与其漫无目的地刷几百道LeetCode不如花两周时间把计算机基础系统地过一遍然后找几套经典笔试题比如小米这套A卷当作模拟测试卡着时间做一遍再对照答案复盘。这个过程下来你对笔试题的套路会有完全不一样的感觉。还有一个通用的建议不管笔试形式怎么变答题时体现出的思维方式才是最关键的。笔试卷上的答案是死的但阅卷人能从答案里看出你是“背过这个答案”还是“真正理解这个问题”。前者也许能过笔试但很难通过后续的面试后者才是拿到offer的真正钥匙。从一份2014年的笔试试卷里你能看到的不仅仅是几道题更是一代研发工程师培养体系里的筛选逻辑。把这些逻辑看懂你准备任何校招笔试都会更有方向。
小米2014校招笔试题解析：一次计算机基础全维度考察
每年秋招季都会有一批经典笔试题在技术社区里被重新翻出来。小米2014校招研发工程师笔试卷A就是其中之一那会儿正是移动互联网最热的时候小米的笔试风格在求职圈里出了名的硬核题目不算偏但覆盖面极广从C语言指针到Linux操作从算法到系统设计都能见到。很多人考完出来第一反应是“我没复习到位”但仔细想想其实是“基础不够牢”。这份试卷的核心价值不在于考倒你而在于用一套组合拳把计算机专业的地基——内存、数据结构、操作系统、网络——全部扫一遍。对今天正在准备大厂校招的人或者想系统补一遍计算机基础的开发者来说它依然是一份非常值得翻出来练手的材料。当年我也参加过类似的笔试后来自己也开始帮团队出题、改卷慢慢看出一些门道这类试卷的每一道题都不是随便出的背后对应着出题人对一名合格研发工程师的定位和理解。下面我就把这套笔试卷的考察逻辑拆开按模块聊聊考点背后的思路、答题技巧以及我踩过的坑。1. 这份试卷背后的时代烙印1.1 为什么2014年的笔试题值得翻出来看2014年是移动互联网的爆发期智能手机出货量节节攀升各大厂商都在疯狂扩招。小米那一年正处于高速扩张阶段MIUI、米聊、手机硬件多条线并行对研发人才的需求量很大。但需求量大不代表门槛低恰恰因为要快速招到能上手的人笔试题目非常看重基础功底而不是简历上写了多少项目。那时候的校招笔试普遍是纸质试卷时间大概两小时题量不小。小米这套A卷的风格和BAT有相似之处但也带着自己的特点会更贴近实际工程场景比如把操作系统知识和移动端的资源限制结合起来考察。这和大厂“招来就能干活”的思路一脉相承也解释了为什么今天看这份试卷依然有参考价值——它考的不是框架API而是那些你换多少家公司、换多少门语言都绕不开的底层知识。另外一个值得翻出来的原因是现在很多笔试题目都变成了在线编程题只考算法反而把基础知识的选择题、简答题弱化了。但实际工作中真正拉开差距的往往就是基础知识的深度。2014年这套卷子放在今天相当于帮助你把校招笔试的“全维度考察”重新体验一遍——算法、数据结构、操作系统、网络、Linux、逻辑推理一个都不少。把这套卷子吃透比盲目刷一百道LeetCode对基础能力的提升更扎实。1.2 出题人到底想筛什么样的人一份笔试卷的命题思路本质上反映的是岗位画像。小米2014年招聘的研发工程师工作内容横跨ROM开发、应用开发、底层优化、服务端开发等多个方向所以笔试不可能针对某一个具体技术栈出太深的题而是筛选具备以下三种素质的人第一是基本功扎实。指针、内存布局、链表操作这类题目看起来简单但能在半小时内写得滴水不漏的人并不多。出题人很清楚基础题不是送分题而是筛选器——如果连内存分配和释放的时机都说不清楚很难胜任底层开发工作。第二是逻辑严谨。试卷里经常出现边界条件、溢出问题、异常分支。比如考察排序算法时不只说“快排的原理”而是追问“什么时候快排会退化”“如何避免退化”。这考察的是写代码时有没有考虑极端情况的习惯而不仅仅是背答案的能力。第三是工程意识。2014年前后服务器的并发模型、移动端的性能瓶颈都是热门话题。试卷里会出现进程和线程的区别、多线程同步、TCP状态变迁这类题目出题人希望你具备“写出来的代码要在真实环境里能跑”的意识而不是只会写玩具程序。说白了出题人想筛的是“计算机科班基础过关、有工程直觉、遇到问题能自己推演”的人。抱着“背几道题就能过”的心态去参加大概率要翻车。2. 计算机基础笔试的压舱石2.1 C/C与内存管理永远绕不开的指针题不管哪个大厂的研发岗笔试试卷C/C都是标配小米这套卷子也不例外。原因很简单C/C是离硬件最近的高级语言考察它能同时测出你对内存模型、编译原理、操作系统地址空间的理解程度。这套试卷里常见的C语言题目有这样几类指针与数组的关系int a[10]; int *p a;问sizeof(a)和sizeof(p)分别是多少以及p[5]和*(a5)是否等价。这类题考的是指针与数组的本质区别——数组名在表达式里会退化为指针但sizeof是编译期操作符它保留了数组的完整类型信息。如果没有深入理解过编译器的类型系统很容易踩坑。内存分配与释放malloc和free配对new和delete配对。常考的坑是只释放了指针指向的内存却忘了指针本身可能是局部变量或者释放之后没有置空造成悬垂指针。更进阶一点会问free之后为什么还要把指针置为NULL因为如果不置空后续如果误用了这个指针你无法判断它指向的内存是否还有效这种bug在大型项目里极难排查。结构体对齐与内存布局struct里char、int、double的排列顺序不同sizeof的结果也不同。这牵扯到编译器的内存对齐规则以及CPU访问内存的效率。我在实际改代码时见过因为结构体字段排列不当导致整个结构体凭空多出8字节内存占用在嵌入式环境里这就是致命的。字符串操作strcpy、strcat、sprintf这类不安全函数为什么不推荐用因为不检查目标缓冲区长度很容易栈溢出。笔试常考的就是让你指出这段代码哪里溢出或者让你手写一个安全的字符串拷贝函数。经验之谈这类C语言题靠考前突击是最没用的。最好的准备方式是打开一本《C语言深度剖析》或者《深入理解计算机系统》的第三章把指针、数组、结构体、栈帧相关的章节彻底过一遍然后自己在Linux环境下用gdb逐步调试几段带有内存问题的代码看寄存器和内存地址的变化。纸上谈兵一百遍不如亲手print一遍地址来得直观。2.2 数据结构链表、栈、队列的变体考察数据结构是笔试的重头戏而链表又是重中之重。为什么要反复考链表因为在嵌入式、内核、底层存储引擎里链表的使用频率远超你的想象而且链表相关的操作对指针的理解要求极高稍有不慎就出现段错误。这套试卷里链表相关题目常常以这样几种形态出现单链表逆置头插法或者递归法都能实现。考这个题的目的不在于你能否背下代码而在于考察你能不能在纸上把“当前节点、前驱节点、后继节点”三个指针的移动过程画清楚。我见过很多候选人代码写得飞快但一问“为什么需要保存后继节点”就卡壳这说明他只是背了模板没有真正理解指针之间的指向关系。判断链表是否有环经典的快慢指针法一个走一步一个走两步如果相遇则有环。追问环节通常会问为什么快指针一定要走两步走三步行不行答案是可以但两步最简单保证慢指针不会“跳过”快指针所在的节点。这种追问才是真正的分水岭。删除链表倒数第N个节点双指针法一个指针先走N步然后两个指针同步移动先走的指针到达末尾时后走的指针正好指向目标节点的前驱。边界条件是链表长度为N时直接删除头节点。两个链表的第一个公共节点先分别遍历两个链表得到长度差然后让较长的链表先走差值的步数再同步遍历找到第一个相同的节点。这类题考察的是对“长度差”这个隐藏条件的敏感度。除了链表栈和队列的变体也很常见。比如用两个栈实现队列用两个队列实现栈。前者是所有“实现题”里的经典思路是入队时往stack1压出队时如果stack2为空就把stack1的元素全部倒到stack2再从stack2弹出。后者则是反过来入栈时往queue1入队出栈时把queue1除队尾外的元素全部搬到queue2然后弹出剩下的队尾元素再交换两个队列的角色。这类题考察的核心其实是“数据结构之间的等价转换能力”。在工作中当你需要在一个不支持某种数据结构的语言环境里实现一个抽象结构时这种能力就会直接派上用场。我在做嵌入式开发时经常因为没有现成的队列库就得用手写数组模拟环形队列原理和“用数组实现栈”完全一脉相承。3. 算法与思维题真正的分水岭3.1 排序与Top K大数据场景下的经典考法在2014年那份试卷里排序算法的考察几乎是必然的而且很少只考“请写出快排代码”这种直球更多是结合应用场景追问。比如托普K问题的经典考法在10亿个数中找出最大的100个数内存只有1GB怎么做这道题的标准解法是用一个大小为100的小根堆遍历所有数据每次比较当前元素和堆顶堆中最小的元素。如果当前元素大于堆顶就替换堆顶并重新调整堆。这样堆中始终维持着遍历到目前为止最大的100个数。时间复杂度是O(N log K)而N是10亿K是100log K可以忽略不计所以效率非常高。面试官在这个基础上通常会追加几个问题为什么不直接用快速排序然后取前100个因为快排需要把所有数据都载入内存10亿个数如果每个占4字节就是40GB显然放不进1GB内存而且快排的时间复杂度是O(N log N)在10亿这个规模下远大于O(N log K)。为什么用堆而不用数组因为数组需要频繁移动元素堆的插入和调整都是O(log K)性能稳定。如果数据分布在多台机器上怎么办这时可以先用每台机器内的局部Top K再在归并阶段把所有局部结果汇总重新建堆选出全局Top K。这就是MapReduce里“分治归并”的思路雏形。再比如经典的手写快排考的不只是代码本身还有对退化情况的理解。快排在完全有序数组上的时间复杂度会退化成O(N²)原因是每次选择的基准都是最大或最小值划分极度不平衡。优化的方式是三数取中首、尾、中间三个元素的中位数作为基准或者递归到小规模子数组时改用插入排序。能讲出这一层的候选人在算法上才算真的过关。3.2 字符串与状态机考的是严谨字符串相关题目在校招笔试里的出现频率极高因为字符串处理非常容易出边界问题是检验细心程度的好工具。这份试卷里可能出现的长相有字符串反转但要求原地操作、O(1)额外空间。思路是用两个指针一个从前往后一个从后往前交换字符并向中间移动。坑在于字符指针的\0结尾交换时不要把结束符也交换了。统计字符串中每个字符出现的次数。最简单的方式是用一个长度为256的数组做哈希遍历字符串的同时计数。追问是如果字符集不是ASCII而是Unicode怎么办这时就不能用固定长度的数组了需要用哈希表或者根据编码规则做解码后再统计。实现atoi函数或者写一个字符串转整数的函数。这道题的考察点非常密集要处理前导空格、正负号、数字越界、非法字符以及空指针——在任何时候一个稳健的atoi都不应该因为意外输入而崩溃。我看过很多候选人在这道题上跌跟头原因不是思路不对而是处理INT_MAX和INT_MIN这两个边界值时丢三落四比如-2147483648这个数正数部分已经溢出int必须先按负数逻辑处理再转换符号。字符串题目背后还隐藏着一类“状态机”思维。比如判断一个字符串是否是合法的IP地址最严谨的做法是先定义状态数字开始、数字中间、遇到点号切换到下一段、四段都结束且最后没有多余字符才判定合法。用状态机的思路去写就不会漏掉“1.1.1.01”这种不合法的输入因为01不是合法表示。我后来自己在写网络协议解析器时发现这种“先定义状态再写逻辑”的方式能避免大量if-else堆叠带来的混乱。3.3 智力题逻辑和边界思维的检验很多研发岗笔试试卷里都会带几道所谓的“智力题”小米这套卷子也不例外。常见的类型包括烧绳子计时、老虎过河、天平找假币、100层楼扔鸡蛋之类的变体。很多人觉得智力题是“脑筋急转弯”其实不然。以天平找假币为例有12枚硬币其中1枚是假的不知轻重用无砝码天平称3次找出假币并说明轻重。这道题的关键是“每次称量获得的信息量是有限的”——天平每次有三种结果左重、右重、平衡所以3次最多能区分3³27种情况而12枚硬币可能的状态是24种12乘以不知轻重在信息论上是可行的。解题的核心策略是让每次称量的结果尽量“均匀分布”不要把硬币分成6和6——因为如果左右平衡剩下的可能性太多更好的分法是4、4、4三组结果都能覆盖大约1/3的情况。智力题本质上考察的是建模能力和分治思想。如果做题时只想着“试出来”而不去思考“为什么这一步能缩小范围”那刷多少智力题都没有用。这类题一旦掌握思路反倒是最容易在笔试里拿分的部分因为套路固定变化有限。4. 操作系统、网络与系统设计4.1 进程线程与并发从理论到案例操作系统是研发工程师笔试的另一座大山。2014年的试卷里进程和线程的区别几乎是必考。常规答案大家都知道进程是资源分配的基本单位线程是CPU调度的基本单位同一进程内的线程共享地址空间而进程之间地址空间相互独立。但这类题目拉开差距的地方在于追问。比如问线程之间共享什么不共享什么共享的包括堆、全局变量、文件描述符、信号处理器不共享的有栈、寄存器上下文、程序计数器。再比如问进程间通信有哪些方式经典答案为管道、消息队列、共享内存、信号量、套接字、信号。关键在于能够解释各自的适用场景管道适合父子进程之间的简单单向通信共享内存适合大数据量高频通信但需要解决同步问题套接字适合跨机器通信。多线程同步和死锁也是高频考点。一个常考的问题是死锁产生的四个必要条件是什么互斥、占有且等待、不可剥夺、循环等待。缺一不可所以打破其中任意一个条件就能预防死锁。工程上最常见的做法是破坏“循环等待”比如让所有线程按同一个全局顺序来获取锁。我在实际项目里遇到过无数次因为两个线程以不同顺序加锁而导致的偶发性死锁这种bug极其隐蔽复现概率低排查成本高。所以笔试里考死锁其实是在考察你有没有在代码设计之初就考虑并发安全性的习惯。信号量、互斥锁、条件变量之间的区别也常被拿来比较。互斥锁是线程间互斥访问共享资源信号量不仅能做互斥还能做同步条件变量则用于等待某个条件满足后再继续执行。笔试常考“生产者-消费者”模型用哪种同步原语实现——标准答案是互斥锁保护共享队列条件变量在队列空时让消费者睡眠生产者往队列里放数据后唤醒消费者。能把这个模型写清楚并发编程这块基本就过关了。4.2 网络协议TCP三次握手之外的追问网络协议里最常考的是TCP三次握手和四次挥手。基础版本是画出状态变迁图说清楚SYN、ACK、FIN各在什么阶段出现。进阶版本是追问为什么建立连接需要三次而释放连接需要四次三次握手的原因是通信双方要确认“自己的发送能力”和“对方的接收能力”都正常。第一次握手客户端发送SYN服务端确认客户端的发送能力第二次握手服务端发送SYNACK客户端确认服务端的发送能力和自己的接收能力第三次握手客户端发送ACK服务端确认客户端的接收能力。三次之后双方都确认了“我发你收、你发我收”都畅通。四次挥手则是由于TCP连接是全双工的关闭时每个方向都必须独立关闭。主动关闭方发送FIN被动关闭方回复ACK被动关闭方再发送自己的FIN主动关闭方回复ACK。中间那个“被动关闭方回复ACK”和“发送FIN”之间可能隔着一段数据处理时间所以不能合并成一次这就是为什么挥手比握手多一次。试卷里还可能涉及TCP和UDP的区别、HTTP和HTTPS的区别。HTTP是应用层协议基于TCPHTTPS在HTTP和TCP之间加了一层TLS/SSL加密。笔试常问HTTPS握手过程中证书验证的流程客户端拿到服务端证书用CA公钥验证证书签名确认服务端身份后双方通过非对称加密协商出一个对称密钥之后的数据传输都用对称加密。这个流程的细节很多能讲清楚“数字签名”“非对称加密协商会话密钥”这两个关键步骤基本就算吃透了。4.3 结合业务场景的小设计题小米的试卷有一个特点会出一些贴近自身业务的小设计题。比如“如果让你设计一个图片加载框架你会怎么做”“如何统计一个App的日活用户”这类问题。这种题目考的不是你到底有没有做过具体项目而是你有没有把操作系统、网络、数据结构的知识串起来用。以图片加载框架为例合理的思路是内存缓存用LRU最近最少使用算法维护一个有限大小的图片缓存超过上限就把最久没用的图片淘汰。磁盘缓存内存不够时把图片文件缓存在本地存储里同样需要设定容量上限。网络加载通过URL发起HTTP请求获取图片数据在子线程完成避免阻塞UI。解码与缩放拿到原始图片数据后根据目标控件的尺寸进行采样压缩避免OOM。这个小设计题几乎把数据结构哈希表双向链表实现LRU、操作系统内存管理、网络HTTP全部串起来了。我在面试别人时发现能答出第一层内存缓存的人很多但能自然而然地想到磁盘缓存和解码压缩的人寥寥无几这往往是实战经验多寡的体现。5. 答题策略与后悔药5.1 笔试现场的时间分配两小时做一套综合卷时间其实很紧张。我的经验是不要按试卷顺序从头做到尾而是先把卷子翻一遍把题目按难易程度分成三档第一档是会做的题先拿拿稳的分。比如选择题、填空题、自己非常有把握的简答题快速扫一遍尽量别失分。第二档是有点思路但需要动笔计算的题比如算法题、数据结构实现题。留出完整的连续时间块来写写之前先在草稿纸上画一画数据结构的变化过程确认逻辑通顺再落笔避免返工。第三档是完全没有思路的题先跳过等全部做完再回头啃。笔试里的每一分都值钱与其在一道15分的难题上耗20分钟不如先用5分钟把后面一道10分的基础题分拿到。常见的翻车现场是在“实现一个字符串反转”这种简单题上纠结于“用循环还是用递归”浪费了大量时间导致后面操作系统和网络的大题来不及写。记住笔试追求的是“总分最大化”不是“每一题都完美”。5.2 我见过的高分卷与低分卷我后来参与校招阅卷时观察到一个规律高分卷和低分卷的区别往往不在会不会做难题而在基础题的正确率。低分卷的典型画像算法题写得洋洋洒洒但指针题里sizeof判断错误进程线程区别回答得模棱两可TCP三次握手少画了一次ACK甚至出现代码缩进混乱、变量名随意这种“看着就不想细看”的问题。高分卷的典型画像基础选择题几乎全对简答题条理清晰算法题即使没有完全跑通也会在注释里写出自己的思路和遇到的边界情况让阅卷人能看出“这个人就算这里没写好也知道正确的方向是什么”。特别要注意卷面。不要把代码写得密密麻麻在纸上写代码时留出足够的行间距方便自己后续修改也方便阅卷人阅读。字迹不一定漂亮但必须清楚——如果你连自己的变量名都认不出来阅卷人更不可能帮你脑补正确的逻辑。还有一个容易忽略的细节算法题如果一时想不出最优解先写一个暴力解再在注释里补充“这个解法的问题在于复杂度太高优化方向是XXXX”。这种做法有两个作用一是保证你至少拿到底分二是让阅卷人看到你有优化意识。相反留白不写的题阅卷人想给分都给不了。5.3 备考时最容易踩的坑针对这份试卷的风格我在备考建议上特别想强调三个坑第一不要只看知识点不写代码。很多人复习操作系统、网络时纯靠背书觉得理解了就行。但笔试卷是要求你写代码的你理解指针是一回事让你在白纸上手写一个链表逆置是另一回事。我建议准备一个白纸本每天手写3-5个算法题或者数据结构操作题写完之后对照标准答案检查边界条件。第二不要只刷算法题忽略其他模块。现在的LeetCode文化让大家把80%的精力都放在了算法题上但类似小米这套卷子的综合笔试算法题通常只占三分之一左右的分数。操作系统、网络、数据库这些基础模块的分同样重要。如果只顾刷题不管其他卷面总分天花板会很低。第三不要眼高手低基础题不等于是送分题。最简单的“进程和线程的区别”很多人答不全包括线程共享进程的地址空间所以线程间通信成本低但代价是一个线程崩溃可能导致整个进程退出而多进程之间互相隔离单个进程崩溃不会拖垮其他进程。这些隐藏在基础概念背后的工程权衡才是阅卷人希望看到的深度。6. 这套卷子对今天还有没有参考价值有人可能会问都过去这么多年了这套2014年的笔试题目还有什么参考价值技术圈变化这么快当年考的Android、iOS知识早就迭代好几轮了。我的看法是框架和语言会过时但计算机基础不会。2024年的大厂校招笔试题照样考TCP三次握手照样考链表操作照样考进程线程区别照样考Top K问题。变化的只是载体——以前是纸质试卷现在是在线OJ以前要手写函数实现现在要处理ACM风格的输入输出。但底层的知识点和考察目标始终是一致的验证你有没有把一个计算机专业毕业的人应该掌握的地基打牢。如果你正在准备校招与其漫无目的地刷几百道LeetCode不如花两周时间把计算机基础系统地过一遍然后找几套经典笔试题比如小米这套A卷当作模拟测试卡着时间做一遍再对照答案复盘。这个过程下来你对笔试题的套路会有完全不一样的感觉。还有一个通用的建议不管笔试形式怎么变答题时体现出的思维方式才是最关键的。笔试卷上的答案是死的但阅卷人能从答案里看出你是“背过这个答案”还是“真正理解这个问题”。前者也许能过笔试但很难通过后续的面试后者才是拿到offer的真正钥匙。从一份2014年的笔试试卷里你能看到的不仅仅是几道题更是一代研发工程师培养体系里的筛选逻辑。把这些逻辑看懂你准备任何校招笔试都会更有方向。
