用简单但可扩展的编程题，在面试中识别简历无法反映的真实代码能力

一个人工作了几年、做过很多项目、带过团队、发表过一些文章，并不能代表他代码写得好；反过来，一个人代码写得好，其他方面的能力一般也不会太差——这个判断催生了一条具体的招聘实践：与其依赖简历上的资历（工作年限、项目经验、职级）去推测一个人的代码能力，不如直接通过白板编程和上机编程来考察。文中给出的一个具体案例是用”写一个代码行数统计工具”作为上机编程题——很多人第一反应是这道题太简单了，但实际效果上这道题的区分度反而很好，原因在于它同时满足了几个巧妙的设计条件：一是题目本身足够简单，即使没有特意准备过面试题库的人也不会因此吃亏；二是这道题的扩展性很好，可以在基础要求上叠加不同的额外条件（按文件类型分别统计、要求提高统计效率、同时统计某些关键词出现次数等），从而灵活调整考察的深度和广度；三是从考察维度看，这道题能同时覆盖基本的树遍历算法能力、代码组织和抽象能力（体现在代码量稍大之后如何组织）、能不能在上机环境下顺利写出代码（能快速识别出”很久没写过程序”的候选人）、以及对程序易用性和性能的理解；最关键的是，最终交付的是一个完整可运行的程序，面试官可以直接按日常工作的标准去评价这份代码，而不是从十几行的孤立函数片段里去猜测这个人在真实工作场景中大概会表现如何。这个案例给出的启示是：评估一项难以直接量化的能力（代码质量）时，与其依赖间接的代理指标（简历、履历、口头描述），不如设计一个成本可控、但足够贴近真实工作场景的具体任务，让候选人在这个任务里的实际产出直接暴露出真实水平——不过这类方法也有其边界：面试表现只能说明候选人有能力写出好代码，不代表他未来在真实工作压力下一定会持续这样做。