一句話總結

招募人才意外地困難。

亮點

• TinyPilot 迎來有史以來表現最好的一個月，營收接近 8 萬美元，超越先前紀錄 15%。
• 我的徵才貼文回應率是六個月前刊登同一職缺時的 8 倍。
• 對於聘僱人才，我有許多想法。

目標成績

每個月月初，我都會宣告本月想完成的目標。以下是我的達成狀況：

將 TinyPilot Community 與 TinyPilot Pro 遷移至次世代更新系統

• 結果：我們已完成 TinyPilot Community 的遷移，但 TinyPilot Pro 尚未就緒。
• 成績：C+

我們從五月開始全面翻新 TinyPilot 的更新系統，耗時遠比我們任何人預期的都要久。

在最初的兩年裡，我在 TinyPilot 的更新系統中累積了大量 technical debt(技術債)。我們現在正在償還，但也意味著我們不斷遇到各種意外狀況，每次都會耗掉一週以上的開發時間。我相當有把握，現在只剩下最後幾週了。

完成 TinyPilot 授權管理方案的定案

• 結果：方案已定案。
• 成績：A

我們已為 TinyPilot 的授權管理定案，我認為所有相關人員都很滿意。這個方案提供了流暢的使用者體驗，同時將工程複雜度降至最低。

將 TinyPilot Voyager 寄給兩位 YouTube 創作者或部落客進行評測

• 結果：忙於招募，無暇處理此事。
• 成績：F

這方面完全沒有進展。我其實應該把招募列為目標之一，因為這個月大部分時間都花在這件事上。

TinyPilot 統計數據

8 月是 TinyPilot 營收與利潤的紀錄新高。我在 7 月底將價格調降了 11%，看起來這讓銷售額成長了 34%。而且，這又是個「平淡」的一個月，沒有任何外部事件推升這些數字，因此我對於能否維持這樣的表現感到樂觀。

我之所以能夠調降價格，是因為我終於有了充足的電路板供應。晶片短缺迫使我們花了八個月重新設計，以替換停產的零件。為了避免有限的庫存被搶購一空，我不得不維持高價。現在我們可以持續生產新晶片，在價格與銷售速度上就有了更大的彈性。

應對 8 倍的應徵量

我在 8 月聘請了第二位支援工程師，這次的經驗與六個月前為同一職位招募時截然不同。

上次，我在 30 天內收到 221 份申請。這次短短兩週內就收到了 802 份申請。申請人數如此之多，我不得不主動放慢腳步，最終在兩週後完全關閉了申請。

我想在趕上回覆進度時暫時隱藏徵才資訊。令人困擾的是，We Work Remotely 不允許暫時隱藏職缺。你要嘛永久刪除貼文並放棄已付費的剩餘刊登時間，要嘛就讓它繼續刊登，吸引遠超你負荷能力的候選人。

作為變通辦法，我保留了職缺刊登，但將地點要求從「全球」改為「僅限美國」。這個職位本身並沒有嚴格要求候選人必須住在美國，但這是我能想到在不完全下架貼文的情況下，減緩申請湧入速度的最佳方式。

加上地點限制後，新申請的速率確實減緩了約一半。不過，仍有許多申請者無視這項要求。在加上限制後，只有 42% 的候選人表示自己確實住在美國，相較於限制前的 18%。

兩週後我關閉了申請，當時已收到 802 份申請，我知道自己無法以足夠快的速度處理全部申請，及時回覆候選人。

為什麼這次的申請人數多了這麼多？以下是我的推測：

結構化的網頁表單比電子郵件更不讓人卻步

我認為最大的因素是這次候選人是透過網頁表單申請。上次我請大家直接用電子郵件寄送履歷和求職信。我猜想人們填寫結構化表單時會感到更自在，因此會鼓勵更多人投遞。

缺點是網頁表單似乎吸引了更多低投入的申請者。上次有 18% 的 We Work Remotely 申請者夠優秀，能通過初步的履歷篩選。這次只有 6% 能進入下一階段。

