一个扎心的现象
我带过一个工程师，技术能力很强。项目里的 HardFault 是他定位的，通信协议是他重构的，低功耗是他优化的。团队里公认的\”技术担当\”。
但他跳槽面试，连续挂了五家。
原因不是技术不过关。技术面里，面试官问的问题他都能答，甚至答得比面试官期望的还深。问题出在表达上。
面试官问：\”你在项目里遇到的最大挑战是什么？\”
他答：\”有一次 HardFault，我排查了两周，最后发现是栈溢出。\”
面试官问：\”栈溢出是怎么发现的？\”
他答：\”用 uxTaskGetStackHighWaterMark 查出来的。\”
面试官问：\”然后呢？\”
他答：\”然后就把栈改大了一点。\”
这段对话，面试官听到的是：
-
遇到问题 → 查了一下 → 改了一下 → 好了。
-
没有方法论，没有系统性，没有工程思维。
而他实际做的是：
-
崩溃现象是\”偶尔重启，无法复现\”。
-
先实现了 HardFault 现场保存，收集了两周的崩溃记录。
-
从 PC 值、LR 值、栈指针入手，排除了外设故障、中断优先级、内存踩踏。
-
最终定位到日志任务的栈溢出，根因是 sprintf 在处理浮点数时消耗超预期。
-
解决方案不是简单地\”改大栈\”，而是把格式化从任务上下文移到独立日志任务，给日志任务足够栈空间，同时给所有任务加了高水位监控。
他做了 100 分的工作，讲出了 30 分的效果。
这就是这个专栏要解决的问题。
一、这个专栏写给谁
如果你技术不错，但面试总是差一口
