为什么招不到最好的程序员?SO 创始人有些建议

【导读】: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 中发现错误。 你需要一种方式能随时联系到远程团队成员,可以很快得到回复。对于所有的远程开发者一直保持这样,可能会有点冲突,HipchatSlack、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 的情况看,从全球招聘有着很大的战略优势。我相信远程开发代表着工作的未来前景。如果我们得花少量时间弄明白如何召集远程工作者,也许途中会犯一些错,但这值得。未来近在眼前,何须等待?

1 2 收藏 1 评论

关于作者:枫轻

软件工程+英语 本科双学位,JAVA 程序媛 92 年一枚,语言主要涉及 JAVA/C/C# ,爱折腾各种新技术,欢迎交流学习 个人主页 · 我的文章 · 12 ·  

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部