我是怎么招聘程序员的
很早以前就想写一篇和面试相关的文章了，今天在网络上看到一篇关于如何去面试程序员的英文文章，发现其中有很多和我共鸣的东西，所以仿照其标题通过自己的经历写下了这篇文章。
工作这么多年来，即被面试过，也面试过他人，对于程序员的面试，经历过很不错的面试，很专业的面试，也经历过一些BT和令人不爽的面试，我个人觉得一个好的面试，面试官是很重要的，所以，本文想从“面试官”的角度来阐述一下。于是，有了下面这样一篇的文章，希望本文对你的职场经历有用，特别是那些正在招聘和面试程序员的朋友，我觉得这篇文章会对大家有很多启示。此外，做为被面试的人，你可以看看本站的《别的程序员是怎么读你的简历的》《程序员需要具备的基本技能》《优秀程序员的十个习惯》其它一些和程序员相关的文章。
对于招聘方来说，在招聘程序员的时候，我估计面试应聘者时，最主要想知道的是下面三件事：
- 这个程序员的是否够聪明？
- 这个程序员能否把事情搞定？
- 这个程序员能和我的团队在一起工作吗？
我相信，这是所有团队经理招人要考虑的三个问题，所有的问题也基本上围绕着这三个问题。有些时候，你也许觉得程序员的技术技能可以同时解决这三个问题，一个技术能力优秀的人必然是一个聪明的，可以搞定事情的人，当然也就能和团队一起工作了。是的，感觉看起来是这个样子，但其实并不是这样的。有些人的确很聪明，但却不能处理好工作上的事情，这样人应该是你的朋友，你的顾问，但不应该是你的雇员。有的人为人很不错，和团队所有人都合得来，但并不是很聪明，但工作很刻苦很努力，这样的人可以成为你的下属，比如某个下属骨干的助手，或是整个团队的助手。如果某个人不能和团队一起工作，无论其有多聪明，解决问题的能力有多强，你都不应该和他在一起工作。人个认为，团队的和谐是一切事情的前提。
对于传统的面试招聘过程，基本上来说都是下面这样的样子的：
- 阅读应聘者的简历，让应聘者做个自我介绍。
- 问一些比较难的非常细节的技术问题，以一问一答的形式。
- 给面试者一些和几个编程难题。（比如某些怪异的算法题）
我个人觉得这种面试方法很可笑，也很糟糕，尤其是后面两点。通常来说，这样的面试只会让你面试到一些“书呆子”或是一些“技术痴迷者”，下面让我来一条一条地剖析一下这几条的弊端。
- 你很难从一个人的简历或是自我介绍上了解一个人。因为这些都是当事人自己写的，或是自己阐述的。所以，这并不是很准确的，通过简历，你只能知道很简单的事情，这对于是否能招入团是远远不够的。而在面试的开始，让应聘者做自我介绍，只会让面试者以很正式的态度来面对整个面试。一但面试过程很正式，很严肃，就会让人很拘禁，其实，这并不是我们想要的，我要的是应聘者真实和自然的表现，从而才能了解到最真实的东西。
- 问几个技术细节的问题。比如：我个人经历过的——“ps的-a参数是什么意思？”，“vi中删除换行符的命令是什么？”，“C++的关键字explict,mutable是用来干什么？”等等，等等。以前做为一个应聘者来说，我非常讨厌这样的问题，因为这样的问题查一下手册就知道。难道他要招的是一个字典手册？不是一个人？对于这方面，重要的不是知识，重要的是其查找知识的能力。
- 给应聘者一个或几个很难的算法题，给上十几分钟，然后让面试者把伪代码或是代码写下来。这样的做法是相当可笑的，不能讨论不能查资料，让人在一种压力状态下作答，这根本就不是实际工作中的状态，而我们的面试也就成了一种刁难（我最变态的经历是，当我把写在两页纸上的代码上交上去后，面试官把其交给旁边程序员输出电脑做校验，结果程序员说，编译出错。于是，面试官说，“很遗憾，可能你写的程序还不多”，相当可笑）。对于这点来说，重要的不是那个解题的答案，而是解题的思路和方法。
我以前经历过很多的面试，当技术人员来和我做面试的时候，我发现，“技术人员的思维”对于某些人来说根本分不清面试和考试，在潜意识里，他们在很多时候不是在面试这个人，而是在刁难这个人并以此展示自己的技能。我个人认为我是一个好的程序员，但我可以告诉你我无法通过那样的面试，因为那样的面试是为他们自己准备的，而不是为应聘者准备的。
那么，我又是怎样去面试的呢？
一、确认简历。首先，阅读一下别人的简历是需要的，从简历上，工作经历，项目经历，技术技能这三个事情是你需要了解的。一般来说，你可以先通过电话确定一下他的工作经历，项目经历和技术技能，然后，如果他和你需要的人条件相符的话，可以叫到公司做面对面的面试。千万不要把别人叫来，你又说你的经历和我们的工作有差距之类的话。（我有过一次面试经历，公司我不说了，反正是那个号称需要有良好沟通的公司，面试了我9次左右，从一般的程序员，PM，经理，到总经理，而最后一次直接告诉我，我以前的经历和他们的要求差距很大。我不禁要问了，前面若干次的面试他们都在干什么呢？）
二、面试开场。其次，把人邀请来公司面试，应聘者到了公司来面试，有一点很重要，那就是你一定要让整个面试过程变得很随意，很放松，就像普通的聊天和一般朋友间的交流一样。这样应聘者才会放松并拿出真实的样子来和你谈话和聊天，你才能在很短的时间内了解得更多。让应聘者放下心理负担，让其表现得自然一些，这是招聘方的责任。千万不要说，别人太紧张发挥的不好，有时候，招聘方得想想自己的问题。
面试开场的时候，千万不要让应聘者介绍自己，因为，应聘者早就给你发过简历了，而你也给其打过电话了。另外，应聘者对这个面试惯例通常都会准备得非常不错的，另一方面，这会让整个面试过程太正式太严肃了。所以，不妨问问应聘者是怎么过来的？最近怎么样？还可以和应聘者谈一个大众话题，比如喜欢什么体育，音乐，电影，社会热点什么的，自己也别板着个脸，说说笑笑，试图让大家都放松下来。另外，通过这些闲聊，你可以知道他/她的与人交往能力和一些性格。另外，不要让桌子放在你和应聘者之间，把环境搞得随意一些。
三、多让应聘者说说他的经历。接下来，如果你要觉得这个应聘者是否是一个可以解决问题，是一个可以把事情搞定的人，不用问他/她会做什么，直接问问其做过什么？干过什么事？对于一个好的程序员来说，很难想像其没有相关的实践，就算你是在大学里，你也应该做过什么。如果你有解决问题的能力，那么，很显然，今天你应该解决了很多问题，也搞定了很多事情，听听应聘者说一说他的那些事。（不要使用一问一答这种方式，应该让应聘者多说，而多听，多想）
在他讲他的项目的时候，通常来说你要注意下面几点：
- 沟通表达能力。应聘者能不能把一个事情讲清楚。如果这个人聪明的话，他就可以用最简单的语言把一个复杂的事情讲清楚。而且，这是一个好的程序员最基本的能力。而且，你可以在应聘者一边描述其经历的时候，你可以和应聘者有一些的良好的来来回回的交谈，这样就可以知道，他的沟通能力和沟通方式，从而了解他的性格，。
- 角色和位置。也许他参与了一个很大的项目，但只是做了一个很简单的模块。所以，了解其在项目中的担任的角色和位置是非常必要的。当应聘者说到“我们”或者“大家”之类的词汇时，一定要向下细化和明确。
- 做出的贡献和解决了什么的问题。这个很重要，通过了解这个，你可以知道面试者是否聪明，是否有能力解决问题，是否有好的技术底子。
- 演示。如果可能，你可以让应聘者展示一些其写过的代码，做过的设计，或是直接给你看看他写的程序的演示。（从设计上，代码的风格，重用性，维护性上你可以了解很多很多）
- 基础知识。了解该项目中应聘者使用的技术的一些基础知识，比如，通过整个过程，你可以问一些网络，语言，面象对象，系统的一些基础知识。基础知识是非常重要的，这直接关系到了他的能力。
- 流程和工具。了解应聘者所熟悉的项目的流程（银弹，瀑布，敏捷，……），还有流程中的一些工件（如：需求文档，设计文档，测试方档等），以及在开发过程中使用的工具（内存测试，代码检查，BUG报告，版本维护，开发调试……）（关于程序员的基本技能，你可以参考——《程序员需要具备的基本技能》）
有人会说，应聘者的经历可以被他自己编出来的，他可以把一些不是他做的事说成是他做的。是的，的确是有这种可能。不过，不要忘了，一个谎言背后需要用更多的谎言来圆谎的，所以，你不必担心这个问题，只要你在应聘者的描述过程中逐步求精，细化问题，你会知道应聘者是否是在编故事的。
千万记住下面几点：
- 谈话风格要随意和自然，不要正式。
- 在了解应聘者以前做过的事的时候，不要太投入了。因为招聘方也是技术人员，所以有时候，招聘者自己会因为应聘者所做的项目中的技术太过迷人而被吸引了。
- 要注意引导应聘人。相信我，应聘的程序员十个人有八个人讲不清楚以前做的是什么。因为他们直接跳过了项目背景和要解决什么样的问题，而直接进入具体实现。
- 不要一问一答，应该多让应聘者说，这样才能多全方位了解一个人。
- 了解一个人的过去，了解一个人做过的事情，比其会做什么更重要。
- 了解一个人的性格，想法，思维和行为，比了解其技术技能更重要。
- 沟通能力，表达能力，语言组织能力，理解能力，等方面的能力，关系到了是否能和别人一起工作。
- 基础知识比知识的点滴要重要得多。你可能不知道其个C++的关键字，但你应该要知道C++的继承和多态。
- 技术技能固然很重要，但比其更重要的是这个人获取知识的能力，学习能力是在计算机这样变化飞快行业中必需具备的。
- 是否可以进行培养，比掌握的技能更重要。
四、实际参与？？这一步可能是很不好实施的。因为，这需要一些应聘者付出一定的时间，如果是毕业生，那没有问题，先让他来实习一段时间。但如果别人有工作，就不好了。也许你会说，这就是试用期的用处了。不过，我个人觉得，你得要尊重应聘者，人家把那边的工作辞了，来你这边工作，三个月试用期间，如果没有什么原则上的问题，你作为一个招聘方又反悔了，这样做很是相当的不好。如果发现这样的事，只能是招聘者自己的问题。
在面试过程中，一些招聘者会让应聘者们一起做个游戏，或是搞个辩论比赛，或是现场组个团队干个简单的事情，有的甚至让应聘者请一天假到自己的公司里来和自己的团队一同工作一天，并要完成某个事情（甚至给其设置上deadline），并通过这些来考量应聘者的实际参与能力。
是的，如果没有一起工作过，没有一些实际的事情发生，单靠几个小时的面试很难了解一个人的。设置上这些面试的环节，在最短的时间内来了解应聘者的一切，对于招聘方来说无可厚非。而且有的时候也能得到不错的效果。在这里，我只提一点，有时候这样的周期拉得很长，让应聘者付出了很多，反尔会让应聘者产生反感和厌烦情绪，从某种意义上来说，这实在是对应聘者的不尊重。
对于这一点，我一直持疑问的态度，所以，我在其后打了两个问号。老实说，对于实际参与这一环节，我个人的意见是适可而止，因为时间太短了，无论你怎么做你都无法了解完整。即然无法了解完整，那就获取你最需要的吧，就是本文开头的那三个问题，以及上面所述的“第三点”（了解应聘者的以往经历）。
也许这个文章中有一些你不同意的观点，没问题，欢迎批评，如果你有更好的做法，我也想听听，不妨在这里留个言，如果不想留也可以email给我。
文章来源：
https://coolshell.cn/articles/1870.html
现附上英文原文：
How I Hire Programmers
by Aaron Swartz
Español
There are three questions you have when you’re hiring a programmer (or anyone, for that matter): Are they smart? Can they get stuff done? Can you work with them? Someone who’s smart but doesn’t get stuff done should be your friend, not your employee. You can talk your problems over with them while they procrastinate on their actual job. Someone who gets stuff done but isn’t smart is inefficient: non-smart people get stuff done by doing it the hard way and working with them is slow and frustrating. Someone you can’t work with, you can’t work with.
The traditional programmer hiring process consists of: a) reading a resume, b) asking some hard questions on the phone, and c) giving them a programming problem in person. I think this is a terrible system for hiring people. You learn very little from a resume and people get real nervous when you ask them tough questions in an interview. Programming isn’t typically a job done under pressure, so seeing how people perform when nervous is pretty useless. And the interview questions usually asked seem chosen just to be cruel. I think I’m a pretty good programmer, but I’ve never passed one of these interviews and I doubt I ever could.
So when I hire people, I just try to answer the three questions. To find out if they can get stuff done, I just ask what they’ve done. If someone can actually get stuff done they should have done so by now. It’s hard to be a good programmer without some previous experience and these days anyone can get some experience by starting or contributing to a free software project. So I just request a code sample and a demo and see whether it looks good. You learn an enormous amount really quickly, because you’re not watching them answer a contrived interview question, you’re seeing their actual production code. Is it concise? clear? elegant? usable? Is it something you’d want in your product?
To find out whether someone’s smart, I just have a casual conversation with them. I do everything I can to take off any pressure off: I meet at a cafe, I make it clear it’s not an interview, I do my best to be casual and friendly. Under no circumstances do I ask them any standard “interview questions” — I just chat with them like I would with someone I met at a party. (If you ask people at parties to name their greatest strengths and weaknesses or to estimate the number of piano tuners in Chicago, you’ve got bigger problems.) I think it’s pretty easy to tell whether someone’s smart in casual conversation. I constantly make judgments about whether people I meet are smart, just like I constantly make judgments about whether people I see are attractive.
But if I had to write down what it is that makes someone seem smart, I’d emphasize three things. First, do they know stuff? Ask them what they’ve been thinking about and probe them about it. Do they seem to understand it in detail? Can they explain it clearly? (Clear explanations are a sign of genuine understanding.) Do they know stuff about the subject that you don’t?
Second, are they curious? Do they reciprocate by asking questions about you? Are they genuinely interested or just being polite? Do they ask follow-up questions about what you’re saying? Do their questions make you think?
Third, do they learn? At some point in the conversation, you’ll probably be explaining something to them. Do they actually understand it or do they just nod and smile? There are people who know stuff about some small area but aren’t curious about others. And there are people who are curious but don’t learn, they ask lots of questions but don’t really listen. You want someone who does all three.
Finally, I figure out whether I can work with someone just by hanging out with them for a bit. Many brilliant people can seem delightful in a one-hour conversation, but their eccentricities become grating after a couple hours. So after you’re done chatting, invite them along for a meal with the rest of the team or a game at the office. Again, keep things as casual as possible. The point is just to see whether they get on your nerves.
If all that looks good and I’m ready to hire someone, there’s a final sanity check to make sure I haven’t been fooled somehow: I ask them to do part of the job. Usually this means picking some fairly separable piece we need and asking them to write it. (If you really insist on seeing someone working under pressure, give them a deadline.) If necessary, you can offer to pay them for the work, but I find most programmers don’t mind being given a small task like this as long as they can open source the work when they’re done. This test doesn’t work on its own, but if someone’s passed the first three parts, it should be enough to prove they didn’t trick you, they can actually do the work.
(I’ve known some people who say “OK, well why don’t we try hiring you for a month and see how it goes.” This doesn’t seem to work. If you can’t make up your mind after a small project you also can’t make it up after a month and you end up hiring people who aren’t good enough. Better to just say no and err on the side of getting better people.)
I’m fairly happy with this method. When I’ve skipped parts, I’ve ended up with bad hires who eventually had to be let go. But when I’ve followed it, I’ve ended up with people I like so much so that I actually feel bad I don’t get to work with them anymore. I’m amazed that so many companies use such silly hiring methods instead.
文章来源：
http://www.aaronsw.com/weblog/hiring