更多招募管道意味著更多候選人

我在另外兩個管道發布了職缺：RemoteOK 和 Craigslist。Craigslist 似乎沒有帶來太多申請者，但 RemoteOK 在兩週內帶來了 127 位。

經濟下滑意味著更多求職者

最後，全球經濟比我六個月前招募時更糟。對經濟衰退的擔憂增加，招募的公司也變少了。我推測現在比起今年稍早，更像是雇主主導的市場。

比較遠端職缺的刊登管道

透過這次過程，我發現不同的招募管道在投資報酬率上有著極大的差異。

我在意的兩個指標是：

• 合格候選人數量
• 合格候選人占總申請人數的比例

我希望平台能為每個職缺提供約 10 至 20 位合格候選人，讓我有足夠的選擇。如果平台的訊噪比太差，必須篩選 3,000 人才能找到少數合格者，那它就沒有價值。

為了這次評估，我將所有通過履歷篩選的人視為合格候選人。而且我只計算職缺開放為全球申請的那五天內的申請。這部分是因為更改地點要求會扭曲回應，另一部分則是因為我還沒處理完所有其他申請。

*「不明」類別包括透過 TinyPilot 網站上的連結申請的候選人，因此涵蓋了在 Twitter 或其他地方看到我發文的人。我最終錄用的人就是從我的推文看到這個職缺的。

We Work Remotely 的表現相當不錯。它當然也有不少低投入和灌水的申請者，但在 359 人中找到 20 位候選人，比例已經相當不錯。

在這段時間內，RemoteOK 沒有帶來任何合格的候選人，而且我使用它的體驗非常糟糕，值得另闢一節來說明。

RemoteOK 令人大失所望

我長期以來一直是 Pieter Levels（皮特·萊維爾斯） 的粉絲。他在 Indie Hackers Podcast 上的訪談是該系列最精彩的其中一集。皮特·萊維爾斯很擅長點出自力創業生活方式令人興奮與自由之處。

然而，皮特·萊維爾斯的旗艦事業 RemoteOK 卻讓人大失所望。我已經不記得上一次使用到感覺如此處處與付費用戶作對的產品是什麼時候了。

一開始，當你建立職缺貼文時，RemoteOK 就會向你推銷各種加價選項。

We Work Remotely 也有類似的加價推銷，但感覺沒那麼令人反感。或許是因為 We Work Remotely 不會為了幫你產生一個 QR code 就收 134 美元。

RemoteOK 的職缺有標籤可協助求職者搜尋，所以我加上了像 linux、customer support、flexible schedule 這類標籤。幾小時後我回來看這個職缺，發現 RemoteOK 自動加上了幾個不正確的標籤，像是 microsoft、windows、webdev、development，儘管這些與我的職缺完全無關。我刪除了 RemoteOK 加上的標籤，但隔天它們又出現了。我唯一能永久移除它們的方法是自己再加上更多標籤。

RemoteOK 剝奪使用者主控權最離譜的例子就是它的魔法關鍵字。RemoteOK 會加上這樣的指示：「申請時請提及單字 [某個隨機單字] 以證明你已完整閱讀徵才資訊。」RemoteOK 並不會告訴你它加了這些指示，而且你無法移除它們。

我討厭、討厭、非常討厭這個功能。如果我早知道有這件事，根本不會在 RemoteOK 上刊登職缺。

我認為這類「魔法關鍵字」要求對求職者是一種侮辱，因此我在刊登職缺時會刻意避免這類要求。RemoteOK 偷偷將它注入我付費購買的徵才貼文中，實在令人非常惱火。

最致命的是，RemoteOK 在它唯一的任務上徹底失敗：提供合格的候選人。在同一段時間內，RemoteOK 的候選人沒有任何一位通過我的初步申請篩選，而 We Work Remotely 則為我媒合了 20 位合格的申請者。

更新（2022-09-25）：針對這篇文章，皮特·萊維爾斯承諾會著手處理我提到的問題，並慷慨地退還了我的付款。

