TinyPilot:第 26 个月
一句话总结
招聘的难度出乎意料。
亮点
- TinyPilot 迎来了有史以来最好的一个月,营收接近 8 万美元,超出此前纪录 15%。
- 我这次招聘启事的回复率是六个月前发布同一职位时的 8 倍。
- 关于招聘,我有不少想法想说说。
目标评分
每个月初,我都会宣布本月想要完成的目标。以下是我对这些目标的完成情况:
将 TinyPilot Community 和 TinyPilot Pro 迁移到下一代更新系统
- 结果:我们迁移了 TinyPilot Community,但 TinyPilot Pro 还没准备好。
- 评分:C+
我们从五月开始就在 overhaul TinyPilot 的更新系统,耗时远超我们所有人的预期。
在前两年里,我在 TinyPilot 的更新系统中积累了大量技术债。现在我们正在偿还这些债务,但这也意味着我们会不断遇到吃掉一周甚至更多开发时间的意外情况。我相当有信心现在已经进入最后几周了。
敲定管理 TinyPilot 许可证的方案
- 结果:方案已敲定。
- 评分:A
我们已经敲定了管理 TinyPilot 许可证的方案,我认为所有相关的人都很满意。它提供了流畅的用户体验,并将工程复杂度降到最低。
把 TinyPilot Voyager 寄给两位 YouTube 创作者或博主进行评测
- 结果:我忙于招聘,没能顾上这件事。
- 评分:F
这方面我没有取得任何进展。我真应该把招聘列为本月目标之一,因为那正是我这个月大部分时间在做的事。
TinyPilot 数据统计
| 指标 | 2022 年 7 月 | 2022 年 8 月 | 变化 |
|---|---|---|---|
| 独立访客数 | 21,242 | 11,903 | -9,339(-44%) |
| 总页面浏览量 | 33,578 | 23,214 | -10,364(-31%) |
| 销售收入 | $56,954.66 | $76,082.06 | +$19,127.40(+34%) |
| 企业订阅收入 | $290.70 | $290.70 | 0 |
| 版税收入 | $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 份申请,我知道自己无法足够快地处理完所有申请、及时回复候选人。
为什么这次的申请者多了这么多?以下是我的猜测:
结构化的网页表单比电子邮件更不让人望而生畏
我认为最大的因素是这次候选人通过网页表单提交申请。上次,我只是让人们直接给我发一封包含简历和求职信的邮件。我猜人们填写结构化表单时感觉更自在,所以这鼓励了更多人前来申请。
缺点是网页表单似乎吸引了更多低投入的申请人。上次,We Work Remotely 的申请人中有 18% 足够优秀、能通过初筛。而这次,只有 6% 通过了第一阶段。
更多的招聘渠道意味着更多的候选人
我把职位额外发到了两个渠道:RemoteOK 和 Craigslist。Craigslist 似乎没带来多少申请人,但 RemoteOK 在两周内带来了 127 人。
经济下行意味着更多求职者
最后,如今全球经济比我六个月前招聘时更糟糕。对衰退的担忧更多,招聘的公司更少。我猜现在的市场比今年早些时候更偏向雇主一方。
比较各远程职位广告渠道
通过这次流程,我发现不同的招聘渠道的投资回报率差异巨大。
我关心的两个指标是:
- 合格候选人的数量
- 合格候选人占总申请人的比例
我希望平台能为每个职位提供大约 10-20 名合格候选人,这样我就有一个像样的备选池。如果平台的信噪比差到我要筛选 3000 人才能找到几个合格的,那它就没有价值。
为了本次评估的目的,我把通过我简历初筛的所有人都视为合格候选人。我也只考虑职位面向全球开放的五天内的申请。这一方面是因为更改地点要求会使回复产生偏差,另一方面是因为我还没处理完其他所有申请。
| 渠道 | 成本 | 候选人总数 | 通过初筛人数 | 每位合格候选人的成本 | 试用录用 |
|---|---|---|---|---|---|
| We Work Remotely | $398 | 359 | 20(6%) | $20 | 0 |
| Remote OK | $448 | 67 | 0(0%) | N/A | 0 |
| Craigslist | $25 | 3 | 1(33%) | $25 | 0 |
| Hacker News | $0 | 2 | 0(0%) | N/A | 0 |
| 其他聚合网站 | $0 | 53 | 1(8%) | $0 | 0 |
| 未知 / 直接申请* | $0 | 52 | 3(15%) | $0 | 1 |
| 总计 | $871 | 464 | 25(5%) | $35 | 1 |
* “未知”类别包括通过 TinyPilot 网站上的链接申请的候选人,因此也包括那些看到我在 Twitter 或其他地方发帖的人。我最终的录用者是通过我的推文找到这份工作的。
We Work Remotely 表现相当不错。它也有不少低投入和垃圾申请者,但从 359 人中找到 20 名候选人是相当不错的比例。
RemoteOK 在这个时间段内没有产出任何合格候选人,而我使用它的体验糟糕到值得单独写一节。
RemoteOK 令人大失所望
长期以来我一直很喜欢 Pieter Levels(彼得·莱弗斯)。他在 Indie Hackers 播客上的访谈是该系列最好的一期之一。Pieter 非常擅长展现自力更生创业者生活方式的激动人心与自由自在之处。
遗憾的是,Pieter 的旗舰业务 RemoteOK 却让我大失所望。我不记得上一次使用一个如此顽固地与作为付费用户的我作对的产品是什么时候了。
一开始,当你创建职位帖子时,RemoteOK 就会向你推销各种附加付费项目。

