1. 程序员面试做题现象的现状观察
最近三年,技术社区关于"面试做题"的讨论热度持续攀升。Stack Overflow 2022开发者调查显示,67%的受访者表示在面试过程中遇到过与日常工作关联度低的算法题考核。国内技术论坛V2EX的相关讨论帖中,"leetcode"、"刷题"等关键词出现频率较五年前增长近300%。
我作为面试官参与过近百场技术面试,也以候选人身份经历过各类考核形式。最直观的感受是:2020年后,原本集中在头部互联网企业的做题面试模式,已经渗透到中小型公司甚至传统行业IT部门。某次给一家制造业企业面试ERP系统开发岗时,对方竟要求候选人现场手写红黑树实现——这个场景完美诠释了当前面试考核的错配现象。
2. 排斥做题的深层原因分析
2.1 考核内容与岗位需求的割裂
互联网大厂早期采用算法题面试的逻辑有其合理性:当应聘者数量远超HC时,需要一种相对公平的筛选机制。但问题在于:
- 电商后台开发岗考动态规划最优解
- 业务系统CRUD岗考线段树区间查询
- 前端工程师考图论最短路径
这种错配直接导致:能解hard级算法题的新人入职后,可能连基本的API设计规范都需重新培训。去年我带过一位ACM银牌选手,他能在30分钟内写出并查集优化方案,却对如何设计一个可扩展的RESTful接口毫无概念。
2.2 刷题产业的异化效应
当某招聘平台数据显示"通过刷题入职的工程师平均在职时间不足18个月"时,这个信号值得深思。刷题产业链包含:
- 付费题库平台(会员费2000+/年)
- 面试题库贩子(最新原题500+/套)
- 代刷服务(包过套餐万元起)
这导致考核失真:知道"股票买卖最佳时机"五种解法的候选人,可能从未真正理解过时间复杂度优化的工程意义。就像考驾照时背熟了所有交规题目,但实际开车仍会压实线。
2.3 时间成本的边际效益递减
以常见的面试准备时间分配为例:
| 准备项目 | 时间占比 | 实际工作应用频率 |
|---|---|---|
| 算法题刷题 | 60% | <5% |
| 系统设计 | 25% | 30% |
| 项目经验梳理 | 10% | 50% |
| 技术栈深度掌握 | 5% | 15% |
当资深工程师需要花费数百小时重温大学算法知识时,这些时间本可用于:
- 研究云原生技术栈
- 优化现有系统架构
- 参与开源项目贡献 这种机会成本的损失对行业整体都是种浪费。
3. 更优面试模式的实践探索
3.1 模拟真实工作场景的考核
某跨境电商团队最近调整的面试流程值得参考:
- 提前48小时发放简化版业务需求文档
- 候选人提交设计方案(不要求完整实现)
- 现场讨论设计决策的权衡取舍
这种方式下,面试官能观察到:
- 技术选型的思考过程
- 对非功能性需求的理解
- 技术债务的防范意识
3.2 开源协作式评估
德国某自动化测试工具厂商采用的方法:
- 提供一个小型真实issue(如GitHub问题)
- 允许候选人使用任何资源
- 评估问题分析和解决能力
关键观察点:
- 代码检索效率
- 调试方法论
- 文档查阅能力 这些恰恰是日常开发的核心能力。
3.3 渐进式实操考核
我的团队现在采用的方案:
阶段1:15分钟 - 实现一个包含边界条件的简单函数 阶段2:30分钟 - 在现有代码基础上添加新特性 阶段3:45分钟 - 代码审查与重构讨论这种设计能清晰区分:
- 基础编码能力(阶段1)
- 扩展性思维(阶段2)
- 工程素养(阶段3)
4. 面试官与候选人的双赢策略
4.1 对面试官的建议
建立岗位能力矩阵图
- 明确区分"必要能力"和"加分项"
- 例如:API开发岗的SQL优化属于加分项而非核心要求
设计分层题目组
- 初级:语言特性与基础逻辑
- 中级:模块设计与调试
- 高级:系统演进与架构权衡
引入代码考古环节
- 提供一段历史bug代码
- 考察debug思路和问题定位能力
4.2 对候选人的准备建议
即使面对做题式面试,也可以更聪明地应对:
针对性刷题法
- 先研究公司技术栈
- 重点准备相关领域算法 (如推荐系统岗位侧重概率统计题)
解题时的表达技巧
- 明确陈述假设条件
- 主动讨论时间/空间复杂度权衡
- 提出可能的优化方向
建立解题映射表
题目类型 实际应用场景 拓扑排序 任务调度系统 前缀树 搜索引擎自动补全 并查集 社交网络好友推荐
5. 行业变革的积极信号
值得欣慰的是,变革已在发生:
- Google近期调整校招政策,允许候选人选择项目展示替代算法考核
- 国内某大厂新规:P7及以上岗位禁止使用纯算法题评估
- GitHub推出的"Copilot面试"模式,重点考察AI协作编程能力
这些变化反映出一个共识:面试应该是工作场景的采样,而非脱离实际的智力测验。就像我们不能通过让厨师背菜谱来评估其烹饪水平,对工程师的评价最终还是要回归到解决实际问题的能力上。