前端真的需要懂算法吗？聊聊感受
最让我头疼的是什么？
就是“算法题”这个环节。
我经常遇到两种候选人。
一种是一听算法题，就两手一摊，表情痛苦，说：“哥，我天天写业务，真没准备这个。”
另一种正好相反。题目一出，眼睛一亮，不出三十秒，就把 LeetCode 上背得滚瓜烂熟的最优解，一字不差地敲了出来，然后一脸期待地看着我。
说实话，这两种，都不是我最想看到的。
这就引出了一个很多候选人都想问，但不敢问的问题：
你们这些面试官，到底怎么想的？你们明知道我们前端平时工作中，99% 的时间都用不上这些，为什么非要折磨我们？
今天，我就想站在桌子对面，跟大伙掏心窝子地聊聊：我们问算法题，到底图个啥。
先承认一件事：我们知道你工作中不怎么写算法
对，你没看错。
我心里门儿清。团队里的小伙伴们，每天的工作是跟产品经理“吵架”，是跟 UI 设计师对像素，是封装 React/Vue 组件，是处理浏览器兼容性，是调 CSS。
我招你进来，也不是为了让你用动态规划来给按钮加 border-radius 的。
我们不会天真地以为，前端开发就是算法竞赛。如果你能把一个复杂的业务表单组件写得清晰、可维护、可扩展，在我眼里，这远比你徒手写一个红黑树要来得有价值。
所以，请你先放轻松。
我们不是在考察你是不是一个“算法大神”。
那我们到底在看什么？
既然不是看你会不会背最优解，那我们花这宝贵的 20 分钟，到底在考察什么？
其实，算法题只是一个“载体”，一个“媒介”。通过这个载体，我想看到的是下面几样东西。
1. 你是怎么解读问题的
一个靠谱的工程师，拿到需求不会立刻动手。他会先问问题，搞清楚所有的边界和约束。
比如我出一道题：
写个函数，找出数组中第二大的数。
普通候选人可能埋头就开始写代码。
但我欣赏的候选人，会先问：
- 这个数组里会有重复的数字吗？
- 数组一定是无序的吗？
- 数字里会有负数吗？
- 如果数组长度小于 2，应该返回什么？
- “第二大”指第二个不同的值，还是排序后的第二个位置？
你看，这就是差距。
我能通过这些问题，看出你是否严谨，是否有处理边界情况的意识。这个能力，在你将来面对产品经理那些模糊的需求时，至关重要。
2. 你的思路是否清晰
我最喜欢看到的，不是你直接写出最优解，而是你告诉我你的思考过程。
比如，你可以这样说：
我首先想到的，是一个最直接的办法：先排序，然后取倒数第二个。这个时间复杂度是 O(n log n)。但感觉可以优化，我再想想……也许只需要遍历一遍，用两个变量来维护最大值和第二大值，这样时间复杂度就能降到 O(n)。
这个“先暴力，再优化”的过程，在我看来，比你直接默写出最优解要加分得多。
因为它展示了你的逻辑推理能力和优化意识。
3. 你的代码品味如何
算法题的代码量不大，但足以管中窥豹，看出一个人的代码品味。
你的变量是怎么命名的？
是 a、b、c，还是 max、secondMax、current？
你有没有处理刚才提到的边界情况？
你的代码有没有基本的缩进、格式和可读性？
一个能让我放心的答案，大概会长这样：
function findSecondLargest(numbers: number[]): number | null {
if (numbers.length < 2) {
return null;
}
let max = -Infinity;
let secondMax = -Infinity;
for (const current of numbers) {
if (current > max) {
secondMax = max;
max = current;
} else if (current < max && current > secondMax) {
secondMax = current;
}
}
return secondMax === -Infinity ? null : secondMax;
}这段代码不复杂，但它至少说明几件事：
- 命名是清楚的。
- 边界情况被考虑到了。
- 重复值的定义是明确的。
- 返回值表达了“找不到第二大值”的状态。
这些细节，都会反映你平时的编码习惯。
一个连算法题都写得乱七八糟的人，我很难相信他在业务项目里能写出整洁的代码。
4. 当你卡住时，你会怎么办
我有时候会故意出一些有点难度的题。
我不是为了让你难堪，而是想看看你卡住的时候，会有什么反应。
是直接放弃，说“不会”？
还是会尝试跟我沟通，说：“我卡在 xxx 了，能不能给点提示？”
我非常乐意给提示。
我更想招一个能和我一起协作解决问题的人，而不是一个遇到困难就躺平的人。你面对一道题的态度，很可能就是你未来面对一个技术难题的态度。
给求职者的一些真心话
所以，聊了这么多，我真正想说的是：
- 别光背题，没用。 我只要稍微改动一下题目条件，或者问你为什么这么写，背题的同学马上就露馅了。
- 多练习“说”。 刷题的时候，试着把你的思路说出来，录下来自己听听，或者讲给朋友听。面试时的口头表达，和自己闷头做题是两回事。
- 重点理解“为什么”。 不要满足于“这道题这么解”，要去理解它为什么要用双指针，为什么要用哈希表。理解了思路，才能举一反三。
- 面试时，心态放平。 没做出最优解，真没关系。把你思考的过程、你的尝试、你的权衡都清晰地表达出来，你已经赢了很多人。
我知道，让前端去卷算法，这个“游戏规则”本身就不那么公平。
我们想找的，是一个会思考、会沟通、有工程素养的“解决问题的人”。
算法题，只是恰好成了当前最方便、成本最低的考察工具而已。
希望这些“面试官的牢骚”，能让你稍微不那么焦虑一点。
你们怎么看？