企业官网建设流程全解析

1. 面试现场还原：技术全对，为什么还是挂了？

先看一个我最近复盘的真实案例。候选人小 A，五年嵌入式经验，简历上写着精通 STM32、熟悉 Linux 驱动开发，目标薪资 30K。面试前半程，主管问了 Cortex-M 内核架构、FreeRTOS 任务调度机制、Linux 中断下半部、设备树语法，小 A 对答如流，几乎每个问题都能给出标准答案。气氛一度非常融洽。

转折点出现在研发总监进场的二面。总监没问任何具体的 API 或寄存器，只抛了三个问题：

第一个：你现在要在一个 STM32F407 上做 32 路按键扫描，要求非阻塞、不能影响主循环里 1ms 周期的控制任务，你会怎么设计？小 A 回答：用定时器中断，每 10ms 扫描一次，按键消抖用延时，或者简单点直接用轮询。总监眉头皱了一下。

第二个：你之前做过一个带 Wi-Fi 模块的网关项目，设备在客户现场偶发死机，你排查了一个星期没找到原因，你怀疑是哪几个方向？小 A 说：可能是硬件复位的问题，可能是电源不稳定，也可能是看门狗没喂好。总监追问：具体怎么定位？回答开始模糊了。

第三个：如果现在让你重新设计那个网关，从硬件选型到软件架构，你会做哪些不一样的决策？小 A 沉默了十几秒，说：可能会换个更强的 MCU，或者加个外部看门狗。

面试结束，总监给的评语是：基础扎实，但思维停留在“点”上，没有“面”的概念，当前薪资给不到 27K。

这不是个例。我今年帮朋友内推了几十个候选人，发现一个普遍规律：很多写了好几年 STM32 的人，技术知识点不可谓不熟——DMA、定时器、I2C、SPI、CAN 都能说出个一二三，Linux 下的字符设备驱动、platform 总线、设备树语法也能背得滚瓜烂熟。但一到系统级的问题，一到“没有标准答案”的开放场景，立马露怯。

这篇文章我想聊的，不是那些“标准答案”，而是研发总监面试时真正在评估的东西。它和你会多少个外设、背过多少个面试题，关系没那么大。

2. 研发总监的视角：他在评估的不是知识量，而是认知层次

2.1 知识点是“存量”，工程能力是“增量”

很多候选人有个误区：面试 = 回答问题。但其实，主管面和总监面考核的维度完全不同。主管面是筛选你能不能干活，总监面是评估你能扛多大摊子、能不能独立闭环。

“STM32 的 I2C 总线有哪些模式？”“Linux 内核里 spinlock 和 mutex 的区别是什么？”——这类问题是知识存量测试，背过就能答。总监不会把重点放在这上面，他会问类似：你这个系统如果同时要处理 128 个传感器数据、十几个外设、一个网口、三个串口，你怎么划分优先级？你的架构怎么保证任何一个模块崩了不会拖垮整个系统？

这里面没有标准答案，但考察的是候选人的系统拆解能力、权衡能力、工程取舍能力。说白了，能不能在资源和成本受限的条件下，设计出一个跑得稳、扛得住现场环境、出了问题能快速排查的系统。

我见过很多候选人，一说 DMA、中断优先级这些知识点，头头是道。但你把一个实际场景摆在他面前——比如串口接收不定长数据，DMA 空闲中断接了，突然又来一个高优先级任务抢占 CPU，数据会不会丢？怎么保证不丢？——就卡壳了。这就是典型的“知识点不会迁移”。

总监面最想验证的一件事：你是拿代码在堆功能，还是在拿架构在管理系统复杂度。前者是码农思维，后者才是工程师思维。30K 对应的是后者的能力。

2.2 面试中暴露的三个致命思维习惯

结合多年围观和参与面试的经验，我总结出三个在总监面中会直接扣分的思维习惯。

第一，答问题永远只答“怎么做”，不答“为什么这么做”。比如问到为什么选 FreeRTOS 而不选 RT-Thread，大部分人会回答“FreeRTOS 资料多、生态好”。但总监想听的是：我的系统有几个不同优先级的中断源、哪些任务对时序要求是硬实时的、哪些任务可以容忍偶发延迟、内存资源有多大、裁剪过后内核占用多少 RAM——基于这些约束条件，FreeRTOS 的调度策略、内存管理方式更适合，或者反过来，RT-Thread 的设备驱动框架能帮我省多少开发周期。没有约束条件的选型，都是拍脑袋。

