为什么招不到最好的程序员？StackOverflow 创始人有这些建议

（点击上方公众号，可快速关注）

编译：伯乐在线 - 枫轻

http://blog.jobbole.com/112539/

【导读】：Jeff Atwood 是一名程序员、Coding Horror 的博主和企业家（创办了 Stack Overflow 和 Discourse）。

作为一名创业者，你最常听到的建议是什么？

永远只招最优秀的人。无论公司规模多大，永远不要在你的招聘标准上妥协。

确实如此。优秀的团队能萌发好的创意，并将其转化成不可思议的，举世无双的产品。

但是有些事总困扰着我，让我对此建议深感迷惑。有个事情虽然没人说出来但是大家都心知肚明：永远只招最好的人……可是谁愿意住在旧金山啊。

不仅是旧金山，山景城、纽约、波士顿、芝加哥或其他城市面临的问题都一样。我们嘴里说着招聘世界上最好的人才，但事实上我们只是在招聘碰巧住附近的最好人才。

你可以说我疯了，但如果我们真的想吸引更多的优秀人才为我们工作，那么我们就必须要真的把他们“雇”来。也就是说，（至少在 IT 行业）不要再死板地认为人们只有亲身前来上班才能产生有意义的工作。因为还有更好的方式。

2008 年我与联合创始人 Joel Spolsky 着手创立 Stack Overflow（现在的 Stack Exchange）时，我所在的公司办公点在加州的伯克利，Joel Spolsky 在纽约，一东一西，我们每周保持一次电话沟通。然后团队扩展了，北卡罗莱纳州有一名开发人员，其他人都在俄勒冈和德克萨斯州。后来一个住在佛罗里达州的社区经理加入了。接着团队又签了两个分别在英国和德国的开发者。虽然我现在已经不在 Stack Overflow工作了，但记得我最后一次统计员工人数时，公司已经有高达约 150 名了。

（Stack Overflow 的两位创始人，左 Joel Spolsky，右 Jeff Atwood）

从 Stack Overflow 的经历中，我学到的最有价值的经验是，许多杰出的软件开发者其实没有住在硅谷附近。真正的招聘应该是全球范围的，而不是局限在人才拥挤的湾区，那些打算从湾区搬家的人也在招聘范围之内。你说你只招聘最好最杰出的人，只有做到这样才能让这句话有意义。

Discourse 是我目前的创业公司/产品，致力于让用户、粉丝和热衷于某一特定话题的听众之间能够对话，无论他们住在世界的哪个角落。我相信公司内部的结构应该反映听众的诉求。如果想让全球社区使用你的软件，那么做这个软件的人才也应该来自于全世界。

实践

把远程工作者集成到你的公司，这想法看似太超前，难以持续。也许是这样。但正如 William Gibson 曾经所说，未来已经在这里了，只是没有均匀分布。想想 GitHub，至少三分之二是远程工作者。看看 WordPress，目前 225 多位的员工中，绝大多数是远程工作。这些公司已经改变了网络的格局，我认为远程工作很大程度上成为这些公司 DNA 的一部分。

理想情况下，你开始把远程工作视为公司的核心哲学。即便如此，要形成远程工作的文化还是具有挑战性的。不过有几个重要的方法你可以尝试一下：

“展示你的工作” VS. “仅仅是露面”

有的人每天准时上下班，但着不意味着他们的工作也很到位。在企业上班不是在高中上体育课，光靠完美的出勤率是没法及格的。

通过产出来评判工作更加合理：

• 员工这周实现了多少个功能？

• 他们修复了多少个 bug

• 他们与客户进行了多少次交流？

• 代码速度提高多少？精简了多少？可维护性提高多少？

在 Discourse，我们一般把 GitHub 上的提交日志作为工作好坏的证据。当然这不是说员工提交的日志数量有指标或者其他什么的，而仅仅作为员工出色工作的一种可追溯的依据。不管是公共项目或是私人项目，都算数。

也许你用 Asana 或 Basecamp （或同类产品）来进行管理。我本身不太在乎进度管理工具。重点是这些工具：

让人们能够记录下他们所做的有用的事。不是“待办”列表，而是“已完成”列表。

我不关心员工何时来上班，或者他们的时间表。不关心他们住在世界上的哪个地方（前提是他们网络畅通）。不关心他们怎么工作。我也不打算微管理。如果你确实招聘到了最好的人，他们应该用产出来证明这点，然后展示他们的工作。

怎么知道这有效呢？当你招来的人发现了什么问题（或者局面完全崩溃了），他们会主动自己调整。你很放心地给他们权限，无论是改变策略，甚至是犯错误，都是靠他们自己来负责，这时事情就能走上正轨了。

通过试用项目招聘

假设一位求职者轻松通过基本测试，有出色的履历，文化高度契合，也顺利通过电话视频。是时候面试了，对吗？

我见过很多求职者，上面说的所有环节面试都很棒，但是加入公司后，一旦到岗后却完全无法胜任。即使你亲自见过一个人，要评判他的职业道德和能力也是非常难的。

