作者：Jason Taylor

我最近经历了一场工作面试的艰难考验。这使我想到大多数公司的软件工程师面试工作做得有多糟糕。以下是我对公司改进面试过程的建议。

面试软件工程师

在我的职业生涯中，我已经经历了许多次软件工程师的面试，无论是当面试官还是当求职者。你看到的大部分面试建议都是针对求职者的。“学习这些原则”、“记住这个模式”、“复习这些标准问题”、“早点到场”、“玩目标公司的游戏”、“准备好最后要问的问题”等等。而对于组织面试的一方，却看不到什么建议。我这么多年来经历了那么多场糟糕的面试就是证据。

我把糟糕的面试分成以下几类：太困难、太简单、考虑不周、前后矛盾、非典型。

Interview-For-Software-engineer(from aanblgo)

太困难

这类面试的特点最显明。它是面试团队中的精英主义文化导致的。当我从事HP时，我们团队的招聘主管说道：“如果他们上的大学不是排名前十，我们才懒得跟他们啰嗦。”年纪轻轻、空有一腔热血的工程师通常把面试当成一场讨厌的比赛或苦恼的仪式，因为资历深厚、脾气暴躁的年长面试官总是以“现在的小孩子都怎么搞的？”的态度来对待他们。

支持者会说：“我们得把标准定得高一点。”这么说是合理的，但极端困难的面试在判断求职者的真才实学方面并没非那么有效。简单地说，困难的面试假设求职者具备基本的和中等水平的技能，所以只专注于考察求职者对某些小问题是否具有深刻的理解。

太困难的面试的结果是，许多优秀的求职者被淘汰了，留下的往往是一些正好回答得了刁钻的问题的人。

我的建议：从简单的问题开始，再根据求职者的表现增加难度。理想的情况下，用最短的时间提问简单的问题，用一半的时间问中等难度的问题，用大量的时间问最困难的问题。如果仍然怀疑求职者的能力，可以要求他们二次面试，并在二面时专注于考察有疑问的地方或特定的技能。

太简单

我曾经遇到一场这种面试，我认为我所说的东西中没有一样能体现我是否胜任那份工作。结果是，我的面试官，未来的老板，根本没有那份工作的经验甚至是当招聘主管的经验。他们幸运的是，那份工作我做得来。我愚蠢的是，居然接受了那份工作——那是我有史以来遇到的最差的工作。

在太简单的面试中，面试官要么不合格，要么漠不关心，要么胆小拘束。

这种面式的结果是，谁进门就雇用谁。同样糟糕的是，无法根据求职者的能力（无论是太强还是太弱）安排工作，因为面试官不能从面试中确定求职者的水平是高还是低。最终，求职者不知道那份工作有什么要求以及自己是否适合做它。

我的建议：让合适的人来当面试官。这很难吧？是的，但把握这些原则：不要让客户端工程师来面试服务器工程师。不要让“这是我的第一份工作”的工程师来面试15年资历的工程师。要让比较热情的人来面试求职者，即不要让个性冷漠的人负责招聘。不要让害羞胆小或有社交障碍的人组织面试。（是的，最后一条是最糟的。）

考虑不周

我有一次去面试居然找不到公司大楼。我查看了招聘邮件和公司的网址，发现我所在的位置没错。我打电话给招聘人员。“喔，那是我们公司的旧址。我们最近搬走了。”

几周以前，我在一家小公司面试。HR反复告诉我要去找她，但当我到时，她居然不在。我被另一个工程师带到一个房间。我不知道我要呆多久，也不知道谁来面试我。“嗨，我是Mike。我是客户端主管。好吧，我们开门见山吧。我希望你在白板上写一份代码来解决以下问题……”一个小时以后，另一个工程师又要求我做了几乎同样的事情。这种情况发生了三次。跟副总裁和CEO说完话后，我终于见到了HR。我并没有正常发挥，但我很确定我不想在那家公司上班。

当我在EA当招聘经理时，那里的招聘人员通常不会在大厅里跟求职者打招呼。结果是，工程师要在10分钟之后才能考核求职者。等到第一轮面试开始时，他们已经浪费15分钟了。

