一句話總結

招募 TinyPilot 的第一位支援工程師

亮點

• 聘請了 TinyPilot 的第一位支援工程師。
• 體認到招募支援工程師比想像中還要困難。
• 正在評估用來支付海外約聘人員的平台。

目標成績

每個月月初，我都會訂下當月想完成的事。以下是達成狀況：

推出 Voyager 2：PoE 版本

• 結果：終於推出 Voyager 2 PoE 了
• 成績：A

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

招募 TinyPilot 支援工程師

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

為了這個職位花了不少功夫，但很開心團隊多了新成員。這篇回顧主要就是在講招募支援工程師的過程，細節請繼續往下看。

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

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

合作的設計公司在二月能投入的時數太少，做不完。我已經和他們談好三、四月保證投入的時數，預計這個月底可以完成。

TinyPilot 數據

自一月以來銷售大致持平。總銷售額因二月天數較少而略降，但若以單日平均來看，其實比一月更好。

二月的利潤異常地高，但主要是時間差造成的。我還在等幾張大額帳單入帳，而且我的企業信用卡額度剛好提高了 2 萬美元，所以手上現金看起來比較多。

招募支援工程師：職缺公告

過去幾個月我一直想聘一位支援工程師，但一直抽不出時間。花的時間比預期還久，不過總算聘到了第一位支援工程師。第一步是建立職缺公告。

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

招募的難處之一在於，身為小企業主，我希望找到能理解我的公司在做什麼、並在應徵時展現這一點的人。問題是，大多數公司對待求職者的方式很糟。這造成一種生態：求職者不願意對任何一家公司投入太多心力，因為有九成機率履歷根本石沉大海。

寫職缺公告時，我試著清楚傳達我會親自閱讀每一份申請。你的申請不會丟給機器學習機器人，或是只會用關鍵字篩選、對職務一知半解的招募人員。如果你用心，我也會用心回應。

我也希望求職者在整個招募流程中都能感受到我尊重他們的時間，因為這正是我希望未來一起工作時的相處方式。

很多職缺公告會寫：「請在求職信中提到 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 工作的樣貌有個概念：「如果他們連面試題目的程式碼審查都做得這麼好，那跟這個團隊一起做真正的產品程式碼一定更棒！」

-Andrew Lee，“How Firebase Interviewed Software Engineers”

Andrew 的做法一直讓我印象深刻，覺得那才是對待人的正確方式，所以我在招募任何職位時都盡量套用這種心態。

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

在回答題目的人當中，有 17 位（共 19 位中的 89%）被歸到 questions-reject 資料夾。

maybe-trial-hire

在招募的第一週，有一位求職者範例題目答得還不錯，但我仍有些顧慮。他是目前為止看過最好的一位，但我想再看看其他人選。我告訴他幾週內會給他答覆，並把他放進 maybe-trial-hire 資料夾。後來我找到了更適合的人選，就告知這位「備選」求職者我選擇了另一位。

聘到第一位支援工程師後，我發現要同時讓多位人選進行試用聘僱太困難。對開發人員，我可以同時讓多人試用，只要指派不同任務就好。但讓多位支援工程師同時在求助論壇上看到彼此的回答、明知大家在競爭同一個職位，感覺太殘酷了。

我還是保留著 maybe-trial-hire 資料夾，以防幾個月後需要增加支援人力。我會向求職者坦白說明目前已有一位試用中的人選，但他們可以繼續完成申請流程，未來若再招募，他們會在優先名單上。或者，我也讓他們選擇先暫停申請，之後再從中斷的地方繼續。

trial-hire

當時我一次只試用一個人，所以在這個階段很好追蹤。但為了完整起見，我還是為招募流程的最後階段建了一個資料夾。

Summary

把我的資料夾系統轉換成「招募漏斗」來看，各階段的數字如下：

招募支援工程師：薪資支付

目前我和三位自由接案的開發者合作，每位都在不同國家，也都用不同方式收款。現在要再增加第四位約聘人員，我想應該用一套統一的方案來處理付款。

我在尋找能做到以下幾點的遠距工作付款平台：

• 讓大家在請款和付款上花的時間降到最低
• 處理法遵文件
• 管理合約文件
• 讓約聘人員可以報帳
• 讓約聘人員能輕鬆記錄計費時數，且不需要安裝監控軟體

Deel（勝出）

最後我選擇了 Deel，因為它完全符合我的需求。目前只用了一週，但體驗不錯。

Deel 似乎比其他供應商更透明，會清楚顯示匯入約聘人員當地銀行帳戶的實際金額，並以當地貨幣呈現。其他供應商只會說會盡量提供好的匯率，但約聘人員要等到款項入帳才知道最終匯率是多少。

Deel 也計畫擴展到美國本地員工的薪資服務。這對我來說是好消息，因為我對 Justworks 和 Gusto 都不太滿意。

Pilot

Pilot 和 Deel 滿像的。兩家都是 Y Combinator 投資的公司，介面也都設計得很流暢。Pilot 不支援工時追蹤，而 Deel 有。

我一開始先註冊了 Pilot，也本來打算用它，但他們花了整整一週才開通我的帳號。這段期間，另一位創辦人向我推薦了 Deel，所以我就換過去了。看來把客戶的 onboarding 做好確實有回報。

Remote