RemoteOK 迫使雇主在九种不同的附加付费项目中选择,其中包括花 $134 生成一个二维码。
We Work Remotely 也尝试类似的推销,但它们没那么令人反感。也许是因为 We Work Remotely 没有收你 $134 来生成二维码。
RemoteOK 的职位带有标签以帮助申请人搜索,所以我添加了诸如 linux、customer support、flexible schedule 这样的标签。几个小时后我再回到该职位页面时,发现 RemoteOK 自动添加了好几个不准确的标签,比如 microsoft windows webdev development,尽管这些与我的职位毫无关系。我删掉了 RemoteOK 的标签,但第二天它们又回来了。我能永久摆脱它们的唯一办法就是自己再添加更多标签。
RemoteOK 剥夺用户控制权最恶劣的例子是它的“魔法关键词”。RemoteOK 会添加这样一条指令:“请在申请时提及单词[某个随机单词],以表明你完整阅读了职位描述。”RemoteOK 不会告诉你它添加了这些指令,而且你也无法删除它们。


RemoteOK 会向你的候选人注入你看不到的额外指令。你无法禁用这种行为。
我讨厌、讨厌、非常讨厌这个功能。如果早知道这一点,我根本不会把职位发到 RemoteOK 上。
我觉得这类“魔法关键词”要求是对申请人的侮辱,我在为自己的职位做宣传时刻意排除此类做法。RemoteOK 偷偷把它注入到我购买的职位帖子中,实在令人恼火至极。
最致命的是,RemoteOK 完全搞砸了它的本职工作:提供合格候选人。RemoteOK 的候选人没有一个通过我的初步申请筛选,而 We Work Remotely 在同一时间段内为我匹配到了 20 名合格申请人。
更新(2022-09-25):针对这篇文章,Pieter Levels 承诺会解决我提到的问题,并慷慨地退还了我的付款。
Homerun 不错,但不完美
上次招聘时,我让候选人直接给我发邮件,然后用收件箱标签来整理申请。结果一团糟,令人困惑。
这一次,我测试了几款 ATS(Applicant Tracking System,申请人跟踪系统),最终选定了 Homerun。
在完整的招聘流程中使用 Homerun 之后,我相当满意。界面好看,也满足了我的一切需求。一切都相当直观,因此可以有条理地处理申请。