当你轻率地对待求职者时，你也让他们讨厌你，不想为你工作——这是直接的后果。比较不明显的是，你让他们感到不安，结果无法在面试中正常发挥。

我的建议：明确谁负责招聘、树立清楚的预期、处理没有尽职的员工（注意，人事职位永远不缺人。如果你的招聘专员做得不好，你可以换掉一个更好的）。跟求职者提前打招呼，给他们一份计划表，给他们休息时间，如果到午餐时间就提供午餐，感谢他们前来面试，确保他们知道怎么去宾馆/机场等，引导他们出去。

前后矛盾

对于这类面试，我还是直接提建议吧。什么人组织面试就该问什么问题。这样不仅可以让你对等地比较不同的求职者，而且有助于监督和改进面试过程。提的问题要能反映职者能力的。对面试后讨论帮助不大的面试官应该换成擅长这一环节的人。

非典型

这是我最讨厌的一类面试。我不得不说，这通常是最糟糕的一类面试。另外，它也是对公司危害最大的一类面试。

我曾经向一家社交游戏公司申请Flash/ActionScript工作。甚至在那时，我就已经是一名具有数年经验的Flash专家，也做过若干个项目了。电话面试成功后，他们让我在家做一个编程测试。我要解决一个问题……用JavaScript。

我共事过的许多工程师都喜欢讨论逻辑问题。“所以你只能把这个金砖切四次。每一次你必须支付blahblahblah……”“你有两个马厩和所有的这些马。每一匹马的奔跑速度都不一样。你想让第一个马厩的马进去第二个马厩blahblahblah……”好吧，这些问题都是废话。首先，通过这些问题，你只能知道他们以前是否听过这个问题，或者他们的脑子转得是否够快；但你并不知道到底是哪一种情况。再者，虽然脑子灵活是优点，但并不能直接反映编写代码的能力。第三，如果你确实需要人来解决这类问题，现成的答案是可以找到的。最后，你并不需要解决这类问题的人。

“这里有一个问题。现在开始在白板上写答案的代码吧。你将用你的半边大脑解释你正在做的事，同时用另外半边大脑从事完全不同的活动——写代码。我会坐在你身后评估你的每一个步骤。在每个步骤中，只要我发现你少了括号、犯了小错误或变量拼写有误，我都会打断你。你必须知道你使用的所有库调用的函数签名。对了，我不知道你想用什么语言写代码，所以你们就用我本人最喜欢的语言写吧，虽然你们不用这种语言已经不下5年了。”是的，几乎在所有面试中，都会出现这种可怕的白板编程测试。因为在实际工作中，那就是面试官的代码方式。你不是一个人安安静静地写代码，在整个系统的环境下认真考虑问题。你没有IDE，没有语法高亮显示，没有代码自动补全。你没有引用材料。你不能快速地写下并测试一小段新增的代码。你当然不擅长你工作的语言。太讽刺了。

我参加过外包软件的大会。在雇用方面，我从BioWare Austin的一个经理那里听到了一条好建议。当时他们与俄国的一家公司合作项目的一大部分工作。他说：“怎么工作就怎么面试。”主管通过邮件联系，用英语，使用俄国开发者的系统规范。开发者按他们自己的喜欢的方式工作，检查代码和用邮件返回结果。对于这种关系，他说，使用传统的交谈面试是不合理的。相反地，他要给他们一张写了问题的纸，给他们一台安装了Java IDE的笔记本电脑，让他们安静地写完答案的代码。

对于非典型的面试，你其实是在浪费时间考察实际工作并不需要的技能。你雇用到的人可能非常擅长解谜和写白板，但并不意味着你找到了一个好工程师。

我的建议：在当面面试以前，先让求职者在家完成一个编程测试。这个测试应该需要4个小时。等到当面面试时，花至少半个小时讨论测试，以确保1）这是求职者自己写出来的；2）他们经过设计考虑和权衡。不要白板编程。留着白板画结构图和给工程师工作时讨论问题使用吧。

总结：

你的底线是，确保求职者把自己的最佳水平发挥出来，通过大量问题来准确地评估他们的能力，保证让合适的、专业的人来组织前后一致的面试，确保面试的方式和讨论的话题与求职者申请的职位相关。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Interviewing Software Engineers

by Jason Taylor

Summary: I recently went through the interview gauntlet in search of my next job. I was reminded of how badly most companies interview software engineers. Here are some anecdotes and suggestions for companies to improve their process.

Interviewing Software Engineers

I have done a lot of software engineer interviewing in my career. I’ve been on both sides of the table of course. Most of the interviewing advice you read is targeted at the candidate. “Study these principles,” “memorize this model,” “review these standard questions,” “arrive early,” “play their games,” “come prepared with good questions,” etc. There is very little advice for the interviewer available, and that is evident from the many, many bad interviews I’ve suffered through over the years.

I’ll classify bad interviews into the following categories: Too Hard, Too Easy, Inconsiderate, Inconsistent, Unrepresentative.

Too Hard

This type of interview is the easiest to spot. It begins with a culture of elitism from the interview team. When I worked at HP one of the hiring managers in our group actually said, “If they didn’t go to a top-ten school why are we even talking to them?” Young, hot-shot engineers often treat the interview as a pissing contest or a hazing ritual. Grizzled, grumpy veterans with a “what’s wrong with kids today” attitude will be merciless.

Proponents will say, “We need to set the bar high.” Fair enough, but interviews that are extremely hard are less effective at actually determining the quality of the candidate. Simply put, hard interviews assume the candidate has fundamental and mid-level skills and focuses on deep understanding in a small set of topics.

The result of the Too Hard interview is too many good candidates get passed over, and occasionally you hire an idiot that happens the know a lot about the one thing you grilled him on.

My advice: Start with easy questions and ramp up difficulty based on how well they are doing. Ideally spend only a short time on easy questions, about half of the time on medium, and a fair amount of time on hard. If there are doubts about the candidate have them back for a second interview focussing on suspect areas or specific skills.

Too Easy

I was once on an interview where, at the end, I wasn’t sure that I had said a single thing that demonstrated I had the skills for the job. As it turned out the interviewer, my future boss, had no experience in this field or even as a manager. It was lucky for them I was qualified. But it was also stupid of me to take the job, which turned out to be the worst job I’ve ever had.

The interviewer is either incompetent, apathetic, or timid.

The result of the Too Easy interview is you’ll hire anyone who walks in the door. Almost as bad, you put people in roles that are at the wrong level for their skill set (either too high or too low) because there is no way for the interviewer to distinguish good from great from okay. Finally, the candidate doesn’t get a sense of what is actually required for the job and whether they would be a good fit for it.

My advice: Geez, just have good interviewers. How hard is that? Hard. Well, here are some one-off suggestions: Don’t send a client engineer to interview a server engineer. Don’t send a my-first-job engineer to interview a 15-year veteran. Reduce the likelihood of apathy by having the affected team interview the candidate, i.e. don’t have a neutral hiring committee. Don’t let timid or socially-awkward people interview. (Yes, this last one can be challenging.)

Inconsiderate

I once arrived for an interview and couldn’t find the company in the building. I checked the recruiting email and the company’s web site. I was in the right place. I called the recruiter. “Oh, you’re at our old address. We recently moved.”

A few weeks ago I interviewed at a startup. The HR rep told me to ask for her, but she wasn’t there when I arrived. I was directed to a room by one of the engineers. I didn’t know how long I was going to be there or who I was interviewing with. “Hi, my name’s Mike. I’m the client lead. Well, let’s get right into it. I want you to write code on the board to solve the following problem…” An hour later another engineer did practically the same thing. Then it happened again. After talking with the VP of Engineering and the CEO I finally met the HR rep. My performance was less than my potential, but I was pretty sure I didn’t want to work there anyway.

When I was a hiring manager at EA the internal recruiter routinely would fail to greet the candidate in the lobby. The engineers would end up retrieving the candidate 10 minutes late. By the time the first session started they had lost 15 minutes.

When you are inconsiderate to candidates you make them not like you and not want to work for you. Pretty straightforward. What is less obvious is that you throw off their game. You agitate them and likely negatively affect their performance.

