我們是如何聘請開源開發人員的

作為初創安全公司 Profian 的首席執行官和聯合創始人，我參與了我們聘請開發人員從事 Enarx 的工作。Enarx 是一個處理機密信息計算的安全項目，幾乎完全用 Rust 語言 編寫（少部分用彙編語言）。Profian 現在已經在這次招聘找到了所有要找的人，一些開發人員將在接下來的幾周內開始工作。然而，Enarx 絕對歡迎新的貢獻者，如果事情繼續順利，公司將來肯定會僱用更多的人。

招聘人員並不容易，加上 Profian 還有一系列特別的要求，這讓招人變得更加困難。因此我認為分享我們如何解決這個問題應該還蠻有意思的，而且也會對社區有幫助。

我們尋找什麼樣的人才？

以下就是我前文提到的特別要求：

• 系統編程：Profian 主要需要那些喜歡系統層編程的人。這一層面的編程已經處於棧的底層，有很多直接與硬體或操作系統的交互。例如，要創建客戶端-伺服器部分，我們必須編寫相當多的協議、管理加密等等，而這方面的工具還不是很成熟（請參閱下面的 「Rust」 一節）。
• Rust：項目幾乎都是用 Rust 語言編寫的，那些不是的則是用彙編語言寫的（目前只有 x86 平台，儘管隨著我們添加更多平台情況可能會有所改變）。Rust 是一門很新、很酷同時也令人興奮的編程語言，但它同時也很年輕，並且一些領域沒有你想要的所有支持或者沒有你希望的那麼成熟 —— 這包括從密碼學到多線程庫到編譯器/構建基本架構。
• 分散各地的團隊：Profian 正在建立一個能夠及時通訊聯繫的團隊。Profian 在德國、芬蘭、荷蘭、北卡羅來納州（美國）、馬薩諸塞州（美國）、弗吉尼亞州（美國）和喬治亞州（美國）都有開發人員。我在英國，我們的社區經理在巴西，我們有來自印度和奈及利亞的實習生。從一開始我們就知道團隊很難聚集在一個地方工作，因此我們需要能夠通過視頻、聊天和（最不濟的情況下）電子郵件與人交流和協作的成員。
• 安全：Enarx 是一個安全項目。雖然我們並不是專門在尋找安全專家，但我們需要能夠將安全放在首位去思考和工作，並設計和編寫適用於安全環境的代碼的人。
• Git：我們所有的代碼都存儲在 Git 中（主要是 GitHub，還有一些存在 GitLab）。我們圍繞代碼的大部分交互都是圍繞 Git 進行的，因此任何加入我們團隊的人都需要能自如使用它作為日常工作中的標準工具。
• 開源：開源不僅僅是許可；更是一種心態，同時，這也是一種合作方式。大量開源軟體是由不同地域的人創建的，他們甚至可能不認為彼此身處於一個團隊。我們需要知道我們招的人不僅能在公司內部凝聚成一個緊密的團隊，同時也能夠與組織外部的人員協作，並接受 Profian 的「默認開放」文化，這裡的開放不僅僅限於代碼，還要有開放的討論、溝通和文檔。

我們是如何找到人才的？

正如我在其他地方提到的，招聘很困難。Profian 使用多種方式尋找候選人，它們取得了不同程度的成功：

• 領英招聘廣告
• 領英搜索
• 特定語言的討論板和招聘板（例如，Reddit）
• 外部招募人員（特别致敬來自 Interstem 公司的 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 – 安全博客 上，經許可後重新發布。

via: https://opensource.com/article/22/2/how-we-hired-open-source-developer

作者：Mike Bursell 選題：lujun9972 譯者：XiaotingHuang22 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive