无意中绕开了 Secretary Problem

# 不经意间绕开了秘书问题。来源：https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html 不经意间绕开了秘书问题。 \↓[目录 (https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#blog-post-toc)\]发布于：2026-03-20更新于：2026-03-22 在员工-雇主匹配这出歌舞伎戏剧中扮演过双方角色后，我觉得我们目前的方式是一场零和游戏。我希望事实并非如此。这篇博文最初作为一大段聊天信息诞生于2024年，那时软件行业的面试桌两侧——情况都很严峻。零利率时代已经结束。到了2026年，后零利率时代的现实已经完全显现，并且情况依然糟糕（"AI"不过是一片（企业版）遮羞布，掩盖了他们自我造成的结构性损伤，而且如果你看看超大规模云服务商GPU的折旧计划，他们会把情况搞砸至少一个数量级）。在此背景下，这里有一个希望能带来希望的招聘轶事，我认为我们在其中避免了所谓的"秘书问题"，该问题被置于最优停止理论的框架内。这是可以做到的。非零和招聘本应是任何行业——无论有无AI——的默认模式。 --- **目录** [秘书问题](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#the-secretary-problem) [绕开秘书问题的故事](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#story-of-bypassing-the-secretary-problem) [短期与五年成果](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#immediate-and-five-year-outcomes) [直接成果](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#direct-outcomes) [间接成果](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#indirect-outcomes) [那个（实际上是好几个）怪招](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#the-one-actually-several-weird-tricks) [走运了](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#getting-lucky) [拒绝照搬零和FAANG招聘流程手册](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#refusing-to-copy-the-zero-sum-faang-hiring-loop-playbook) [运行紧凑、*人性化的*招聘流程：最长24小时SLA。始终友善。](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#running-a-tight-humane-hiring-loop-max-24-hour-sla.-always-be-kind.) [脚注](https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#footnotes) --- > "你需要多少申请人才能找到对的那一个？一个？五个？每次都整个社区？:笑哭:" —— Clojurians Slack 里的一位同仁。问话者并非在开玩笑。任何使用不熟悉技术的提议，尤其是像 Clojure (https://www.evalapply.org/tags/clojure/index.html#main) 这样的编程语言，不可避免地会引发管理层对人才库的焦虑。还有什么比在一个"小众中的小众"领域尝试招聘更能引发管理层的手足无措呢？你看看能不能回到2014年，在浦那/印度，找到愿意学习读写Clojure代码的QA人员，以帮助后端工程师测试一个用Clojure编写的相当大的SaaS。在随后的讨论中，我了解到了所谓的***"秘书问题"***1 (https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#fn1)。这个命题被用来研究*最优停止理论*。它设定了一个招聘场景，探讨如何最大化选择到最佳申请者的几率。这是一个有趣的探索兔子洞。 ## 绕开秘书问题的故事 **秘书问题的一个关键约束是***一旦拒绝，申请者就无法被重新召回*。*** 曾几何时，我的同事 Mayank (https://www.linkedin.com/in/firesofmay/) 和我，在我们那本应常规的技术招聘流程中，违反了这个我们当时不知道的约束，通过： - *不仅*在冷却期后明确为重新申请敞开大门， - *还*主动提出帮助人们学习我们感兴趣招聘的技能，采取自愿原则。我们会发送课程大纲，并在固定每周时间提供办公时间，给那些表现出学习兴趣的人。 大约在2013年末到2014年间，他和我在 helpshift.com（一家喜欢Clojure的初创公司）为我们的QA团队招聘程序员（团队就他和我两人 :)。我们想要好奇心强且具备足够技术素养的人，这样我们可以教导和培训，因为我们在用Clojure编写测试工具和套件。更不用说各种手动测试我们系统（这些系统难以自动化），这要求人们具备阅读大量技术手册和文档的基本能力，以及学习并*使用*我们命令行工具、脚本和配置（如果不是自己编写的话）的意愿和能力。我们知道测试员-程序员的组合本身就很难招，尤其是在印度，那里的招聘池几乎全是纯手动测试人员2 (https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#fn2)。所以我们做好了面对嘈杂申请管道的准备。在这种情况下，我认为失去任何有潜力的人都太疯狂了。在我之前的职业生涯中，作为一名业务经理，我见过公司流失那些具有恰到好处的生活经验，但学位或出身或测试分数不对的候选人。于是我提出了重新申请+自愿支持的想法。我的同事喜欢这个想法，于是就这么定了。幸运的是，公司文化已经倾向于"非传统"招聘，可以说是寻找"未经雕琢的钻石"3 (https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#fn3)。而且因为我们没有HR职能，我们俩只能自行其是。回想起来，即使HR再支持，让他们介入也会很糟糕，因为我们将*不得不*妥协说类似这样的话："哦，这次非常抱歉，但你是我们候选人库的一部分，我们*会*与你联系的，拉钩保证。以后吧。你也可以六个月后再申请"。我读过这种拒绝邮件，也知道随后是永远的沉默和申请黑洞。我把这类拒绝邮件看作是花言巧语、推卸责任的常规操作。往好了说是无伤大雅的自欺欺人。现实点……你们公司*永远*不会有人跟进那件事。如果我没有信号表明*为什么*有人会在仅仅六个月后愿意听我的话，我，这个满怀希望的候选人，就不会浪费时间重新申请。所以别设置那种期望。 ## 直接成果 在我们运行面试流程的大约一年时间里： - 我们在大约300份申请中成功录用了五人。 - 每个人在我们小开放办公区角落里都很快（约一个月）就能产出。三人掌握了Clojure，两人转向了移动SDK（截至2017年装机量达20亿设备）。 - 每个人后来都远超我们的预期成长，在公司范围重组取消独立QA职能时，转到了其他岗位，如后端开发和产品经理。 - 对于风险资本支持的高增长初创公司来说，这是相当不错的留存率……我们所有的人都成为了长期员工（每人四到十年）。 ## 间接成果 每一位这样的员工，都进一步将他们的投入转化为内部的高速增长初创公司职业发展，以及之后在其他地方、甚至他们自己创立的初创公司的发展。***职业成长和留存的主要功劳归于所有同事建立和培养的工程文化。***雇佣有潜力的人至关重要，但这仅仅是个开始。他们所做的所有工作，积极地帮助这些早期员工掌握了专业技能，使他们能够走出去并正在做他们现在的事情。我们还*间接地*雇佣了一位极其出色的工程师（他也成为了长期员工），因为我们的方法赢得了良好的口碑（这是我们没有预料到的，但它确实发生了）。他被我们为他妻子提供的学习支持所震撼，我们筛选过他妻子，她选择了参加我们的办公时间，但我们最终没有雇佣她。 ## 那个（实际上是好几个）怪招 ## 走运了 事后看来，我想知道我们的方法是否会陷入某些HR或法律泥潭（比如，如果会面了，是否会产生隐含的雇佣承诺，如果我们不雇佣，是否会违反某些晦涩的劳动法？）。总之，我们当时只是因为能做才做了，我很高兴我们抓住了机会。我希望这成为默认的招聘方式。 ## 拻绝照搬零和FAANG招聘流程手册 普遍经验是，典型的招聘漏斗每10名申请者会产生一个最终录用/接受（大致如此）。这表明在全球市场，如果每个人都使用典型的招聘方法——"我们有5轮面试，因为FAANG有5轮；这证明它是最佳实践"——小虾米总会输给大鱼，因为你根本无法分配足够的资源来承受如此嘈杂的招聘管道造成的损失。换句话说，正常招聘实践的主要问题似乎是，我们把它当作零和游戏来玩*即使这是一场对抗性游戏*。 - 我们没有客观标准来确定观察到的质量。 - 我们通常事先不知道`n`……对于某个职位，我们应该假定申请池由多少申请者构成？ - 申请者到达我们这里的概率并不均匀，我们无法在拥有后见之明的情况下面试所有人。 ## 运行紧凑、*人性化的*招聘流程：最长24小时SLA。始终友善。 这一点，我敢于自夸从一开始就坚持下来了，因为之前雇佣过人，并且完全信服了速度是招聘核心价值的观点——这要感谢Kayak的前任CEO Paul English4 (https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#fn4)。他的"SLA"是七个日历日（不是七个工作日），从*了解到候选人存在的那一刻起，到发出正式录用通知*。 ***我们习惯于收到"感谢"邮件，作为对我们发出的"遗憾"邮件的回应——这些邮件是在候选人通过我们四到五步筛选流程中的三步后发出的***（注：这个筛选流程中的"一步"*不等于*"一到数小时长的面试阶段"）。我将这主要归因于我们的响应速度和清晰的沟通。任何读到这里的招聘人员，*请*深思这个生活事实。以下是我们一年来运行流程时制定或演化出的一些规则的杂集回忆： - **与候选人设定清晰的沟通期望：** 我们向候选人承诺最长24小时的周转时间。我们明确要求他们如果在24小时内没有收到回复就联系我们。5 (https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html#fn5) - **绝不放任何人鸽子。** 我们都*讨厌*在任何沟通中被放鸽子，不仅仅是招聘。收到一个快速的"不"，远比在被拖延了三个月、经历了多个面试阶段后听到"是的，但是"要好得多。 - **无情地保护我们自己的脑力资源：** - 背景为王。让*所有*沟通通过ATS进行。*立即*为每个候选人每个阶段的投票/决策记录"原因"。就像良好的提交信息规范一样。如果我们中任何一个碰巧与某个候选人有场外沟通，会立即在ATS中记下一笔。我们两人笔记本电脑上始终打开一个专用的浏览器标签页。 - 同步电话和/或现场面试对我们成本很高，因为会中断我们自己的QA工作。确保我们总是最后才安排这些，并且总是单独进行。这迫使我们早期就精确弄清楚要沟通什么，我们阶段性的检查清单应该是什么，要寻找什么信号，如何在ATS中设置模板和阶段，如何登记投票等。 - 所有个人电话都按照该电话的剧本进行。如果情况不妙，提前结束通话。准备好一套娴熟、清晰且友善的结束方式。"开放大门"政策有帮助。对每个问题设定结构化的问答+决策标准也有帮助。 - 持续调整我们的工作流程，以最大化异步沟通和决策标准。我们共同的、*书面化的*、清单式的清晰度，帮助我们在注意到ATS中某些变化时，能在几秒或几分钟内独立决策和行动——投票/拒绝/推进。 - 勤勉遵守我们24小时沟通SLA。缓慢的周转时间会产生"候选人库存"积压，迫使我们停下手中的工作去处理队列。在快节奏的初创公司里这永远不会发生，因为一切总是处于救火状态，于是候选人就在放鸽子地狱里煎熬。 - **保护*他们*的时间：** - 这种对候选人的好处大部分源于保护我们自己的脑力资源。 - 此外，等待回复对候选人来说*糟透了*。因此，*绝不*布置需要候选人花几个小时完成的编码作业，因为这对他们来说是时间负担，也意味着*我们*需要花几个小时仔细阅读来评审代码。大型编码作业是信噪比极差的工具。任何编码作业对候选人所处的职业层级来说，都应该是一个*十五分钟左右*的活。因为他们一提交，评审者一眼就能看出是应该拒绝，还是接下来该问什么问题。默认情况下，我们的立即要求会是使用完全不同的设计来*重构*解决方案。 - 允许一定程度的复制粘贴。但要求候选人对此保持透明和坦诚。明确声明这是不可逾越的界限和*解雇*标准——如果我们在任何时候（是的，即使在他们被雇佣并全职工作后）发现他们复制了东西却没有披露。 - 实践中，*分钟级*的代码评审周转时间常常让我们能在*当天内*完全异步地做出通过/不通过的决定。这只是并发编程的基础。 - 正如你将看到的，这又反馈回"无情保护我们的脑力资源"。当这两个机制积极地相互反馈时，效果很好。 - **重视书面沟通和阅读理解：** - 所有初步筛选都通过邮件进行，包括编码作业、关于编码作业的问答，以及解决方案的重构。 - 所有邮件都*要求对方思考与该阶段相关的问题*，并提供简短的书面答复。 - 我们的第一封邮件会列举候选人应该考虑的潜在不可接受因素。例如，必须学习Clojure编程，可能在汇报层级上低一两级（"程序员"而非"经理"），大致的薪酬预算，成长和晋升前景，值班要求，每次提交代码评审文化的严格程度等等……这些工作文化的小方面累积起来，会让人说"不"。（注：我们不被允许预先披露薪资范围和薪酬，但我坚信披露这些将是最佳实践。有潜力的候选人在薪资谈判阶段流失，这是*极其*昂贵的损失点。） - **筛选主动性和好奇心：** - 深入挖掘真正自主驱动的的学习和项目工作，任何形式。Github作品集和个人网站*不是*自动的好信号。它们是深入挖掘的入口。 - 试图理解候选人的*"为什么"*。是什么在驱动他们？据此设计面试问题。 - 对所有我们说过"不"的"可能通过"候选人，提供"办公时间"支持。 - **异步决策协议：** - 只有两个"同意"票才能进入下一阶段。 - 一个同意，一个拒绝 = 拒绝（两个拒绝 = 显然拒绝）。 - 两票*必须*