突击面试指南-3.0

A motley gang of anarchists, free-love advocates, and banana-rights agitators have hijacked The Love Boat out of Puerto Vallarta and are threatening to sink it in 7 days with all 616 passengers and 327 crew members unless their demands are met. The demand? A million dollars in small unmarked bills, and a GPL implementation of WATFIV, that is, the esteemed Waterloo Fortran IV compiler. (It’s surprising how few things the free-love people can find to agree on with the banana-rights people.)

一群混杂着无政府主义，大爱无疆主义，以及香蕉权利至上分子的黑帮在巴亚而港外劫持了爱心号邮轮， 并且威胁说如果他们的要求在7天内得不到满足的话就会炸沉邮轮杀死船上327名船员。 他们的要求？ 一百万现金，小额且不能带任何标记；还有一个GPL版的WATFIV，对就是赫赫有名的滑铁卢FortranIV编译器。（你可以想象要大爱无疆主义者和香蕉权利至上的人达成一致得有多难）

As chief programmer of the Festival Cruise programming staff, you’ve got to decide if you can deliver a Fortran compiler from scratch in seven days. You’ve got a staff of two programmers to help you.

作为四季漫游编程组的首席程序员，你必须得决定你是不是能在接下来的7天里从零开始写个Fotran编译器。 你有两个组员来帮你。

Can you do it?

你能做到么？

“Well, I suppose, it depends,” you say. One of the benefits of writing this article is that I get to put words into your mouth and you can’t do a darn thing about it.

“嗯，我觉得，这要看情况”，你说. 写这篇文章的一大好处就是我能这样把这些话塞进你嘴里，而你也没办法。

On what?

“看什么？”

“Um, will my team be able to use UML-generating tools?”

“嗯，我的团队能用UML生成工具么？”

Does that really matter? Three programmers, seven days, Waterloo Fortran IV. Are UML tools going to make or break it?

这有关系么？三个程序员，七天，滑铁卢FortranIV。UML会起决定作用？

“I guess not.”

“也不是”

OK, so, what does it depend on?

好吧，那取决于什么呢？

“Will we have 19 inch monitors? And will we have access to all the Jolt we can drink?”

“我们能有19英寸的显示器么？还有，我们能喝柜子里的所有饮料么？

Again, does this matter? Is caffeine going to determine whether you can do it?

再次声明，这有关系么？咖啡因能决定你是否能做出来么？

“I guess not. Oh, wait. You said I have a staff of two programmers?”

“那也不是。哦等等，你说我有两个组员？”

Right.

是的

“Who are they?”

“他们是谁？”

Does that matter?

这有关系么？

“Sure! If the team doesn’t get along, we’ll never be able to work together. And I know a few superstar programmers who could crank out a Fortran compiler by themselves in one week, and lots of programmers who couldn’t write the code to print the startup banner if they had six months.”

“当然有关系！如果整个团队合不来，我们永远没法合作。 而且我知道有一些超级巨星程序员能够在一个礼拜自己搞出一个Fortran编译器来， 而无数的程序员哪怕你给他6个月，他连个文章抬头都打不出来。”

Now we’re on to something!

Everybody gives lip service to the idea that people are the most important part of a software project, but nobody is quite sure what you can do about it. The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmersare, and this is usually done in the interview process. So this chapter is all about interviewing.

这下我们谈到点子上去了！

所有的人都愿意动动嘴来赞成人是软件项目中最重要的部分，但是没人清楚应该要为此做点儿什么。 而如果你想做点儿正确的事情来雇几个好的程序员的话首先就要招对人， 也就是说你得搞清楚正确人选是什么样子的， 而这通常要经过面试来达成。 所以这篇文章就是讲面试。

(The in-person interview is just one part of the hiring process, which starts with sorting resumes and a phone screen. This article only covers in-person interviews.)

You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate (that is, other programmers, not managers). You know the kind of company that just has some salty old manager interview each candidate, and that decision is the only one that matters? These companies don’t have very good people working there. It’s too easy to fake out one interview, especially when a non-programmer interviews a programmer.

（现场面试只是招聘的一个部分，整个过程从筛选简历开始然后电话面试。 这篇文章只谈论现场面试部分）

首先要确保每一个被雇佣的人都至少被6个人面试过， 然后至少5个人愿意跟这哥们出去喝一杯（这些人都得是程序员而不是程序经理）。 你知道有些公司只有一些老东西经理来面试每个候选人，而他的决定就真的那么重要么？ 这样的公司不会有非常好的员工。 太容易混过仅一场面试了， 特别是当非程序员面试程序员的时候。

If even two of the six interviewers thinks that a person is not worth hiring, don’t hire them. That means you can technically end the “day” of interviews after the first two if the candidate is not going to be hired, which is not a bad idea, but to avoid cruelty you may not want to tell the candidate in advance how many people will be interviewing them. I have heard of companies that allow any interviewer to reject a candidate. This strikes me as a little bit too aggressive; I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn’t like them.

哪怕6个人中只有两个人觉得这个人不值得录取，那就不能录取。 这也就意味着如果在一天的面试中已经有两个面试官觉得这个人不该录取的话，面试就该结束了。这主意不坏，但是为了免得显得对候选人那么残忍就不要事先告诉他要进行几轮面试了。 我曾经听说过有的公司允许任何一个面试官拒绝掉候选人。 我觉得很惊讶因为有点过了； 我大概最多能允许一个资深的面试官拒绝候选人而不会因为一些初级的面试官不喜欢候选人而拒绝他们。

Don’t try to interview a bunch of people at the same time. It’s just not fair. Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard. I can tell you from extensive experience that if you spend less than one hour on an interview you’re not going to be able to make a decision.

不要尝试同时面试一堆人。 这不公平。 每一场面试都应该包含一个面试官和一个候选人， 面试应该在一个封闭的有白板的房间内进行。 我可以以我丰富的经验告诉你如果你在面试上只花了一个小时你不可能做出一个合理的决定。

You’re going to see three types of people in your interviews. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions. At the other extreme you’ve got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever.

你在面试的时候会看见三类人。 一个极端， 没挑选好的那堆， 缺乏对这份工作最基本的技能要求。 他们很容易被揪出剔除掉， 或者就问两三个简单的问题。 另一个极端就是你遇到了那种超级巨星，会在周末的时候在NDS上写lisp编译器消遣。 中间的部分就是那种“大概”类型的看起来能做点儿什么的。 技巧就在于区分那些超级巨星和大概类型的， 因为秘诀就在于你永远不要雇那些“大概”能做点儿什么的，永远不要。

At the end of the interview, you must be prepared to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire. There is no other possible answer.Never say, “Hire, but not for my team.” This is rude and implies that the candidate is not smart enough to work with you, but maybe he’s smart enough for those losers over in that other team. If you find yourself tempted to say “Hire, but not in my team,” simply translate that mechanically to “No Hire” and you’ll be OK. Even if you have a candidate that would be brilliant at doing your particular task, but wouldn’t be very good in another team, that’s a No Hire. In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic,No Hire. You’ll solve some short term pain in exchange for a lot of long term pain.

在面试的最后，你必须准备对候选人做一个尖刻的决定。 只有两种可能的结果：录取和拒绝。 不可能有其他的结果。 永远不要说，“录取吧，但别给我的团队”。 这很无礼，像是在说候选人不够好所以不能和我一起工作但是可以和其他组的那些卢瑟们混混。 如果你发现你想要说“录取吧，但别在我的团队”的时候，简单将其翻译成“拒绝”即可。 哪怕你的候选人对于你的特定的任务完成十分出色但是无法完成其他团队的任务的时候，也是“拒绝”。 在软件行业，事情变化的是如此之快和频繁，你需要的人员需要能够完成你扔给他们的任何任务。 如果出于某种特殊的原因你找到了一个蠢学究，他真的很擅长SQL ，但是似乎完全不能学习其他事情， “拒绝” 你以短时间内短时间的痛苦交换了未来长时间的痛苦。

Never say “Maybe, I can’t tell.” If you can’t tell, that means No Hire. It’s really easier than you’d think. Can’t tell? Just say no! If you are on the fence, that means No Hire. Never say, “Well, Hire, I guess, but I’m a little bit concerned about…” That’s a No Hire as well. Mechanically translate all the waffling to “no” and you’ll be all right.

永远不要说“也许，我不知道”。 如果你没法分辨，那就意味着“拒绝”。 实际上比你想的要简单，不是么？ 只要说不要！ 如果你觉得在边界上，那意味着“拒绝”。 永远不要说，“好吧，录取，但是，我还是有点儿担心…” 这也是“拒绝”。 机械地把所有的胡扯翻译成“不”那就可以了。

Why am I so hardnosed about this? It’s because it is much, muchbetter to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees. And they might be bad programmers but really nice people or maybe they really need this job, so you can’t bear to fire them, or you can’t fire them without pissing everybody off, or whatever. It’s just a bad scene.

为什么我对此如此强硬？ 因为拒绝掉一个好的候选人要比招进来一个错误的人选要好的多。 一个错误的候选人会花掉很多钱，并且还要花费其他人的时间精力来修复他们造成的错误。 要解雇那些你错误地雇进来的人会花费几个月而且会跟噩梦般困难， 特别是他们决定提起诉讼的时候。 在有些情况下你根本不可能解雇一些人。 坏的雇员还会影响好的雇员的士气。 也许他们只是差的程序员但可能是个好人，或者他们真的很需要这份工作， 所以你没法下手解雇他们， 或者如果你非解雇他会惹怒所有人， 或者随便其他理由， 反正是个坏例子。

On the other hand, if you reject a good candidate, I mean, I guess in some existential sense an injustice has been done, but, hey, if they’re so smart, don’t worry, they’ll get lots of good job offers. Don’t be afraid that you’re going to reject too many people and you won’t be able to find anyone to hire. During the interview, it’s not your problem. Of course, it’s important to seek out good candidates. But once you’re actually interviewing someone, pretend that you’ve got 900 more people lined up outside the door. Don’t lower your standards no matter how hard it seems to find those great candidates.

另一方面，如果你拒绝掉一个好的候选人， 我是说， 我猜你会觉得存在某人受到了不公正对待这样的事情， 但是，如果他们真的那么聪明的话，别担心，他们会拿到一堆好的工作要约的。 别担心你们会拒绝掉太多的人然后雇不到人。 在面试的时候这不是你的问题。 当然找到好的候选人很重要。 但是当你真正在面试某个人的时候，装作门外面排着900个人吧。 不要因为找到好的候选人十分困难而降低你的标准。

OK, I didn’t tell you the most important part—how do you know whether to hire someone?

In principle, it’s simple. You’re looking for people who are

1 . Smart, and

2 . Get things done.

好吧，我还没告诉你最重要的部分 – 如何决定是否录取某人？

原则上，这很简单，你要找的人要：

1 .聪明

2 .能办事

That’s it. That’s all you’re looking for. Memorize that. Recite it to yourself before you go to bed every night. You don’t have enough time to figure out much more in a short interview, so don’t waste time trying to figure out whether the candidate might be pleasant to be stuck in an airport with, or whether they really know ATL and COM programming or if they’re just faking it.

就这样，这就是你要找的。 记住，每天晚上上床之前背诵。 你没办法在一个简短的面试过程中获得更多的信息了， 所以不要浪费时间去考虑候选人被困在机场的时候会不会很不高兴，或者他们是不是真的懂ATL/COM编程 还是他们只是装作他们懂。

People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say, “Spreadsheets are really just a special case of programming language,” and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful. The other way to identify these people is that they have a tendency to show up at your office, coffee mug in hand, and try to start a long conversation about the relative merits of Java introspection vs. COM type libraries, on the day you are trying to ship a beta.