第二，出了问题只会“猜”，不会“推”。现场的设备偶发故障，这是最考验人的场景。候选人如果只会说“可能是电源问题、可能是干扰问题”，这在总监眼里等于没说。正确的推演路径应该是：先看故障现象是逻辑错误还是硬件异常，再根据现象倒推可疑模块，再针对每个可疑点设计可复现的验证方案——比如用日志插桩、用示波器抓波形、用二分法屏蔽无关模块，逐步缩小范围。这背后其实是结构化思维和排查方法的双重验证。

第三，完全没有“成本意识”。很多人聊技术方案，开口就是“加个 FPGA”、“换个高端 A8 核心板”、“上一套完整的 HMI”。总监心里在冒汗：你知不知道一块 FPGA 多少钱、换核心板要重新过一遍 EMC 认证、加 HMI 要重新开模？30K 的工程师，必须有成本概念。你的每一行代码、每一个元件选型，最终都会反映到产品的毛利上。

2.3 从“会做”到“会设计”差了哪些能力

我自己带团队这几年，体会很深。一个能做东西的人，和一个能设计东西的人，最大的区别在于：前者遇到问题想的是“怎么解决掉”，后者想的是“这个问题为什么会存在，怎么从根源上消灭它”。

举一个实在的例子。之前我们做过一个物联网网关，用 STM32F429 + Linux 双处理器架构。F429 负责数据采集和实时控制，Linux 核心板负责协议栈和远程管理。最初软件团队的习惯是：F429 的代码里，各种功能模块直接在 main 函数里平铺，采集、处理、上报全在一层。结果每次改动一个模块，就要重新编译刷机，测试周期很长。后来我要求 F429 侧把所有外设驱动抽象成独立组件，每个组件有标准接口，应用层只调接口不碰寄存器。改动底层驱动，应用层一行代码不用动；新增一个传感器模块，只需要写一个符合接口规范的驱动，其余代码全部复用。

这个设计本身不复杂，但很多人没想到，或者想到了嫌麻烦没做。而“想到了且做到了”和“想到了但没做到”，在工作三五年之后就拉开了差距。总监面就是来找这个差距的。

3. 硬核拆解：三个典型的“看似全对实则不及格”的面试回答

3.1 STM32 类问题：按键扫描 32 路、非阻塞、不拖累 1ms 控制周期

第一个典型场景就是文章开头那个按键扫描问题。我先把一个能及的格回答完整写出来，你们感受一下差距。

先说布局：STM32F407 主频 168MHz，一个空循环周期大概几十纳秒级别。32 路按键如果用独立的 GPIO 中断去做，一个按键一个中断通道，资源占用大，而且多个按键同时按下时中断嵌套很麻烦。常规做法是分组扫描：把 32 路分成 4 组 × 8 路，每组共用一个行引脚，列引脚接上拉输入。扫描时依次拉低一行，读 8 个列引脚的状态，整个 32 路扫一轮只需要拉低 4 次 GPIO，加上读数据、处理消抖，总耗时不超过几十微秒。

重点来了：怎么把扫描逻辑嵌入到系统里，才能不拖累 1ms 控制周期？这里有两层设计考量。

第一层，时间片规划。1ms 的 SysTick 中断是控制任务的节拍，如果按键扫描也在中断里做，中断服务程序会变长，影响控制任务的确定性。所以按键扫描不应该放在 1ms 定时中断里，而是放在主循环里，用状态机的方式实现非阻塞扫描：每次进入扫描函数，只采集一次当前行的状态，更新一个 32 位的按键状态变量，然后立即返回。控制任务该干嘛干嘛，下一次主循环再扫下一行。

第二层，消抖。常见的 20ms 延时消抖是阻塞式的，32 路按键如果用延时消抖，按一下卡 20ms，根本没法用。正确做法是非阻塞消抖：每次扫描拿到的原始电平值，先放进一个环形缓冲或移位寄存器，连续 3-5 次扫描结果一致才认为按键状态稳定。比如每 2ms 扫一次组，5 次一致意味着经过 10ms 的持续稳定期，消抖完成。这整个过程全是等宽的时间片处理，不会阻塞任何任务。