The result of the Inconsiderate interview is you miss out on good candidates because they didn’t seem that good or YOU didn’t seem that good.

My advice: Make sure it is clear who is responsible for recruiting, set clear expectations, and take action against those who aren’t doing their job. (Note that there is no shortage of recruiters. If you have a crappy one fire him and get a better one.) Greet the candidate, give them a schedule, give them breaks, provide lunch if it’s lunch time, thank them for taking the time to come in, make sure they know how to get to their hotel/airport/whatever, walk them out. Don’t be a dick.

Inconsistent

I’ll jump straight to advice here. Be consistent with who is interviewing and what types of questions they ask. Not only does this allow you to compare apples-to-apples with multiple candidates, but it allows you to inspect and refine your interview process. Questions that don’t seem to predict ability of the candidate can be replaced in favor of ones that do. Interviewers that don’t ever have much of value to add to the post-interview discussion can be replaced with ones that do.

Unrepresentative

This is my favorite category. And by favorite I mean least favorite. I’ll go so far as to say I believe this is the most frequent bad interview type. Also, it’s probably the worst for your company.

I once applied at a social gaming company for a Flash/ActionScript job. Even at the time I was a Flash expert with several years of experience and a few projects under my belt. After a successful phone screen they gave me a take-home programming test. I was to solve a problem… in JavaScript.

Many of the engineers I’ve worked with love to pose logic problems. “So you have this gold brick, and you can only cut it four times. Each day you need to pay blah blah blah.” “You have two stables and all these horse. Each horse runs at a different speed. You want to get all the horses from the first stable to the second stable blah blah blah.” Okay, these kinds of questions are bullshit. First, you are assessing if either they’ve heard the problem before or they’re pretty smart. You don’t know which. Second, while smart is good is doesn’t directly translate to coding ability. Third, if you really need someone to solve these types of problems on the job there are known solutions to them that can be looked up. Forth, you don’t need someone to solve these types of problems.

“Here’s a problem. Now start coding the answer on the whiteboard. You explain what you’re doing with half your brain while the other half of your brain performs the entirely different activity of writing code. I’ll sit behind you awkwardly judging your every move. Each step of the way I will interrupt you for things like missing parenthesis, off-by-one errors, and typos in variable names. You’ll need to know the exact function signatures of any library call you make. Oh, and I don’t know the language you want to code in, so I’ll just have you code my favorite language that you haven’t used in over five year.” Yes, dreaded whiteboard coding happens pretty much every interview. Because on the job that’s how you code. You don’t do it quietly, by yourself, after careful consideration of the problem in context of the entire system. You don’t have an IDE with syntax highlighting and code completion. You don’t have reference material. You can’t quickly write and test small increments of code. And you certainly aren’t proficient in the language that you do your work in. Oh, wait. #sarcasm

I was at a conference on how to be successful at engineering outsourcing. In relation to hiring I heard excellent advice from a manager from BioWare Austin. They worked with a company in Russia to do a significant amount of work on a project. He said, “Interview like you work.” The leads communicated via email, in English, with system specifications for the Russian developers. The developers did their work however they wanted, checked in code, and emailed back that it was done. For this type of relationship, he said, it didn’t make sense to have a traditional conversational interview. Instead he handed them a piece of paper with a problem, provided them a laptop with a Java IDE, and left them undisturbed until they were finished.

For the Unrepresentative interview you waste time assessing skills that aren’t actually needed for the job. You might end up with a puzzle-loving, unintimidated whiteboarder, but that doesn’t mean you have a good engineer.

My advice: Include a take-home programming test BEFORE the candidate comes in. The test should take about four hours. Assuming it looks good bring them in and spend at least thirty minutes discussing it to make sure 1) they actually wrote it, and 2) that they can discuss design considerations and trade-offs meaningfully. NO WHITEBOARD CODING. Save the whiteboard for drawing architectural diagrams and other things that engineers actually do at work when discussing things with each other.

Conclusion

The bottom line is you want candidates to perform their best, you want to ask a broad range of questions to accurately assess their abilities, you want a consistent interview process with a qualified and professional interviewing team, and you want to interview in a manner and on the topics that are relevant to the position.(source:gamasutra)