嵌入式面试到底要不要刷算法题

嵌入式到底要不要刷算法题，我面了 20 多家之后的结论是：大厂要刷，而且不能完全不刷。

小公司不用在算法题上投入太多时间，性价比很低。

一开始我对这个问题也很纠结。

因为嵌入式岗位的核心明明是硬件基础、单片机、RTOS、通信协议、项目经验，为什么面试里还会出现链表、二叉树、动态规划？

后来面得多了，我慢慢发现：

算法题在嵌入式面试里，不是为了考你会不会“做 LeetCode”，而是面试官用来快速判断你的基础能力和筛选效率。

真正的问题从来不是“嵌入式岗该不该刷算法”，而是：

你投的公司层级不同，算法题的重要性完全不一样。

一、算法题在嵌入式面试里的真实定位

面试官用算法题，通常在判断三件事：

你是否具备基本的数据结构与代码能力

你写代码时是否有逻辑性和边界意识

你能不能在压力下快速组织思路并表达清楚

很多人会觉得：

“嵌入式又不是纯软件，为什么还考算法？”

但站在公司的角度，这件事其实很好理解。

因为算法题是一个非常标准化的筛选工具。

它有几个特点：

出题成本低

区分度高

短时间内就能看出候选人的编码基本功

不依赖项目背景，便于横向比较

所以对大厂来说，算法题不是因为“嵌入式岗位真的天天写算法”，而是因为它适合做筛选。

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

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

二、我的结论很直接：大厂要刷，小公司没必要重投入

这件事我后来想得很清楚：

如果你目标是大厂嵌入式岗，算法题必须准备。

不一定要求你刷到竞赛水平，但至少不能在常见题型上完全不会。

因为很多大厂的流程决定了：

笔试会考算法

一面可能手撕代码

有些部门即使是做驱动、BSP、系统软件，也会拿算法题做基础筛选

你如果算法完全不准备，很可能不是“技术不行”，而是连后面的项目面都进不去。

但如果你投的是中小厂、制造业、传统硬件公司、区域性企业，情况往往完全不同。

这类公司更关心的是：

你能不能看懂原理图

你会不会调串口、SPI、I2C、CAN

你能不能写驱动、排查时序问题

你有没有 RTOS 和项目落地经验

在这些岗位里，算法题通常不是重点，甚至根本不考。

你花大量时间去刷难题，收益可能远低于你去补通信协议、实时系统、项目表达。

所以我的建议不是“刷”或者“不刷”，而是：

看目标公司决定投入比例。

三、大厂为什么会在嵌入式岗里考算法

这个问题如果想通了，准备策略就会清晰很多。

大厂考算法，核心原因有三个。

1. 算法题是最高效的统一筛选手段

大厂招聘量大，候选人背景差异也大。

有人做过比赛，有人只做过课程设计，有人项目很强但表达一般。

这时候算法题最大的价值就是：

它能快速建立一条相对统一的评价标准。

不管你项目写在简历上多漂亮，面试官还是希望确认一件事：

你能不能独立写出一段正确、清晰、可运行的代码。

2. 嵌入式开发本身也需要一定的数据结构和逻辑能力

虽然嵌入式不是算法岗，但很多场景仍然需要基本算法思维，比如：

环形缓冲区

链表管理

状态机设计

查找、排序、去重

协议解析

内存管理

任务调度与事件组织

所以面试官考算法，不完全是“跨界乱考”，而是在看你有没有最基础的代码组织能力。

3. 算法题还能顺带看出你的思维质量

真正拉开差距的，很多时候不是你会不会这道题，而是你能不能：

先说朴素解法

再分析复杂度

再优化思路

最后把边界条件补完整

这套过程，本质上和你分析系统问题、定位 bug、设计模块结构是共通的。

四、小公司为什么通常没那么在意算法题

小公司招人更看重“来了能不能干活”。

他们更现实，也更直接。

相比于你会不会做二叉树最近公共祖先，他们更关心：

你能不能把板子带起来

你会不会看 datasheet

你能不能独立调通外设

你有没有量产或接近量产的经验

出了问题你会不会查

换句话说，小公司更看工程落地能力，而不是标准化筛选能力。

所以如果你的求职目标本来就是中小厂，那准备重点应该放在这些地方：

STM32 / MCU 基础

中断、定时器、DMA

UART / SPI / I2C / CAN

FreeRTOS

驱动开发

项目介绍与问题排查

而不是每天花大量时间死磕高难度算法题。

五、嵌入式岗刷算法，刷到什么程度才够

这是最关键的，不然很容易走偏。

我的理解是：

嵌入式岗刷算法，不追求难度，追求“常见题型不陌生，手写代码不慌”。

重点应该放在这些内容：

数组、字符串

链表

栈、队列

哈希

二分

双指针

递归与回溯基础

二叉树遍历

简单动态规划

你至少要做到：

能独立写出常见题

能把时间复杂度和空间复杂度说清楚

能处理边界条件

能现场把代码写得不太乱

如果目标只是嵌入式而不是算法岗，没必要把大量时间砸在特别偏、特别难的题上。

因为很多时候，高投入并不会带来对应收益。

六、我后来对“刷算法”这件事的理解变了

后期我不再纠结“嵌入式到底该不该刷算法”，而是把它理解成：

算法题是求职策略问题，不是技术信仰问题。

如果目标是大厂，那算法题就是门槛之一，你绕不过去。

如果目标是小公司，那算法题只要保证不拖后腿就够了，更重要的是项目和基础。

也就是说，你的准备顺序应该是：

先看岗位层级

再看面试流程

最后决定算法投入比例

而不是一上来就陷入“我要不要刷 300 题”的焦虑里。

七、如果只剩最后一段时间，该怎么分配

如果时间已经不多，我会这样建议：

目标大厂：项目、八股、算法都要准备

算法至少要覆盖高频基础题型

保证笔试和手撕代码不过早挂掉

目标中小厂：算法简单过一遍即可

重点放在 MCU 基础、RTOS、驱动、协议、项目细节

把“能干活”的能力讲透，比刷很多题更重要

本质上就是一句话：

大厂看筛选，小公司看落地。

八、一个很现实的结论

在我面过的 20 多家里，算法题对嵌入式岗的重要性并不统一。

但如果一定要总结成一句话，那就是：

嵌入式不是必须大量刷算法题，但如果你想进大厂，算法题大概率是绕不过去的门槛。

真正高效的准备方式不是盲目刷题，而是明确自己的目标：

冲大厂，就把算法补到能过筛选

投小厂，就别在算法上投入过多，优先补工程能力

因为嵌入式面试真正决定你上限的，很多时候还是这些东西：

硬件基础

RTOS

驱动与通信协议

项目深度

问题排查能力

算法题能决定你能不能进场，

但工程能力才决定你能不能真正拿到 offer。

如果你愿意，我还可以继续帮你把这篇整理成更像你原文那种“可直接发”的版本，语气会再锐一点，排版也会更像面经文章。