如果再往上走一步，还可以加一个更高级的处理：把按键事件和按键状态分开。底层扫描只维护“当前按键状态”，上层逻辑通过对状态变化沿的检测（比如从 0 变 1 的边沿）来生成“按下事件”。这样上层协议栈、UI 模块只需关心事件，不用关心 GPIO 细节。这一层抽象，就是区分普通嵌入式工程师和高级嵌入式工程师的关键要素。

3.2 Linux 类问题：双机架构下的网关死机排查思路

第二个典型场景，回到那个双处理器网关。总监问设备偶发死机怎么排查，如果只会说“可能是硬件复位”“可能是电源不稳”，这个回答在工程上是零分。我拆解一套完整的排查思路，你们可以直接套用到自己的项目里。

先把“死机”做一个定性分类。是 Linux 侧死机，还是 STM32 侧死机？这就分成了两个完全不同的排查方向。如果是 Linux 侧死机，优先查 dmesg、查内核日志、查 /var/log/messages，看有没有 kernel panic、oops 信息、驱动报错、内存不足、看门狗超时重置。如果日志是空的，就要考虑是不是硬件复位导致系统来不及写日志——这时候需要用串口接一个调试终端，配合 sysrq 触发内核转储，看系统死前最后在干什么。

如果是 STM32 侧死机，那先确认是不是程序跑飞，也就是进入了 HardFault。在 Cortex-M 内核上，HardFault 是可以用代码捕获的：在启动文件里注册一个 HardFault_Handler，把堆栈指针指向的寄存器组（R0-R3、R12、LR、PC、xPSR）和故障状态寄存器（CFSR、HFSR、MMFAR、BFAR）全部保存下来，通过串口打印或存储到 Flash。有了 PC 指针，就能精确定位是死在哪个函数、哪个地址。

但这里还有一个更隐蔽的点：死机有可能是双机之间的通信异常引发的。比如 Linux 侧通过串口或 SPI 与 STM32 通信，如果 Linux 侧某个驱动有 bug，一直向 STM32 发送异常数据，STM32 的协议栈解析异常数据时陷入死循环或内存越界，结果表现为 STM32 死机，但根源在 Linux 侧。排查时不能只盯着“死掉的那一侧”，要检查两侧的通信协议状态机是否完备：有没有帧超时保护、有没有非法帧丢弃机制、有没有双方心跳互检机制。

最后是系统性预防思路。排查完问题之后，总监一定还会追问：你怎么避免以后再出现，或者至少快速定位？答案不是“我这次找到了 bug 修掉了”，而是从四个维度补强：日志系统（包括内核日志、应用日志、双机通信日志）、看门狗策略（Linux 侧硬件看门狗 + STM32 侧独立看门狗 + 双机互检）、异常捕获机制（HardFault 处理器、panic 重启后的转储分析）、长期监控（温度、电压、系统负载的定期采集）。这四个维度全做齐了，才叫一个完整的排查闭环，才叫“具备解决现场故障的能力”。

3.3 架构类问题：网关项目的重新规划，体现系统级设计思维

第三个典型场景，“重新设计网关，你会怎么规划”——这个问题的本质是考察你有没有系统设计的方法论。我给出一个完整的回答框架，这个框架无论面试还是实际做项目都适用。

首先是硬件架构层。双处理器到底要不要保留？我的答案是大概率要保留，但两边的分工边界必须清楚。实时控制侧用 MCU（STM32 系列或更新的 Cortex-M7/M33），负责传感器采集、执行器控制、硬实时逻辑；非实时应用侧用 Linux 核心板（基于 IMX6ULL、全志 H3 或瑞芯微 RV1126 这类方案），负责网络协议栈、数据存储、远程管理、OTA 升级。两边用 SPI 或 USB 高速通道通信，SPI 速度能到几十 Mbps，足够传传感器数据和命令帧，而且延迟可控、协议简单。如果通信量特别大，可以换 USB 或并口，但会增加复杂度，需要权衡。

其次是软件架构层。MCU 侧的操作系统选型要按实时性需求决定：如果硬实时任务多（PWM 控制、编码器读取），就用 FreeRTOS 或 RT-Thread，关键任务优先级用最高，中断尽可能短；如果只有简单的数据采集和转发，甚至可以做裸机状态机。Linux 侧的应用层，要严格按“采集 -> 处理 -> 上报/存储 -> 管理”四条线拆分成独立进程或线程，进程间通信统一走消息队列或 socket，日志单独成一个模块。

