一句話摘要

聘僱 TinyPilot 首位支援工程師

亮點

• 我聘僱了 TinyPilot 的首位支援工程師。
• 我體會到，聘僱支援工程師比預期的還要困難。
• 我正在評估用來支付海外約聘人員的平台。

目標成績

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

推出 Voyager 2：PoE 版本

• 結果：我終於發表了 Voyager 2 PoE
• 成績：A

哎呀，這花費的時間遠比我預期久。我回頭看了 2021 年 4 月初寫的原始設計文件，當時我預估 2021 年 5 月 15 日前就能備好 200 台。換句話說，我原本預估六週，結果卻花了 11 個月。

聘僱 TinyPilot 支援工程師

• 結果：與一位支援工程師開始試用聘僱
• 成績：A

這個職缺的招募花了不少工夫，但我很興奮團隊迎來這位新成員。這篇回顧主要就是在談聘僱支援工程師的過程，詳情請繼續往下看。

完成 TinyPilot 網站改版的設計工作

• 結果：延後至三月
• 成績：N/A

合作的設計公司在二月的可用時數不足。我已與他們談妥，確保三月與四月有足夠時數，預計能在月底前完成。

TinyPilot 數據

自一月以來銷售保持穩定。由於二月天數較少，總銷售額略微下滑，但若以單日平均來看，其實表現比一月更好。

二月的獲利異常地高，但主要是時間差所致。我還在等待幾張大額發票入帳，而且我的企業信用卡額度剛調高了 2 萬美元，所以手上持有的現金較多。

聘僱支援工程師：職缺公告

過去幾個月我一直想聘一位支援工程師，只是時間一直不夠。雖然花了比預期更久的時間，但我已經聘到了首位支援工程師。第一步是建立職缺公告。

我在三個管道刊登了職缺說明：

聘僱的難題之一在於，身為小企業主，我希望應徵者能理解我的公司是什麼樣子，並在應徵時向我傳達這一點。問題是，多數公司對待求職者的方式很糟。這造就了一種生態，讓求職者不願意對任何特定公司投入太多時間，因為有 90% 的機率他們的履歷會石沉大海。

撰寫職缺公告時，我試圖讓大家明白，我會親自閱讀每一份申請。申請資料不會被送進機器學習機器人，或交給只會用關鍵字盲目篩選、對情況一無所知的招募人員手上。如果你付出了努力，我也會付出努力。

我也希望應徵者在整個招募過程中感受到我尊重他們的時間，因為這正是我希望未來共事時的感受。

許多職缺公告會寫類似這樣的話：「請在求職信中提到 banana 這個字，讓我知道你有仔細閱讀職務說明。」我刻意選擇不這麼做，因為我覺得這樣會讓關係一開始就變調。我不希望應徵者覺得我預設他們很懶或能力不足。我只需幾秒就能辨識出不用心的申請，所以不需要什麼通關密語。

對於薪資該開多少，我不太確定。這個職位的市場行情很難衡量，因為很少有職缺會揭露薪資，尤其是兼職約聘的職位。我開出時薪 40 美元，但和其他創辦人聊過後，他們表示預期用時薪 20 至 30 美元就能找到合適的人選。

聘僱支援工程師：篩選申請

職缺公告上線後，接下來就是開始篩選申請。這是整個流程中最耗時的部分。

在這個階段，我評估的重點是：

• 他們的寫作是否清晰、文法是否正確？
• 他們是否花時間了解 TinyPilot？
• 他們是否有客服或撰寫面向使用者文件的經驗？
• 他們是否符合技術條件？

我試著盡快找出突出的應徵者並迅速回覆。至於其他人，我會直接快速婉拒，或依時間安排排入回覆佇列。

我很快發現需要一套整理系統來管理處於不同階段的應徵者，因此我把所有進行中的信件往來分門別類，放進不同的電子郵件資料夾：

instant-reject

我的 instant-reject 資料夾是用來放未依照申請說明投遞的應徵者，包括：

• 只寄來空白郵件並附上履歷的應徵者
• 求職信中未提及該職缺或 TinyPilot 的任何具體內容（罐頭申請）
• 未符合職缺條件，且在求職信中未說明落差的應徵者

對於這些應徵者，我會將其申請移至 instant-reject 資料夾，且不予回覆。

我將 138 位應徵者（占總數 62%）放入 instant-reject 資料夾。

cover-letter-reject