聪明但是不能做事的人通常会有博士学历，或者在大公司呆过但是没人愿意听他们的因为他们太不实际了。 他们更愿意在问题上慢慢的学术的磨也不愿意准时递交问题的解决方案。 这种人很容易识别，因为他们很喜欢指出两个差别很大的概念的相似之处。 例如，他们会说， “电子表单其实是编程语言的特殊形式”， 然后他们会花一个礼拜去写个吓人的聪明的白皮书阐述电子表单作为编程语言的理论上的计算机语言特性。 聪明，但是没用。 识别这些人的另一个办法就是，这些人会更倾向于端着咖啡在你的办公室出现，然后尝试跟你讨论Java反射和COM类库的相对优劣点， 就在你准备发布一个BETA版本的那天。

People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time. They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood, and instead of simple loops adding up items in an array you’ve got an AdderVistior class (yes, it’s spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more.

那些能做事但不够聪明的人会做愚蠢的不经过思考的事情，而其他人则得稍后清理他们留下来的这团糟。这样他们就成了公司的负资产，因为他们不仅会失败而且他们会消耗别人的时间。他们就是那种决定要用Visitor模式来重构你的核心算法的那种人，他们不过是隔夜读到了这种模式而且完全错误的理解了这个模式，然后你就得到了一个AdderVistior类而不是简单的循环相加（是的，连拼都拼错了） 一个VisitationArrangingOfficer单例，然后你所有代码就都不能正常工作了。

How do you detect smart in an interview? The first good sign is that you don’t have to explain things over and over again. The conversation just flows. Often, the candidate says something that shows real insight, or brains, or mental acuity. So an important part of the interview is creating a situation where someone can show you how smart they are. The worst kind of interviewer is the blowhard. That’s the kind who blabs the whole time and barely leaves the candidate time to say, “yes, that’s so true, I couldn’t agree with you more.” Blowhards hire everyone; they think that the candidate must be smart because “he thinks so much like me!”

你在面试中怎么判断一个人是否聪明呢？第一点就是你不需要反反复复的解释某个概念。交流会很顺畅。 通常候选人展露出他们的智力，见地和敏锐。 所以面试的一个重要部分就是创造一个这样的氛围让候选人展示他们的聪明才智。 最差的面试官就是那种吹牛大王。 就是那种整段时间都自己乱吹候选人几乎无话可说，只能说“是的，如此正确，非常同意”。 吹牛大王会雇任何人； 他们认为候选人聪明只有一点“他跟我想法如此一致！”

The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means “knows a lot of facts.” They just ask a bunch of trivia questions about programming and give points for correct answers. Just for fun, here is the worst interview question on Earth: “What’s the difference between varchar and varchar2 in Oracle 8i?” This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of trivia and people that you want to hire. Who cares what the difference is? You can find out online in about fifteen seconds! Remember, smart does not mean “knows the answer to trivia questions.” Anyway, software teams want to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it’s better to hire people that are going to be able to learn any new technology rather than people who happen to know how to make JDBC talk to a MySQL database right this minute.

第二差的面试官是那中猜谜秀面试官。 这种人聪明的标准就是“知道很多概念” 他们会问很多关于编程的无关紧要的东西，然后按这些问题给分。 开个玩笑，世界上最糟糕的面试问题大概就是：Oracle8i里varchar和varchar2有什么区别？ 真是可怕的问题。 知道这个无关紧要的问题的答案的人和你想要录取的人之间没有任何存在的或可以想象的正相关性。有谁会关心有什么区别？随便在网上一搜你15秒就能找到问题的答案！ 记住，聪明绝对不是说知道这种无关紧要问题的答案。 不管怎么说要知道软件团队要雇的是有能力的人，而不是有什么特定技能的人。 任何人携带的技术技能都会在接下来的一两年里被淘汰掉。所以最好是录取那些能够学习新技术的人而不是录取那些刚好就知道如何使用JDBC链接MYSQL数据库的人。

But in general, the way to learn the most about a person is to let them do the talking. Give them open-ended questions and problems.

So, what do you ask?

My personal list of interview questions originates from my first job at Microsoft. There are actually hundreds of famous Microsoft interview questions. Everybody has a set of questions that they really like. You, too, will develop a particular set of questions and a personal interviewing style which helps you make the Hire/No Hire decision. Here are some techniques that I have used that have been successful.

但是总而言之，了解一个人的最好的方式就是听他们说。 给他们开放式的问题。

那么，你要问什么呢？

我个人的面试问题列表源于我在微软的第一份工作。 实际上有上百套著名的微软面试题。 每个人都有一套他自己最喜欢的面试题集。 你，同样也会开发出一套个人的面试题集系列来帮助你做录取/拒绝的决定。 下面是我个人采用的比较成功的方式：

Before the interview, I read over the candidates resume and jot down an interview plan on a scrap of paper. That’s just a list of questions that I want to ask. Here’s a typical plan for interviewing a programmer:

1 . Introduction

2 . Question about recent project candidate worked on

3 . Easy Programming Question

4 . Pointer/Recursion Question

5 . Are you satisfied?

6 . Do you have any questions?

在面试之前， 我会翻阅候选人简历然后在一张纸上抄下面试计划。 记下我要问的问题。 下面就是一个典型的面试程序员的计划：

1 . 自我介绍

2 . 问些候选人最近工作的项目

3 . 简单的编程问题

4 . 指针/递归问题

5 . 满意了么？

6 . 你有其他问题么？

I am very, very careful to avoid anything that might give me some preconceived notions about the candidate. If you think that someone is smart before they even walk into the room, just because they have a Ph.D. from MIT, then nothing they can say in one hour is going to overcome that initial prejudice. If you think they are a bozo because they went to community college, nothing they can say will overcome that initial impression. An interview is like a very, very delicate scale—it’s very hard to judge someone based on a one hour interview and it may seem like a very close call. But if you know a little bit about the candidate beforehand, it’s like a big weight on one side of the scale, and the interview is useless. Once, right before an interview, a recruiter came into my office. “You’re going to love this guy,” she said. Boy did this make me mad. What I should have said was, “Well, if you’re so sure I’m going to love him, why don’t you just hire him instead of wasting my time going through this interview.” But I was young and naïve, so I interviewed him. When he said not-so-smart things, I thought to myself, “gee, must be the exception that proves the rule.” I looked at everything he said through rose-colored glasses. I wound up saying Hire even though he was a crappy candidate. You know what? Everybody else who interviewed him said No Hire. So: don’t listen to recruiters; don’t ask around about the person before you interview them; and never, ever talk to the other interviewers about the candidate until you’ve both made your decisions independently. That’s the scientific method.

我非常非常小心的避免任何会给我带来关于对面试者偏见的概念。 如果在面试之前你就因为某个人有MIT的博士学位而觉得他很聪明，那么不管他在面试的一个小时里说什么都很难改变你的这种第一印象。如果你因为候选人上的是社区大学就觉得他们是草包，那么在接下来的一个小时里不管他们说什么也很难改变你的这种第一印象。 面试是非常非常精细的一面 – 很难基于一个小时的结果评价某个人，它很像是靠的很近的一通电话。 但是如果你事先了解一下候选人的话， 就好象这精巧一面的大部分都被定下来了， 面试就变的很无用了。 有一次，就在面试之前， 一个招录官走进我的办公室。 “你会很喜欢这家伙的”，她说。 这小伙子实在太招人喜欢了。 我应该跟她说，“恩，如果你那么确定我会喜欢他的话，你为什么不直接录取他？反而浪费我的时间面试他呢。” 但当时我很傻很天真， 所以我就面试了他。 当他说一些不那么聪明的事情的时候，我就会对自己说，“天，肯定是个特例”。 我戴上有色眼镜审视它说的所有的话。 虽然我觉得他很挫，我最后还是同意录取他。 你猜怎么着？ 其他所有面试过的人都说不能录取。 所以不要听招录官的； 绝对不要和其他人讨论候选人除非你们都已经各自做出了评判。 这才是科学方法。

The introduction phase of the interview is intended to put the candidate at ease. I ask them if they had a nice flight. I spend about 30 seconds telling the person who I am and how the interview will work. I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.

面试的自我介绍阶段是为了让候选人放松。 我会问它们飞行是不是愉快。 我会花大概30秒钟跟他介绍我是谁，面试过程大概是什么样子的。 我会向候选人强调我们感兴趣他们是如何解决问题的，而不是仅仅关心答案。

Part two is a question about some recent project that the candidate worked on. For interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed. For example, sometimes I will ask, “what class did you take last semester that you liked the most? It doesn’t have to be computer-related.” When interviewing experienced candidates, you can talk about their most recent assignment from their previous job.

第二部分是关于候选人最近工作的项目的一些问题。 如果面试应届生，如果可以的话，问些关于他们毕业论文的问题，或者是一个包含一个他们参与的很长的项目他们又很喜欢的课程。 例如，我会问，“上学期你参加的最喜欢的课程是什么？不一定要是一定计算机相关的” 当面试有经验的候选人的时候， 你可以问问他们上一份工作最近的一项任务。

Again, ask open-ended questions and sit back and listen, with only the occasional “tell me more about that” if they seem to stall.

再次强调， 问一个开放的问题然后坐着听，然后如果他们冷场的话，偶尔的问一句“跟我说说那个吧”。

What should you look for during the open ended questions?

在开放问题的阶段应该要寻找什么呢？

One: Look for passion. Smart people are passionate about the projects they work on. They get very excited talking about the subject. They talk quickly, and get animated. Being passionately negative can be just as good a sign. “My last boss wanted to do everything on VAX computers because it was all he understood. What a dope!” There are far too many people around that can work on something and not really care one way or the other. It’s hard to get people like this motivated about anything.

第一点： 寻找热情。 聪明人会对他们的项目充满热情。 他们讨论起这些的时候会很激动。 他们会说的很快， 甚至手舞足蹈。 很激动乃至负面也是一个好的标志。 “我的上一个老板想在VAX电脑上实现所有的东西，因为那就是他唯一知道的东西。 纯傻逼！” 周围实在有太多的人能工作在一件他们并不太在乎这样或那样的事情上。 很难鼓舞这样的人。

Bad candidates just don’t care and will not get enthusiastic at all during the interview. A really good sign that a candidate is passionate about something is that when they are talking about it, they will forget for a moment that they are in an interview. Sometimes a candidate comes in who is very nervous about being in an interview situation—this is normal, of course, and I always ignore it. But then when you get them talking about Computational Monochromatic Art they will get extremely excited and lose all signs of nervousness. Good. I like passionate people who really care. (To see an example of Computational Monochromatic Art try unplugging your monitor.) You can challenge them on something (try it—wait for them to say something that’s probably true and say “that couldn’t be true”) and they will defend themselves, even if they were sweating five minutes ago, because they care so much they forget that you are going to be making Major Decisions About Their Life soon.

差的候选人在面试的过程中不会在乎而且根本不会热情。 候选人热心于一样事情的时候的标志就是当他们在谈论关于这个东西的时候他们会忘了他们是在面试中。 有时候候选人会很紧张， 这当然很正常， 我通常会忽视这一点。 但是当你和他们讨论ASCII绘画艺术的时候，他们就会变得十分激动，然后完全没有紧张的表情。 我很喜欢在乎某样东西的激情的人。 （要看计算机黑白艺术画，请拔掉你的显示器） 你可以尝试在某件事情上挑战他们（ 尝试一下 – 然后等他们说某样东西可能是正确的，然后你说“那不可能”） 然后他们就会为自己辩护， 哪怕他们五分钟前还在流汗， 但是因为他们太在乎这个东西了乃至于他们忘记了你接下来会作改变他们一生的决定 。

Two: Good candidates are careful to explain things well, at whatever level. I have rejected candidates because when they talked about their previous project, they couldn’t explain it in terms that a normal person could understand. Often CS majors will just assume that everyone knows what Bates Theorem is or what O(log n) means. If they start doing this, stop them for a minute and say, “could you do me a favor, just for the sake of the exercise, could you please explain this in terms my grandmother could understand.” At this point many people will stillcontinue to use jargon and will completely fail to make themselves understood. Gong! You don’t want to hire them, basically, because they are not smart enough to comprehend what it takes to make other people understand their ideas.

第二点： 好的候选人会很仔细的把事情解释清楚， 不管到某种程度。 我曾经拒绝过这样的候选人因为他们在讨论他们之前的项目时，他们没办法用正常人能理解的术语讲清楚。 通常计算机专业的人会假定所有的人都懂贝叶斯定理或者O(logn)是什么意思。 如果他们开始这样，那么打断他们然后说“能帮个忙， 作为练习， 你能用我奶奶能听懂的语言描述这个么？”。 到这个点上还是会有很多人继续使用术语，然后完全不能讲清楚他们在说什么。 完了！你不会想录取他们的，基本上是因为他们不够聪明来让其他人明白他们自己的想法。

Three: If the project was a team project, look for signs that they took a leadership role. A candidate might say, “We were working on X, but the boss said Y and the client said Z.” I’ll ask, “So what did you do?” A good answer to this might be “I got together with the other members of the team and wrote a proposal…” A bad answer might be, “Well, there was nothing I could do. It was an impossible situation.” Remember, Smart and Gets Things Done. The only way you’re going to be able to tell if somebody Gets Things Done is to see if historically they have tended to get things done in the past. In fact, you can even ask them directly to give you an example from their recent past when they took a leadership role and got something done—overcoming some institutional inertia, for example.

第三点：如果项目是个团队项目，那么寻找他担任过团队领袖角色的迹象。 候选人可能会说， “我们做的是X，但是老板说的是Y，客户说的是Z”。 我就会问：“那么你做了什么呢？” 一个好的回答也许是“我把团队里的其他人集中起来写了个项目建议…” 一个差的回答也许是“嗯，我没什么能干的啊。 这就是个不可能的场景。” 记住， 聪明和能办事也意味着他们在过去的经历中有这种能办事的经验。 实际上，你甚至可以直接问他们在过去的项目经验中承担团队领袖角色的例子，例如：克服了一些公司制度然后把事情办成的例子。

Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.

当然面试的大多数时间还是应在让候选人证明他们能写代码上。

Reassure candidates that you understand that it’s hard to write code without an editor, and you will forgive them if the whiteboard gets really messy. Also you understand that it’s hard to write bug-free code without a compiler, and you will take that into account.

跟候选人说明你知道没有编辑器写代码很困难，所以如果白板变得很乱的话你是会理解的；告诉他们你知道没有编译器要写出没有错误的代码还是很困难的，你会把这些考虑进去。

For the first interview of the day, I’ve started including a really, really easy programming problem. I had to start doing this during the dotcom boom when a lot of people who thought HTML was “programming” started showing up for interviews, and I needed a way to avoid wasting too much time with them. It’s the kind of problem that any programmer working today should be able to solve in about one minute. Some examples:

面试当天的头一个问题，我通常会给一个非常非常容易的编程问题。 我开始这么做的时候是互联网泡沫鼎盛的时候，当时有一堆觉得会写HTML也算会编程的人开始出现在面试中， 我需要这样一种途径避免浪费太多时间在他们身上。 这就是那种今天任何工作过的程序员能够在一分钟内写出来的程序。 例如：

1 . Write a function that determines if a string starts with an upper-case letter A-Z

2 . Write a function that determines the area of a circle given the radius

3 . Add up all the values in an array

1 . 编写一个函数来确定一个字符串是否以大写字母A-Z打头

2 . 编写一个函数来确定给定圆半径的圆的面积

3 . 把数组里所有元素的值相加

These softball questions seem too easy, so when I first started asking them, I had to admit that I really expected everyone to sail right through them. What I discovered was that everybody solved the problem, but there was a lot of variation in how long it took them to solve.

这些垒球问题看起来很容易， 所以当我开始问他们这些问题的时候，我得承认的我的期望是他们必须顺利的做出这些问题。 我发现几乎所有的人都解决了这些问题， 但是解决这些问题花的时间他们却各不相同。

That reminded me of why I couldn’t trade bonds for a living.

这让我想起了我为什么不能干销售债券这行。

Jared is a bond trader. He is always telling me about interesting deals that he did. There’s this thing called an option, and there are puts, and calls, and the market steepens, so you put on steepeners, and it’s all very confusing, but the weird thing is that I know what all the words mean, I know exactly what a put is (the right, but not the responsibility, to sell something at a certain price) and in only three minutes I can figure out what should happen if you own a put and the market goes up, but I need the full three minutes to figure it out, and when he’s telling me a more complicated story, where the puts are just the first bit, there are lots of other bits to the story, I lose track very quickly, because I’m lost in thought (“let’s see, market goes up, that mean interest rates go down, and now, a put is the right to sell something…”) until he gets out the graph paper and starts walking me through it, and my eyes glazeth over and it’s very sad. Even though I understand all the little bits, I can’t understand them fast enough to get the big picture.

杰拉德是个债券交易员。 他总是会告诉我一些他做过的有意思的交易。 有一种东西叫做期权， 有看空期权，看长期权。 当市场走高的时候，你就赌那些看涨的，很让人费解， 但是奇怪的是我却明白所有字的意思， 我知道看空期权具体是什么（ 是一种权利， 但是不是义务， 以某一个价格卖出一样东西） 只需要三分钟我就能明白如果你有看空期权而市场上涨的时候意味着什么， 但我需要整整三分钟，并且当他告诉我一些更复杂的故事的时候， 看空期权只是最基础的一部分， 还有很多其他方面的东西， 我很快就跟不上了因为我陷入了思考之中（ 让我看看，市场价上涨， 利率下跌，然后现在，看空期权是卖出某样东西…”）知道他拿出图画纸然后开始跟我解释这些，我的眼睛呆住了，很悲哀。 虽然我明白所有的这些基础， 但是我不能很快的理解这些基础来获得更高层的场景。

And the same thing happens in programming. If the basic concepts aren’t so easy that you don’t even have to think about them, you’re not going to get the big concepts.

同样的事情在编程里也发生。 如果那些基础概念对你来讲不是那种不需要思考就能理解的话，那么你不可能理解高层次的概念。

Serge Lang, a math professor at Yale, used to give his Calculus students a fairly simple algebra problem on the first day of classes, one which almost everyone could solve, but some of them solved it as quickly as they could write while others took a while, and Professor Lang claimed that all of the students who solved the problem as quickly as they could write would get an A in the Calculus course, and all the others wouldn’t. The speed with which they solved a simple algebra problem was as good a predictor of the final grade in Calculus as a whole semester of homework, tests, midterms, and a final.

耶鲁的数学教授SergeLang以前会在他教授的微积分的第一堂课上给他的学生出一道简单的代数题， 就是那种几乎所有的人都会解，但是有些人能在最短的时间内做出来，而有的人则要花一段时间， 然后Lang教授声称那些以最快速度解出来的学生会在这个课程得到A，而其他人则不会。 他们解简单代数题的速度是对他们最后微积分成绩（包括一学期的作业，测试，期中，期末考试）的很好预判。

You see, if you can’t whiz through the easy stuff at 100 m.p.h., you’re never gonna get the advanced stuff.

你明白了吧，如果你不能以100码的速度冲刺过简单的东西，那么你永远也解决不了那些高级的东西。

But like I said, the good programmers stand up, write the answer on the board, sometimes adding a clever fillip (Ooh! Unicode compliant! Nice!), and it takes thirty seconds, and now I have to decide if they’re really good, so I bring out the big guns: recursion and pointers.

不过就像我说的，那些好的程序员会站起来，在白板上写下答案， 有时候还会机智的添上一笔（哦，兼容Unicode！好！）， 总共花费30秒， 然后我就得判断他们是不是真的那么好， 所以这时我才会掏出我的真家伙：递归和指针。

15 years of experience interviewing programmers has convinced me that the best programmers all have an easy aptitude for dealing with multiple levels of abstraction simultaneously. In programming, that means specifically that they have no problem with recursion (which involves holding in your head multiple levels of the call stack at the same time) or complex pointer-based algorithms (where the address of an object is sort of like an abstract representation of the object itself).

15年的面试经验已经让我明白了程序员都能很好的处理不同程度的抽象关系。 就编程而言这就意味着递归对他们来说也没有问题（这关系到要在你的头脑里同时保持调用堆栈的不同层次）或者是复杂的基于指针的算法（对象的地址就像对象本身的抽象表示一样）。

I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly,they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched.For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.

我意识到在C里面理解指针不是一种技能更像是一种能力倾向。 在计算机科学一年级的课程里， 学期开始的时候有大学200个孩子， 所有人在4岁的时候都能在他们的电脑上用BASIC写复杂的冒险游戏。 他们在大学里有大把时间学C或者PASCAL。 直到有一天教授介绍了指针，然后突然他们就不明白了，他们就什么都不明白了。 课上90%的学生转专业去了政治学专业， 然后他们告诉身边的朋友说计算机科学专业成绩不是同性别中足够好的，所以他们转了专业。 出于某种原因，大多数人似乎出生的时候就没有能处理好指针的那部分大脑。 指针需要一种复杂的双层间接性，因此有些人就学不来，而这部分对于编程又是至关重要的。很多的通过拷贝JavaScript代码到他们网页上来学编程的“脚本乔克斯”会转而去学Perl而从来不会去学习指针， 这些人基本不可能写出你要的那种质量的代码。

That’s the source of all these famous interview questions you hear about, like “reversing a linked list” or “detect loops in a tree structure.”

这就是你听到的那些著名的面试问题的来源， 例如“反转单链表” 或者 “检测树结构里的环路”。

Sadly, despite the fact that I think that all good programmers should be able to handle recursion and pointers, and that this is an excellent way to tell if someone is a good programmer, the truth is that these days, programming languages have almost completely made that specific art unnecessary. Whereas ten years ago it was rare for a computer science student to get through college without learning recursion and functional programming in one class and C or Pascal with data structures in another class, today it’s possible in many otherwise reputable schools to coast by on Java alone.

很可悲的是，虽然我认为好的程序员必须具备处理递归和指针的能力， 这也是辨识某人是否确实是好的程序员的一种方法。 事实却是，这些年来，编程语言却把这部分艺术变得完全不是必要的了。 而10年前，计算机科学的学生上完大学却没有上课学到递归和函数式编程和C/PASCAL描述的数据结构，这是很少见的。 而如今很可能知名高校仅仅教授Java。

A lot of programmers that you might interview these days are apt to consider recursion, pointers, and even data structures to be a silly implementation detail which has been abstracted away by today’s many happy programming languages. “When was the last time you had to write a sorting algorithm?” they snicker.

如今你面试的很多程序员都倾向于将递归，指针，甚至数据结构看作是很傻的实现细节，而这些细节现在的流行编程语言已经将其抽象掉了。 “你上次还要自己写个排序算法是什么时候？”他们会暗自发笑。

Still, I don’t really care. I want my ER doctor to understand anatomy, even if all she has to do is put the computerized defibrillator nodes on my chest and push the big red button, and I want programmers to know programming down to the CPU level, even if Ruby on Rails doesread your mind and build a complete Web 2.0 social collaborative networking site for you with three clicks of the mouse.

但，我不管。 我希望的我的急诊医生要理解解剖学，哪怕其实她要做的只是把计算机除颤器节点放到胸部然后按下红色按钮， 我希望程序员理解编程要下到CPU级别， 哪怕RubyOnRails确实能够理解意识，通过点击鼠标按钮三次帮你构建一个Web2.0社会协作站点。

Even though the format of the interview is, superficially, just a candidate writing some code on the whiteboard, my real goal here is to have a conversation about it. “Why did you do it that way?” “What are the performance characteristics of your algorithm?” “What did you forget?” “Where’s your bug?”

虽然面试的形式很流于表面，只不过是让候选人在白板上写下一些代码， 我真实的目标其实是关于这段代码展开一段对话。 “你为什么这样做？” “你算法的性能特性是什么样的？” “你忘记什么了？”“错误在哪儿？”

That means I don’t really mind giving programming problems that are too hard, as long as the candidate has some chance of starting out, and then I’m happy to dole out little hints along the way, little toeholds, so to speak. I might ask someone, say, to project a triangle onto a plane, a typical graphics problem, and I don’t mind helping them with the trig (SOH-CAH-TOA, baby!), and when I ask them how to speed it up, I might drop little hints about look-up tables. Notice that the kinds of hints I’m happy to provide are really just answers to trivia questions—the kinds of things that you find on Google.

也就是说我不会太介意给出非常困难的编程题，只要候选人有机会开始，那么我在此过程中很乐意施舍一些提示，一些基本点，比如说:我会让某人将三角形投影到一个平面， 很典型的图形学问题， 我不介意帮助帮他们理清三角函数的基本计算概念， 当我问他们如何加速的时候， 我可能会提示一些比如说查表啦。 注意，我乐于提供的这种提示实际上是简单问题的答案 – 那种你能在Google上找到的。

Inevitably, you will see a bug in their function. So we come to question five from my interview plan: “Are you satisfied with that code?” You may want to ask, “OK, so where’s the bug?” The quintessential Open Ended Question From Hell. All programmers make mistakes, there’s nothing wrong with that, they just have to be able to find them. With string functions in C, most college kids forget to null-terminate the new string. With almost any function, they are likely to have off-by-one errors. They will forget semicolons sometimes. Their function won’t work correctly on 0 length strings, or it will GPF if malloc fails… Very, very rarely, you will find a candidate that doesn’t have any bugs the first time. In this case, this question is even more fun. When you say, “There’s a bug in that code,” they will review their code carefully, and then you get to see if they can be diplomatic yet firm in asserting that the code is perfect.

不可避免的，你会发现他们函数中的错误。 然后就到了我面试问题计划中的第五点： “你对那段代码还满意么？” 你也许想问，“好吧，错误在哪儿？” 那种该死的典型的开放式问题。 所有的程序员都会犯错， 这没什么问题， 但他们要能找到这些错误。 比如说C的字符串函数， 大部分的大学毕业生会忘掉要字符串的NULL终结符。不管哪种函数，他们都能有一打错误。 他们有的时候会忘掉都好啦。 他们的函数不能在长度为0的字符串上工作啦， 或者在malloc失败的时候扔出通用保护错误啦… 很少很少的情况下，你会发现候选人一次就写出了没有错误的代码。 这个时候就更有意思了。 你说“这段代码里有个错误，”然后他们就会仔细的检查他们的代码，然后你就能发现他们是不是足够外交辞令的向你声明这段代码完全没有问题。

As the last step in an interview, ask the candidate if they have any questions. Remember, even though you’re interviewing them, the good candidates have lots of choices about where to work and they’re using this day to figure out if they want to work for you.

作为面试的最后一步，问问候选人他们是不是有什么问题。 记住， 虽然是你在面试他们， 好的候选人有一大堆去哪儿工作的选择并且他们会用这天来确定他们是不是想来你这儿工作。

Some interviewees try to judge if the candidate asks “intelligent” questions. Personally, I don’t care what questions they ask; by this point I’ve already made my decision. The trouble is, candidates have to see about five or six people in one day, and it’s hard for them to ask five or six people different, brilliant questions, so if they don’t have any questions, fine.

有些面试官会评判候选人是不是会问“聪明”的问题。 就我个人而言，我不关心他们会问什么样的问题； 到这个时候我其实已经做出我的决定了。麻烦的是候选人一天里要见大概五到六个人，要他们同时问五六个人不同的，聪明的问题也不现实， 所以他们没什么问题也正常。

I always leave about five minutes at the end of the interview to sell the candidate on the company and the job. This is actually important even if you are not going to hire them. If you’ve been lucky enough to find a really good candidate, you want to do everything you can at this point to make sure that they want to come work for you. Even if they are a bad candidate, you want them to like your company and go away with a positive impression.

我通常会在面试的末尾留个五分钟向候选人推销公司和职位。 哪怕你最后不想录取这个人，这一点也很重要。 如果你很幸运找到了非常棒的候选人， 那么到这个时候，你就想尽可能的做任何事情保证他们会来你这儿工作。 哪怕是糟糕的候选人，你希望他们能喜欢你们公司然后走的时候对公司留下个积极的映像。

Ah, I just remembered that I should give you some more examples of really bad questions.

啊，我刚想起来我应该给你们一些坏问题的例子。

First of all, avoid the illegal questions. Anything related to race, religion, gender, national origin, age, military service eligibility, veteran status, sexual orientation, or physical handicap is illegal here in the United States. If their resume says they were in the Marines, you can’t ask them, even to make pleasant conversation, if they were in Iraq. It’s against the law to discriminate based on veteran status. If their resume says that they attended the Technion in Haifa, don’t ask them, even conversationally, if they are Israeli, even if you’re just making conversation because your wife is Israeli, or you love Felafel. It’s against the law to discriminate based on national origin.

首先，避免问不合法的问题。 任何关于种族，宗教信仰，性别， 国籍，年龄，是否服兵役， 参军情况， 性取向，或者是否残疾在美国都是非法的问题。 如果他们简历上提到了他们在海军呆过，你不能问他们， 哪怕仅仅是出于缓和对话氛围的目的；如果他们在伊拉克呆过。那么基于他们的参军史歧视他们是违法的。 如果他们的建立提到了他们在以色列学院上过学，不要问他们，哪怕是会话上的；如果他们是以色列人，哪怕你老婆是以色列人你想以此开始你们的对话， 或者你喜欢Felafel 。 国籍歧视是违法的

Next, avoid any questions which might make it seem like you care about, or are discriminating based on, things which you don’t actually care about or discriminate based on. The best example of this I can think of is asking someone if they have kids or if they are married. This might give the impression that you think that people with kids aren’t going to devote enough time to their work or that they are going to run off and take maternity leave. Basically, stick to questions which are completely relevant to the job for which they are interviewing.

然后避免任何可能让你看起来很在乎的问题， 或者你可能会基于这些事实产生偏见的问题， 或者是你不在乎或者歧视的问题。 这类问题我能想到的比如说就是问他们是否有小孩或者是否结婚了。 这似乎会产生这样的一种映像就是说你觉得有小孩的人没办法全身心投入到工作中去或者他们会临阵脱逃修产嫁之类的。 基本上就是要坚持问完全是跟他们面试的工作相关的问题。

Finally, avoid brain teaser questions like the one where you have to arrange 6 equal length sticks to make exactly 4 identical perfect triangles. Or anything involving pirates, marbles, and secret codes. Most of these are “Aha!” questions—the kind of question where either you know the answer or you don’t. With these questions knowing the answer just means you heard that brain teaser before. So as an interviewer, you don’t get any information about “smart/get things done” by figuring out if they happen to make a particular mental leap.

最后，避免问智力题。例如，如何安排6根等长的火柴棍构造出4个正三角形。 或者任何包含了，海盗，宝石，和密码之类的问题。 大部分这些都是“啊一声”的问题。 这种问题要么你知道答案要么你不知道。 对于这些问题，知道答案说明你以前听说过这问题。 所以作为面试官，搞清楚他们是否能够智力上跳跃并不能帮助你弄清楚他们是否“聪明，能办事”。

In the past, I’ve used “impossible questions,” also known as “back of the envelope questions.” Classic examples of this are “How many piano tuners are there in Seattle?” The candidate won’t know the answer, but smart candidates won’t give up and they’ll be happy to try and estimate a reasonable number for you. Let’s see, there are probably… what, a million people in Seattle? And maybe 1% of them have pianos? And a piano needs to be tuned every couple of years? And it takes 35 minutes to tune one? All wrong, of course, but at least they’re attacking the problem. The only reason to ask a question like this is that it lets you have a conversation with the candidate. “OK, 35 minutes, but what about travel time between pianos?”

过去，我曾经用过“不可能问题，” 也叫做“估算问题”。 经典的例子诸如“西雅图有多少钢琴调音师？” 候选人不可能知道问题的答案， 但是聪明的候选人不会放弃，他们很乐意尝试给出一个合理的估计。 让我想想, 大概有… 恩，一百万人生活在西雅图？ 大概1%的人有钢琴？ 每架钢琴大概隔几年就要调一下？ 调一次大概要花35分钟？ 当然，全部错了， 当至少他们在尝试解决这个问题。 问这种问题的唯一理由就是你要跟候选人开始一段会话。 “好35分钟， 那么在钢琴直接来回的时间呢？”

“Good point. If the piano tuner could take reservations well in advance they could probably set up their schedule to minimize travel time. You know, do all the pianos in Redmond on Monday rather than going back and forth across 520 three times a day.”

“有道理。 如果调音师能够预先接受预订，那么他们大概能够预先计划好行程来缩短行程时间。 你想， 周一调完Remond的所有钢琴而不是一天里来来回回520多次。”

A good back-of-the-envelope question allows you to have a conversation with the candidate that helps you form an opinion about whether they are smart. A bad “Aha!” pirate question usually results in the candidate just sort of staring at you for a while and then saying they’re stuck.

一个好的估算问题能够让你跟候选人展开一段会话从而帮助你判断候选人是否聪明。 一个糟糕的“啊”海盗问题通常会让候选人盯着你一段时间然后说他们卡住了。

If, at the end of the interview, you’ve convinced yourself that this person is smart and gets things done, and four or five other interviewers agree, you probably won’t go wrong in hiring them. But if you have any doubts, you’re better off waiting for someone better.

如果，面试的最后，你说服了你自己这个人就是那种聪明能办事的人， 而其他4到5个面试官也同意的话， 你不大可能错误的录取他们。 但是如果你有些担忧的话， 你还是等等其他人选。

The optimal time to make a decision about the candidate is about three minutes after the end of the interview. Far too many companies allow interviewers to wait days or weeks before turning in their feedback. Unfortunately, the more time that passes, the less you’ll remember.

对候选人做出决定的最佳时机就是面试最后的大约3分钟。 太多的公司允许面试官等待数天甚至数周后再提交反馈。 不幸的是，时间过去的越久，你记住的就越少。

I ask interviewers to write immediate feedback after the interview, either a “hire” or “no hire”, followed by a one or two paragraph justification. It’s due 15 minutes after the interview ends.

If you’re having trouble deciding, there’s a very simple solution. NO HIRE. Just don’t hire people that you aren’t sure about. This is a little nerve wracking the first few times—what if we never find someone good? That’s OK. If your resume and phone-screening process is working, you’ll probably have about 20% hires in the live interview. And when you find the smart, gets-things-done candidate, you’ll know it. If you’re not thrilled with someone, move on.

我会让面试官面试之后马上给反馈， 要么“录取”要么“拒绝”，加上一到两段的陈述。 面试后的15分钟内就要提交。

如果你决定起来有困难，那么有很简单的办法，“拒绝”。 就是不要录取你不确定的候选人。 一开始的几次有点精神紧张的 – 要是我们永远找不到好的人选怎么办？ 没关系。 如果你的简历筛选和电话面试过程工作正常， 你在现场面试过程中大概会有20%的录取率。 当你发现聪明能做事的候选人的时候，你马上就能感觉到。 如果你对某人不感兴趣，那么继续面试吧。