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

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

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

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

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

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

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

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

对，你没看错。

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

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

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

【顺手推几个技术大厂的机会，前、后端or测试，感兴趣就试试 ，待遇还不错】

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

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

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

1. 你是怎么“解读”问题的（沟通与理解能力）

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

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

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

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

2. 你的“思路”是否清晰（逻辑思维）

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

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

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

3. 你的代码“品味”（工程素养）

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

• 你的变量是怎么命名的？a, b, c 还是 max, secondMax, current？
• 你有没有处理我刚才提到的那些边界情况？
• 你的代码有没有基本的缩进和格式？

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

4. 当你卡住时，你会怎么办？（抗压与学习能力）

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

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

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

给求职者的一些真心话

所以，聊了这么多：

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

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

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

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

——转载自：ErpanOmer