一句话总结

招聘 TinyPilot 的首位技术支持工程师

亮点

• 聘用了 TinyPilot 的首位技术支持工程师。
• 发现招聘技术支持工程师比预想的还要困难。
• 正在评估用于向海外合作者付款的平台。

目标完成情况

每月初我都会定下当月想要完成的目标，以下是本月的完成情况：

发布 Voyager 2 PoE 版

• 结果：终于发布了 Voyager 2 PoE
• 评分：A

哎呀，这比我预想的花了太久。我回头看了看自己在 2021 年 4 月初写的原始设计文档，当时我预计到 2021 年 5 月 15 日就能备好 200 台。换句话说，我原本估计只要六周，结果却花了 11 个月。

招聘一名 TinyPilot 技术支持工程师

• 结果：与一位技术支持工程师开始了试用
• 评分：A

为这个岗位招聘费了不少功夫，但很高兴团队迎来了新成员。本篇复盘主要就是讲招聘技术支持工程师的过程，详情请继续往下看。

完成 TinyPilot 网站改版的设计工作

• 结果：延期至三月
• 评分：不适用

合作的设计公司在二月份可用工时不足，没能按时完成设计。我已与他们协商确定了三、四月份的保障工时，预计月底前可以完成。

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 和树莓派方面有很多出色的经验，但这个岗位更需要有面向客户的内容写作经验。你的英语已经相当不错，但求职信和简历中仍有几处错误，所以我觉得这个岗位不太适合你。

很抱歉这次没能合作，祝你求职顺利。

祝好，
Michael

在回复中，我尽量强调我拒绝的是这份申请，而不是在说“我拒绝你这个人”。我也避免写得过于具体，不想让对方觉得我是在挑剔或因为某个粗心的错误就否定他们。

大多数雇主会省略个性化的拒信，我能理解原因。这非常耗时，而且对雇主本身没有直接好处。但我觉得，既然已经让对方花了无偿的时间来申请，再对其不理不睬或只发一封模板拒信，是不尊重人的。

大约 65% 的候选人收到拒信后没有再回复。约 25% 的人表示感谢我的反馈，其中有几位进一步询问了细节，我也给出了具体的修改建议并推荐了提升写作的资料。

在收到拒信的候选人中，约 10% 试图说服我让他们完成筛选题目来证明自己。虽然有些心动，但点评筛选题目的耗时要比在求职信阶段拒绝高出一个数量级，我不想浪费双方的时间。

大多数回复的人都对能收到指出具体问题的拒信感到意外和感激，这似乎很少见。没有人表现出敌意，大家都保持了专业态度。

共有 62 位候选人（28%）被归入 cover-letter-reject 文件夹。算上 instant-reject 和 cover-letter-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

我一次只试用一个人，所以这个阶段的跟踪很简单。但为了完整起见，我还是为招聘漏斗的最后阶段建了一个文件夹。

小结

如果把我的文件夹体系换算成“招聘漏斗”，各阶段的数据如下：

招聘技术支持工程师：薪酬支付

目前我与三位自由职业开发者合作，他们分别在不同的国家，收款方式也各不相同。现在要增加第四位合作者，我想用一个统一的方案来规范支付流程。

我希望远程工作者支付平台能做到以下几点：

• 尽量减少各方在开票和付款上花费的时间
• 管理合规文件
• 管理合同文件
• 让合作者可以记录报销
• 让合作者能轻松记录计费工时，且无需安装监控软件

Deel（最终选择）

最终我选择了 Deel，它满足了我的所有需求。目前才使用了一周，但体验不错。

与其他服务商相比，Deel 在显示以当地货币实际到账金额方面似乎更透明。其他平台只承诺会尽力提供优惠的汇率，而合作者要等款项到账后才知道最终汇率是多少。

Deel 还计划拓展面向美国本土员工的薪酬服务。这对我来说是个好消息，因为我对 Justworks 和 Gusto 都不太满意。

Pilot

Pilot 和 Deel 颇为相似，两家都获得了 Y Combinator 的投资，界面也同样精美。不过 Pilot 不支持工时跟踪，而 Deel 支持。

我一开始注册的是 Pilot，本来打算就用它，但他们花了一整周才开通我的账户。期间另一位创始人向我提到了 Deel，于是我就换了过去。看来做好客户引导确实很重要。

Remote

Remote 为合作者提供免费支付服务。听起来很棒，对吧？但恰恰是“免费”让我放弃了它。

如果别人每人每月收费 30 到 50 美元的服务，Remote 却能免费提供，那肯定有问题。可能意味着他们会以某种意想不到的方式从我身上赚钱，比如在汇率中隐藏费用。也可能意味着合作者支付只是他们不在乎的边缘业务，随时可能像 Google 对待免费服务那样突然砍掉。

Gusto

我已经在用 Gusto 为本地员工发工资。我对 Gusto 并不是特别满意，但如果能用同一个服务支付所有人，确实会更方便。

