招聘那点事儿

最近开始接触一些程序员的招聘工作，于是开始思考如何在短时间内了解一个人，并给出聘用或不聘用的意见。

一个通常招聘流程如下：

筛选简历

• 从一堆简历中筛选候选人，通常马马虎虎的简历（有明显的错误）背后可能隐藏着马马虎虎的工作习惯，若没有更多的选择理由可能就会被直接舍弃了。

• 从简历中寻找有选择理由的事情。例如，业内知名公司的工作经历，如果是刚毕业的学生，那么有像ACM / ICPC的比赛经历，都是很好的选择理由。

电话面试

• 对于一些从简历中无法确切判断是否进行现场面试的人选，可以采用电话面试来进行互动性更好、更深入点的了解，从而辅助决策是否进行现场面试。

• 从概率上讲对于不确定人选有一半的比例是不符合招聘需求的，可以通过电面很好的甄别，从而节省彼此直接面试的时间

现场面试

思考面试问题，拟定面试计划（头脑中或草稿纸），包括：

• 简短的热身交流。介绍彼此，面试的流程等。

• 了解最近从事的工作情况（或最值得一提的工作经历）。若是学生，可了解最感兴趣的课程和主修情况。这一阶段的交流相对开放，提问更自由，从中可重点寻找过去工作中责任承担者或领导者的角色经历。观察应聘者阐述问题和事情的表达能力，优秀的人总是可以在不同的抽象层面清楚的阐述同一件事情。寻找和发掘应聘者心中的激情因子，不错，我更喜欢真正在乎一些东西而坚持、执着因而充满激情的人。人会因性格的不同在激情方面表现差异很大，有些人会对他们从事过的项目充满激情，谈论时绘声绘色，而滔滔不绝。而有些人虽不善言、却言简意赅，目标清晰，眼神坚定。

• 专业领域提问。注重于测试才智和能力，而非技能，毕竟人们能够带给任务的任何技能从技术角度讲，经过几年以后总是要过时的，因此聘用能够主动迅速学习新知识的人，而不是眼前碰巧知道某种技能人更好。不提琐碎的知识问答题，例如oracle clob和blob的区别，web中forward和redirect的区别，凑巧知道某个问题的答案什么也说明不了，因为这些问题都能在10秒钟内从网上查出来。提这样的知识问答题，不如就一个特定的程序设计问题聊上半小时，例如：“你大致怎样去设计一个高并发多线程集群环境下的服务端程序？”，这是一个抽象的命题，机智的应聘者会意识到这个命题缺乏一个开展设计前的场景边界，并就此展开询问或假设一个场景的适用边界。通过不断的互动中，面试官不断的具象化场景，而应聘者不断的就具体的场景进行分析、思考和提供解决问题的思路。其实这样的问题我们真正关注的是应聘者使问题得到解决的方式而不是答案本身。

• 发散性的思考。可以提一些与程序设计无关但又很难回答的问题，例如，你所在的城市大概有多少程序员？机智的应聘者也许会说：“恩，让我想想，这个城市大概有3个软件园区，每个园区大概有多大规模，而其中程序员的比例可以根据我所了解的一些公司做一个推测等等。” 这就足够了，目的不再答案本身。我们需要考察在面对一些看似不可能的问题时，能否主动积极的去寻求解决问题的途径。很多软件项目所面临的问题并不仅仅是程序设计的问题，还有人的问题、环境的问题、管理的问题、制度的问题等等，有些问题已超出了程序本身又该如何面对？那么态度就很关键了，是等着主动别人来拯救还是积极的寻找方法。

• 让面试者提问。这是最后阶段，要是有幸发现了一位非常优秀的应聘人员，那么在这时所能做的就是向他表达愿意一起共事的意愿确保他能来到公司，而不是因为他的某种不确定而做了其他选择（我们相信优秀的程序员都是有很多选择的）。即使是不太符合条件的应聘者，出于礼节性，我们也希望他能带着一个正面的印象离开这里。

做出评价

面试结束，必须准备对应聘人员做出尖锐的决定。注意尖锐这个词，不要说好像差不多，可以要也可以不要，吃不准之类的话。吃不准那就说No。

最后不要因为招聘优秀人员太困难而随意降低标准，除非标准太不合理，例如，标准是在寻找毕业于MIT并在Google工作过的前海军陆战队员。

以上仅仅是就专业素质领域评价一个应聘人员做出的一些思考，还有其他一些感性的因素很难做一个理性的评价，例如，说话的感觉，是否经常微笑，个人的素养，人生观等等。通常对于一个人的面试会有多个面试官进行多次独立的面试，最好是各个面试官独立评价，在评价前不参考其他面试官的评价，以免陷入先入为主和主观假设。

转载于:https://www.cnblogs.com/hehe520/archive/2011/08/24/6147687.html