浅谈社招招聘（四）：笔试的设计
有些单位在招聘时，会安排一轮笔试。本文谈一谈笔试的经验。
笔试的目的
笔试最大的特点就是省事，只要事先把题目设计好，让应聘者过来答题就OK，因此适合应聘者比较多的情况。
笔试应当放在招聘的第一环节，以便“筛掉一大批垃圾”。为了筛掉明显不合适的应聘者，笔试的题目还要有一定的区分度，不然的话，所有人都拿到满意的成绩，笔试就没意义了。
笔试不能代替面试。笔试只适合考察技术问题，心理素质、团队意识、个人素养等非技术特性是无法通过笔试考查出来的。
笔试的内容
笔试题建议分为三部分：送分题、经验题、实战题。
送分题
笔试题中，应该包含一些送分题，既是给应聘者一点信心，又能筛掉明显不适合开发工作的人——如果连送分题都答不上来，赶紧回家躺平去吧。
就像高考数学卷，满分150分，对于冲985、211重点的考生来说，其中100分都是白送分的信心题，必须全部拿到手，剩下50分才是重点大学的入场券，拿得越多越容易进重点。然而高考也要照顾大多数人，如果每道题都是奥林匹克竞赛水平，那就几乎没人能考大学了，即使有能力，一大片答不上的空白也会挫败考生信心。
送分题，题型可以是简单的选择、填空，内容可以简单到只要学过编程就能答上，最后评卷的时候把没答上的人给PASS掉就行。
经验题
前面提到了“送分题”，那么“经验题”难度就要比送分题高一些了。这部分问题建议设计成问答题，挑取开发中常见的一些技术问题，以考察应聘者是否具备一定的开发经验。
例如MySQL并发事务容易出现问题，所以可以考察应聘者对脏读、不可重复读、幻读的理解，并要求应聘者回答如何规避。
这部分问题既可以是有标准答案的死问题，也可以是开放的活问题。建议少出一些死问题，多出一些活问题，以免某些应聘者靠背答案来蒙混过关。
实战题
最后要设计一两道实战题。可以以公司业务场景为基础，做一些设计或编码工作，重点考察应聘者是否逻辑清晰、思维缜密。同时可以在题目中设置一点陷阱，考察应聘者是否细心。
以信息管理系统为例，考虑一个特定的业务场景，要求应聘者设计表结构，至少可以考察到以下几个方面：
- 是否设计了主键？
- 表和字段的命名习惯如何，是汉语拼音，还是英文单词？
- 数据类型是否规范？长度和类型是否够用？是否用NOT NULL？
- （MySQL）是否考虑并发读写的问题？
- 是否考虑了业务变化的需要？
通过一个题，既考察了技术水平，也在一定程度上考察了非技术水平。
出题者还可以在此基础上扩展，例如要求应聘者写SQL语句，或者提出性能要求，这样就能进一步了解他对SQL的熟悉程度。
再举一个案例，要求应聘者往一个树形结构中插入一个节点，可以考察到以下几个方面：
- 能否正确地实现功能？
- 代码是否简洁明了？
- 代码格式（命名、缩进等）是否规范？
- 是否有防御性编程意识，例如检查边界、空指针等低级错误？
笔试的设计
考察技术能力，当然不应当局限于答案的对错。在设计题目时，除了标准答案，建议注明：
- 每道题的考察目的，这样在整张试卷设计完成后，你就能知道考察要点是否有所遗漏。
- 加分点/扣分点：虽然题目没有标准答案，或者有标准答案而应聘者答案错误，但是有些要点正确，例如他考虑了有效性校验。可以将这类加分点或扣分点也明确标示出来。
题目范围应当考虑公司工作实际需要。例如公司是做信息系统的，用不到复杂算法，那么别考编程竞赛那种高难的算法题；如果公司是做图像识别的，可以出一些数学方面的问题，而且要求应聘者禁止靠某些工具类来偷懒。
对技术能力的考察，应当把重点放在基本功和基本素养上面，例如问题分析能力、编程语言或框架基本原理，而非某一种高级用法、复杂逻辑。像某些特别具体的API，如果连你自己平时都要到百度查用法，拿出来考应试者显然是不合适的。
笔试之后
应聘者通过笔试后，应当尽快向应聘者进行反馈。如果应聘者水平OK，建议两三天之内就通知应聘者参加面试，笔试面试间隔不超过一周，否则应聘者就跑了。
参考资料
- 俺的招聘经验 - 编程随想的博客