如何面试程序员？

这段时间负责新部门人员招聘工作，感觉压力山大。

从网上查找了一些关于招聘方面的知识，记录在偶的 BLOG 中以方便以后学习，有三篇文章。

你要面试一个程序员，应该问他什么问题？怎么才能在面试中发现合格的人？相信这是很多管理者关注的问题。
如何面试程序员？
一、提问之前的准备
你应该想清楚：
1.需要新员工完成什么样的任务？
2.怎样的人能完成这样的任务？
3.哪些途径和方法可以发现这样的人？
只有明确这些根本性的问题，才能正确高效地完成面试。
二、提问的原则
假定你对上一节的三个问题，已经有了清晰的想法，那么接下来就可以设计如何提问了。
有一些提问的原则，是你应该遵循的：
1.每一个面试问题都有明确的目的。你不仅自己了解，还能向其他面试官解释清楚。
2.多提一些开放性(Open-ended)的问题，而不是那种用Yes/No就可以回答的问题。
这样做使你有机会与面试者展开讨论，并且提出后续的问题，尽可能多地了解对方。
3.不要问宗教、家庭、健康、个人隐私等方面的问题。
4.不要问太复杂的问题。因为面试者没有太多思考时间，所以无法周全地回答，你也就无从判断他的能力了。
三、考察专业能力
为了确认面试者是胜任的，你可以问一些与职位相关的专业方面的问题。(不过通常来说，一次面试不足以看出一个人的专业能力。)
比如，你的招聘职位是系统管理员，你可以问"如何快速地在50台机器上部署Linux？"(提示：正确答案不是刻录50张安装光盘。)
另外，你还应该向面试者了解他的过去，因为过去是未来的最好预测依据。不过，提问的重点不要仅仅是他过去的成果，更要关注在当时的环境中，他是如何决策和实施的。
四、考察综合素质
因为人是会发展的，所以某种程度上，面试者的综合素质要比他的专业能力更重要。
所以，具体的技术问题(如何调用API、什么是设计模式、编程语言的语法等等)可以少问一些，更应该关注面试者的事业心、对工作的热情、进取心、自律能力、毅力等方面。
下面是一些典型问题：
1.Why did you get into development?
　　你为什么开发软件？
2.How many technical books did you read in the past year?
　　去年你读了几本技术书籍？
3.What was your favorite technical book in the past year? What did you learn from it?
　　去年你最喜欢的技术书籍是哪本？你从中学到了什么？
4.What websites do you read regularly, related to development?
　　平时你经常访问哪些编程类网站？
5.Do you maintain any open-source projects?
　　你有自己的开源项目吗？
6.Do you code in your spare-time?
　　业余时间你编程吗？
7.Do you love programming, or do you do it for the money?
　　对于你来说，编程是一种爱好，还是一种谋生手段？
8.Have you accomplished anything important in your career yet? Do you want to? 
　　你的职业生涯之中有什么重要的成就？它是你主导的吗？
9.What would make you feel that you have done something important?
　　什么事情会让你很有成就感？
五、考察理性思维
某些情况下，你可能需要了解面试者的分析判断能力，看他能否全面地思考问题、客观地评价自己。
那么，你可以依次提出这样三个问题：
1.What's your favorite programming language? Why? 
　　你最喜欢的编程语言是哪种？为什么？
2.If you could add one feature to your favorite language, what would it be? Why?
　　如果允许你为这种语言加一种功能，你会加什么功能？为什么？
3.If you could remove one feature from it, what would it be? Why?
　　如果允许你取消一种功能，会是什么功能？为什么？
这里的重点是，让面试者从正反两方面评价一件自己熟悉的东西，看看他的思维是否片面。答案无所谓对错，只要面试者有一个明确的立场，能够从正反两方面说出令人信服的理由，就可以了。比如，某个软件的口碑不好，但是面试者说他很喜欢，而且说得出一大堆理由，清楚地解释了这种软件的优点和缺点在哪里，这样就很好。
你还可以把这些问题，套用在其他东西上面，比如操作系统、文字编辑器等等。
----------------------------------------------------------------------------------------------------
怎样去面试以找到适合自己需求的从才呢?
一、确认简历。
首先，阅读一下别人的简历是需要的。从简历上，工作经历、项目经历、技术技能这三个事情是你需要了解的。一般来说，你可以先通过电话确定一下他的工作经历、项目经历和技术技能，然后，如果他和你需要的人条件相符的话，可以叫到公司做面对面的面试。千万不要把别人叫来，你又说你的经历和我们的工作有差距之类的话。(我有过一次面试经历，公司我不说了，反正是那个号称需要有良好沟通的公司，面试了我9次左右，从一般的程序员，PM，经理，到总经理，而最后一次直接告诉我，我以前的经历和他们的要求差距很大。我不禁要问了，前面若干次的面试他们都在干什么呢?)
二、面试开场。
把人邀请来公司面试，应聘者到了公司来面试，有一点很重要，那就是你一定要让整个面试过程变得很随意，很放松，就像普通的聊天和一般朋友间的交流一样。这样应聘者才会放松并拿出真实的样子来和你谈话和聊天，你才能在很短的时间内了解得更多。让应聘者放下心理负担，让其表现得自然一些，这是招聘方的责任。千万不要说，别人太紧张发挥的不好，有时候，招聘方得想想自己的问题。
面试开场的时候，千万不要让应聘者介绍自己，因为，应聘者早就给你发过简历了，而你也给其打过电话了。另外，应聘者对这个面试惯例通常都会准备得非常不错的，另一方面，这会让整个面试过程太正式太严肃了。所以，不妨问问应聘者是怎么过来的?最近怎么样?还可以和应聘者谈一个大众话题，比如喜欢什么体育，音乐，电影，社会热点什么的，自己也别板着个脸，说说笑笑，试图让大家都放松下来。另外，通过这些闲聊，你可以知道他/她的与人交往能力和一些性格。另外，不要让桌子放在你和应聘者之间，把环境搞得随意一些。
三、多让应聘者说说他的经历。接下来，如果你要觉得这个应聘者是否是一个可以解决问题，是一个可以把事情搞定的人，不用问他/她会做什么，直接问问其做过什么?干过什么事?对于一个好的程序员来说，很难想像其没有相关的实践，就算你是在大学里，你也应该做过什么。如果你有解决问题的能力，那么，很显然，今天你应该解决了很多问题，也搞定了很多事情，听听应聘者说一说他的那些事。(不要使用一问一答这种方式，应该让应聘者多说，而多听，多想)
在他讲他的项目的时候，通常来说你要注意下面几点：
1.沟通表达能力。应聘者能不能把一个事情讲清楚。如果这个人聪明的话，他就可以用最简单的语言把一个复杂的事情讲清楚。而且，这是一个好的程序员最基本的能力。而且，你可以在应聘者一边描述其经历的时候，你可以和应聘者有一些的良好的来来回回的交谈，这样就可以知道，他的沟通能力和沟通方式，从而了解他的性格。
2.角色和位置。也许他参与了一个很大的项目，但只是做了一个很简单的模块。所以，了解其在项目中的担任的角色和位置是非常必要的。当应聘者说到“我们”或者“大家”之类的词汇时，一定要向下细化和明确。
3.做出的贡献和解决了什么的问题。这个很重要，通过了解这个，你可以知道面试者是否聪明，是否有能力解决问题，是否有好的技术底子。
4.演示。如果可能，你可以让应聘者展示一些其写过的代码，做过的设计，或是直接给你看看他写的程序的演示。(从设计上，代码的风格，重用性，维护性上你可以了解很多很多)
5.基础知识。了解该项目中应聘者使用的技术的一些基础知识，比如，通过整个过程，你可以问一些网络，语言，面象对象，系统的一些基础知识。基础知识是非常重要的，这直接关系到了他的能力。
6.流程和工具。了解应聘者所熟悉的项目的流程(银弹，瀑布，敏捷，……)，还有流程中的一些工件(如：需求文档，设计文档，测试方档等)，以及在开发过程中使用的工具(内存测试，代码检查，BUG报告，版本维护，开发调试……)(关于程序员的基本技能，你可以参考——《程序员需要具备的基本技能》)
有人会说，应聘者的经历可以被他自己编出来的，他可以把一些不是他做的事说成是他做的。是的，的确是有这种可能。不过，不要忘了，一个谎言背后需要用更多的谎言来圆谎的，所以，你不必担心这个问题，只要你在应聘者的描述过程中逐步求精，细化问题，你会知道应聘者是否是在编故事的。
千万记住下面几点：
1.谈话风格要随意和自然，不要正式。
2.在了解应聘者以前做过的事的时候，不要太投入了。因为招聘方也是技术人员，所以有时候，招聘者自己会因为应聘者所做的项目中的技术太过迷人而被吸引了。
要注意引导应聘人。相信我，应聘的程序员十个人有八个人讲不清楚以前做的是什么。因为他们直接跳过了项目背景和要解决什么样的问题，而直接进入具体实现。
3.不要一问一答，应该多让应聘者说，这样才能多全方位了解一个人。
4.了解一个人的过去，了解一个人做过的事情，比其会做什么更重要。
5.了解一个人的性格，想法，思维和行为，比了解其技术技能更重要。
6.沟通能力，表达能力，语言组织能力，理解能力，等方面的能力，关系到了是否能和别人一起工作。
7.基础知识比知识的点滴要重要得多。你可能不知道其个C++的关键字，但你应该要知道C++的继承和多态。
8.技术技能固然很重要，但比其更重要的是这个人获取知识的能力，学习能力是在计算机这样变化飞快行业中必需具备的。
9.是否可以进行培养，比掌握的技能更重要。
四、实际参与?
这一步可能是很不好实施的。因为，这需要一些应聘者付出一定的时间，如果是毕业生，那没有问题，先让他来实习一段时间。但如果别人有工作，就不好了。也许你会说，这就是试用期的用处了。不过，我个人觉得，你得要尊重应聘者，人家把那边的工作辞了，来你这边工作，三个月试用期间，如果没有什么原则上的问题，你作为一个招聘方又反悔了，这样做很是相当的不好。如果发现这样的事，只能是招聘者自己的问题。
在面试过程中，一些招聘者会让应聘者们一起做个游戏，或是搞个辩论比赛，或是现场组个团队干个简单的事情，有的甚至让应聘者请一天假到自己的公司里来和自己的团队一同工作一天，并要完成某个事情(甚至给其设置上deadline)，并通过这些来考量应聘者的实际参与能力。
是的，如果没有一起工作过，没有一些实际的事情发生，单靠几个小时的面试很难了解一个人的。设置上这些面试的环节，在最短的时间内来了解应聘者的一切，对于招聘方来说无可厚非。而且有的时候也能得到不错的效果。在这里，我只提一点，有时候这样的周期拉得很长，让应聘者付出了很多，反尔会让应聘者产生反感和厌烦情绪，从某种意义上来说，这实在是对应聘者的不尊重。
对于这一点，我一直持疑问的态度，所以，我在其后打了两个问号。老实说，对于实际参与这一环节，我个人的意见是适可而止，因为时间太短了，无论你怎么做你都无法了解完整。即然无法了解完整，那就获取你最需要的吧，就是本文开头的那三个问题，以及上面所述的“第三点”(了解应聘者的以往经历)。
也许这个文章中有一些你不同意的观点，没问题，欢迎批评。
----------------------------------------------------------------------------------------------------
如何在面试中发现优秀程序员
我曾在一次面试中要求一个很有经验的嵌入式软件开发人员写出一个反转一段字符串并输出到屏幕上的程序。他在这个题目上挣扎了很久，这个家伙是个很神奇的人。你给他一些没用的零件，他能建造一个机器人，并能用程序控制它在屋里走来走去。他曾经参与过研制卫星，并且这个卫星现在正在轨运行。他只用左脑都比我能干。但是对于这个题目他却从来、从来没机会干过：在屏幕上显示什么东西。
有些人就有这种技能，能在面试中问出正确的问题，发现优秀的程序员。而有些人却害怕提问，畏首畏尾，问一些从网上拷贝下来的问题，自己没主见，只会跟随其他面试官的意见。但面试对于大多数开发人员来说是一项很基本的技能。一次失败的招聘会给一个组织造成很严重的长期的后果，因为很水的雇员会把其他很水的人也带进公司。另一方面，把优秀的应聘者拒之门外对公司也是一种伤害。
一场技术性的面试至少包括三个部分：
1.我们要做的是看应聘者的简历上写的是否符合实际情况
2.我们要评估一下候选者究竟有多少实际经验
3.我们要用一些问答选项或编程问题来测试这些经验。
一、测试简历的真实性
有一次我跟一位同事面试一个候选人。当面试完之后，我觉得这个候选人还可以，但不是十分出色。
可我的同事看起来很不满意：“他撒谎，他说他会XXX技术，可很显然他根本没有做过这种技术。绝对不能要这种人。”
虽然这XXX技术对我们公司并不是很重要，“因为他撒了这个慌，”我的同事继续说，“我就不会相信他在简历上写的任何东西了。”
应聘人员应该在简历中用一种很积极的色彩来描绘自己。然而，这种积极的描绘应该有个度，过了这个度，就表达的不正确了。在上面的例子中，我并不和我的同事一样觉得这个事很严重，因为我事先就假设了，简历上的任何东西都是假的，除非被证明。如果简历上说，“擅长于XXX技术”，那么我就认为这个应聘者可能仅是知道XXX技术这个名字。如果简历上说，“在一个开发多线程股票交易系统的团队里工作，”那我就会认为应聘者可能只是为这个系统挑选了一下背景的颜色。我的要求一向不严格，除非碰到了一位有十年工作经验、已经不再写代码的家伙。如果有人说他开发了OpenOffice软件的文本格式化工具，或拥有哲学博士学位，那我们就很容易假设他们有什么技能了。假设一无所有，一切都要证实。
对于简历上每条相关的描述，我会首先估摸一下应聘者的实际情况。然后，我通过下面的交谈来证实。
例如：开发过一个实时操作系统作为练习项目。
你工作的团队有多大？15个成员？哦，那么，你实际上负责哪部分的？消息队列？很好！请描述一下一个高优先级的任务向一个低优先级的任务发送消息时会发生什么情况？
例如：完全自主开发了一套为无线安全系统使用的音频传输协议。
你的团队有多少人？只有你？哦，你是如何测试的？你为什么不使用RTP呢？
例如：给XXX引擎修复Bug。
请你描述一下你曾发现过的一个特别有挑战性的Bug，以及你是如何修复它的。
第二部分：发现实际的经验
拥有更多的经验是一个优秀人才的很好的指标。有经验的开发人员都是从犯错误中成熟的。他们知道何时该，何时不该使用设计模式。他们有第六感，能感觉到需求的哪一部分需要修改，哪一部分要保持原样。他们知道何时该偷懒，何时该考究。是真实的经验让优秀的开发者和平庸的开发者之间的差距大的无法跨越。
并非所有的经验都是等效的。很有可能，对于某个人，他通过多年的工作，在很多的任务中写或重新无数的代码，犯了许多的错误，就能获得扎实的技能。而另一种情况，一个人会在十年的时间里只在一个项目里修改了一行代码，没有学到任何新的东西。
发现隐藏的时间
很多伟大的程序员都是在他们大学的第二年就开始编程了。当他们离开学校时，他们就已经有了几年的工作经验了。还有，有些很神奇的程序员在他们很小的时候就开始学习编程的艺术了。我也认识好几个人在他们十几岁或更小时就写出来一些不算小的程序了。这些信息你是在简历上找不到的，需要你在面试中把它们引诱出来。
1.你是怎么进入到软件开发这一行的？
2.你曾经学过的第一种编程语言是什么？
经验的密度
很多神奇的程序员只是在他们工作的时间里编码。这很好，工作生活很平衡，你没有理由不雇佣这样的人。然而，在工作和学习之余做一些个人的编程项目是一个优秀的人才的很好的指标。有业余编程经验的应聘者很明显有更丰富的经验，更适合公司。没有个人项目？这里有其他几点也能做这方面的指标：
1.在很小的团队或小组里工作。
2.参与过很多各种各样的项目。
3.对一个大型项目的各个抽象层面上都有很详细的了解。
4.在一个项目组里作为主要开发者。
第三部分：验证经验
在对应聘者有了一个基本的真正经验水平的感觉后，就开始对他们进行重要的实际编程经验的验证了。几分钟的时间对于一个真正的测试肯定是很不充分的，但也只有这样了。我们可以通过对编程开发的各个领域进行提问来认识应聘者对这些知识掌握的深度和广度。当然了，你对应聘者技能水平的看法会由于你自身的经验水平而有所偏向。对于你不太熟悉的领域你不可能对答案做出正确的判断。所以我们一般同时会有好几个面试官。
工作职务的不同会有不同的面试主题。然而，下面几个领域是很常见的：
1.数据结构和算法
2.多线程
3.字节操作
4.内存分配
5.对象，继承，设计模式
6.递归
7.汇编知识和程序运行原理
我选择的每个领域都有一个精心挑选的很基础的问题(“什么是一个信号？”)。问题很基础，只要应聘者在这个领域做过一些工作就能回答上这些问题。每个领域都有一些其它的较深入的问题。候选人对这些问题的回答能证明他们到底是不是专业。例如，如果你问一个有经验的嵌入式软件开发人员如何把0x4c转化成二进制，他写出一个4×16+12，这就不是很对了。
编码问题
在完成了上面的步骤后，我通常就已经能认定了这个候选人是否能过关，如果还有困难，那编码问题会帮我扫除最后的障碍。这个很重要，即使在电话面试里也不能漏过。为了行之有效，在面试之前，你要好好的思考和计划要提出的编码问题。问错误了，回答也就没意义了。
1.问题的选择必须基于应聘者的工作经验之上。如果你想起来3D飞机，想把所有问题都围绕着它进行，这样会有很妙的问题。但你还是省省吧，吃午饭时跟同事说说还行。如果招聘的工作跟3D图形没一点关系，那这个候选人就肯定被不公平的排除掉了。
2.问题必须精确的表达出来。“写出一个用来移动一摞卡片的函数”，这个表述就十分的含混不清。要给出功能性标题，避免误解，这种事情经常发生。如果你不小心，面试者有可能回答的是一个比你提出的问题更难或者更简单的问题，而不是你想要问的。如果回答的是更难的问题，那还好，除非难题让他目瞪口呆。如果回答的是更简单的问题，那没有什么用处。为了防止浪费大量的时间，在他们答题的几分钟后问一下他们的答题纲要，看看他们的理解是否在正确的方向上。
3.上面的指导并不能解决所有问题。这些主要是针对工作经验。你也许会错过一些没有多少经验但有非常大的潜力的优秀程序员。特别是当面试官想通过一些不用编码的难题来考察应聘者解决问题的能力的时候。
这里所说的这些面试技巧都是要基于一种假设、可能性、内部直觉。假设候选人是一个很出色的开发人员。那一个出色的开发人员应该具有哪些品质呢？你没法直接的测量这些品质，所以你需要想：一个具有这些品质的优秀开发人员对这样一个特定问题进行快速回答的可能性是多少？你不可能通过面试对一个候选人进行100%正确的评价，但通过尽量周全的提问，你会做到很接近这个结果。