document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update and rename sources/talk/20220204 How we hired an open source developer.md to translated/talk/20220204 How we hired an open source developer.md

Browse Source 
translated by XiaotingHuang22.
This commit is contained in:
Xiaoting Huang 2023-02-13 22:26:27 +08:00 committed by GitHub
parent 71aee8d542
commit 25bc2d78c5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 103 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

104
sources/talk/20220204 How we hired an open source developer.md
View File

@ -1,104 +0,0 @@
[#]: subject: "How we hired an open source developer"
[#]: via: "https://opensource.com/article/22/2/how-we-hired-open-source-developer"
[#]: author: "Mike Bursell https://opensource.com/users/mikecamel"
[#]: collector: "lujun9972"
[#]: translator: " "
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
How we hired an open source developer
======
My team opted out of the standard algorithm coding exercise for a
process that yielded more relevant results.
![people in different locations who are part of the same team][1]
As the CEO and co-founder of [Profian][2], a start-up security company, I've been part of our effort to hire developers to work on [Enarx][3], a security project that deals with confidential computing, written almost exclusively in [Rust][4] (with a bit of Assembly). Profian has now found all the people it was looking for in this search, with a couple of developers due to start in the next few weeks. However, new contributors are absolutely welcome to Enarx, and if things continue to go well, the company will definitely want to hire more folks in the future.
Hiring people is not easy, and Profian had a set of specialized requirements that made the task even more difficult. I thought it would be useful and interesting for the community to share how we approached the problem.
### What were we looking for?
These are the specialized requirements I'm talking about:
* **Systems programming:** Profian mainly needs people who are happy programming at the systems layer. This is pretty far down the stack, with lots of interactions directly with hardware or the OS. To create client-server pieces, for instance, we have to write quite a lot of the protocols, manage the crypto, and so forth, and the tools for this aren't all very mature (see "Rust" below).
* **Rust:** Almost all of the project is written in Rust, and what isn't is written in Assembly language (currently exclusively x86, though that may change as we add more platforms). Rust is new, cool, and exciting, but it's still quite young, and some areas don't have all the support you might like or aren't as mature as you'd hope—everything from cryptography through multithreading libraries and compiler/build infrastructure.
* **Distributed team:** Profian is building a team of folks where we can find them. Profian has developers in Germany, Finland, the Netherlands, North Carolina (US), Massachusetts (US), Virginia (US), and Georgia (US). I'm in the United Kingdom, our community manager is in Brazil, and we have interns in India and Nigeria. We knew from the beginning that we wouldn't have everyone in one place, and this required people who would be able to communicate and collaborate with people via video, chat, and (at worst) email.
* **Security:** Enarx is a security project. Although we weren't specifically looking for security experts, we need people who can think and work with security top of mind and design and write code that is applicable and appropriate for the environment.
* **Git:** All of our code is stored in git (mainly [GitHub][5], with a bit of GitLab thrown in). so much of our interaction around code revolves around git that anybody joining us would need to be very comfortable using it as a standard tool in their day-to-day work.
* **Open source:** Open source isn't just a licence; it's a mindset and, equally important, a way of collaborating. A great deal of open source software is created by people who aren't geographically co-located and who might not even see themselves as a team. We needed to know that the people we hired, while gelling as a close team within the company, would be able to collaborate with people outside the organisation and embrace Profian's "open by default" culture, not just for code, but for discussions, communications, and documentation.
### How did we find them?
As I've mentioned elsewhere, [recruiting is hard][6]. Profian used a variety of means to find candidates, with varying levels of success:
* LinkedIn job adverts
* LinkedIn searches
* Language-specific discussion boards and hiring boards (e.g., Reddit)
* An external recruiter (shout out to Gerald at [Interstem][7])
* Word-of-mouth/personal recommendations
It's difficult to judge between these sources in terms of quality, but without an external recruiter, we'd certainly have struggled with quantity (and we had some great candidates from that pathway, too).
### How did we select them?
We needed to measure all of the candidates against all of the requirements noted above, but not all of them were equal. For instance, although we were keen to hire Rust programmers, someone with strong C/C++ skills at the systems level would be able to pick up Rust quickly enough to be useful. On the other hand, a good knowledge of using git was absolutely vital, as we couldn't spend time working with new team members to bring them up to speed on our way of working.
A strong open source background was, possibly surprisingly, not a requirement, but the mindset to work in that sort of model was, and anyone with a history of open source involvement is likely to have a good knowledge of git. The same goes for the ability to work in a distributed team: So much of open source is distributed that involvement in almost any open source community was a positive indicator. Security, we decided, was a "nice-to-have" qualification.
We wanted to keep the process simple and quick. Profian doesn't have a dedicated HR or People function, and we're busy trying to get code written. This is what we ended up with (with slight variations), and we tried to complete it within 1-2 weeks:
1. Initial CV/resume/GitHub/GitLab/LinkedIn review to decide whether to interview
2. 30-40 minute discussion with me as CEO, to find out if they might be a good cultural fit, to give them a chance to find out about us, and to get an idea if they were as technically adept as they appeared in Step 1
3. Deep dive technical discussion led by Nathaniel, usually with me there
4. Chat with other members of the team
5. Coding exercise
6. Quick decision (usually within 24 hours)
The coding exercise was key, but we decided against the usual approach. Our view was that a pure "algorithm coding" exercise beloved by many tech companies was pretty much useless for what we wanted: to find out whether a candidate could quickly understand a piece of code, fix some problems, and work with the team to do so. We created a GitHub repository with some almost-working Rust code in it (in fact, we ended up using two, with one for people a little higher up the stack), then instructed candidates to fix it, perform some git-related processes on it, and improve it slightly, adding tests along the way.
An essential part of the test was to get candidates to interact with the team via our chat room(s). We scheduled 15 minutes on a video call for setup and initial questions, two hours for the exercise ("open book" – as well as talking to the team, candidates were encouraged to use all resources available to them on the Internet), followed by a 30-minute wrap-up session where the team could ask questions, and the candidate could reflect on the task. This conversation, combined with the chat interactions during the exercise, allowed us to get an idea of how well the candidate was able to communicate with the team. Afterwards, the candidate would drop off the call, and we'd most often decide within 5-10 minutes whether we wanted to hire them.
This method generally worked very well. Some candidates struggled with the task, some didn't communicate well, some failed to do well with the git interactions – these were the people we didn't hire. It doesn't mean they're not good coders or might not be a good fit for the project or the company later on, but they didn't meet the criteria we need now. Of the developers we hired, the level of Rust experience and need for interaction with the team varied, but the level of git expertise and their reactions to our discussions afterwards were always sufficient for us to decide to take them.
### Reflections
On the whole, I don't think we'd change a huge amount about the selection process—though I'm pretty sure we could do better with the search process. The route through to the coding exercise allowed us to filter out quite a few candidates, and the coding exercise did a great job of helping us pick the right people. Hopefully, everyone who's come through the process will be a great fit and produce great code (and tests and documentation and …) for the project. Time will tell!
* * *
This article originally appeared on [Alice, Eve and Bob – a security blog][8] and is republished with permission.
--------------------------------------------------------------------------------
via: https://opensource.com/article/22/2/how-we-hired-open-source-developer
作者：[Mike Bursell][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/mikecamel
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/connection_people_team_collaboration.png?itok=0_vQT8xV (people in different locations who are part of the same team)
[2]: https://profian.com/
[3]: https://enarx.dev/
[4]: https://opensource.com/article/21/3/rust-programmer
[5]: https://github.com/enarx/
[6]: https://aliceevebob.com/2021/11/09/recruiting-is-hard/
[7]: https://www.interstem.co.uk/
[8]: https://aliceevebob.com/

103
translated/talk/20220204 How we hired an open source developer.md Normal file
View File

@ -0,0 +1,103 @@
[#]: subject: "How we hired an open source developer"
[#]: via: "https://opensource.com/article/22/2/how-we-hired-open-source-developer"
[#]: author: "Mike Bursell https://opensource.com/users/mikecamel"
[#]: collector: "lujun9972"
[#]: translator: "XiaotingHuang22"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
我们如何聘请开源开发人员
======
我的团队不再采用标准的算法编程练习，而是采用一套能够产出更多相关成果的流程。
![同一团队里来自不同地方的人][1]
作为初创安全公司 [Profian][2] 的首席执行官和联合创始人，我参与了我们聘请开发人员从事 [Enarx][3] 的工作。Enarx是一个处理机密信息计算的安全项目，几乎完全用 [Rust语言][4] 编写（少部分用Assembly）。 Profian 现在已经在这次招聘找到了所有要找的人，一些开发人员将在接下来的几周内开始工作。然而，Enarx 绝对欢迎新的贡献者，如果事情继续顺利，公司将来肯定会雇用更多的人。
招聘人员并不容易，加上Profian还有一系列特别的要求，这让招人变得更加困难。因此我认为分享我们如何解决这个问题应该还蛮有意思的，而且也会对社区有帮助。
### 我们寻找什么样的人才？
以下就是我前文提到的特别要求：
* **系统编程：** Profian主要需要那些喜欢系统层编程的人。这一层面的编程已经处于栈的底层，有很多直接与硬件或操作系统的交互。例如，要创建客户端-服务器部分，我们必须编写相当多的协议、管理加密等等，而这方面的工具还不是很成熟（请参阅下面的“Rust”）。
* * **Rust：** 几乎所有项目都是用 Rust 语言编写的，那些不是的则是用Assembly写的（目前只有 x86，尽管随着我们添加更多平台情况可能会有所改变）。 Rust是一门很新、很酷同时也令人兴奋的编程语言，但它同时也很年轻，并且一些领域没有你想要的所有支持或者没有你希望的那么成熟——从多线程库的密码学到编译器/构建基本架构。
* **分散各地的团队：** Profian正在建立一个能够及时通讯联系的团队。 Profian 在德国、芬兰、荷兰、北卡罗来纳州（美国）、马萨诸塞州（美国）、弗吉尼亚州（美国）和乔治亚州（美国）都有开发人员。我在英国，我们的社区经理在巴西，我们有来自印度和尼日利亚的实习生。从一开始我们就知道团队很难聚集在一个地方工作，因此我们需要能够通过视频、聊天和（最不济的情况下）电子邮件与人交流和协作的成员。
* * **安全：** Enarx 是一个安全项目。虽然我们并不是在寻找安全专家，但我们需要能够将安全放在首位去思考和工作，并设计和编写适用于安全环境的代码的人。
* * **Git：** 我们所有的代码都存储在 git 中（主要是 [GitHub][5]，还有一些存在 GitLab）。我们围绕代码的大部分交互都是围绕git进行的，因此任何加入我们团队的人都需要能自如使用它作为日常工作中的标准工具。
* **开源：** 开源不仅仅是许可；更是一种心态，同等重要的，这也是一种合作方式。大量开源软件是由不同地域的人创建的，他们甚至可能不认为彼此身处于一个团队。我们需要知道我们招的人不仅能在公司内部凝聚成一个紧密的团队，同时也能够与组织外部的人员协作，并接受 Profian 的“默认开放”文化，这里的开放不仅仅限于代码，还要有开放的讨论、沟通和文档。
### 我们是如何找到人才的？
正如我在其他地方提到的，[招聘很困难][6]。Profian 使用多种方式寻找候选人，它们取得了不同程度的成功：
* 领英招聘广告
* 领英搜索
* 特定语言的讨论板和招聘板（例如，Reddit）
* 外部招募人员（特别致敬来自[Interstem][7]公司的Gerald）
* 口口相传/个人推荐
虽然很难从质量方面判断这些来源如何，但如果没有外部招聘人员，我们肯定会在数量上苦苦挣扎（我们也有一些来自该途径的优秀候选人）。
### 我们如何筛选出想要的人才？
我们需要按照上述的所有要求衡量所有候选人，但并非所有要求都是同等重要的。例如，虽然我们热衷于雇用 Rust 程序员，但那些在系统级别具有强大 C/C++ 技能的人也能成为团队里有用的一份子，因为她们能够很快掌握 Rust 语言。另一方面，熟悉使用 git 是至关重要的，因为我们无法花时间去培养新团队成员，让他们跟上我们的工作方式。
你可能会觉得很惊讶，但强大的开源背景并不是必需的要求，但在类似模式中工作的心态是必需的，而任何有开源参与历史的人都可能对 git 有很好的了解。同理，在一个分散各地的团队中工作的能力这一条件上，我们认为有过任意开源社区的参与经历都会是个积极的指标，因为有如此多的开源项目都是由分散各地的人们完成的。至于安全这一条件，我们则一致决定只是一个“锦上添花”的条件。
我们想让这个过程简单快捷。 Profian没有设置专门的人力资源部门或人力职能，因为我们正忙于编写代码。以下是我们最终使用的招聘流程（实际流程中可能略有不同），我们试图在 1-2 周内完成招聘：
1. 初审：个人履历/简历/GitHub/GitLab/领英主页，决定是否面试
2. 我作为CEO和候选人进行一场30-40分钟的讨论，了解他们是否适合我们团队的文化，同时让他们有机会了解我们，并了解他们是否真的像在初审提交的材料中所说的那样精通技术
3. 由 Nathaniel 领导的有关技术方面的深入讨论，通常我也在场
4. 与团队其他成员谈话
5. 编码练习题
6. 快速决策（通常在24小时内）
编码练习题很关键，但我们决定不采用通常的方法。 我们的观点是，许多科技公司钟爱的纯“算法编码”练习对我们想要的几乎毫无用处：考察候选人是否可以快速理解一段代码，解决一些问题，并与团队合作完成以上的工作。我们创建了一个 GitHub 存储库，其中包含一些几乎可以正常运行的 Rust 代码（事实上，我们最终使用了两个，其中一个用于技术栈上层的人），然后让候选人修复它，在上面执行一些与 git 相关的过程，并稍作改进，在此过程中添加测试。
测试中一个必不可少的部分是让候选人通过我们的聊天室与团队互动。我们安排了 15 分钟的视频通话时间用于设置和初始问题，两个小时用于做习题（“开卷”——以及与团队交谈，鼓励候选人使用互联网上所有可用的资源），然后是 30 分钟的总结会议，在这个会议上团队可以提出问题，候选人可以反思任务。这次谈话，结合练习期间的聊天互动，让我们了解了候选人与团队沟通的能力。候选人挂断电话之后我们通常会在5-10分钟内决定是否要雇用他们。
这种方法通常效果很好。一些候选人在任务上遇到困难，一些人沟通不畅，一些人在git交互方面做得不好——这些是我们没有雇用的人。 这并不意味着他们不是优秀的程序员或者不适合未来的项目或公司，但他们不符合我们现在需要的标准。在我们聘用的开发人员中，他们的Rust经验水平和与团队互动的需求各不相同，但git专业知识水平以及他们在和我们讨论之后的反应始终足以让我们决定接受他们。
### 反思
总的来说，我认为我们不会对筛选过程进行大量更改——尽管我很确定我们可以在搜寻过程环节做得更好。通过编码习题测试，我们可以筛选掉相当多的候选人，而且很好地帮了我们挑选合适的人。希望通过了这次选拔的每个人都很适合这个项目并且产出出色的代码（以及测试和文档等等）。时间会证明一切！
* * *
本文最初出现在 [Alice、Eve 和 Bob – 安全博客][8] 上，经许可后重新发布。
--------------------------------------------------------------------------------
via: https://opensource.com/article/22/2/how-we-hired-open-source-developer
作者：[Mike Bursell][a]
选题：[lujun9972][b]
译者：[XiaotingHuang22](https://github.com/XiaotingHuang22)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/mikecamel
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/connection_people_team_collaboration.png?itok=0_vQT8xV (people in different locations who are part of the same team)
[2]: https://profian.com/
[3]: https://enarx.dev/
[4]: https://opensource.com/article/21/3/rust-programmer
[5]: https://github.com/enarx/
[6]: https://aliceevebob.com/2021/11/09/recruiting-is-hard/
[7]: https://www.interstem.co.uk/
[8]: https://aliceevebob.com/