Homerun 還不錯，但稱不上出色

上次招募時，我請候選人直接寫信給我，然後用收件匣標籤來整理申請。結果變得雜亂又令人困惑。

這次我測試了數個 applicant tracking systems(應徵者追蹤系統)，最終選擇了 Homerun。

在完整招募流程中使用 Homerun 後，我相當滿意。介面美觀，也具備我需要的所有功能。一切都相當直覺，因此能有條理地處理申請。

我非常喜歡 Homerun 的範本郵件功能。我很少寄完全制式的信件給候選人，但對於常見的回覆能有一個基本架構很有幫助，例如：

• 你的 Linux 經驗不足
• 你的英文未達此職位要求的程度
• 你是非常優秀的候選人，讓我們進入範例題目階段

Homerun 每月收費 71 美元，對大多數小型企業來說在可負擔範圍內。而且計費方式很合理，在沒有招募時不需要付費。大多數其他 applicant tracking platforms若你停止支付全額月費，就會刪除你所有的資料。Homerun 允許你在沒有積極招募時降級為免費方案，並保留所有資料。免費方案唯一的限制是在你重新付費之前，無法接受新的申請者。

我確實也遇到了 Homerun 的幾個重大缺點：

無法篩選候選人

在候選人數量如此龐大的情況下，我希望能提早聯繫最有潛力的人。我很想篩選出居住在英語系國家且自評精通 Linux 的候選人。Homerun 擁有這些資料，但卻沒有提供任何依這些條件篩選候選人的方式。要在待審清單中找到這些申請者，唯一的方法就是逐一審閱每份申請。

糟糕的電子郵件使用體驗

Homerun 最糟的介面設計之一就是它的電子郵件功能。像所有 applicant tracking systems 一樣，Homerun 讓你在網頁應用程式內直接寄信給候選人。但它是透過彈出一個強制回應視窗來實現：

這個強制回應視窗完全遮住了候選人在申請中撰寫的所有內容，因此你無法參考自己的筆記、對方的履歷或他們在申請表單中對問題的回答。這是個糟糕的設計，因為雇主在回覆候選人時顯然需要這些資訊。

我用並排開啟兩個 Homerun 視窗的方式來繞過這個問題。這方法還算可行，但 Homerun 在不同瀏覽器視窗間的同步做得不好。如果我在一個視窗中將候選人標記為不予錄用，另一個視窗就會混亂，並從申請清單頂端重新載入。

電子郵件寄達率不佳

我以 PDF 連結的形式寄送範例作業給候選人，但有幾位候選人告訴我他們沒收到。我懷疑 Homerun 使用的郵件伺服器寄件者信譽不佳，因此垃圾郵件過濾器會攔截含有連結的 Homerun 郵件。

網頁應用程式速度緩慢

Homerun 網頁應用程式慢得惱人。我使用的是配備光纖網路的現代桌機，但大多數 Homerun 頁面仍需 2 到 5 秒才能載入，有些甚至長達 10 秒。

下次招募的改進方向

我對這次招募中對待候選人的方式感到不滿意。我沒有為申請量做好準備，也因為接受了超過我在合理時間內能處理數量的申請，而浪費了求職者的時間。

以下是為了改善所有人的招募體驗，我計畫在下次做出的一些改變。

回覆時更加謹慎

剛開始用 Homerun 處理申請時，我對它的郵件範本過於熱衷。上一次招募時，如果候選人寄來低投入的申請，我就直接忽略。有了 Homerun，郵件範本讓我即使對投入度低的人也能輕鬆回覆。

我做了一個範本，大意是因為申請內容看起來像是複製貼上，所以予以婉拒。我當時認為，至少給予回饋，告訴他們複製貼上的申請方式會讓他們失去工作機會，是件好事。

這個策略效果很差。

在有回覆的候選人中，約 50% 的人態度友善並感謝回饋，這部分還不錯。約 20% 的人則表現得粗魯或帶有敵意，這部分就很糟。

