怎么招聘程序员？

我以前写过一篇“我是怎么招聘程序员的”的文章。今天，我想再谈谈关于招聘和面试这方面的东西，主要是以下这些原因：

  近半年来我在进行了大量的招聘工作，对面试有一些新的体会。
  酷壳最近发布了几篇趣味面试题（面试题一，面试题二，面试题三），从回复中让我有一些思考。
  我有一个同事最近面试了一家公司，他和我分享了一个博士专家对他的面试，也让我思考了一些。
  在豆瓣上看到“知乎上某人写面试豆瓣产品经理的经历，很欢乐”(亮点是面试官现身知乎亲自作答)

　　所以，我很想把自己的这些新的想法再次写下来的。还是和以前一样，这篇文章同样是献给面试官的。我认为，面试的好坏完全在面试官而不是面试的人。下面是我对“我是怎么招聘程序员的”一文中的一些加强性的观点。

　　为了让我的文章有连续性，请允许我重申一下前文的几个重要观点。

  只有应聘者真实和自然的表现，才能了解到最真实的东西
  重要的不是知识，重要的是其查找知识的能力
  重要的不是那个解题的答案，而是解题的思路和方法

　　操作，知识，经验，能力

我们有很多的面试官似乎分不清，什么是操作能力，什么是知识，什么是经验，什么是能力，这导致了我们的面试官经常错误地对面试者下结论，我认为分不清这些事的人是没有资格做面试官的。所以，我有必要在这里把这个问题先讲清楚.

1. 操作。我们的面试官分不清楚什么是操作技能，什么是知识，他们甚至认为操作技能就是知识甚至经验。比如他们会问如下的问题，请问Java中的final是什么意思？怎么查看进程的CPU利用率？怎么编写一个管道程序？怎么查看进程的程序路径？VI中的拷贝粘贴命令是什么？包括面向对象的XX模式是什么？等等。我以为，这些能够通过查阅相关操作手册或是能够Google到的东西只能说明这个人的操作技术，并不能说明他有知识或有经验。
2. 知识。知识是一个人认知和学习的体现，可能会是一些基础概念和知识。比如这些问题：TCP和UDP的优缺点比较，链表和哈希表的优缺点的比较。什么是堆什么是栈？进程间是怎么通信的？进程和线程的优缺点？同步和异步的优缺点？面向对象的XX设计模式的主要原则是什么，等等。我以为，“知其然”只是操作技术，“知其所以然”才是真正的知识。知识不够并不代表他不能工作，会操作技能就可以应付工作，但是知识的欠缺一定会限制你的经验和能力，同样会影响你的开发质量。
3. 经验。经验通常跟一个人的经历有关系。一个人的知识范围，一个人经历过的事，通常会成为一个人经验的体现。面试中，我们会问这些问题：你解决过最难的问题是什么？你是怎么设计这个系统的？你是怎么调试和测试你的程序的？你是怎么做性能调优的？什么样的代码是好的代码？等等。对于工作年限不长的人来说，经历和做过的事的确会成为其经验的主要因素，尤其是业务上的有行业背景的东西。但是，我更以为，经验可能更多的是你对知识的运用和驾驭，是你对做过事情的反思和总结，是你对他人的学习，观察和交流。
4. 能力。一个人的能力并不会因为知道东西少而不行，也不会因为没有经验而没有能力。一个人的能力是他做事情的一种态度，性格，想法，思路，行为，方法和风格。只要有热情，有想法，有好的行为方法，以及好的行事风格，那么知识和经验对他来说只是一个时间问题。比如：学习能力，专研精神，分析能力，沟通能力，组织能力，问题调查能力，合作能力等等。所以，对于一个新手来说，也许他的知识和经验有限，但并不代表他能力上有问题，但是对于一个老手来说，如果其存在知识和经验欠缺的问题，那么通常都是其能力的问题。你可能暂时怀才不遇，但我不相信你会长期怀才不遇。如果是的话，那么必然是这些问题让你的能力发挥不出来。而此时，“没有经历过”只会是你“没有能力”的一个借口。

　　我不否认这四样东西对于一个优秀的程序员来说都很重要。但是，通过上述的分析，我们可以知道，能力和经验和知识需要分开对待。当然，这些东西是相辅相成的，你的能力可以让你获得知识，你的知识可以让你更有经验，你的经验又会改变你的想法和思路，从而改善你的能力。在面试中，我们需要清楚的认识到，应聘者的操作技能，知识和经验只是其能力的必要条件，并不是充要条件，而我们更应该关注于应聘者的能力。

  如果面试只是考查这个人的操作技能的话，那么这个面试完全失败。这是一个没有资格的面试官。
  如果面试只是在考查这个人的知识和经验的话，那么成功了一半。因为你了解了基础知和做过的事，但这并不代表你完全了解他的真正能力。
  如果你能够在了解这个人的知识和经验的过程中重点关注其能力（态度、性格、想法，思路，行为，方法和风格），并能正确地评估这个人的能力，那么你的面试算是非常成功的。

