面试悖论：当算法崇拜遭遇工程现实，程序员面试正在制造“优秀的废人”
我们正在用一套精心设计的、高度标准化的面试流程，来筛选一种只在面试中存在的“完美候选人”。LeetCode 上的 500 道题、系统设计里画满的盒子与箭头、行为面试中背得滚瓜烂熟的 STAR 法则——这一切共同构成了一座奇特的“面试剧场”。而真实世界里的软件工程，却是在遗留代码上做外科手术、在模糊需求中确定优先级、在凌晨两点的故障告警里保持冷静。这两者之间的裂痕，远比我们承认的要深。几乎所有面试官都在心里默认：“算法好的人，工程一定不差”，但这个假设从未被认真检验过。相反，大量数据与经验表明，算法能力与工程产出之间的相关性，低得令人不安。
这种“算法崇拜”并非没有根源。它源于行业对“可量化标准”的极度渴望。公司期望复制 Google 当年的成功，而这套基于算法题和脑筋急转弯的面试体系，在互联网早期确实淘汰过不少平庸的候选人。但如今，它已经异化为一场军备竞赛。候选人在培训机构与开源题库的辅助下，用三个月甚至更短的时间“刷出”了漂亮的简历和熟练的解题套路。面试官问一道 Hard 题，候选人能在十分钟内给出最优解，却说不清自己项目里一个核心模块的部署方式。这种畸形导致了一个系统性悖论：我们筛选出了最会“做题”的人，却错过了那些真正能推动产品、搭建稳定系统、带领团队走出技术泥潭的人。更糟糕的是，算法崇拜还会反向塑造整个行业——年轻一代程序员疯狂追逐“最优解”和“复杂度”，却对代码的可读性、可维护性、以及业务的价值逻辑漠不关心。
让我们做一次冷静的对比。在真实工程场景中，你很少需要手写红黑树或动态规划，但你需要频繁地阅读、修改和重构别人写的烂代码。你需要理解业务需求背后的意图，并把它转化为技术方案。你需要与非技术人员沟通，说服他们接受你的技术取舍。你需要处理并发问题、分布式一致性、系统监控、灰度发布、故障回滚……这些能力，没有一个是靠刷题能获得的。相反，一道好的算法题通常有明确的标准答案，但在真实世界中，几乎每一个决定都没有“标准答案”，往往需要在多个糟糕的选项中选择相对不那么糟糕的那个。这就是为什么许多在面试中狂飙突进的人，到了实际工作中却像躺在手术台上的病人一样无助。而一些在面试中表现得笨拙、甚至答不出“最大子数组和”最优解的工程师，反而能在生产中构建出优雅而健壮的系统。
所以，我们是否应该彻底抛弃算法面试？不，那不是我的结论。算法素养依然是优秀工程师的基础之一，它代表了抽象思维和逻辑能力，但它不是全部，甚至不是最重要的部分。我真正要批判的是那种“唯算法论”的单维筛选机制。真正的选拔，需要引入多维度、基于真实情境的评估。例如，可以设计一个小型但完整的代码审查任务，让候选人修复一个有缺陷的真实项目，并解释其决策；或者给出一个模糊的产品需求，让候选人通过沟通来澄清并设计出实现方案；更有价值的，是让候选人携带自己的代码并展开深度辩论，考察其设计思路与迭代逻辑。这些方式能够同时考验技术深度、工程判断、协作能力和沟通能力，而不仅仅是算法记忆。我们需要创造出一种“低伪装高信号”的面试环境，让候选人可以展示真实的自己，而不是在猜面试官想要的答案。
这场面试的异化，并非只伤害候选人，也伤害公司。将大量时间投入到算法题库上的后果，是组织逐渐失去对“人”的敏感度。面试官基于几十分钟的代码表演，做出了多年雇佣决定，这简直是一场高风险的投资，却用骰子来决定回报。要摆脱这种困境，除了调整面试设计，还需要整个行业的文化转向——承认“做手艺”和“做题”不同。我们需要一个新的评估范式，它不排斥算法的严谨性，但更看重工程交付的能力、面对不确定性的韧性、以及与人协作的智慧。如果你正在准备面试，请不要只是埋头刷题，去构建一个真实产品、去开源、去解答那些没有标准答案的问题；如果你正在面试别人，请停下因为候选人“题没答好”就淘汰的现实，转而考验他们面对混乱世界的生存能力。只有当我们真正拥抱工程现实的复杂性，我们的选拔机制才能配得上我们正在建设的复杂系统。
