程序员招聘的7大误区-程序员应聘

你知道为什么有些滥竽充数鱼目混珠的家伙仍然被雇佣吗？要知道他们不擅长编译，也写不出高质量的代码。为此，我总结了在招聘程序员时常犯的 7 个错误。

[[123228]]

下面我将一一予以说明。

1. 关于注重工作年限

工作年限其实很简单，我们一看便知。很多人会认为工作时间越长他的经验肯定越丰富，于是自然而然的，这渐渐成为了衡量技巧和能力的标尺。

但是不幸的是，这完全是个谬论，特别是在编程领域。要想成为一个伟大的程序员，最重要的是你得有这个潜力。有的人天生就是程序员，而有的人则不是。所以我们在招聘时，首要任务是看清楚这个人有没有做程序员的天赋。如果没有，那么即使再多的工作经验也无济于事。他永远也不可能成为一名伟大的程序员。

2. 相信应聘人员对自我技能的评价

在面试的时候，我几乎每次都会问他们对自己不同领域技能的评价。知道他们的自我评价是其一，但是，我从不相信他们。因为有的人能力很强却谦虚谨慎，而有的人才懂点皮毛就爱大吹大擂。

那么如何才能区分他们的优劣呢？我会问一些关于他们所谓最强领域的问题，然后给他们做代码测试。通过让他们展示自己最强的区域从而正确评价他们。

3. 没有要求应聘者现场写代码

代码测试应该是面试中一个非常重要的组成部分，但是很多人却常常会忽略这一点。我想说的是，很多人说起代码来是一套一套的，一旦要他们写代码，立马就怂了。

代码测试不需要很难。那些不会编程的人即使是个非常简单的测试也会原形毕露。在我近期的面试中，我使用了“两任务法”。

第一个任务是数据访问。给出一个小数据库，里面是人名和车牌表。还有一个从车牌表到人名表的外键，指出了每辆车的主人。然后我会让应聘人员解释一下，两者之间的关系如何通过外键来实现（这还需要在人名表上建立一个主键）。接着我会要求他们制作一个简单的结果集合。

实现方式可以是 LINQ 也可以是 SQL，随他们挑选。无论是哪种方式，如果他是一名经验丰富的开发人员，这应该是小菜一碟。

第二个任务是在我提供的形状类（Shape）上写一个的子类正方形（Square）。

public abstract class Shape
{
  public abstract float GetArea ();
}

4. 为其他团队招人的观念

每次面试结束的时候，我都会问自己下面这个问题。

我会不会愿意这个家伙加入我的团队，坐在我旁边的办公桌上和我一起工作？

如果回答是否定的，那就不要雇佣他，正如 Joel Spolsky 在他的《面试手册》中写道，如果你觉得这是在为其他团队招人：

千万不要想着，“随便吧，反正不是我的团队。”因为如果你觉得这家伙和你一起工作还不够格，那就不要幻想他在其他团队能表现出众。

5. 不计较在简历中出现的拼写错误

在面试之前我会先好好看看应聘人员的简历，看看结构如何，看看有没有拼写错误。

书面沟通技巧对于每个人程序员而言都是非常重要的。因为程序员在写代码之外还得会写文档，有时候还需要与客户有邮件交流。如果在自己的简历中都含糊其辞表达不清，我又怎么能相信以后在干其他事情的时候他能够做到表达清晰呢？

如果在简历中出现很多拼写错误，那就说明这家伙很懒，看到错误也懒得去改正（因为现在基本上所有的 word 软件都会将拼写错误标记出来）。如果应聘人员在求职的时候都这么懒，江山易改本性难移，将来在工作的时候他仍然还是会这么懒——看到 bug 也懒得去修复。

6. 只注重技术技能，不要求沟通技巧

有的人会认为口头交际能力对于程序员而言并不重要——只要他们会写代码那就 ok 了。

但是如果是在团队环境中，这种想法就大错特错了。为了解决各种问题，团队经常需要聚集在一起群策群力，一起想出好办法来。这个时候清楚明白地表达自己的想法就非常重要了。

我经常会让应聘人员讲讲以前做过的系统架构是怎么样。是什么系统不重要，只要这位面试人员能够真正理解并正确表达出来，那就 ok。

7. 不愿招聘更优秀的人

技术面试的主考官通常由资深的开发人员或架构师担任。这类人员通常在公司中有一定的职位，而且常常是那种能解决难题的唯一人才。

这个时候如果应聘人员恰巧同样出色甚至更为优秀，猜猜面试官会怎么做？下面是两种截然不同的反应。

第一种想法其实并不少见（不仅存在于程序员，很多职业都有）。但是如果大家在招人的时候都只挑选比自己差的，那整个团队就会走下坡路，逐渐减弱公司的竞争力。

你敢不敢招进一个比你更优秀的人呢？

总结：招聘工作不简单

招聘并不是一件简单的事情。不但需要我们有这个自信敢于聘用有能力挑战自己的人才，还需要从公司的角度做出一些难以取舍的决定。

因为你的“判决”将决定在接下来的几年时间里，你的每周 40 小时会和一个怎么样的人一起工作。