上次我用收件箱标签在邮箱里整理申请人(左)。这次我用了 Homerun,它通过看板视图对申请进行更好的组织(右)。
我很喜欢 Homerun 的邮件模板功能。我很少给候选人发纯套话信件,但对于常见的回复来说,有一个现成的骨架结构很有帮助,比如:
- 你的 Linux 经验不足
- 你的英语水平达不到该职位的要求
- 你是位很棒的候选人,让我们进入示例问题环节吧
![你好 [first_name],感谢你申请 [company_name] 的 [job_title] 职位,并抽出时间进一步了解公司。很遗憾,我认为这个职位与你的技能不太匹配。该职位需要一位在撰写面向客户的内容方面更有经验的人。你的英语相当不错,但你的申请中有若干语法错误,所以我认为这个角色并不适合你。很抱歉未能如愿,祝你在求职中一切顺利。](https://mtlynch.io/retrospectives/2022/09/poor-english-rejection.png)
我为不同常见类别的邮件创建了模板作为起点。
Homerun 每月收费 $71,对大多数小企业来说都在可负担范围内。而且计费方式很公平:你不招聘的月份无需付费。大多数其他申请人跟踪平台在你停止支付全额月费时会删除你的全部数据。Homerun 允许你在没有积极招聘时降级到免费计划,从而保留你的所有数据。免费版的唯一限制是在你重新开始付费之前不能接收新的申请人。
不过我确实遇到了 Homerun 的几个大缺点:
无法筛选候选人
面对如此大量的候选人,我想尽早联系最有希望的那些。我很希望能筛选出住在英语国家且自评精通 Linux 的候选人。Homerun 有这些数据,却不提供任何按这些条件筛选候选人的方式。在我的队列中找到这些申请人的唯一办法就是逐一审阅每份申请。
糟糕的邮件用户体验
Homerun 最糟糕的 UI 决策之一就是其邮件功能的工作方式。和所有申请人跟踪系统一样,Homerun 允许你在其 Web 应用内给候选人发邮件。但它是通过弹出一个模态窗口来实现的:

Homerun 的应用内邮件会创建一个模态窗口,导致你在给候选人写邮件时无法参考他们的申请内容。
这个模态窗口完全遮挡了候选人在申请中写的所有内容,所以你无法参考自己的笔记、他们的简历或他们对申请表问题的回答。这是一个糟糕的设计,因为雇主在回复候选人时显然需要这些信息。
我的变通办法是把 Homerun 在两个并排的窗口中打开。这还算凑合,但 Homerun 在浏览器窗口之间的同步不太好。如果我在一个窗口中把某位候选人标记为拒绝,另一个窗口就会混乱并从头重新加载申请人列表。
邮件送达率差
我把示例作业以 PDF 链接的形式发给候选人,但有几位候选人告诉我他们没有收到。我怀疑 Homerun 使用的邮件服务器发件人信誉较弱,所以垃圾邮件过滤器拦截了包含链接的 Homerun 邮件。
Web 应用速度慢
Homerun 的 Web 应用慢得恼人。我用的是配备光纤网络的现代台式机,但 Homerun 大多数页面需要 2-5 秒才能加载。有些页面甚至要长达 10 秒。
下次招聘的改进措施
我对这一轮招聘中对待候选人的方式感到不满。我没有预料到申请的数量,接受了超出我能在合理时间内处理的申请量,浪费了申请人的时间。
以下是我计划下次做出的一些改变,以改善所有人的招聘体验。
发送回复时要更加保守
刚开始用 Homerun 处理申请时,我对它的邮件模板过于热衷。上一轮招聘时,如果有候选人提交了低投入的申请,我就直接忽略他们。而有了 Homerun,邮件模板让回复低投入的申请者也变得容易起来。
我做了一个模板,大意是说:我拒绝他们是因为他们的申请看起来像是复制粘贴的。我觉得至少让他们知道复制粘贴申请正在让他们丢掉工作机会,这是件好事。
![你好 [first_name],感谢你申请 TinyPilot 的 [job_title] 职位。很遗憾,我决定不再推进你的申请。我读了你提交的问题回答,似乎没有什么关于公司或工作的具体内容吸引到你,所以我认为这不是一个好的匹配。很抱歉未能如愿,祝你求职顺利。](https://mtlynch.io/retrospectives/2022/09/low-effort-rejection.png)
对于用复制粘贴的回答来申请的候选人,这是我发给他们的套话式回复。
这个策略效果很差。
在回复了的候选人中,约 50% 很有风度并感谢反馈,这很好。约 20% 粗鲁或有敌意,这很糟。
最后 30% 意识到终于有一个真人在和他们交流,而他们的申请并没有像他们以为的那样消失在虚空中。这时,他们开始研究公司,并表示其实他们对 TinyPilot 本身很感兴趣。这让我陷入了一个尴尬的境地。如果我重新考虑他们的申请,对那些从一开始就认真作答而不是向所有人复制粘贴同样内容的候选人来说就不公平了。
在一两天内为低投入申请耗费时间之后,我干脆停止回复这一类别的申请人。我把策略改为只在满足以下条件时才回复:
- 候选人在基本层面上符合该职位要求
- 例如,如果职位要求之一是“熟悉 Linux”,而候选人说自己从未用过 Linux:不予回复。
- 候选人在申请上至少投入了几分钟
- 例如,如果回答明显是复制粘贴或草草了事的:不予回复。
这个新策略带来了一个愉快的副作用:消除了敌意回复。当我拒绝认真作答的候选人并说明理由时,他们不一定都会回复,但只要回复,都是专业且感谢反馈的。
雇人来帮我做初筛
筛选简历和申请需要几十个小时,但这完全是我可以训练一个聪明人替我完成的任务。
我不想使用愚蠢的自动过滤器或机器学习——对我来说重要的是,我可以诚实地告诉候选人,有一位真正的人在审阅他们的申请。只是这个人不一定非得是我。
为客户支持建立冗余
拖延我回复申请人的因素之一是,通常负责客户支持的 TinyPilot 员工病假了一周。客户支持感觉上是有冗余的,因为我们的支持工程师可以顶上。如果那样还不行,我就是最后一道防线。但当 TinyPilot 平时负责客户支持的人生病缺席时,我才意识到我们的客户支持流程是多么脆弱。
我忘了自己做客户支持时工作量有多大,尤其是还要额外与 800 名求职者沟通。除此之外,我还休了几天假,这意味着 TinyPilot 的支持工程师成了唯一提供支持的人。那段时间很艰难,因为他没有 Shopify 或我们本地履约办公室的权限,所以他所能提供的支持种类有限。
等支持工程团队的事情稳定下来后,我打算再增加第二个人来负责客户支持。这将有助于在某人生病或休假时保持运转顺畅。
当申请达到某个上限时,把申请表单转换为候补名单
即使有其他人帮我招聘,我们在合理时间内能审阅的申请数量也是有限的。一旦超过某个上限,比如 400 名候选人,我就应该把申请转换为候补名单,免得浪费候选人的时间去解释他们为什么想和我一起工作。
记住这件事有多耗时
我以前通过招聘启事招过人,但直到再次开始做这件事,我才想起这个过程有多耗时。
在我脑海中,时间投入是这样的:

我想象中的招聘运作方式
第一天就有大批候选人涌入申请。我逐一筛选,直到缩小到一个人。最后,我录用了那个人,他开始接手我以前做的任务,一切都很美好。
现实中,时间投入更像这样:

现实中的招聘运作方式
先是大量申请人涌入,然后在我处理他们的同时,人们还在不断申请。而当我终于录用某人之后,我还得跟进所有未被选中的人,同时还要为新员工办理入职并进行培训。
所以,下次招聘时,我只需要重温这两张美丽而有信息量的图表,提醒自己需要留出大量富余精力来应对这件事。
结语
完成了什么?
- 聘用了第二名 TinyPilot 支持工程师
- 将下一代更新系统部署到 TinyPilot Community 版本
- 发布了关于自力更生创业者的申请人跟踪系统的笔记
- 发布了关于调试 PicoShare 内存问题的笔记
经验教训
- 招聘总是比我想象的更难
下个月的目标
- 将 TinyPilot Pro 迁移到下一代更新系统。
- 把 TinyPilot Voyager 寄给两位 YouTube 创作者或博主进行评测
- 探索新的外壳制造选项
随机一篇博客