我们如何招聘开源开发者

作为初创安全公司 Profian 的首席执行官和联合创始人，我参与了我们招聘开发人员以开发 Enarx 的工作，这是一个处理机密计算的安全项目，几乎完全用 Rust 编写（带有一点汇编）。 Profian 现在已经找到了所有正在寻找的人员，其中几位开发人员将在未来几周内开始工作。 然而，Enarx 绝对欢迎新的贡献者，如果一切继续顺利，该公司肯定会在未来想要雇用更多的人。

招聘人员并不容易，Profian 有一套专门的要求，这使得这项任务更加困难。 我认为与社区分享我们如何解决这个问题将是有用且有趣的。

我们在寻找什么？

这些就是我所说的专门要求

• 系统编程： Profian 主要需要乐于在系统层进行编程的人员。 这相当底层，有很多与硬件或 OS 的直接交互。 例如，为了创建客户端-服务器组件，我们必须编写大量的协议，管理密码等等，而这方面的工具都不是非常成熟（请参阅下面的“Rust”）。

• Rust：几乎所有项目都是用 Rust 编写的，而没有用 Rust 编写的部分是用汇编语言编写的（目前仅限于 x86，但随着我们添加更多平台，这种情况可能会发生变化）。 Rust 既新颖、酷炫又令人兴奋，但它仍然很年轻，某些领域并没有你可能想要的所有支持，或者不如你希望的那么成熟——从密码学到多线程库和编译器/构建基础设施的所有方面。

• 分布式团队： Profian 正在组建一个团队，无论在哪里找到他们。 Profian 在德国、芬兰、荷兰、北卡罗来纳州（美国）、马萨诸塞州（美国）、弗吉尼亚州（美国）和佐治亚州（美国）都有开发人员。 我在英国，我们的社区经理在巴西，我们在印度和尼日利亚有实习生。 从一开始我们就知道我们不会让每个人都在同一个地方，这需要能够通过视频、聊天和（最坏情况下）电子邮件与他人进行沟通和协作的人员。

• 安全性： Enarx 是一个安全项目。 尽管我们没有专门寻找安全专家，但我们需要能够以安全为重进行思考和工作，并设计和编写适用于该环境的代码的人员。

• Git：我们所有的代码都存储在 git 中（主要是 GitHub，也使用一点 GitLab）。 因此，我们围绕代码的许多交互都围绕着 git，任何加入我们的人都需要非常舒适地将其用作日常工作中的标准工具。

• 开源：开源不仅仅是一种许可； 它是一种心态，同样重要的是，也是一种协作方式。 大量的开源软件是由地理位置上不在一起，甚至可能不认为自己是一个团队的人创建的。 我们需要知道，我们雇用的人员，在公司内部组成一个紧密的团队的同时，也能够与组织外部的人员进行协作，并接受 Profian 的“默认开放”文化，不仅适用于代码，还适用于讨论、沟通和文档。

我们是如何找到他们的？

正如我在其他地方提到的，招聘很难。 Profian 使用了各种方法来寻找候选人，其成功程度各不相同

• LinkedIn 招聘广告
• LinkedIn 搜索
• 特定于语言的讨论区和招聘版（例如，Reddit）
• 外部招聘人员（向 Interstem 的 Gerald 致敬）
• 口口相传/个人推荐

很难根据质量来判断这些来源之间的差异，但如果没有外部招聘人员，我们肯定会很难保证数量（而且我们也有一些来自该途径的优秀候选人）。

我们是如何选择他们的？

我们需要根据上面提到的所有要求来衡量所有候选人，但并非所有要求都相同。 例如，尽管我们渴望雇用 Rust 程序员，但具有系统级强大 C/C++ 技能的人员能够快速掌握 Rust 并发挥作用。 另一方面，熟练掌握 git 的使用绝对至关重要，因为我们无法花费时间与新团队成员合作，使他们能够快速适应我们的工作方式。

强大的开源背景可能令人惊讶，但不是必需的，但以这种模式工作的思维方式是必需的，并且任何有开源参与历史的人都可能对 git 有很好的了解。 分布式团队工作能力也是如此：如此多的开源是分布式的，参与几乎任何开源社区都是一个积极的指标。 我们决定，安全是一项“锦上添花”的资质。

我们希望保持流程简单快捷。 Profian 没有专门的 HR 或人事部门，我们正忙于编写代码。 这就是我们最终得到的（略有变化），我们尝试在 1-2 周内完成它

1. 初步简历/GitHub/GitLab/LinkedIn 审查以决定是否面试
2. 与我（作为 CEO）进行 30-40 分钟的讨论，以了解他们是否适合我们的企业文化，让他们有机会了解我们，并了解他们的技术能力是否与第一步中表现出来的一样好
3. 由 Nathaniel 领导的深入技术讨论，通常有我在场
4. 与其他团队成员聊天
5. 编码练习
6. 快速决定（通常在 24 小时内）

编码练习是关键，但我们决定反对通常的方法。 我们的观点是，许多科技公司钟爱的纯粹“算法编码”练习对于我们想要的东西几乎毫无用处：找出候选人是否可以快速理解一段代码，修复一些问题，并与团队合作完成此操作。 我们创建了一个 GitHub 存储库，其中包含一些几乎可以工作的 Rust 代码（事实上，我们最终使用了两个，一个用于堆栈中位置稍高的人），然后指示候选人修复它，对其执行一些与 git 相关的流程，并略微改进它，并在沿途添加测试。

测试的一个重要部分是让候选人通过我们的聊天室与团队互动。 我们安排了 15 分钟的视频通话用于设置和初始问题，两个小时用于练习（“开卷”——除了与团队交谈外，还鼓励候选人使用他们可以在互联网上获得的所有资源），然后进行 30 分钟的总结会议，团队可以在其中提出问题，候选人可以反思任务。 这种对话，加上练习期间的聊天互动，使我们能够了解候选人与团队沟通的能力。 之后，候选人会退出通话，我们通常会在 5-10 分钟内决定是否要雇用他们。

这种方法通常效果很好。 一些候选人在任务中挣扎，一些人沟通不好，一些人在 git 互动中表现不佳——这些人是我们没有雇用的人。 这并不意味着他们不是优秀的程序员，或者以后可能不适合该项目或公司，但他们不符合我们现在需要的标准。 在我们雇用的开发人员中，Rust 经验的水平以及与团队互动的需求各不相同，但 git 专业知识的水平以及他们对我们事后讨论的反应总是足以让我们决定接受他们。

反思

总的来说，我认为我们不会对选择过程做出太大的改变——尽管我很确定我们可以更好地进行搜索过程。 到达编码练习的途径使我们能够筛选出相当多的候选人，而编码练习在帮助我们选择合适的人员方面做得非常出色。 希望每个经历过这个过程的人都能很好地适应，并为该项目生成出色的代码（以及测试和文档等等……）。 时间会证明一切！

本文最初发表于 Alice, Eve and Bob – a security blog 并经许可转载。