以后嵌入式面试还能问出真水平吗？

问项目做过什么。问某个模块是不是你负责的。问任务怎么划分，队列怎么用，中断里做了什么。再往下问一点，指针、内存、volatile、栈溢出、RTOS 调度、串口丢包、I2C 异常、DMA 这些细节，基本就能看出一个人到底有没有做过。

会就是会。

不会也能临时说几句，但很快就会露出来。

因为嵌入式很多东西不是背几个概念就能装出来的。你有没有在板子前面熬过，有没有被一个偶发 bug 折磨过，有没有看过寄存器、波形、日志、map 文件，问深一点，感觉是不一样的。

但现在 AI 出来以后，这件事变得有点微妙。

简历可以让 AI 润色。项目经历可以让 AI 帮你整理。面试题可以让 AI 帮你准备。不会的概念，可以让 AI 用很漂亮的话解释。甚至一个学生没有完整做过项目，也能让 AI 帮他把课程设计、毕业设计包装成一套看起来很完整的技术叙述。

那以后嵌入式面试还怎么问？

是不是问基础，别人说是 AI 帮我学的；问项目，别人说是 AI 辅助开发的；问代码，别人说 AI 写了第一版，我调了一下。

这个问题对面试者是挑战，对公司也是挑战。

1

以前面试，很多问题能问出经历

我自己以前理解嵌入式面试，核心不是把人考倒，而是确认几件事。

第一，他到底有没有接触过真实工程。

有些人简历上写了很多项目，但一问供电、通信、任务划分、资源限制，就讲得很空。真实做过的人，通常会记得一些很具体的东西，比如某个任务栈开小了，某个外设初始化顺序不对，某个串口在高负载下丢数据，某个驱动在中断里处理太多导致系统抖动。

这些细节不是标准答案。

它们更像项目留下来的伤口。

第二，他基础是不是能支撑他继续成长。

嵌入式绕不开 C 语言。指针、数组、结构体、内存布局、编译链接、static、const、volatile，这些东西平时看着老生常谈，但真正出了问题，经常就卡在这里。

比如一个变量在主循环和中断里同时用，为什么要考虑 volatile，为什么只加 volatile 还不一定够。比如一个局部数组开大了，为什么系统会跑飞。比如一个函数指针表写错了，为什么看起来像随机跳转。

这些问题过去很好问。

因为你要么真理解，要么就是背了几句定义。再加几个追问，很容易看出来。

第三，他遇到问题时是不是有排查路径。

嵌入式开发不是只写代码。更多时候是在和不确定性打交道。程序不进中断，先看 NVIC 还是看引脚复用？I2C 偶发 NACK，先怀疑上拉、电平、时序，还是驱动状态机？低功耗电流下不来，先看外设时钟，还是 IO 状态？

这些东西没有唯一答案，但能看出一个人的工程感觉。

2

AI 把很多表面差距抹平了

现在的问题是，AI 把很多表面差距抹平了。

一个大学生基础不扎实，但他可以让 AI 帮他补基础题。

不知道 volatile，AI 可以给出定义、例子、常见误区。

不知道 RTOS 死锁，AI 可以讲互斥锁、优先级反转、资源竞争。

不知道项目怎么介绍，AI 可以帮他把“我做了个温湿度采集系统”包装成“基于 FreeRTOS 的多任务传感器采集与通信系统”。

如果只是看简历和听前两分钟介绍，确实很难分辨。

尤其是大学生。

现在很多课程设计、实验报告、毕业论文，都可以被 AI 加工得非常完整。以前一个学生有没有真的把代码跑起来，报告里多少能看出痕迹。现在报告可能写得比真实经历还顺。

这就会带来一个很现实的问题：面试官问基础知识，候选人可以背 AI 帮他整理的答案；问项目经历，候选人也可以背 AI 帮他梳理的项目话术。

如果面试还是停留在“请你讲一下什么是指针”“请你介绍一下你的项目”，确实会越来越难筛人。

但我不觉得基础题就不能问了。

问题不是基础题没用了，而是基础题不能再孤立地问。

3

以后基础题要放进场景里问

比如问 volatile，以前可以直接问：volatile 有什么作用？

现在这样问，候选人很容易背出一套答案。什么防止编译器优化，什么内存可见性，什么硬件寄存器和中断共享变量。

