前言
最近在掘金上看到一篇关于前端面试的文章《前端真的需要懂算法吗？聊聊感受》作者的经历让我感同身受。文章中提到的那些脱离实际的“八股文”、为了炫技而设计的算法题目，以及糟糕的候选人体验，几乎是当前技术面试环境的一个缩影。
曾经的偏执
刚开始带团队的时候，我对“面试”这件事理解得很偏。
那时候的我，总想着在候选人面前表现得专业一点、厉害一点。潜意识里，会把面试当成一种“展示”，甚至有点像上课——通过问一些对方答不上来的问题，来证明自己懂得多、站得高，从而建立所谓的“技术权威”。
现在回头看，这种心态挺糟糕的。
它的直接后果就是：
我可能筛掉了不少技术基础不错、但表达不那么强势的人；
更糟的是，还可能给候选人留下“这家公司面试体验不太行”的印象。
当面试和真实工作开始严重脱节
现在的面试环境，其实有点“拧巴”。
候选人在拼命背闭包、原型链、事件循环的各种问法，甚至还有场景题的固定回答；
面试官在纠结这些点到底要怎么问，才能显得自己问得“专业”。
但现实是
关掉面试页面，打开项目代码，大家一边看需求，一边开着 Cursor、Copilot，靠 AI 把重复劳动全都扫掉。
一、当写代码变简单，我更在意你的“选择”
说句大实话，现在“把代码写出来”这件事，已经没那么值钱了。
以前招一个前端，可能会看他能不能说出Vue，React原理，或者现场手撕一个深拷贝。
但现在，只要逻辑讲得通，AI 生成的代码，规范性和可读性往往比大多数人都好。
所以这两年，我在面试里，已经刻意把“纯手写代码”的比重降得很低。
相比之下，我更喜欢抛一个接近真实项目的烂摊子，比如：
“我们要重构一个老模块，后端接口的数据结构很乱，还要兼容好几年前的版本。你会从哪里开始动手？”
这个问题没有标准答案，我也不期待你马上给出一个“完美方案”。
我真正想听的，是你的取舍逻辑。
- 数据清洗是放在前端，还是推动后端一起改？
- 是为了赶进度先兜底，还是先抽离核心模块？
- 哪些地方可以先忍，哪些地方必须现在就改？
这些在业务和技术之间做判断的能力，才是 AI 暂时替代不了的部分。
如果一个人只会把代码写对，却说不清“为什么这么做”，那在现在这个阶段，竞争力其实已经被削弱了不少。
二、团队不是选最强，而是选“刚好缺的那块”
带团队一段时间之后，我越来越清楚一件事：
招人不是为了找最牛的人，而是为了让团队更完整。
我以前也走过弯路，总觉得每个人都应该是那种想法很多、喜欢研究新技术的“技术极客”。
但后来发现，如果一个团队里全是这种人，项目反而容易失控——大家都在讨论架构和未来，却没人愿意去把当下的活踏踏实实做完。
现在我会更清楚地看：这个人，能给团队补什么。
一般来说，大概会有两种类型：
一种是“爱提想法、善于沟通”的人
他们对流程、工具、代码质量都很敏感，总能发现哪里效率低、哪里设计得别扭。这类人很适合推动改进，帮团队不断往前走。
另一种是“执行力强、特别稳”的人
我不太喜欢用“听话”这个词，那不专业。
更准确地说，这类人是团队的底气。任务交给他，你会很安心——逻辑清楚、细节到位，代码交付出来基本不用反复返工。
作为组长，我要做的不是评判哪种人更厉害，而是判断：
我们现在，缺的是哪一种。
如果你能在面试中，让我清楚地感受到你更偏向哪一类，这比背十套八股文答案都要有用。
三、所谓团队氛围，其实就是“好不好一起干活”
这些年，我见过不少技术很强的人，简历亮眼、项目经历漂亮。
但真正共事之后，却会发现：大家都在下意识地躲着他。
Code Review 时，他会把建议当成挑刺；
跟产品讨论需求，第一反应永远是“这个做不了”。
慢慢地我意识到一句话：
技术决定一个人的下限，但沟通和性格，决定了他的上限。
所以现在面试，我会刻意观察一些很细微的点：
- 当我指出他方案里的问题时，他是先反驳，还是先听？
- 面对不确定的问题，是愿意讨论，还是急着给结论？
前端不是一个人闷头敲代码的职业。
我们要和设计磨细节，和后端对接口，和产品反复拉扯需求。
一个合作起来不费劲的人，能省掉我大量的沟通成本。
最后一点心里话
现在的面试环境，确实很卷，也确实有点冷。
有时候你会觉得自己面试表现得不错，但最后还是没被选中。
很多情况下，这并不是能力问题，而是当下这个团队需要的角色，和你的风格并不完全匹配。
End
- 欢迎大家在评论区表达自己的想法讨论
- 本文有用ai润色过