第三是协议设计层。这里最容易翻车。网关与传感器的通信协议、网关与云平台的通信协议、MCU 与 Linux 侧的内部通信协议，三者必须统一设计，最好都能做到：帧头、帧尾、长度校验、CRC、帧超时重传、异常帧丢弃。内部协议尤其要做成跨平台可用的格式（比如简单 TLV 结构或 JSON over UART），这样 MCU 侧和 Linux 侧都能解析，调试时两边对得上。我最怕的就是看到两边定义了一套完全不同的私有协议，联调时全靠抓包猜，那个效率低到想哭。

第四是可靠性设计层。双机热备如果预算充足可以做，但绝大多数场景只要“快速恢复”就够。方案是：MCU 侧独立看门狗 + Linux 侧硬件看门狗 + 双机心跳互检。如果 Linux 侧挂掉，MCU 侧检测到心跳超时，可以触发 Linux 硬件复位，同时 MCU 继续维持现场关键控制任务不中断。如果 MCU 侧跑飞，独立看门狗自动复位，Linux 侧通过串口检测到 MCU 重启后，主动进入初始化流程，两边重新握手。整个故障恢复时间控制在 5 秒以内，对大多数工业现场是可以接受的。

第五层是工具链和可维护性层：Bootloader 支持 OTA，分区表要预留版本回滚空间；编译构建用 CMake 或 Yocto，保证可复现；日志统一输出格式（时间戳 + 模块名 + 级别），方便后期大数据分析。这一层很多项目不做，然后出了现场问题就抓瞎，因为脚本不够、日志不全，只能飞过去插 JTAG。

如果以上五层你都能在面试现场说出来，并且结合你真实的项目经历举出具体例子，这个架构问题的回答基本可以封神。总监就会从“这人值不值 30K”切换到“这个人能不能帮我带团队”的评估维度。

4. 嵌入式学习与面试的实战复盘：把“知道”变成“做到”

4.1 学习路线的误区：资料刷得多，系统没搭过

热搜词里频繁出现“嵌入式学习路线”，说明很多人还在找路。我的观点很明确：学习资料不在多，而在于你的练习是否逼近真实的工程复杂度。很多人学了 STM32、学了 Linux，问题出在哪？他们学的是“单片机编程”和“Linux 使用”，而不是“嵌入式系统设计”。

怎么理解这句话？一个典型误区是：跟着开发板教程点灯、跑 FreeRTOS demo、照抄一个字符设备驱动，就觉得自己会嵌入式了。这些练习的本质是“模块验证”，和真实工程的区别在于，真实工程有无数个模块同时运行，彼此之间互相影响，内存有限、中断频繁、时序约束强、现场环境恶劣。从来没有哪个教程会教你“当 DMA 和 CPU 同时要访问同一块内存时怎么不冲突”，但真实项目里这种事天天发生。

所以我的建议是：学完基础外设后，立刻尝试搭一个自己的“小系统”，哪怕是个很简陋的：一块 STM32F4 或 F1 开发板 + 一个 ESP8266 或 4G 模块 + 几个传感器。然后给自己定几个挑战目标：数据采集要带 DMA；网络传输要带协议解析；掉线要能自动重连；所有模块发生异常都不能死机；整个系统功耗压到最低。当年我把这些目标一一实现，比什么教程都管用。

如果你的目标是 Linux 方向，倒也不要一上来就啃内核源码。先学会最基本的交叉编译、kernel 编译烧写、设备树修改、驱动模块加载卸载，然后尝试在一个真实板子上把 SPI、I2C、UART 几个驱动全部调通，再做几个真正落地的项目——哪怕是一个简单的 Linux 网关。内核源码是等你用到了某个子系统时再深入去啃，效率更高。

4.2 面试前自检清单：30K 级工程师必须回答出来的问题

很多候选人问我：面试前怎么准备？除了刷题之外，更有效的方式是做一次自我能力扫描。我把 30K 级嵌入式工程师应该能回答出来的问题整理成清单，你可以自我对照。如果大部分答不上来，那说明你还没到 30K 的水平，先补课再面试。

第一类是 STM32 深度问题。比如：你用过 DMA 的哪几种模式，什么场景用内存到内存、什么场景用外设到内存，DMA 中断里的数据怎么保护？你的定时器 PWM 输出最高能做到多少频率、多少占空比分辨率？ADC 多通道采样时怎么保证通道切换的稳定时间（这个对应热搜词里的“stm32 adc切换通道”，面试官很可能问到，你必须知道每个通道的采样时间和序列寄存器配置）？中断嵌套级别你怎么设置，为什么 SysTick 不能放最低优先级？你的按键消抖是怎么实现的，阻塞还是非阻塞，为什么？这些问题的共同点是：不问你“知道什么”，问你“在你的项目里怎么用”。