　　也许用这四个词来描述定套东西并不太合适，但我相信你明白我想表达的。

　　不要肤浅地认识算法题和智力题

　　很多公司都会在面试的时候给一些算法题或是一些智力题或是一些设计题，我相信算法题或是智力题是程序员们在面试过程中最反感的事了。很多人都很BS面试官问的算法题，因为他们认为面试官问的这些算法题或智力题在实际工作当中用不到。但我想在这里说，问难的算法智力题并没有错，错的很多面试官只是在肤浅甚至错误地理解着面试中的难题的目的。他们认为，能做出算法题和智力题的人就是聪明的人就是有能力的人，这种想法实在是相当的肤浅。

　　其实，能解难题并不意味着这个人就有能力就能在工作中解决问题，你可以想想，小学奥数题可能比这些题更难，但并不意味着那些奥数能手就有实际工作能力。你可以想一想你们班考试得高分的同学并不一定就是聪明的人，也不一定就是有能力的人，相反，这样的人往往者是在应试教育下培养出来的书呆子。

　　所以，我认为解难题的过程更重要，你要主要是通过解题查看这个应聘者的思路，方法，运用到的知识，有没有一些经验，和你一起交互时和沟通得是否顺畅，等等，这些才是你重点要去观察的。当然，最终是要找到答案的。

　　我想，让面试者解决一个难题的真正思路是：

  看看他对知识的应用和理解。比如，他是否会用一些基础的数据结构和算法来解决算法题？
  看看他的整个解题思路和想法。答案是次要的，他的想法和行为才是重要的。
  看看他是如何和你讨论交流的。把面试者当成你未来的同事，当成你的工作伙伴，一起解题，一起讨论，这样可以看看大家是否可以在一起工作。

　　这些方面才是考查应聘者的能力（思路，方法、态度，性格等），并顺带着考查面试者的经验和知识。下面是一些面试的点：

  应聘者在解算法题时会不会分解或简化这个难题。这是分析能力。
  应聘者在解算法题时会不会使用一些基础知识，如数据结构和基础算法。这是知识。
  应聘者在解题时和你讨论的过程中你有没有感到应聘者的专研精神和良好的沟通。
  应聘者在对待这个算法题的心态和态度。如，面试面是否有畏难情绪。
  应聘者在解题时的思路和方法是否得当，是否是比较科学的方法？
  等等。

　　在解难题的过程中考察应聘者的能力才是最终目的，而不是为难应聘者，不然，你只是一个傲慢而无知的面试官。

　　模拟实际中的挑战和能力

　　作为面试官的你，你应该多想想你的工作，以及你的成长经历。这会对你的面试很有帮助。你在工作中解决问题的实际情况是什么？你写代码的实际情况是什么？你的成长经历是什么？你是怎么获得知识和能力的？你喜欢和什么样的人工作？相信你不难会发现你工作中的实际情况和面试的情况完全是两码事，那么，你怎么可以用这种与实际情况差别那么大的面试来评估一个人的能力呢？

　　所以，最为理想的面试是一起工作一段时间。当然，这个在招聘过程中，操作起来几乎不可能，因此，这就要求我们的面试官尽可能地把面试的过程模拟成平时工作的过程。大家一些讨论来解决一个难题，和应聘者一起回顾一下他已经做过的事情，并在回顾的过程中相互讨论相互学习。下面举一个例子。

　　我们知道，对于软件开发来说，开发软件不难，难是的下面是这些挑战：

  软件的维护成本远远大于软件的开发成本。
  软件的质量变得越来越重要，所以，测试工作也变得越来越重要。
  软件的需求总是在变的，软件的需求总是一点一点往上加的。
  程序中大量的代码都是在处理一些错误的或是不正常的流程。

　　所以，当我们在考察应聘者的代码能力的时候，我们为什么不能模拟这样的过程呢？比如，让应聘者实现一个atoi()的函数，实现起来应该很简单，然后不断地往上加新的需求或新的案例，比如：处理符号，处理非数字的字母的情况，处理有空格的情况，处理十六进制，处理二进制，处理“逗号”，等等，我们要看应聘者是怎么修改他的代码的，怎么写测试案例的，怎么重构的，随着要处理的东西越来越多，他的代码是否还是那么易读和清晰。如果只是考查编码能力，一个小时，就问这一个问题，足矣。真正的程序员每天都在和这样的事打交道的。