Remote 為約聘人員提供免費付款服務。聽起來很棒，對吧？免費反而讓我打退堂鼓。

如果 Remote 能免費提供別人每月每人收 30 到 50 美元的服務，那肯定有哪裡不對勁。可能是他們用其他意想不到的方式從我身上賺錢，例如在匯率轉換中藏手續費。也可能是約聘人員根本不是他們在乎的使用情境，之後可能像 Google 對免費服務那樣說收就收。

Gusto

我已經用 Gusto 來處理本地員工的薪資。雖然我對 Gusto 不是很滿意，但如果能用同一套服務付給所有人，會比較方便。

可惜 Gusto 只支援每個支付週期領固定金額的海外約聘人員。如果你的約聘人員每週工時不同，Gusto 就不適用。

舊專案（RIP）

我以前會在回顧中固定更新舊事業的近況，但內容越來越無聊，基本上都是：「什麼都沒做。以下是這對數據的影響。」

我打算把「舊專案」改成「業餘專案」，這樣就能聊聊我在週末和晚上玩的興趣專案。

業餘專案

Lenny

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

垃圾郵件越來越囂張。現在垃圾郵件發送者甚至會在我沒回第一封信時，自動寄送一連串的追蹤郵件。

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

我的靈感來自一個 YouTube 頻道，他們用語音聊天機器人來浪費電話行銷人員的時間。這個頻道維護了一個 VoIP 號碼，接聽行銷電話並用一位名叫 Lenny 的和藹澳洲老先生的錄音來回應。那些錄音總是對行銷人員推銷的東西表現出興趣，但又會不斷岔題、東拉西扯。Lenny 大概已經讓電話行銷公司損失了數萬甚至數十萬美元。

我自己也做了一個類似 Lenny 的版本，不過是針對電子郵件而不是語音通話。現在收到垃圾郵件時，我會把它轉寄給我自己的 Email 版 Lenny。Lenny 會熱情地回覆垃圾郵件發送者，但又會一直分心、把對話繞回原地打轉。

以下是兩個不同的垃圾郵件發送者，對我為聊天機器人寫的同一套訊息序列的回應。Lenny 在同一個地方讓兩邊都回了五次才放棄。在第二個例子中，Lenny 的回覆在語境上已經不太通順，但對方還是持續了一陣子。

我盡量把第三方依賴降到最低，不過二月開始用了 Bulma CSS framework，讓介面好看多了。

除此之外，我一直在讓定義新回覆變得更容易。目前所有回覆都寫死在程式碼裡，但我希望未來能透過網頁介面直接編輯。

我還不確定 Lenny 這個專案會往哪裡走。我可能會把它當作免費的開源工具釋出，但也覺得或許有人願意為這種代管服務付費。目前就只是為了好玩、做給自己用，但希望未來幾個月能提供給其他人使用。

PicoShare

PicoShare 是一個簡單的檔案分享工具。

市面上有上百萬個可以代管和分享檔案的服務，但每一個都會在某個環節礙手礙腳。舉例來說，我沒辦法直接把影片上傳到 Google Drive 然後丟個連結給別人。Google Drive 堅持要重新轉檔，所以上傳後還要等十分鐘影片才會可用。就算可用了，收件者還得在 Google Drive 的介面裡繞來繞去才能播放。同樣的情況也發生在 Dropbox、imgur 等等。

PicoShare 是一個不花俏、不囉嗦的檔案分享服務。你上傳檔案後就能拿到直接連結，任何有連結的人都能直接檢視或下載，不用註冊帳號、也不用看廣告。

我最近用 PicoShare 在家庭群組裡分享了一段《娛樂揸Fit人》（30 Rock）的短片。以下是上傳短片到 PicoShare 並取得可分享連結的過程：

PicoShare 也支援為分享的檔案設定到期時間。有時我想為 TinyPilot 分享檔案，但裡面可能有敏感資料，不想讓它永遠躺在別人的信箱裡。過去我會把檔案上傳到雲端空間再分享連結，但之後還得記得去刪除。PicoShare 會在到期後自動刪除檔案，幫我省去這個麻煩。

我才開始做 PicoShare 幾週，所以還很粗糙。我覺得這裡面沒什麼商機，因為處理濫用的成本太高。目前它是開源的，但我還在快速迭代，所以還沒花太多心力在文件上。

總結

完成了什麼？

• 推出了 TinyPilot Voyager 2 PoE
• 聘請了 TinyPilot 的第一位支援工程師
• 打造了 PicoShare

學到的教訓

• 把招募流程當作未來工作關係的預演。
  • 優秀的人才想和會善待他們的人一起工作。
  • 你的職缺說明和招募流程應該讓求職者感受到你會尊重他們、珍惜他們的時間。
• 如果職缺說明很籠統，就無法辨識出罐頭申請。
  • 如果你寫了一份籠統的職缺說明，只會收到一堆對你的公司毫無針對性的罐頭申請。
  • 要用職缺說明把你的公司和其他公司區隔開來。給求職者一些獨特的切入點，讓他們能在求職信中展現自己有花心力了解你的公司。
• 善待求職者很花成本，但會讓人感動。
  • 用尊重的方式對待被婉拒的求職者，要花十倍時間，但不代表就該跳過。
  • 身為創辦人，你可以自己選擇如何對待他人，即使這對你沒有直接好處。

下個月的目標

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