秋招春招面了 20 家左右大厂后，我总结了这些 STM32 / 嵌入式面试经验

秋招加春招，前前后后我差不多面了 20 家公司，岗位主要集中在嵌入式软件开发、STM32 方向、Linux 驱动、底层软件，还有一部分车载相关岗位。

一路面下来，我最大的感受就是：嵌入式面试真的很容易让人产生一种“我好像都会”的错觉。

准备的时候，很多知识点看着都眼熟，八股也背了，项目也做过，平时自己写代码的时候也没觉得哪里不懂。

但真正到了面试里，尤其是一被追问，就会很快发现：很多内容其实只是“看过”“背过”，离“真正理解”“能展开讲清楚”“能抗住连续追问”还差得很远。

下面这几条，是我秋招春招一路面下来最真实的感受。如果你也在准备 STM32、嵌入式、驱动、底软这类岗位，希望这些总结能给你一点参考。

1. 八股一定要背，但更重要的是“理解版八股”

先说结论：嵌入式面试一定离不开八股。

这个几乎没什么悬念。

C 语言、指针、数组和指针区别、内存分区、栈和堆、volatile、static、const、结构体对齐、大小端、中断、回调、状态机、STM32 启动流程、GPIO/UART/SPI/I2C/CAN、DMA、FreeRTOS、任务调度、临界区、互斥锁、信号量、死锁、Linux 进程线程、虚拟内存、设备驱动模型……这些基本都是高频中的高频。

但真正面得多了你会发现，大厂其实不太吃“背诵型回答”。

很多题如果你只是把标准答案背出来，面试官大概率不会就这么放过你，而是会继续往下追，比如：

• volatile 能不能保证线程安全？
• const 和宏定义常量的区别是什么？
• 中断里为什么不能做太多事情？
• SPI 和 I2C 各自适合什么场景？
• 互斥锁和信号量本质区别是什么？
• FreeRTOS 任务切换的触发条件有哪些？
• 为什么会出现优先级反转？怎么解决？
• 用户态和内核态切换的开销主要体现在哪？
• DMA 为什么能减轻 CPU 负担？代价是什么？

准备嵌入式面试八股文我推荐这个专栏，真的很全面，很深入：

https://www.nowcoder.com/creation/manager/columnDetail/mPZ4kk

这些问题表面上看还是八股，但本质上已经不是在考“你有没有背过”，而是在考：你到底理解到什么程度。

所以我后面越来越觉得，准备八股不能只停留在“记住答案”这一层，而是至少要准备三个层次：

第一层：能把概念说清楚。

比如别人问 volatile，你不能只说“防止编译器优化”，你得知道它到底防止了什么优化，为什么在寄存器变量、中断共享变量、多线程共享变量里常见。

第二层：能说出适用场景和局限。

比如你要知道 volatile 能保证可见性，但不能保证原子性，也不能直接保证线程安全。

第三层：能结合项目举例。

比如你可以说自己在哪个 STM32 项目里，把串口接收标志位或中断共享变量定义成了 volatile，否则主循环里可能读不到更新后的值。

只有你准备到这个程度，面试的时候才不容易被问两句就卡住。

我自己的感觉是，嵌入式八股准备最怕的一种状态就是：“看着都熟，真讲不会。”

而大部分人被挂，很多时候不是因为完全不会，而是因为回答总停留在太表面的位置。

2. 项目才是真正的主战场，很多公司其实是在“借项目考基础”

一开始我有个误区，觉得项目这块我自己做过，肯定比八股更稳。

后来面多了才发现，完全不是这么回事。

很多公司的面试风格其实是这样的：

先让你介绍项目，然后一路顺着项目往下挖。

表面上像是在问你做过什么，实际上是在借你的项目去考你的基础、工程理解、问题定位能力，甚至考你是不是“真的做过”。

比如你说你做过一个 STM32 智能硬件项目，面试官后面很可能接着问：

• 系统整体架构怎么分的？
• 为什么选 STM32，而不是别的 MCU？
• 外设驱动是自己写的还是基于 HAL/LL？
• 为什么这里用中断，不用轮询？
• 为什么这里用 DMA？
• 任务优先级怎么定的？
• 你们为什么选 FreeRTOS，不用裸机？
• 通信为什么选 UART / SPI / CAN？
• 系统里有没有做状态机？怎么设计的？
• 你遇到过最难的问题是什么？
• 这个 bug 当时怎么定位的？
• 最后怎么验证修复真的生效了？