剩下的 30% 意識到終於有真人與他們互動，申請並沒有像他們以為的那樣石沉大海。此時他們開始研究公司，並表示其實他們對 TinyPilot 本身很感興趣。這讓我陷入尷尬的處境。如果我重新考慮他們的申請，對那些一開始就認真撰寫用心回答、而非對每個人都複製貼上相同內容的候選人來說，似乎並不公平。

在低投入申請上浪費了一兩天時間後，我乾脆停止回覆這類申請者。我的策略改為只有在符合以下條件時才回覆：

• 候選人至少在基本層面上符合職位資格
  • 例如，若職位要求之一是「熟悉 Linux」而候選人表示從未使用過 Linux：不予回覆。
• 候選人至少在申請上投入了幾分鐘時間
  • 例如，若回覆明顯是複製貼上或隨意草草寫就：不予回覆。

這個新策略帶來一個令人愉快的副作用：消除了敵意的回覆。當我婉拒那些回答用心的候選人並說明原因時，他們不一定會回覆，但若有回覆，態度都相當專業並感謝回饋。

聘請他人協助我進行初步篩選

篩選履歷和申請需要數十小時，但這是一項我可以輕鬆訓練聰明的人來幫我完成的工作。

我不想使用笨拙的自動化篩選或機器學習——對我而言，能誠實地告訴候選人有真人正在審閱他們的申請是很重要的。只是那個人不一定非得是我。

為客戶支援建立備援

延誤我回覆求職者的因素之一，是平時負責客戶支援的 TinyPilot 員工請了一週病假。客戶支援感覺上似乎有備援，因為我們的支援工程師可以替補。如果還是不行，我就是最後一道防線。但當 TinyPilot 平時的客服人員請病假時，讓我意識到我們的客戶支援流程有多麼脆弱。

我忘了自己親自處理客戶支援時工作量有多大，尤其還要額外負擔與 800 位求職者溝通的工作。除此之外，我還休了幾天假，這意味著 TinyPilot 的支援工程師是唯一提供支援的人。這段時間相當吃緊，因為他沒有 Shopify 或我們本地出貨辦公室的存取權限，因此能提供的支援相當有限。

等支援工程團隊穩定下來後，我也打算再增加一位負責客戶支援的人手。這將有助於在有人生病或休假時維持運作順暢。

達到一定數量後，將職缺申請表單轉為候補名單

即使我找其他人來協助招募，我們在合理時間內能審閱的申請數量還是有上限。一旦超過像 400 位候選人這樣的門檻，我應該將申請表單轉為候補名單，以免要求候選人說明為何想與我們共事而浪費他們的時間。

記住這件事有多麼耗時

我以前曾透過徵才貼文聘請過人，但直到再次經歷，才想起這個過程有多麼耗時。

在我的想像中，時間投入看起來是這樣的：

有一大批候選人在第一天就全部投遞。我篩選候選人，直到縮小到唯一一人。最後，我聘請了那個人，他開始接手我以前在做的工作，一切都非常美好。

實際上，時間投入更像是這樣的：

先有一大波申請人湧入，然後在我處理這些申請的同時，不斷有人繼續投遞。接著當我終於聘請到人時，還得同時跟進所有未獲選的人，並同步讓新進人員報到與接受培訓。

所以，下次招募時，我只要回頭看看這些精美又富含資訊的圖表，提醒自己需要預留大量空檔來應付這件事。

總結

完成了什麼？

• 聘請了第二位 TinyPilot 支援工程師
• 將次世代更新系統部署到 TinyPilot 的 Community 版本
• 發布了我關於給自力創業者的 applicant tracking systems的筆記
• 發布了我關於在 PicoShare 中偵錯記憶體問題的筆記

學到的教訓

• 招募永遠比我預期的更困難

下個月的目標

• 將 TinyPilot Pro 遷移至次世代更新系統。
• 將 TinyPilot Voyager 寄給兩位 YouTube 創作者或部落客進行評測
• 探索新的機殼製造方案