如果你想摆脱对面试的质疑，确定一个人到底能不能胜任，那就给他们一个试用项目（audition project）吧！在他们与你团队中其他员工交谈之前就让他们做。我不是在说那种宽泛抽象的测试项目。而是现实世界中，今天在你实际产品中马上要做的真实工作。这些测试项目就是你在平时要分给正式员工做的工作，这样做也能减轻正式员工的压力。

理想情况下，试用项目的评估应该是一个很小的临时咨询任务，最多耗时个把小时，并具有明确的任务说明。选择一个几天内能完成的小项目，或者最多一两周。让求职者选择来办公地点还是远程工作。

我知道不是每个业务都可以分成小块的工作单元，来分配给公司外面的人。但如果你不这么做的话：

如果你没法给厉害的求职者找到一个小型试用项目，也许你也没有为现有员工合理规划工作。

在 Stack Overflow，有我们的一些开源组件，我们经常给求职者机会，让他们基于这些组件做开发，以实现我们预先想好的很多功能。那些能够独立工作，与我们清晰交流，并非常及时地发布所需功能的人，显然就是我们要找的人才。

如果试用项目进展良好，非常棒，那你现在有了一位高度符合条件的候选人，他明显有能力完成任务，也完成了需要做的事。到目前为止，我见过的能胜任试用项目的求职者，全部都能胜任工作。我非常看重试用项目中的表现；这是求职者拿到 offer 之前接触到的最接近现实的工作。如果谁都无法搞定试用项目，那么仅仅会造成这个很小的咨询工作失败，相比于让四五个人参与的全套面试流程付出的成本，孰优孰劣就非常明显了。再不济，你可以把这个项目传给下一位厉害的求职者去做。

从你的社区中招聘

通过多次的经验我发现，文化契合度比技能更能预示着成功。但是当团队都不在同一个地方办公，你如何才能创建这种文化呢？（注意这里还远远谈不上加深文化）

我意识到，并不是每个企业都有相应的社区，但如果你有更广泛的用户圈、开发群体或粉丝，无论何时，你应该拼命从这些群体中招聘。他们自然地倾向你这边，由于与公司文化契合，完全拉到你公司的重力井。这些候选人与公司文化契合的机率出奇的高，这正是你想要的。

你的一些用户为你的游戏做过令人惊叹的改造吗？在你们论坛中，有资深用户每天回答别人的问题吗？有工程师发现隐晦的安全漏洞并提醒你注意吗？这些就是你应该致力去招聘的人。为了增加机会，你们可以早早开始培养新起之星，比如增加交流，提供特殊 offer，在他们当中培养名声。

在 Discourse，我们的首位工程师就是按着招聘计划，根据他在 GitHub 上面强大的开源贡献。在 Stack Overflow，我们有一个长条的“受欢迎人”列表，这些人高度活跃在我们管理的站群。

如果你的创业公司很小，或者产品和市场契合，你仍然有选择。有很多社区，就人们的类型和他们的交流方式而言，与你希望构建的相似。追随他们吧。来一次令人信服的讨论，关于你是如何开展工作的，他们如何能够有机会帮助你塑造它。

有点反其道而行之，也可以尝试看看你的领域或行业中，那些热衷于吐槽现状的社区。这可能有点难以说明你的情况，但如果你接触到合适的人，你可以解释，你的产品正是他们在市场中期待的。他们会立马来帮助你让产品做到极致。

每天使用公共通讯工具

当你有远程工作者，沟通工具不该是仅仅他们参与的时候你才用，而应该一直使用，作为工作中很自然的部分。

不要在茶水间或者走廊会议中谈重要信息，除了现场偶尔听到的人，没人会受益。

每个拥有远程工作者的公司会需要满足这些基本要素：

实时通话

当你的团队成员住在南美洲，你不可能走到他桌前，问他一个快速问题，或者在他最近的 checkin 中发现错误。 你需要一种方式能随时联系到远程团队成员，可以很快得到回复。对于所有的远程开发者一直保持这样，可能会有点冲突，Hipchat、 Slack、IM、IRC、一些基于 Web 的工具。重要的是每个人都持续使用，作为领导者你可能需要不断地强化这个意识。

在 Discourse，目前我们是用 Slack 试验，大家都很喜欢，但它发挥作用是因为我们全天都在 Slack 上面，交流想法，开创新的对话途径，读他人的评论等等。当人们远程工作时，聊天是最重要的无处不在的沟通方式，所以在进一步合作前，你需要非常确定它运作顺畅。

在线公告板

当然，你的远程团队可能知道项目细节，但所有其他的工作呢？他们如何找到这些东西，甚至知道它摆在第一位？你需要一个虚拟公告板，它不像对话那么短暂：可以显示公告、团队周报和会议总结的地方。Discourse 正好提供这个服务，其他很多网站也拥有类似的功能。

你想要一些事能占据邮件列表和在线讨论区之间的空区。你应该能够订阅每个帖子到来时的邮件通知，或者通过 Web 查看在线对话。每个人应该能获得每周或每日的自动摘要。

有句话要注意：每次你收到类似这样的邮件，最好发自内心地相信它包含着有用的信息。一旦那些邮件仅仅沦为另一个“我有时间再读那些东西”……你让他人谎发警报多次，也毁了它。所以这里请谨慎行事。在公共讨论区分享的东西，应该是大家需要知道的。

它可以看起来像这样：

语音和视频通话

正如我喜欢 ASCII 一样，有时见不着面的字符不足以捕捉文字背后人们的专注和感觉。当你发现自己来来回回发送数 KB 的文字，仍然不满意交流的清晰度，这时就应该灌输一种“投靠语音”的反射性习惯。

永远不要低估与其他人实际交谈的作用。我知道，我知道，很多人投身编程的原因完全是想避免与其他人交谈，但是忍受下我。没有六小时以上的飞行，你压根见不到你的远程团队，并且谁有那个时间呢？我现在有工作马上要完成！

另一件比跳上飞机更好的事是使用 Skype 或者谷歌 Hangout 或同类产品，这样能够看到对方的肢体语言和脸部表情。如果你计划定期语音和视频通话，电话或邮件丢失的那些细微差别会蜂拥而来。我建议至少一周一次，这是最低限制；不一定要冗长的会议，但能帮助理解那些 checkin 背后的人们。

没人比我还讨厌会议和流程场面话，但你需要保持一定量的流程，同步维续着一帮松散连接的远程团队。看到人们实时互动是让这成为可能的关键。

周一团队状态报告

每周一，你公司的每个团队（即使只有一个）应该产生出一份简明，总结性的概要：

上周我们做了什么。

这周我们计划做什么。

阻塞我们的事情，或者我们所关注的事情。

这不一定非要是一份冗长的报告，事实上也不应该是。越简明越好，但尽量列出所有关键点。每周一雷打不动地发布在电子公告板上。现在，你有多少个“团队”取决于你；我不认为这需要每个开发者去完成，但如果公司还很小，你可以这样。

渐渐地，随着机构扩大，人们断开联系了。大家不知道其他人从事的工作，或他们的工作细节。

一份非常简洁，高水准的关于上周团队工作的概要让问题迎刃而解。周一状态报告对于小团队充其量是一个 issue，然而这有助于非常简练地覆盖上周工作的点，即使只是五人团队口头上的报告。

会议记录

任何时候你主导的可以认为是与他人的一次“会议”，做记录！也就是说，以公告点的形式记录下发生的事，那些不在场的远程团队成员就能从中受益 – 或至少了解到 – 接下来会发生的事。

再次强调，那些记录不需要很长，如果你发现做会议记录很累，那八成做错了。几句简单的列项就足够了。不需要记录每个小细节，仅是大概的轮廓：谁参与？讨论的话题？做的决定？下一步和工作项？

上述的都应该，当然，发帖到你的讨论区，这样每个人都会收到邮件自动通知。
除了这些，我见过一些特殊情景，让远程工作变得没那么理想：

头脑风暴

这是大头。如果你正在进行天马行空的即兴会议，很难实现远程。人们实际到场，见到面，听到声音，看到他们的肢体语言，这更有利于快速反弹的想法，并找出广泛的点子。你需要带宽非常高、延迟非常低的个人连接，才能有效进行头脑风暴。

好消息是，至少以我在 Stack Overflow 和 Discourse 的经验看，这种会议相当少见。你需要他们的时候，会在每年一度的线下活动，每个人为着来年更大的梦想，飞聚一起。

例如，在 Stack Overflow 的年会上，我们偏重投票多的公司价值，并建立我们称之为“艰苦卓绝的目标”，即2010年成为世界前 50 网站。自那之后，目标实现了。让每个人与团队齐头并进实现目标。

导师制

导师制需要一系列快速的来来回回的互动，经常性的被打断，因为年轻工程师会询问高级工程师对于工作的反馈。这对于远程工作连接松散的沟通模式，不太匹配。

我们对此的“解决方法”是避免招聘需要大量指导的人。在 Stack Overflow 和 Discourse 的时候，我们倾向招聘经验丰富的人，并非不相信年轻有才华的开发者（我们是相信的），而是因为远程指导他们不太现实。从招聘人用于远程工作的角度看，你或者能胜任……或者不能。我发现远程工作良好的人，但如果在技术层面上存在很大的不对称，会拖慢生产率。

如果你有意将年轻开发者培养成高级开发者，就需要规划时间，使得他们能紧密合作。结对编程在这种情况就能受益了。

考虑到所有的利弊，想象未来的 20、40 或 60 年，数字工作是怎样的，你觉得人们每天还会继续花一两个小时在上下班的路上吗？

你认为招聘策略应该基于十年前的工作状况，而不是十年后可能的工作状况吗？

以我们在 Discourse 和 Stack Overflow 的情况看，从全球招聘有着很大的战略优势。我相信远程开发代表着工作的未来前景。如果我们得花少量时间弄明白如何召集远程工作者，也许途中会犯一些错，但这值得。未来近在眼前，何须等待？

看完本文有收获？请转发分享给更多人

关注「Python开发者」，提升Python技能