TinyPilot: Month 26

Michael Lynch

TinyPilot:第 26 個月

原文由 Michael Lynch 發布,訂閱此部落格

一句話總結

徵才,比想像中困難得多。

本月亮點

  • TinyPilot 創下有史以來表現最好的一個月,營收逼近 8 萬美元,比先前的最高紀錄高出 15%。
  • 這次職缺公告收到的應徵數量,是半年前刊登同樣職缺時的 8 倍。
  • 關於徵才,我有不少心得想分享。

目標達成度

每個月月初,我都會訂下當月想完成的目標。以下是這個月的達成狀況:

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

  • 結果:已完成 TinyPilot Community 的遷移,但 TinyPilot Pro 還沒準備好。
  • 成績:C+

我們從五月就開始全面翻新 TinyPilot 的更新系統,花費的時間遠比我們任何人預期的都還要久。

在最初的兩年裡,我在 TinyPilot 的更新系統中累積了不少技術債。我們現在正在償還,但也因此不斷遇到意料之外的狀況,每次都要多花一週以上的開發時間。不過我相當有信心,現在已經進入最後幾週的收尾階段了。

確定 TinyPilot 授權管理方案

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

我們已經敲定了 TinyPilot 授權的管理方案,我認為參與的每個人都很滿意。這個方案能提供流暢的使用者體驗,同時將工程上的複雜度降到最低。

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

  • 結果:忙著徵才,沒時間處理這件事。
  • 成績:F

這項目標完全沒有進展。我其實應該把徵才直接列為目標之一才對,因為這個月大部分時間都在忙這件事。

TinyPilot 數據

指標2022 年 7 月2022 年 8 月變化
不重複訪客21,24211,903-9,339 (-44%)
總瀏覽次數33,57823,214-10,364 (-31%)
銷售營收$56,954.66$76,082.06+$19,127.40 (+34%)
企業訂閱$290.70$290.700
權利金$2,513.71$3,264.23+$750.52 (+30%)
總營收$59,759.07$79,636.99+$19,877.92 (+33%)
獲利$-12,349.21$21,580.82+$33,930.03 (+inf%)

八月是 TinyPilot 營收與獲利的創紀錄月份。我在七月底將價格調降了 11%,看起來這讓銷售額成長了 34%。而且又是一個「無聊」的一個月——沒有任何外部事件推動這些數字,因此我對於能夠維持這樣的表現感到樂觀。

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

如何應對暴增 8 倍的應徵量

我在八月聘請了第二位支援工程師,這次的經驗與半年前招聘同一職位時截然不同。

上次我在30 天內收到 221 份申請。這次僅僅兩週就收到了 802 份。應徵者多到我必須主動設法減緩速度,最後在兩週後完全關閉了申請管道。

我想先暫停職缺公告,好讓自己有時間消化回覆。惱人的是,We Work Remotely 不讓你暫時隱藏職缺。你要嘛永久刪除、放棄已付費的刊登時間,要嘛就讓它繼續曝光,吸引多到你無法負荷的應徵者。

作為變通辦法,我讓職缺繼續刊登,但把地點需求從「全球皆可」改成「僅限美國」。這個職位其實並沒有硬性要求應徵者必須住在美國,但這是我能想到在不完全下架公告的前提下,最能減緩申請湧入的方法。

每日申請數量圖表

加上地點限制後,新增申請的速度確實減緩了大約一半。不過,仍有許多應徵者直接忽略這項要求。加上限制後,只有 42% 的應徵者表示自己確實住在美國,相較之下,限制前的比例是 18%。

兩週後我關閉了申請,因為已經收到 802 份申請,我知道自己無法夠快地處理完所有案件,及時給予每位應徵者回覆。

為什麼這次的應徵者會多這麼多?以下是我的推測:

結構化的網頁表單比電子郵件更讓人沒有壓力

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

缺點是,網頁表單似乎也吸引了更多隨便投遞的應徵者。上次有 18% 的 We Work Remotely 應徵者強到足以通過初步的履歷篩選,這次只有 6% 能進入下一階段。

更多的徵才管道意味著更多的應徵者

我還把職缺多刊登到兩個管道:RemoteOK 和 Craigslist。Craigslist 似乎沒有帶來太多應徵者,但 RemoteOK 在兩週內帶來了 127 位。

景氣下滑意味著更多求職者

