前端真的需要懂算法吗？聊聊感受

在公司干了几年，带个小团队，零零总总也面试了上百个前端候选人了。说实话，有时候面完一天，感觉人都是麻的。

最让我头疼的是什么？就是算法题这个环节。

我经常遇到两种候选人。一种是一听算法题，就两手一摊，表情痛苦，说 哥，我天天写业务，真没准备这个。另一种呢，正好相反，题目一出，眼睛一亮，不出三十秒，就把 LeetCode 上背得滚瓜烂熟的最优解，一字不差地敲了出来，然后一脸期待地看着我。

说实话，这两种，都不是我最想看到的。

这就引出了一个很多候选人都想问，但不敢问的问题：你们这些面试官，到底怎么想的？你们明知道我们前端平时工作中，99% 的时间都用不上这些，为什么非要折磨我们？

今天，我就想站在桌子对面，跟大伙掏心窝子地聊聊，我们问算法题，到底图个啥。

---

首先，我得承认一件事：我们知道你工作中不怎么写算法

对，你没看错。

我心里门儿清，我团队里的小伙伴们，每天的工作是跟产品经理吵架，是跟 UI 设计师对像素，是封装 React/Vue 组件，是处理浏览器兼容性，是调 CSS。我招你进来，也不是为了让你用动态规划来给按钮加border-radius的。

我们不会天真地以为，前端开发就是算法竞赛。如果你能把一个复杂的业务表单组件写得清晰、可维护、可扩展，在我眼里，这远比你徒手写一个红黑树要来得有价值。

所以，请你先放轻松。我们不是在考察你是不是一个算法大神。

---

那我们到底在看什么？——思路远比答案重要

既然不是看你会不会背最优解，那我们花这宝贵的20分钟，到底在考察什么？

其实，算法题只是一个载体，一个媒介。通过这个载体，我想看到的是这几样东西：

你是怎么解读问题的

一个靠谱的工程师，拿到需求不会立刻动手。他会先问问题，搞清楚所有的边界和约束。

我出一道题：写个函数，找出数组中第二大的数。

• 普通候选人：埋头就开始写代码。
• 我欣赏的候选人：会先问我，这个数组里会有重复的数字吗？会是无序的吗？会有负数吗？如果数组长度小于2怎么办？

你看，这就是差距。我能通过这些问题，看出你是否严谨，是否有处理边界情况的意识。这个能力，在你将来面对产品经理那些模糊的需求时，至关重要。

你的思路是否清晰

我最喜欢看到的，不是你直接写出最优解，而是你告诉我你的思考过程。

比如，你可以说：我首先想到的，是一个最笨的办法，先排序，然后取倒数第二个。这个时间复杂度是 O(n log n)。但感觉可以优化，我再想想……也许我只需要遍历一遍，用两个变量来维护最大值和第二大值，这样时间复杂度就降到 O(n)了。

这个先暴力，再优化的思考过程，在我看来，比你直接默写出最优解要加分得多。因为它展示了你的逻辑推理能力和优化意识。

你的品味 - 工程素养

算法题的代码量不大，但足以管中窥豹，看出一个人的代码品味。

你的变量是怎么命名的？a, b, c 还是 max, secondMax, current？

你有没有处理我刚才提到的那些边界情况？

你的代码有没有基本的缩进和格式？

这些细节，都反映了你平时的编码习惯。一个连算法题都写得乱七八糟的人，我很难相信他在业务项目里能写出整洁的代码。

当你卡住时，你会怎么办？

我有时候会故意出一些有点难度的题。我不是为了让你难堪，而是想看看你卡住的时候，会有什么反应。

是直接放弃，说不会？还是会尝试跟我沟通，说我卡在 xxx 了，能不能给点提示？

我非常乐意给提示。我更想招一个能和我一起协作解决问题的人，而不是一个遇到困难就躺平的人。你面对一道题的态度，很可能就是你未来面对一个技术难题的态度。

---

给求职者的一些真心话

所以，聊了这么多：

• 别光背题，没用。 我只要稍微改动一下题目条件，或者问你为什么这么写，背题的同学马上就露馅了。
• 多练习说 。刷题的时候，试着把你的思路说出来，录下来自己听听，或者讲给朋友听。面试时的口头表达，和自己闷头做题是两回事。
• 重点理解为什么 。不要满足于这道题这么解，要去理解它为什么要用双指针，为什么要用哈希表。理解了思路，才能举一反三。
• 面试时，心态放平。 没做出最优解，真没关系。把你思考的过程、你的尝试、你的权衡都清晰地表达出来，你已经赢了很多人了。

我知道，让前端去卷算法，这个游戏规则本身就不那么公平。我们想找的是一个会思考、会沟通、有工程素养的解决问题的人。

算法题，只是恰好成了当前最方便、成本最低的考察工具而已。

希望这些面试官的牢骚，能让你稍微不那么焦虑一点。

你们怎么看？