可惜的是，Gusto 仅在国际合作者每期收款金额固定的情况下才支持。如果合作者每周工时不同，Gusto 就无法满足需求。

往期项目（RIP）

以前我的复盘中会固定有一个章节来更新往期项目的进展，但内容越来越枯燥，基本都是“我什么也没做，以上就是对数据的影响。”

所以我打算用“业余项目”来取代“往期项目”，聊聊我在周末和晚上捣鼓的兴趣项目。

业余项目

Lenny

Lenny 是一个替我回复垃圾邮件的聊天机器人。

垃圾邮件变得越来越嚣张。现在，垃圾邮件发送者会在我不回复第一封邮件后，自动发送一系列催促消息。

让我恼火的是，垃圾邮件发送者可以不断侵扰我的收件箱、浪费我的时间，而他们付出的成本不过是每封邮件几分之一美分，外加每隔几个月换个新域名。他们之所以能对成千上万人这么做，就是因为在收到回复之前几乎不用付出任何精力。我想找个办法提高他们的成本，让这种批量、半定向的群发邮件不再那么划算。

我从一个用语音聊天机器人浪费电话推销员时间的 YouTube 频道获得了灵感。该频道维护着一个 VoIP 号码，接听推销电话并用一位名叫 Lenny 的和蔼澳大利亚男子的录音来回应。这些录音总是表现出对推销产品的兴趣，但又夹杂着大量絮絮叨叨的跑题内容。据估计，Lenny 已经让电话推销公司损失了数万甚至数十万美元。

我也做了自己的 Lenny，不过是针对邮件而非语音电话。现在收到垃圾邮件时，我会把它转发给自己的邮件版 Lenny。Lenny 会热情地回复垃圾邮件发送者，但总是不断跑题，把对话带得兜圈子。

下面是两位不同的垃圾邮件发送者对同一套自动回复话术的回应。Lenny 成功让每位发送者在放弃前都回了五封邮件。在第二个例子中，Lenny 的回复在语境上已经前言不搭后语，但对方还是继续纠缠了一段时间。

我尽量减少第三方依赖，不过二月份开始使用了 Bulma CSS 框架，界面好看了不少。

除此之外，我一直在让新增回复变得更简单。目前所有回复都写死在代码里，但我希望以后能通过网页界面直接编辑。

我还不确定 Lenny 这个项目会走向何方。可能会作为免费开源工具发布，但我觉得也可能有人愿意为托管服务付费。目前只是出于自娱自乐在做，不过希望未来几个月内能开放给更多人使用。

PicoShare

PicoShare 是一个简单的文件分享工具。

市面上有无数可托管和分享文件的服务，但或多或少都会碍事。举个例子，我无法直接把视频上传到 Google Drive 然后发个链接给别人。Google Drive 非要对视频重新编码，等上十分钟才能访问。就算能访问了，对方还得在 Google Drive 的界面里点来点去才能播放。Dropbox、imgur 等也都一样。

PicoShare 是一个简洁、无障碍的文件分享服务。上传文件即可获得直链，任何拥有链接的人都能直接查看或下载，无需注册账号或观看广告。

前不久我用 PicoShare 在家庭群里分享了一段《我为喜剧狂》（30 Rock）的短视频。下面就是我上传片段并获取分享链接的过程：

PicoShare 还支持为分享的文件设置过期时间。有时我想为 TinyPilot 分享文件，但其中可能包含敏感信息，不希望它一直留在对方的邮箱里。过去我会把文件上传到云存储再分享链接，之后还得记得手动删除。PicoShare 会在过期后自动删除文件，省去了这个麻烦。

PicoShare 才做了几周，还很粗糙。我不认为这里面有商业机会，因为打击滥用的成本太高。目前它是开源的，但由于还在快速迭代，我还没怎么投入精力写文档。

总结

完成了什么？

• 发布了 TinyPilot Voyager 2 PoE
• 聘用了 TinyPilot 的首位技术支持工程师
• 创建了 PicoShare

经验教训

• 把招聘过程当作未来合作关系的预演。
  • 优秀的人才希望与善待他们的人共事。
  • 职位描述和招聘流程应该让求职者感受到你会尊重他们、珍惜他们的时间。
• 如果职位描述本身千篇一律，你就无法识别出模板化的申请。
  • 写出泛泛的职位描述，只会收到对你公司毫无针对性的套用申请。
  • 要用职位描述把你的公司与其他公司区分开来，给求职者提供独特的切入点，让他们能在求职信中证明自己确实花时间了解了你的公司。
• 善待求职者成本很高，但会让人感到惊喜。
  • 体面地对待被拒的候选人要多花 10 倍时间，但这不意味着就可以省略。
  • 作为创始人，即使对自己没有直接好处，你也可以选择如何对待他人。

下月目标

• 发布 TinyPilot Pro 2.4.0
• 完成 TinyPilot 网站的设计改版
• 完成新任技术支持工程师的入职培训