最後,全球經濟比我半年前徵才時更糟。對經濟衰退的擔憂增加,徵才的公司也變少了。我猜現在比起年初,更像是雇主市場。

比較遠端職缺的刊登管道

透過這次過程,我發現不同徵才管道的投資報酬率差異非常大。

我在意的兩個指標是:

  • 合格應徵者的人數
  • 合格應徵者在總應徵者中的比例

我希望一個平台能為每個職缺帶來約 10 到 20 位合格的應徵者,讓我有足夠的人選可以挑選。如果平台的訊噪比太差,讓我必須篩選 3,000 人才能找到幾個合格的人,那它就沒有價值。

在這次評估中,我把所有通過履歷篩選的人都視為合格的應徵者。而且我只計算職缺開放給全球應徵的那五天內的申請。一方面是因為更改地點限制會造成偏差,另一方面也是因為我還沒處理完其他所有的申請。

管道花費應徵總數通過初步篩選每位合格應徵者成本試用聘僱
We Work Remotely$39835920 (6%)$200
Remote OK$448670 (0%)N/A0
Craigslist$2531 (33%)$250
Hacker News$020 (0%)N/A0
其他彙整網站$0531 (8%)$00
不明/直接應徵*$0523 (15%)$01
總計$87146425 (5%)$351

*「不明」類別包含透過 TinyPilot 網站上連結應徵的人,因此也包括在 Twitter 或其他地方看到我發文的人。我最終錄用的人就是透過我的推文找到這份工作的。

We Work Remotely 的表現相當不錯。它當然也有不少隨便投遞和垃圾申請,但能在 359 人中找到 20 位合格者,算是相當不錯的比例。

RemoteOK 在這段期間內沒有帶來任何合格的應徵者,而我使用它的體驗糟到值得另闢一節來談。

RemoteOK 讓人非常失望

我一直以來都很欣賞Pieter Levels他在 Indie Hackers 播客上的訪談是該系列最精彩的集數之一。Pieter 非常擅長點出自給自足的創業者(bootstrapper)生活方式為何令人興奮又自由。

可惜的是,Pieter 的旗艦事業 RemoteOK 卻讓人大失所望。我已經想不起上次使用一個感覺如此頑固地與付費用戶作對的產品是什麼時候了。

一開始建立職缺時,RemoteOK 就會向你推銷一堆額外的加價選項。

Remote OK 上加價選項的截圖

RemoteOK 要求雇主在九種加價選項中做選擇,包括花 134 美元產生一個 QR code。

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

RemoteOK 的職缺有標籤可幫助應徵者搜尋,所以我加上了 linuxcustomer supportflexible schedule 等標籤。幾小時後我再回來看,卻發現 RemoteOK 自動加上了幾個不正確的標籤,像是 microsoftwindowswebdevdevelopment,儘管這些跟我的職缺一點關係都沒有。我刪掉了 RemoteOK 加的標籤,但隔天它們又出現了。我唯一能永久移除它們的方法,就是自己再多加一些標籤。

RemoteOK 剝奪使用者主控權最誇張的例子,就是它的「通關密語」功能。RemoteOK 會加上這樣的指示:「申請時請提及單字 [某個隨機單字] 以證明你已完整閱讀職缺說明。」RemoteOK 並不會告訴你它加了這些指示,而且你無法移除它們

雇主視角顯示我撰寫的說明應徵者視角包含額外文字:Please mention the word EMINENCE when applying to show you read the job post completely.

RemoteOK 會偷偷在你給應徵者的資訊中注入額外指示,而你自己卻看不到。你無法關閉這個行為

我討厭、討厭、非常討厭這個功能。要是我早知道有這回事,根本就不會在 RemoteOK 上刊登職缺。

我覺得這種「通關密語」的要求對應徵者是一種侮辱,所以我在刊登職缺時刻意避免這類要求。RemoteOK 竟然偷偷把它塞進我付費刊登的職缺中,實在令人非常惱火。

最致命的是,RemoteOK 在它唯一的任務上徹底失敗:提供合格的應徵者。在同一段時間內,RemoteOK 的應徵者沒有一位通過我的初步篩選,而 We Work Remotely 卻幫我媒合到 20 位合格的應徵者。

更新(2022-09-25):針對這篇文章,Pieter Levels 承諾會著手處理我提到的問題,並大方地退還了我的款項。

Homerun 不錯,但不到優秀

上次徵才時,我請應徵者直接寫信給我,然後用收件匣的標籤來整理申請。結果搞得一團亂、難以管理。