第二类是 RTOS 深度问题。FreeRTOS 的任务栈大小怎么估算？消息队列满了怎么办？二值信号量和互斥量的区别除了优先级翻转还有哪些？时间片轮转和优先级抢占在你的项目里分别用在哪？中断服务程序里能不能调用 osDelay，为什么？

第三类是 Linux 方向问题。你编译内核时裁剪了哪些子系统，为什么？设备树里 interrupts 和 interrupts-extended 有什么区别？probe 函数的执行时机是什么？你在驱动里申请内存用的什么 API，和 kmalloc 有什么区别？工作队列和 tasklet 的适用场景分别是什么？这些如果答不上来，说明你只是“读过”Linux，没真正写过。

第四类是通用系统设计题。这是总监面重头戏：系统的最大功耗和散热方案你怎么评估？你的看门狗策略是什么，独立看门狗和窗口看门狗分别用在哪里？你的系统在 -20℃ 和 +70℃ 环境下工作有什么差异，哪些器件会受影响？你的远程升级失败了，现场设备变成砖头，怎么拯救？你的产品出了批量性问题，客诉来了，你的处理流程是什么？

注意第四类问题，没有一个有标准答案。但恰恰是这些问题决定你的薪资段位。技术知识点是入场券，系统设计和工程推断能力才是议价筹码。

4.3 一条高价值路径：如何打造一个能写进简历的嵌入式开源项目

热搜词里“嵌入式开源项目”热度很高，这是好事，但我发现很多人的开源项目就是把自己跟着教程做的某个模块代码传上去，质量低、没有系统价值。真正能帮你拿到 30K 面试机会的嵌入式开源项目，应该做到三点：有完整工程结构、有设计文档、有可运行的系统级 Demo。

比如你做一个智能环境监控网关，不要只写一个温湿度读取代码，你要把整个系统拆成：GUI 或串口命令交互层、业务逻辑层（报警规则、数据记录）、中间层（数据队列、协议解析）、驱动层（传感器、LCD、联网模组）。每一层之间有清晰接口，有统一的错误处理机制（错误码定义、日志记录、自动恢复）。这个体系本身就是一个非常有说服力的项目，即使功能不复杂，也证明你有工程化思维。

如果你能做 Linux 方向的开源项目，价值更高。一个可行的方案：基于 buildroot 或 Yocto 构建一个最小 Linux 系统，移植到一块便宜的 ARM 开发板（友善之臂 NanoPi 或 全志 V3s 这类），然后做：一个通过 SPI 通讯的外设驱动、一个使用 netlink 或 socket 的应用层程序、一个通过 /sys 或 debugfs 暴露数据的调试接口。这样一套项目，既覆盖嵌入式 Linux 的大部分核心知识点，又能体现你的系统设计能力。

写代码时注意几点：统一的代码风格；提交信息写清楚；用 CMake 或 Makefile 组织构建，能一键构建出固件；写一份 README 说明系统架构、编译方法、使用说明；把调试过程中的踩坑记录写进去（比如“ADC 通道切换后前两次采样值要丢弃，否则电压跳变”——对应热搜词“stm32 adc切换通道”）。这几点全做到，你的 GitHub 主页不输一份简历。

4.4 面谈加分项：如何给研发总监留下“这个人值 30K”的印象

面试除了答对问题，还有很多细节决定成败。我以面试官的身份说说哪些举动会让我在满意度表上打高分。

第一，主动介绍你的系统架构，而不是等我问。当我问“介绍一下你最近做的项目”时，很多人会从“我实现了 xx 功能”开始，把需求文档复述一遍。我更想听的是：项目的整体架构图是什么样的？为什么要选这个 MCU/核心板？任务怎么划分的？内存怎么规划的？遇到过最大的技术挑战是什么，怎么解决的？如果你能主动把这些讲清楚，我基本就知道你是什么水平了。

第二，承认自己不知道，但不要空洞地说不知道。说“这个我确实没深入研究过”是可以理解的，但最好接一句“不过基于我对 XX 的理解，我猜测问题可能出在……”——这展现出逻辑推理能力和学习潜力，而不是知识广度。