这些话都对，但不够。

更好的问法可能是：

volatile uint8_t rx_done = 0;

void USART_IRQHandler(void)
{
    rx_done = 1;
}

int wait_rx_done(void)
{
    int timeout = 100000;
    while (!rx_done && timeout--) {
    }
    return rx_done ? 0 : -1;
}

然后问：这段代码能不能工作？有什么风险？

如果 rx_done 不是 8 位，而是一个 32 位计数器，会有什么不同？

如果这个变量在多个任务之间共享，光加 volatile 够不够？

如果面试者真的理解，他会讲到编译优化、中断共享、超时设计、原子性、任务同步，甚至会说这里更好的方式可能是信号量、事件标志或者环形缓冲。

如果只是背 AI 答案，很容易停在第一层。

再比如问指针，也不要只问“指针是什么”。可以给一段真实一点的代码：

void parse_frame(uint8_t *buf, uint16_t len)
{
    uint16_t payload_len = buf[2] << 8 | buf[3];
    uint8_t *payload = &buf[4];

    for (uint16_t i = 0; i < payload_len; i++) {
        handle_byte(payload[i]);
    }
}

然后问：这里可能有什么问题？如果 len 小于 4 会怎样？如果 payload_len 比实际缓冲区长会怎样？如果这个函数处理的是串口 DMA 接收缓冲区，还要考虑什么？

这种问题仍然是基础，但它不是背概念，而是看一个人能不能把基础放回工程现场。

4

项目经历也不能只听介绍

很多公司现在更喜欢问项目经历，这个方向是对的，但只听候选人讲项目，也会被 AI 影响。

因为项目介绍非常容易被包装。

一个普通的课程设计，AI 可以帮你扩写成架构清晰、模块完整、术语准确的项目描述。比如传感器采集、通信协议、上位机显示、数据存储、异常处理，听起来都很像那么回事。

所以以后问项目，不能只问“你做了什么”，而要问“你怎么做的，为什么这么做，中间错过什么”。

比如一个人说自己做过基于 RTOS 的数据采集项目，可以继续问：

当时为什么要上 RTOS，而不是裸机轮询？

任务优先级怎么分的？

队列长度怎么定的？

有没有遇到过队列满、数据丢失、任务卡死？

某个任务的栈大小怎么估算？

如果采样频率翻倍，系统瓶颈会在哪里？

项目里哪个 bug 让你印象最深？

这些问题不一定要求候选人回答得完美，但能看出他是不是经历过真实取舍。

真实项目里一定会有不顺。

如果一个人把项目讲得过于完整、过于正确、没有任何波折，反而要警惕。工程不是 PPT，尤其是嵌入式项目，不可能从头到尾都像文档写得那么顺。

5

面试不该排斥 AI，但要问清 AI 的边界

我不认为以后面试应该简单地问一句：这个项目是不是 AI 写的？

这个问题意义不大。

现在工作里用 AI 已经很正常。写脚本、查资料、解释代码、生成测试用例、整理文档，这些都可以用。一个候选人会用 AI，本身不应该扣分。

真正该问的是：

AI 帮了你哪一部分？

你自己改了哪一部分？

AI 给过哪些不靠谱的建议？

你是怎么验证生成代码的？

最后出了问题，你怎么定位？

如果候选人能坦诚说明 AI 的使用边界，并且能讲清楚自己负责的判断和验证，我反而觉得这是加分项。

因为这说明他不是把 AI 当代写工具，而是当工程助手。

相反，如果一个人所有细节都说不清，只会说“这是 AI 生成的，我调了一下”，那就很危险。

公司招人不是招一个会复制 AI 答案的人，而是招一个能对结果负责的人。

6

大学生会更难，也会更容易露出来

AI 对大学生面试的影响会更明显。

一方面，大学生可以借助 AI 更快做出东西。以前大一、大二基础不够，很难做一个完整项目。现在只要会提问，会跟着 AI 调整，做出一个能演示的系统并不难。

这对学生是好事。

至少它降低了实践门槛。很多人以前卡在环境配置、语法错误、资料查找上，现在可以更快进入项目。

另一方面，也更容易形成一种虚假的熟练感。

项目是跑起来了，但不知道为什么这样设计。