一旦问到这里，项目就已经完全不是“自我介绍”了，而是在考你对整个系统有没有掌控感。

我后面复盘的时候越来越觉得，项目准备最重要的不是背项目介绍，而是把项目真正拆开。

至少要能从这几个角度去讲：

• 项目背景是什么，解决什么问题
• 你负责了哪一部分
• 整个系统怎么分层、怎么协作
• 关键模块为什么这么设计
• 遇到过什么问题
• 你怎么分析、怎么定位、怎么解决
• 最终结果是什么，有没有优化效果

如果这些内容你没有提前梳理过，面试时就特别容易出现一种情况：

一开始讲得还行，但讲着讲着就散了，细节一问就虚了，最后面试官很容易怀疑你是不是只参与了很小一部分，或者只是“跟着做”。

尤其是 STM32 这类岗位，项目深挖特别常见。

因为相比纯算法岗，嵌入式岗位更强调“你有没有真实做过系统”，而项目恰恰是最容易看出这个东西的地方。

3. 一面看广度，二面看深度，越往后越像“能力验证”

面得多了之后，我一个很明显的感受就是：不同轮次面试的重点真的不一样。

一面：更像基础筛选

一面通常覆盖面比较广。

C 语言基础、STM32 外设、操作系统、通信协议、RTOS、Linux 基础，再加一点项目概述，这些都很常见。

这一轮更像是在判断：

你是不是这个岗位的基本盘匹配人选。

所以如果基础比较薄，一面往往就会打得很难受。因为它不是专挑一个方向深挖，而是会把高频考点快速扫一遍。只要某一块明显短板，就很容易暴露。

二面 / 主管面：更像能力验证

但到了二面，尤其是主管面或者更偏核心团队的面试，风格一般会明显变化。

这时候面试官往往已经不满足于“你知道这个知识点”，他更关心的是：

你到底能不能做事。

项目深挖、系统设计、问题定位、工程取舍，这些内容会明显变多。

有些公司二面甚至会围绕一个项目一直问四五十分钟，从系统架构问到模块实现，从正常流程问到异常场景，从调试思路问到优化方法。

尤其是车载、驱动、底层软件这类岗位，二面经常会比一面难很多。

一面可能还偏“知识问答”，二面就已经开始偏“工程思维”了。

比如很常见的这类问题：

• 如果系统偶发死机，你怎么排查？
• 如果中断非常频繁，导致任务得不到调度，怎么办？
• 如果串口偶发丢数据，你怎么判断是硬件问题、驱动问题还是协议问题？
• 如果任务栈溢出了，一般有哪些现象？怎么定位？
• 如果某个模块资源很紧张，你怎么做取舍？
• 如果让你重构这个模块，你会怎么设计？

这类题很多时候没有标准答案，但特别能看出一个人到底有没有工程经验。

所以准备面试不能只按“题库思维”来。

除了背高频题，你还得训练自己两种能力：

• 系统思维：能站在整体上看模块关系
• 问题定位思维：遇到问题知道怎么一步步缩小范围

这两种能力，往往就是二面最爱考的地方。

4. 面试官特别在意你有没有“真实做事能力”

这一点我感触非常深。

很多时候，面试官未必要求你每道题都回答得非常完美，但他会特别在意一件事：

你像不像一个真正做过工程的人。

什么叫“像真正做过工程的人”？

不是说你简历上写了“做过 STM32 项目”“做过驱动开发”“做过 RTOS 移植”，而是你能不能把很多细节讲出来。

比如：

• 为什么当时这么设计？
• 这个方案的优点和代价分别是什么？
• 你踩过哪些坑？
• 问题出现的时候你第一反应是什么？
• 你当时怎么缩小问题范围？
• 你怎么验证自己的猜想？
• 你怎么确认这个问题真的解决了？

这些内容一说出来，面试官通常一下就能感觉到：

这个人到底是亲手做过，还是只是参与过边缘部分，或者只是会复述结果。

反过来，如果一个项目听起来很大很复杂，但一问细节，你的回答总是：