第三，敢于表达你的技术取舍和理由。当总监提出一个方案（比如“换一颗更便宜的芯片”），如果你能接住并分析出利弊——比如“这个型号没有硬件 CAN，如果换的话软件模拟 CAN 实时性不够，我建议在预算允许范围内保留当前方案或加一颗 GPIO 扩展”——这在总监眼里就是“能和产品经理对话的工程师”，而不是只会闷头写代码的执行者。

5. 常见问题速查：面试即兴发挥之外的避坑清单

我把这些年听到的、踩过的、复盘的问题整理成一张速查表，按“面试中常见但容易答偏”的场景分类，看完你至少能避开 80% 的坑。

这表里每一行都来自真实面试场景。我特别想多提一嘴“2100 字节的帧”这个问题，很多人卡在“长度固定就可以收满中断”上——但实际现场通讯里，帧长度经常会因为协议扩展而变化，如果不处理不定长，DMA 就会在错误位置断开，导致帧解析失败。正确答案是利用 STM32 的 UART 空闲中断（IDLE），每收到一帧数据后触发空闲中断，此时 DMA 当前计数就是实际收到的字节数，配合一个环形缓冲，既能处理定长帧也能处理不定长帧。把 DMA、空闲中断、环形缓冲、帧解析四个东西串联起来，才叫真的会串口。

再提示一个容易被问懵的细节：STM32 的启动文件里，ld链接脚本（.ld 文件，对应热搜词“stm32 ld文件”）怎么理解？很多人说“没用过”。但面试官可能问：链接脚本里定义了哪些段，_estack、_Min_Heap_Size、_Min_Stack_Size分别是什么作用？为什么中断向量表要放在最前面？如果你能随口说出“堆和栈的增长方向、栈溢出后可能会破坏哪些数据、怎么用 MPU 保护”这些理解，这个回答就会有加分效果。这类“看似冷门实则常用”的细节，经常是区分候选人的关键点。

6. 面试后的延伸思考：技术没过关？不，是工程心智需升级

6.1 一个被我反复验证的结论：高薪面试考验的不是技术权威知识

写到最后有点感慨。我见过很多面试失败后回来问我“到底哪里不够好”的候选人，他们普遍以为是自己某个知识点没答好，比如某个寄存器配置错了、某个 Linux 内核 API 记混了。但复盘下来，真正拉开差距的从来不是这些“记忆性知识”，而是三个层面：

第一层是“系统观”。你能不能把一个设备理解为一个由硬件、驱动、RTOS、应用、协议、云端共同构成的整体系统，并且清楚每一层和每一层的边界、交互、故障传播路径。

第二层是“取舍观”。在资源受限、成本受限、时间受限的真实条件下，你能不能做出理性的技术选型，而不是一味堆料。

第三层是“闭环观”。出了问题能不能用一套方法论（观察 -> 假设 -> 验证 -> 复盘 -> 预防）把它彻底解决，而不是救火式地猜、试、改。

这三观是刷题刷不出来的，只能在真实项目里反复迭代打磨。换句话说，30K 不是一个“知识门槛”，而是一个“工程思维门槛”。

6.2 我自己的一个体检方法，分享给你

后台很多人问：我怎么知道自己到底值多少钱？我提供一个简单有效的自检方法，你可以每半年做一次。

拿出你最近做的项目，关掉 IDE，用一张白纸，回答这几个问题：

1. 你这个系统如果内存从 64KB 减到 32KB，哪些功能要砍，顺序是什么？
2. 一个核心外设在运行时突然异常（比如 SPI 总线拉低不释放），你的代码会在多久之内发现并恢复？
3. 你的设备在野外连续运行一年不重启，你怎么证明它不会内存泄漏？
4. 客户要求增加 50 个新数据点，你的软件架构需要改几天？
5. 你手下的新人犯了个低级错误导致返工，你怎么设计一个机制防止同类错误再次发生？

如果这些问题你能给出清晰、有细节、有据可循的回答，那么恭喜你，你差不多已经具备不值 30K 的能力了。如果你答得支支吾吾，那就说明你的下一个项目里，应该设计一个模块专门解决这个问题。

面试是验证，日常项目才是修炼。嵌入式这一行的魅力恰恰在这里：永远有学不完的新东西，但也永远有做不完的坑等着你去填。希望这篇“嵌入式跃迁”系列能帮你少走几条弯路。