cover-letter-reject 資料夾是用來放有誠意應徵，但從求職信或履歷就能看出不太合適的應徵者。

對於這些應徵者，我會寄送個別化的回覆。以下是一個範例：

嗨 Joe（喬），

感謝你來信，並花時間進一步了解 TinyPilot。

很遺憾，我認為這次可能不太合適。

看起來你在 Linux 和 Raspberry Pi 方面有很豐富的經驗，但這個職位需要更有撰寫面向客戶內容經驗的人。你的英文相當不錯，但求職信和履歷中有幾處錯誤，因此我認為這個職位可能不太適合你。

很抱歉這次未能合作，祝你求職順利。

祝好，
Michael（麥可）

在回覆中，我試著強調我婉拒的是他們的申請，而非說「我婉拒的是你這個人」。我避免講得太具體，因為我不希望應徵者覺得我在挑剔，或因為單一粗心錯誤就否定他們。

多數雇主會省略個別化的婉拒信，我能理解原因。這非常耗時，且對雇主沒有直接好處。不過，在我要求對方投入無償時間來申請與我共事後，若對他們不理不睬或只寄制式回覆，我覺得是不尊重的。

約 65% 收到婉拒信的應徵者沒有再回覆。約 25% 表示感謝我的回饋。其中有幾位要求進一步說明，我也針對他們可以改進的地方提供了具體建議，並推薦了提升寫作能力的資源。

在收到婉拒通知的應徵者中，約 10% 試圖說服我，只要讓他們完成我的篩選題目，就能證明自己的能力。雖然很誘人，但針對篩選題目提供回饋所花的時間，比在求職信階段婉拒要多上一個數量級，所以為了不浪費彼此時間，我沒有這麼做。

大多數回覆的人似乎對收到指出申請具體問題的回覆感到驚訝與感謝，因為這似乎很罕見。沒有人在回覆中表現出敵意，大家都保持專業。

我將 62 位應徵者（28%）放入 cover-letter-reject 資料夾。加上 instant-reject 的人數，只有 19 位應徵者（9%）通過了履歷篩選。

pending-questions

如果應徵者的求職信用英文寫得清晰、文法正確，且符合技術條件，我會寫一封個人化的回覆，告訴他們我欣賞申請中的哪些地方，以及為何我認為他們可能適合 TinyPilot。

接著我會邀請這些應徵者回答三個模擬的客戶支援請求，以便了解他們如何與客戶溝通並提供技術解決方案。

回覆後，我會將他們移至 pending-questions 資料夾，直到他們完成題目。

有 19 位應徵者（9%）進入此階段。其中只有 10 位（53%）提交了答案，不過有兩、三位應徵者是在最後幾天才收到題目，可能仍會回覆。

questions-reject

當應徵者分享他們對範例題目的回答後，我會決定是否讓他們進入試用聘僱。

無論是否要提供聘僱機會，我都會給所有回答範例題目的應徵者詳細的回饋。這個想法來自 Firebase 創辦人 Andrew Lee（安德魯·李）：

讓應徵者不覺得自己在浪費時間至關重要。在 Firebase，我們透過在帶回家的測驗流程中投入大量心力來確保這一點……[在]他們提交答案後，我們會提供詳盡細緻的程式碼審查（通常由傳奇人物 @mikelehen 執行）。

我們把這種程式碼審查當作真正的正式產品程式碼審查來對待，而且無論是否打算繼續面試該應徵者，我們都會這麼做。這份審查有兩個非常重要的原因。首先，它向應徵者表明我們認真看待他們，並且我們在面試流程中投入了大量自己的時間。其次，它讓應徵者對在 Firebase 工作的情況有個概念；「如果他們對程式設計挑戰的程式碼審查都做得這麼好，我等不及想和這個團隊一起做真正的產品程式碼了！」

-安德魯·李，「How Firebase Interviewed Software Engineers」

安德魯·李的做法一直讓我印象深刻，我認為這是對待他人的正確方式，因此我在任何職位的招募中都試著秉持這種心態。

大多數人對詳細的回饋表示感謝，並說這些建議很有幫助。有一位覺得我的標準過於嚴格，我也根據他的回饋修改了題目。

在回答問題的應徵者中，我將 19 位中的 17 位（89%）放入 questions-reject 資料夾。

maybe-trial-hire

在搜尋的第一週，有一位應徵者把篩選題目回答得相當不錯，但我仍有些保留。他是目前為止表現最好的，但我想再看看其他人選。我告訴他幾週後會給他答覆，並將他放入 maybe-trial-hire 資料夾。後來我找到更合適的人選，因此告知這位「備選」應徵者我選擇了另一位。

聘到第一位支援工程師後，我意識到要同時讓多位應徵者進行試用聘僱會太困難。對開發人員，我可以同時讓多人試用，因為只要給他們不同的任務即可。但讓多位支援工程師同時在求助論壇上看到彼此的回答，並知道彼此在競爭同一個職位，感覺太過殘酷。

我仍保留 maybe-trial-hire 資料夾，以備幾個月後需要增加支援工程師時使用。我會向應徵者坦白說明目前已有一位試用中的人選，但他們可以繼續申請流程，若之後再聘請支援人員，他們會在優先名單上。或者，我也提供他們暫停申請、之後從中斷處繼續的選項。

trial-hire

我一次只會試用聘僱一個人，所以在這個階段很容易追蹤。不過，為了完整起見，我仍為招募漏斗的最後階段建立了一個資料夾。

小結

若將我的資料夾系統轉換為「招募漏斗」，各階段的數字如下：

聘僱支援工程師：薪酬支付

我目前與三位自由接案的開發者合作，每位都在不同國家。他們各自以不同方式收款。現在要增加第四位約聘人員，我想用單一解決方案來統一支付流程。

我尋找能做到以下幾點的遠端工作者支付平台：

• 盡量減少大家在請款與付款上花費的時間
• 管理法遵文件
• 管理合約文件
• 讓約聘人員能夠記錄開支
• 讓約聘人員能輕鬆追蹤計費工時，且無需安裝間諜軟體

Deel（勝出）

我最後選擇了 Deel，因為它符合我所有的需求。目前才使用一週，但情況相當順利。

Deel 似乎比其他供應商更透明，能清楚顯示約聘人員的銀行帳戶最終會以當地貨幣收到多少金額。其他供應商只承諾會盡力爭取好的匯率，但約聘人員只有在款項入帳時才知道最終匯率。

Deel 也計畫擴展至針對美國員工的薪資服務。這對我來說會很棒，因為我對 Justworks 和 Gusto 都不太滿意。

Pilot

Pilot 和 Deel 頗為相似。兩者都由 Y Combinator 投資，介面也同樣流暢。Pilot 不支援工時追蹤，而 Deel 有支援。

我先註冊了 Pilot，原本打算使用它，但他們花了整整一週才啟用我的帳號。在此期間，另一位創辦人提到了 Deel，於是我就改用了。看來好好引導客戶上線確實很重要。

Remote

Remote 為約聘人員提供免費支付服務。聽起來很棒，對吧？但免費服務正是我放棄它的原因。

如果 Remote 能免費提供其他業者每位約聘人員每月收費 30 至 50 美元的服務，那就有點可疑。這可能意味著他們用我意想不到的方式賺錢，例如在匯率轉換中藏有手續費。也可能代表約聘人員不是他們在意的客群，他們可能會像 Google 一再對免費服務做的那樣，突然終止服務。

Gusto

我已經使用 Gusto 作為本地員工的薪資服務。我對 Gusto 不是很滿意，但若能用單一服務支付所有人會很方便。

可惜的是，Gusto 只有在海外約聘人員每個支薪週期領取固定金額時才支援。如果你的約聘人員每週工時不同，Gusto 就無法使用。

舊有專案（RIP）

我過去會在回顧中固定保留一個區塊來更新舊有事業的狀況，但內容已變得相當乏味。基本上都是「我什麼都沒做，以下是這對指標的影響。」

我將把「舊有專案」替換為「Side projects（業餘專案）」，這樣就能聊聊我在週末和晚上把玩的興趣專案。

業餘專案

Lenny

Lenny 是一個會代我回覆垃圾郵件的聊天機器人。

垃圾郵件變得越來越囂張。現在垃圾郵件發送者會在我未回覆第一封郵件時，自動發送一連串後續訊息。

讓我感到惱火的是，垃圾郵件發送者可以不斷入侵我的收件匣、浪費我的時間，而他們付出的成本不過是每封郵件不到一分錢，以及每隔幾個月換個新網域。他們之所以對成千上萬的人這麼做，是因為在收到回覆前幾乎不需付出任何努力。我想找個方法來提高垃圾郵件發送者的成本，讓這種大量、半精準的郵件不再那麼划算。