• “这个就是这么实现的”
• “当时调了很久”
• “最后反正解决了”
• “这个具体我记不太清了”

那基本就很难让人信服。

我后来复盘自己的面试，也越来越确认一件事：

真正拉开差距的，往往不是谁背得更多，而是谁能把“知识”变成“经历”，再把“经历”讲成一段有逻辑的解决过程”。

所以如果你真的想把项目这一块准备扎实，我很建议每个项目都准备两个版本：

一个是 1 分钟版本。

适合自我介绍、快速概括、面试开场。

一个是 5 分钟版本。

适合展开讲系统架构、核心模块、难点、问题定位和优化过程。

这样面试的时候，你就不会一上来讲太散，也不会被问深以后完全没得说。

5. 面试其实是一个不断校准自己的过程，前几场被打懵很正常

最后一个感受，其实更偏心态。

刚开始面试的时候，真的特别容易被打懵。

尤其是嵌入式岗位，知识面本来就很广：从 C 语言到底层原理，从 MCU 外设到 RTOS，从协议到驱动，从硬件协同到系统调试，几乎什么都可能问。

很多时候并不是你完全不会，而是你平时虽然学过、做过，但没有在那种高压环境下把它组织成一段清晰、有逻辑、能抗追问的表达。

所以前几场面得不顺，太正常了。

但只要你坚持复盘，面多了之后，你会很明显感觉到自己在变稳：

• 你会慢慢知道哪些题是高频中的高频
• 你会知道自己哪些点总是答不完整
• 你会发现哪些项目表述最容易被问穿
• 你会知道怎样回答更容易让面试官听懂
• 你也会更清楚，哪些岗位到底适合自己

这个过程其实很像调系统。

先暴露问题，再定位问题，再一点点补齐短板，最后整体状态越来越稳定。

我自己一路面下来，最大的变化不是某一个知识点突然学会了，而是对“嵌入式面试这件事”有了更清晰的理解：

企业不是只想找一个“背题的人”，

也不是只想找一个“做过几个项目的人”，

而是想找一个 基础过关、项目真实、思路清晰、能定位问题、能落地做事 的工程师。

这也是为什么嵌入式面试很少能靠单点突破。

只背八股不行，只堆项目不行，只会写代码但讲不出来也不行。

真正有效的准备方式，还是把 基础、项目、表达 这三件事一起抓。

如果让我重新准备一次，我会把精力重点放在这几件事上

1. 把高频基础题真正学懂，而不是只背答案

尤其是 C 语言、STM32 外设、中断、RTOS、通信协议、Linux 基础这些内容，不能停留在“我看过”，而是要到“我能讲清楚”的程度。

2. 把每个项目按固定框架完整复盘

最起码要能讲清楚：

背景 - 架构 - 负责部分 - 难点 - 问题 - 定位 - 解决 - 结果

3. 多练表达，尤其练“怎么把复杂问题讲简单”

很多人不是不会，而是讲不清。

而面试本质上就是一种高压表达场景，所以表达能力真的很重要。

4. 每面完一场都及时复盘

哪些题没答好，哪些点被追问了，哪些项目细节暴露短板了，都尽量记下来。

因为很多提升，其实都是靠一场一场复盘积累出来的。

5. 不要因为前几场表现一般就怀疑自己

嵌入式面试本来就是一个知识面广、追问深、很看综合能力的过程。

很多进步不是你学了一天两天就能立刻看到的，而是在连续被拷打、连续修正之后，慢慢出现的。

最后

秋招春招一路走下来，我越来越觉得，嵌入式面试本质上考的不是：

“你背了多少”

而是：

“你到底理解了多少，做过多少，能说清多少。”

这三件事如果准备到位了，后面的面试体验真的会顺很多。

尤其是 STM32、嵌入式软件、Linux 驱动、底层软件这些岗位，看起来像是在问知识点，实际上最后拼的还是：

你有没有真实理解，有没有真实做事，有没有工程思维。

如果你现在也正在准备这类岗位，我很想说一句：

前几场被问懵、答不好、节奏乱，真的都很正常。别太早否定自己。很多人不是不行，而是还没完成那轮必要的“校准”。

面试这件事，本来就是一边被问，一边暴露问题，再一边补齐问题的过程。