這次我測試了好幾個應徵者追蹤系統,最後選定了 Homerun

完整跑過一次招募流程後,我對 Homerun 還算滿意。介面好看,也具備我需要的所有功能。一切都相當直覺,讓我能有條理地處理申請。

在 Fastmail 中使用收件匣標籤的截圖Homerun 以看板視圖依招募階段整理應徵者

上次我用電子郵件的收件匣標籤來整理應徵者(左)。這次我使用 Homerun,它以看板視圖來整理申請,組織性更好(右)。

我很喜歡 Homerun 的範本郵件功能。我很少直接寄制式信給應徵者,但對於常見的回覆,有個基本的架構非常有幫助,例如:

  • 你的 Linux 經驗不足
  • 你的英文程度未達職位要求
  • 你是很棒的人選,我們來進入範例題目吧
嗨 [first_name],感謝你應徵 [company_name] 的 [job_title] 職缺,並花時間了解公司。很遺憾,我認為這個職位不太適合你的技能。這個職位需要更有撰寫面對客戶內容經驗的人。你的英文已經相當不錯,但在申請資料中有幾個句法錯誤,所以我覺得這個職位不太適合。很抱歉這次沒能合作,祝你求職順利。

我為不同常見類別的郵件建立了範本,作為撰寫時的起點。

Homerun 的費用是每月 71 美元,對大多數小企業來說都在可負擔範圍內。而且它的計費方式很合理,不在徵才的月份就不用付費。大多數其他的應徵者追蹤平台在你停止支付全額月費後,就會刪除你所有的資料。Homerun 則允許你在沒有積極徵才時降級到免費方案,這樣就能保留所有資料。免費方案唯一的限制是,在你重新付費之前無法接受新的應徵者。

我也確實遇到 Homerun 幾個明顯的缺點:

無法篩選應徵者

面對這麼大量的應徵者,我希望能有方法及早聯繫最有潛力的人。我很想篩選出住在英語系國家、且自評 Linux 熟練的應徵者。Homerun 雖然有這些資料,卻沒有提供任何依此條件篩選的功能。要在待審清單中找到這些人,唯一的方法就是一份一份地逐一審閱。

糟糕的郵件使用體驗

Homerun 最糟的介面設計之一就是它的郵件功能。跟所有應徵者追蹤系統一樣,Homerun 讓你在網頁應用程式內直接寄信給應徵者。但它的作法是彈出一個強制回應視窗:

Homerun 中阻擋所有應徵者相關資訊的強制回應視窗截圖

Homerun 的應用程式內郵件會產生一個強制回應視窗,讓你在寫信給應徵者時無法參考對方的申請資料。

這個強制回應視窗會完全遮住應徵者在申請中寫的所有內容,讓你無法參考自己的筆記、對方的履歷,或他們在申請表上對問題的回答。這是個非常糟糕的設計,因為雇主在回覆應徵者時顯然需要這些資訊。

我的變通方法是同時並排開啟兩個 Homerun 視窗。這樣還算可行,但 Homerun 在不同瀏覽器視窗之間的同步很差。如果我在一個視窗中將某位應徵者標記為婉拒,另一個視窗就會錯亂,並重新載入到申請清單的最頂端。

郵件寄達率不佳

我把範例作業以 PDF 連結的形式寄給應徵者,但有好幾位告訴我他們沒收到。我懷疑 Homerun 使用的郵件伺服器寄件者信譽不佳,導致垃圾郵件過濾器擋掉了內含連結的 Homerun 郵件。

網頁應用程式速度緩慢

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

下次徵才想改進的地方

我對這次徵才過程中對待應徵者的方式感到不滿意。我沒有為這麼大的申請量做好準備,也因為接受了超出我在合理時間內能處理的申請數量,而浪費了應徵者的時間。

以下是為了改善所有人的徵才體驗,我下次打算做的一些改變。

在回覆上更保守一點

剛開始用 Homerun 處理申請時,我對它的郵件範本有點過於熱衷。上一次徵才時,如果應徵者寄來很隨便的申請,我就直接忽略。有了 Homerun 後,透過範本即使對那些很不用心的應徵者也能輕鬆回覆。

我做了一個範本,大意是因為對方的申請看起來像是複製貼上的,所以予以婉拒。我想至少給個回饋,讓他們知道這樣複製貼上的申請會讓他們失去工作機會,應該是好事。