　　如果要考查应聘者的设计能力，同样可以如法泡制。不断地加新的功能，新的需求。看看面试者的思路，想法，分析的方法，和你的讨论是否流畅，说没说在点上，思想清不清晰，会应用什么样的知识，他在设计这个系统时的经验是会是什么样的，面对不断的修改和越来越复杂的需求，他的设计是否还是那么好？

　　当然，因为时间比较短，所以，你不能出太复杂的问题，这需要你精心设计一些精制的有代表性的问题。

　　把应聘者当成你的同事

　　有些公司的面试官，在面试过程中问你一个算法题，然后等着你解答了，如果你给出一个答案，然后就会问你有没有更好的答案，如果你给出了正确的答案，他们就会问你一个更难的问题，如此循环下去。他们基本上很少给你提示，甚至不停地质问你，挑战你，搞得应聘者很紧张。

　　另外，有很多问题是没有标题答案的，或者说是，同一个答案的描述方法有多种，很多面试官会觉得你没有回答到他想要的答案，因此表现得有对你不屑，并表现出你不行的样子，并觉得你的能力有问题。真是可笑了。比如我一个朋友在回答什么是异步的问题时，举例说明了异步调用就是不能处理完就返回，并且需要传递一个回调函数给调用方以便完成后回调通知结果。这样的回答并没有错，但是这并不符合面试官心里想要的答案，面试官对此并不满意，进而认为我这个朋友还需要去多读读书。

　　我相信大多数面试官都会这样干的。我想问问这样的面试官，你们有没有用面试的方式对待过你的同事？在你的工作场景中，你会不会用面试的风格和你的同事进行交流和说话？不妨让我们来问我们自己下面几个问题：

  你在工作当中遇到难题时你是怎么解决的？你会和人讨论吗？你只用15分钟就能得出最优解吗？
  你在工作当中解决难题时是否会有一个人在旁边质问你并给你压力吗？
  你在工作当中会为难你的同事吗？会让你的同事紧张吗？你觉得在紧张的状态下能做好工作吗？
  你在工作中觉得同事的回答并不是你想要的答案，不是符合你的答案，你会认为你的同事不行吗？
  你的成长过程是什么样的？在是压力和天天被人质问的情况下成长的吗？
  大家都知道学校里应试教育的弊端，你觉得你的面试是不是一种应试呢？
  （看看这么多的应聘者们都在做各种各样的算法题，这不就是一种应试吗？）

　　想一想你的日常工作，问自己一下上面这些问题，想一想你自己的成长过程，想一想你和你的同事是怎么相处的，想一想你的日常工作中是什么样的，相信你自己也能得出结论的。

　　如果你把应聘者当成自己未来的同事，那么你的面试会有下面的收获：

  面试的气氛会很不错，应聘者会放松，表现自然，更接近于真实的状态。
  面试中的交流和互动（而不是一问一答）会让你更全面的考查和了解一个人。
  非应试的面试，会让你了解得更多。
  真实的了解一个人，你才能做出真正正确的结论。

　　向应聘者学习

　　下面有几个观点

  面试的过程是一个相互学习的过程，并不是你为难面试者的过程。
  一问一答是很一种呆板死板的过程，相互讨论相互学习，有良好的互动才是好的面试过程。
  面试官要证明的不是你有多强有多聪明，而是要挖掘应聘者的优势和能力。
  面试官要为自己的问题预设好一个标准答案，看看应聘者能为你带来什么。
  向来应聘的人学习，而不是刁难。

　　无论你多牛，要难倒你实在是太容易了。出难题不是目的，难倒人也很容易，出难题只不过是用来了解应聘者能力的一个手段，而不是面试的全部。

　　我不知道你喜欢不喜欢一些竞技类的运动？比如踢球，打篮球，羽毛球，下象棋等，你一般想和什么样的人玩？是差的，还是强的？所以，能够从面试者那里学到东西，喜欢和面试者一起工作，这才是面试真正的目的。

　　对于一个团队来说，如果大家都是一样的想法，一样的主张，一样的倾向，那么这个团队最终会是一个闭塞的团队，你如果不能真正接纳不同想法的人，不同主张的人，那么你也将失去进步的机会。如果你的团队总是在招入和你一样的人，那么你的团队怎么可能会有out-of-box的想法呢？世界因为不同而美好。

　　另外，对于公司来说，如果你招进来的人还不如已经有的人，作为一个公司，你又怎么能有更好的人让你的公司进步呢？

　　所以，面试应该是向面试者学习的一个过程。当然，如果你从他身上学不到什么，那么你就教他一些吧。这样，就算是面试不通过，面试者也会欣然接受的。不然，让面试者产生一些负面情绪，出去说一些不好的话，也有损你和公司的形象。