代码是能用了，但不知道边界在哪里。

报告是写完了，但不知道实验现象是否真实。

简历是好看了，但一问调试细节就空了。

所以大学生面试以后可能会出现一个很大的分化。

会用 AI 学习的人，会成长得更快。他能让 AI 解释代码，但自己会复盘；能让 AI 生成第一版，但自己会改；能让 AI 准备面试题，但自己会把题放到项目里理解。

只用 AI 包装的人，短期看起来也不错，但面试一深入就会露出来。尤其是嵌入式岗位，只要问到具体代码、具体硬件、具体异常、具体调试过程，空心项目很难撑太久。

7

公司也不能再用老办法筛人

这件事不只是候选人的问题。

公司如果还完全按以前的面试方式来，也会吃亏。

只看简历关键词，会被 AI 润色影响。

只问概念题，会被 AI 标准答案影响。

只让候选人讲项目，会被 AI 话术影响。

只做笔试题，也可能筛掉一些真实工程能力不错但不擅长刷题的人。

嵌入式岗位更适合增加一些现场判断类问题。

比如给一段有问题的 C 代码，让候选人读出来风险。

比如给一个串口丢包的现象，让候选人说排查顺序。

比如给一个 HardFault 的寄存器现场，让候选人说可能方向。

比如给一个 RTOS 任务卡死的描述，让候选人分析是死锁、优先级、栈溢出还是中断占用太久。

比如给一个外设初始化失败的场景，让候选人说先看时钟、引脚复用、复位、供电还是手册限制。

这些题不一定要有唯一标准答案。

面试官要看的，是候选人的推理过程。

他会不会先确认事实？

会不会区分现象和猜测？

会不会提出可验证的下一步？

会不会承认不确定，而不是硬编？

这些东西比背答案更接近真实工作。

8

我觉得更合适的面试方式

如果让我设计一个 AI 时代的嵌入式面试，我可能会分成几块。

第一块，基础概念，但必须结合代码。

不要只问定义。给短代码，让候选人看风险。比如数组越界、指针生命周期、volatile、中断共享变量、内存对齐、大小端、环形缓冲、错误码处理。

第二块，项目经历，但必须追到现场。

不问泛泛的“项目介绍”，而问模块边界、资源约束、失败经历、调试路径、版本变化。真实做过的人不一定讲得华丽，但会有细节。

第三块，调试题，看思路。

给一个现象，不要求马上说出答案，而是要求给排查步骤。嵌入式工程里，很多问题本来就不是一眼能判断的。能不能合理缩小范围，比能不能猜中答案更重要。

第四块，AI 使用边界。

直接问候选人平时怎么用 AI。让他讲一个 AI 帮上忙的例子，也讲一个 AI 误导他的例子。这个问题很有价值，因为以后工作里大家都会用 AI，关键是看他有没有验证意识。

第五块，小任务。

如果条件允许，可以给一个很小的代码修改任务。比如修一个环形缓冲区问题，补一个超时处理，改一个状态机边界。时间不用长，十几分钟就能看出很多东西。

AI 之后，嵌入式面试不会变简单。

它会变得更难。

以前问几个基础题、追几个项目细节，大概就能判断一个人。以后这些表层内容都会被 AI 打磨，面试官需要更会问，候选人也需要更真实地证明自己。

但我不觉得这是坏事。

因为嵌入式本来就不是只靠背答案能做好的行业。

你可以让 AI 帮你解释指针，但指针越界导致系统跑飞时，你还是要能定位。

你可以让 AI 帮你写驱动框架，但外设不工作时，你还是要看手册、看时钟、看波形。

你可以让 AI 帮你准备项目介绍，但面试官问到某个 bug 怎么来的、怎么复现、怎么修掉时，真实经历是藏不住的。

以后真正有价值的面试，不是问候选人有没有用 AI，而是看他有没有在 AI 之外长出自己的判断。

对面试者来说，AI 可以帮你跑得更快，但不能替你长出经验。

对公司来说，AI 会让包装变得更容易，也会让真正会思考的人更值得被识别出来。

嵌入式面试最终要找的，还是那种能把问题带回现场的人。

看到现象，能拆。

看到代码，能读。

看到 AI 的答案，能判断。

出了问题，能负责。