嗨 [first_name],感謝你應徵 TinyPilot 的 [job_title] 職缺。很遺憾,我決定這次不繼續處理你的申請。我閱讀了你提交的問答內容,感覺不到有任何關於公司或工作本身特別吸引你的地方,所以我認為這不會是個合適的配對。很抱歉這次沒能合作,祝你求職順利。

我給那些以複製貼上方式填寫申請的應徵者的制式回覆。

這個策略效果很差。

在有回覆的應徵者中,約 50% 的人態度大方、感謝我的回饋,這部分還不錯。約 20% 的人則很無禮或帶有敵意,這就很糟了。

剩下 30% 的人則意識到終於有真人在跟他們互動,他們的申請並沒有像他們以為的那樣石沉大海。這時他們才開始研究公司,並表示他們其實對 TinyPilot 特別感興趣。這讓我陷入尷尬的處境。如果我重新考慮他們的申請,對那些一開始就認真撰寫、用心回答,而非對每家公司都貼上同樣內容的應徵者來說,就顯得不公平。

在這種隨便投遞的申請上浪費了一兩天後,我就不再回覆這類應徵者了。我把策略改為只有在符合以下條件時才回覆:

  • 應徵者在基本層面上符合職位資格
    • 例如,如果職位要求之一是「熟悉 Linux」,而應徵者表示從未使用過 Linux:不回覆。
  • 應徵者至少花了幾分鐘認真填寫申請
    • 例如,如果回答明顯是複製貼上或隨手寫的:不回覆。

這個新策略還有個令人愉快的副作用:消除了帶有敵意的回覆。當我婉拒那些認真作答的應徵者並說明原因時,他們不一定會回覆,但一旦回覆,態度都很專業,也感謝我的回饋。

找人協助我做初步篩選

篩選履歷和申請要花上數十小時,但這是我可以輕易訓練一個聰明的人來幫我做的工作。

我不想使用笨拙的自動篩選或機器學習——對我來說,能誠實地告訴應徵者有真人在審閱他們的申請是很重要的。只是那個人不一定非得是我。

為客戶支援建立備援

延誤我回覆應徵者的因素之一,是平常負責客戶支援的 TinyPilot 員工請了一週病假。客戶支援感覺上是有備援的,因為我們的支援工程師可以代班。如果還是不行,我就是最後一道防線。但當平常負責支援的人請病假時,我才意識到我們的客戶支援流程有多脆弱。

當我親自處理時,才想起客戶支援的工作量有多大,尤其還要額外應付與 800 位求職者的聯繫。除此之外,我還休了幾天假,這意味著那幾天只有 TinyPilot 的支援工程師在提供支援。情況有點吃緊,因為他沒有 Shopify 或我們本地出貨辦公室的存取權限,能提供的支援很有限。

等支援工程團隊穩定下來後,我也打算再增加一位負責客戶支援的人。這樣當有人請病假或休假時,才能維持運作順暢。

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

就算找其他人來幫忙徵才,我們能在合理時間內審閱的申請數量還是有上限。一旦超過像是 400 位這樣的門檻,我就應該把申請表轉為候補名單,以免要求應徵者解釋為何想加入我們,卻又浪費他們的時間。

記住這件事有多花時間

我以前也曾透過刊登職缺來徵才,但直到再次經歷,才想起這個過程有多耗時。

在我腦海中,時間投入看起來是這樣:

在我心中想像的徵才過程

第一天就會湧入大量應徵者,大家都在同一天申請。我篩選這些應徵者,直到縮小到只剩一個人。最後,我聘用了那個人,他開始處理我以前在做的事,一切都變得很美好。

實際上的徵才過程

實際上,會先有一大波應徵者湧入,然後在我處理這些申請的同時,還不斷有人繼續投遞。接著當我終於聘到人時,還得一邊引導新人到職、培訓新人,一邊跟所有沒被錄取的人做後續聯繫。

所以,下次徵才時,我只要回頭看看這兩張精美又充滿資訊量的圖表,就會提醒自己需要預留大量空檔來應付這一切。

總結

完成了哪些事?

學到的教訓

  • 徵才總是比我想像的更困難

下個月的目標

  • 將 TinyPilot Pro 遷移至新一代更新系統。
  • 將 TinyPilot Voyager 寄給兩位 YouTube 創作者或部落客試用評測
  • 探索新的外殼製造選項

本文章由 muse-spark-1.2-contributor 進行翻譯

留言