今天找一份工作的成本

这篇内容很短，但一直让我困扰。

几个月前，我升任工程负责人，随之而来的是这份工作中我一直觉得最困难的部分：招聘。我很幸运，身边已经汇聚了一批优秀的人才。

但在初创公司，总有一种持续而隐秘的压力，要求我们不断寻找人才——因为一旦真正需要人手，就不可能等上三个月去等待那个“完美”的候选人。

技能并非全部

我曾对“唯才是举”抱有宏大的设想：应聘者应当仅凭能力被录用，别无其他考量。事实证明我大错特错。一个人的行为方式、与他人的相处模式、解决问题的思路以及为团队带来的活力，与技术能力同样重要，甚至更为关键。

从我个人有限且带有轶事色彩的经验来看，只要具备基本的专业能力，愿意付出努力往往比多掌握一点技术更能助你走得更远。在初创企业中，这种逻辑尤为合理——正是凭借这一点，规模小、资源有限的小团队才能与那些拥有数千名员工、有能力以更高薪酬挖走市场上任何工程师的大公司抗衡。

那些与你无关的阻碍

因此，当一些真正稀缺的优秀工程师因与自身技术能力无关的原因无法加入我们时，这尤其令人痛心。他们可能拿不到签证，也可能居住在其他城市，或者合同条款并不适合他们。

不过最近，我又有了新的思考。我认为，如今使用大型语言模型（LLM）已成为软件开发不可或缺的一部分。因此，在我们的面试和技术测评中，我们都期望候选人能够运用这些工具。

现在换位思考一下

假设你是求职者，暂时没有收入。如今的求职很大程度上是一场“数字游戏”，你可能一周内就要参加五家公司的面试。而每一家都会给你布置一项需要使用人工智能的挑战任务。

然而，AI并非免费。那些真正擅长编码的工具通常需要按月订阅或购买API调用额度。这意味着你在人生中或许最拮据的时刻，还要为这些服务付费。

常见的回应是：“一直以来都是这样，找工作总是要花钱。”这话没错——为了投递简历，你至少得有住所、衣物和食物。但这些开销并不是专为求职而设的。

LLM的成本则不同：它是短暂的，其唯一目的就是帮助你获得这份工作。

没有完美的答案

这让我陷入两难。我可以接受现状，明知会有一定数量的优秀工程师仅仅因为负担不起完成测评所需的优质模型而与我们失之交臂；也可以尝试一些不同的做法。

我为此反复权衡，却始终找不到令人满意的解决方案。给候选人提供公司账号用于测评不可行：这会带来责任风险，而且我无法确保其使用方式。

报销候选人的支出同样不现实——既难以作为公司成本列支，又容易陷入财务上的灰色地带。

我能改变的环节

既然无法消除这笔费用，那我就把重点放在流程本身。目标是让候选人尽可能少花钱，并且只在真正必要的时候才投入。

将测评环节后移。在与候选人尚未进行充分沟通之前，不应让他们消耗算力资源。只有到了测评阶段，才说明我们已对其产生浓厚兴趣，此时所花费的成本更有可能转化为一份录用意向。

缩小测评规模。如果一项测评需要顶级模型运行数小时，那其实是在考验候选人的钱包，而非其能力。我更倾向于给出一个范围明确、难度适中的问题，用免费层级或基础套餐即可完成；然后把更多时间花在交流候选人如何解题的过程上。

毕竟，我真正想了解的，也正是在那段对话中。

改为协作式测评。这是我最喜欢的方式。不再采用“带回家”的形式，而是安排一场实时互动，由候选人主导，而AI则在我们这边、用我们的设备和账户运行。

这样既无责任风险，也无需报销，更不存在灰色地带。同时，我也能观察到我真正关心的内容：你的思维方式、沟通能力，以及当模型自信地给出错误结果时，你如何应对。

降低代码产出的权重。说到底，最大的改变在于测评本身的分量。如今，我更看重关于架构设计以及开发习惯的深入讨论：你会如何构建系统？

边界该如何划定？你对测试、代码评审和上线发布又有怎样的思考？当LLM可以代写大部分代码时，代码本身能揭示的信息反而变少了。相反，你如何权衡取舍，这段对话才更有价值，而且完全不需要额外花费。

以上方案都非十全十美。实时测评对部分人来说压力较大，而规模较小的测评也难免暴露不足。但我宁愿主动做出取舍，也不愿假装问题并不存在。

如果你也在招聘，请问问自己：当前的流程会给那些暂时没有收入的求职者带来多少经济负担？又可能因此失去多少优秀人才，而你却浑然不知。

补充一句。如果你住在柏林，且方便来我们位于罗森塔勒广场的办公室，并热爱初创公司的氛围，欢迎发邮件至gerard@konvoai.com。作为开场话题，不妨谈谈你对RAG的看法、过往的使用经验，以及你认为是否有更适合智能体式AI助手的方案。

:)