我的靈感來自一個 YouTube 頻道，該頻道用語音聊天機器人來浪費電話行銷人員的時間。該頻道維護一個 VoIP 號碼來接聽電話行銷的來電，並以一位名叫 Lenny 的和藹澳洲男子的錄音來回應。這些錄音回覆總是對電話行銷人員推銷的東西表現出興趣，但又夾雜大量冗長的離題閒聊。Lenny 可能已經讓電話行銷公司損失了數萬甚至數十萬美元。

我打造了自己的 Lenny 版本，不過是用於電子郵件而非語音通話。現在當我收到垃圾郵件時，我會將它們轉寄給我自己這個以電子郵件為基礎的 Lenny。Lenny 會熱情地回覆垃圾郵件發送者，但又不斷分心、把對話繞回圈裡。

以下是兩位不同的垃圾郵件發送者，對我為聊天機器人撰寫的同一套訊息序列的回應。Lenny 成功讓每位垃圾郵件發送者都回覆了五次，之後他們都在同一個節點放棄。在第二個例子中，Lenny 的回覆在垃圾郵件訊息的脈絡中已不再合理，但垃圾郵件發送者仍持續了一陣子。

我盡量將第三方依賴降到最低，但在二月，我開始使用 Bulma CSS framework，它讓介面看起來好多了。

除此之外，我一直在努力讓定義新回覆變得更容易。目前所有回覆都寫死在程式碼中，但我希望能讓它們透過網頁介面進行編輯。

我還不確定 Lenny 這個專案會往哪裡發展。我可能會將它作為免費的開源工具發布，但我覺得人們或許願意為這種代管服務付費。目前，我只是為了自己的樂趣而開發，但希望在未來幾個月內能提供給其他人使用。

PicoShare

PicoShare 是一個用於分享檔案的簡易工具。

市面上有無數可讓你託管與分享檔案的服務，但它們總會以某種形式礙事。舉例來說，我無法只是把影片上傳到 Google Drive 然後傳送連結給別人。Google Drive 堅持要重新編碼影片，所以要等上 10 分鐘影片才會可用。即便如此，接收者還得在 Google Drive 介面中一番操作才能播放檔案。Dropbox、imgur 等服務也是一樣。

PicoShare 是一項簡單俐落、毫無麻煩的檔案分享服務。你上傳檔案後就能取得直接連結。任何擁有連結的人都可以直接檢視或下載，無需註冊帳號或觀看廣告。

我最近用 PicoShare 在家庭群組訊息中分享了一段來自《30 Rock》的短片。以下是我將該短片上傳到 PicoShare 並取得可分享連結的過程：

PicoShare 也支援為分享的檔案設定到期時間。有時我想為 TinyPilot 分享檔案，但其中可能包含敏感資料，我不希望它無限期地躺在別人的電子郵件帳號中。過去我會把檔案上傳到雲端儲存空間並分享連結，但之後還得記得刪除檔案。PicoShare 會在到期後自動刪除檔案，幫我自動化這個流程。

我才開始做 PicoShare 幾週，所以它還很粗糙。我認為這裡沒有商業機會，因為管控濫用的成本太高。目前它是開源的，但我還在快速迭代，所以還沒有投入太多心力在文件上。

總結

完成了什麼？

• 推出 TinyPilot Voyager 2 PoE
• 聘僱 TinyPilot 首位支援工程師
• 打造 PicoShare

學到的經驗

• 把招募流程當作工作關係的預演。
  • 優秀人才想與善待他們的人共事。
  • 你的職缺說明與招募流程應該向應徵者展現你會尊重他們並珍惜他們的時間。
• 如果職缺說明寫得千篇一律，你就無法辨識出罐頭申請。
  • 如果你寫出制式的職缺說明，就會收到對你的公司毫無具體著墨的罐頭申請。
  • 利用職缺說明讓你的公司與眾不同。提供應徵者在求職信中可以談論的獨特內容，以證明他們有用心了解你的公司。
• 善待應徵者成本很高，但能讓人感到愉悅。
  • 尊重地對待被婉拒的應徵者要花 10 倍的時間，但這不代表你就該省略。
  • 身為創辦人，即使對你沒有直接好處，你仍可以選擇如何對待他人。

下個月的目標

• 發布 TinyPilot Pro 2.4.0
• 完成 TinyPilot 網站的設計改版
• 完成 TinyPilot 新任支援工程師的入職流程