为什么程序员找不到工作：无关技术，4个不可思议的事情！

当求职被拒时，我们多半会认为是自己的错：“我被三家公司拒了，我可能是一个差劲的工程师。”招聘比你想象的还要复杂。工程师出身的技术猎头 Iwan 在本文讲了 4 个故事，那些优秀的工程师，因为一些无关技术水平或文化契合等原因，遭到拒绝。

以下是全文：

我做了很长一段时间的技术招聘后，我可以向你保证，招聘过程中的随机因素和干扰因素（false negatives）也很重要。通常，拒绝是由于发生的偶然事件和一些不合理的原因（true negative）造成的。

事件1：候选人因框架而拒

针对一家代理公司的前端需求，我推荐了一个前端工程师，他对 ECMAScript 和开源项目做出了很大的贡献。我花了好几个星期找到这个人，并花了好几个小时来详细评估他，包括视频面试（我们喜欢在 coderfit.com 上这样做）。但是，仅仅在审查了 10 分钟他提交的代码后，代理公司的一名工程师就拒绝了他。候选人甚至没有得到一个合适的拒绝理由，仅有公司寄给他一个固定模板的回复：

“[…]尽管你的简历和求职信很有竞争力，我们的招聘团队审查你的应用程序后，认为你不在我们的考虑范围内。“[…]

这是一个非常糟糕的回复，因为他从没提交过求职信！读完回复后，我抛下手中的一切事情，开车来到他们的办公室，去和代理公司的那个工程师谈谈，因为他拒绝的这位候选者，是我在 2017 年面试过中的最佳前端工程师。

期初，代理公司负责面试的工程师没有告诉我真正拒绝的理由，他只是说尽管结构是正确的，所有 ES6 操作符和短函数都是正确的，但“代码设计过度”。经过 10 分钟的讨论后，拒绝的理由清晰：因为候选人使用了一个面试官不知道的 MVC 框架。我觉得候选人能在编码面试中使用这个框架非常了不起，所以我无法理解这（对面试的公司而言）会是一个问题。

通过一些背景调查，我明白了更深层次的原因，也知道了为什么候选人要使用这个 MVC 框架：招聘公司希望寻找的，是可重复循环利用的程序和方案（以节约相应的时间和金钱），而首席工程师（不是那个面试官）向我抱怨，候选人这样的则更倾向于“为每个客户重新造轮子”，这明显不符合公司的诉求。然而，我推荐的候选人在他的空闲时间，做了一个定制框架，恰恰解决了代理公司正面临的一些问题。

但是那位面试官没有看过我的文章或视频采访记录，他没有考虑候选人使用这个框架的原因，只是单纯地给出了“拒绝”这一结果。而且，团队领导人（同时也是候选人的支持者）正巧在休假，他也无法干预结果。

提示：在做评估之前，先了解别人对候选人的看法，这不好。但在某些情况下，如果有特殊状况，这样做还是有意义的。

这个故事让人特别难过，因为 CEO 相信我并给我一些额外的报酬，让我给他们带来“最好的人”，所以我对这事格外用心。然而，我却没有得到公司员工和招聘负责人的支持，他们并没有真正意义上评估我推荐的候选人。拒绝候选人的工程师甚至告诉我：“招聘对我们来说，无足轻重。”如果你作为招聘人员获得了额外的报酬，这会让你更有动力和使命感；但如果你缺乏被雇佣团队的支持，那么招聘的价值就几乎不存在了。

更糟糕的是，这位候选人在受到这样的待遇后，产生了抵触情绪，不想再和其他瑞士雇主有所接触（吐槽点：来自 HR 的模板式回复，没有反馈，代码提交后等待两周才被审核）。

事件 2：前谷歌工程师差点因为不知道贝叶斯公式被拒

一家创业公司为了招聘一位 Python 工程师，面试了一个在谷歌工作四年的程序员。由于每个人都认为他会要求一份从谷歌到苏黎世的补偿金（超过 200k 瑞士法郎，工程师平均工资的两倍），我在推荐他的时候碰到了点阻力。

然而，他提出的要求合情合理，只是想要（加入）一个和谐的团队，来面对有趣的技术挑战。因此，他接受了每一轮面试，并给大多数和他交谈过的人留下了深刻印象。一家初创公司让他经历了四轮面试，而最后一轮他和面试团队里的每个人都谈了一次。

面试结束后，一个人站了起来，明确表示不应该雇佣候选人，因为他不知道/不能解释贝叶斯公式（Bayesian formula）。

几乎没人关心这点，技术主管除外，他是唯一与团队共担风险的人，并直接向 CEO 汇报。几个月以来团队都没有雇佣任何人。面对这种情况，他行使了自己的否决权，并明确表示，因为没有熟记一些细节的琐事而拒绝一名优秀的工程师，这是一个非常愚蠢的理由。他们最终雇佣了候选人。后来的结果证明，被雇佣的工程师是公司有史以来做出最大贡献的人。

事实证明，技术主管的决定是正确的：候选人安装了开发环境后，在第一天就破纪录地把三个 bug 解决了。之后，每个人都很激动，对这个决定感到高兴。

谷歌等一些大公司使用技巧或算法问题，是因为这些大公司能够承担招聘过程中的错漏问题：它们可以拒绝很多优秀的候选人，是因为有无数人想为它们工作（谷歌每年有 300 万个求职申请）。正如 Erin Ptacek 曾说过的：“疯狂的定义就是以谷歌的风格做事，并期待成功降临。”

事件 3：程序员被 HR “遗忘”了

通常，我密切关注我的候选人，以及他们在招聘渠道的进展。当我在度假时，一个 CEO 接受了我推荐的一名程序员，但远在另一个国家的 HR 部门却没有跟进。由于我在度假，我也没有及时跟进，而候选人考虑了几周后，得出了**他被拒绝的结论，因为没有人跟进，告知他结果。如果没有人跟进，也并不意味着拒绝。这是一个典型的工程错误。

两个月后，我再次接触这位候选人，问他发生了什么事。他和 HR 都不明白为什么没有后续进展了。所以我给所有相关人员都写了邮件，询问我们是否能结束整个招聘流程。

一般而言，HR 薪资较低、内部结构混乱。内部招聘人员通常还要负责其他行政任务，而不只是招聘事务。更糟糕的是，有时小公司甚至没有 HR 部门，而前台的人负责简历的审核、拒绝和转发操作。这些人通常不太了解技术岗位的要求。他们从招聘经理那里接受了 15 分钟的简报，知道了一些信息关于“正在寻找的人才”，然后做些适当的“过滤”。由于缺乏相关知识和对岗位的了解，结果往往不尽如人意。

事件 4：候选人因为比面试官牛叉被拒

有 Hacker News 网友评论说，有时候优秀的候选人不会被录用，因为**他们太优秀了~ **所以，我写下了一直困扰我的第 4 个故事：

我也曾碰到过这种情况，现在我仍然认为候选人的技术能力比面试官要好。那位候选人是个 22 岁的天才程序员，对开源程序做出过贡献，但在代码筛选阶段被拒，我们就叫那个拒绝的面试官 Jon 好了。我对此感到十分震惊，所以我打了个电话来讨论此事。HR、Jon 和我三人参与了这次电话会议。

Jon 在电话里给出的理由有点可笑，我甚至不确定 Jon 是不是认真的。值得一提的是，Jon 的 Github 贡献，推送请求（pull request）等其他方面都很糟糕，但正是他负责招聘的简历筛选，所以我必须听听他的反馈。

Jon 指出了代码中的一些问题，甚至让我们在共享屏幕上看看。他提到的所有事情，其实都是更符合当下的倾向性选择，而不是真正的问题。他批评的其他东西在外行看来确实有问题，但实际上都有着很好的理由去解释（冗长的 try catch 块，是由于代码与交互的 API 不干净）。然后我就发火了，他的这些批评激发了我防御机制，并提出候选人代码的质量比 Jon 发在 Github 上的还要好，此时的我像变了个人似的。此时，HR 制止了我，并提醒道“我们现在并不是在评估 Jon”。但为时已晚，我只好快速转移话题，并结束了电话。

这可能成为另一篇博文的素材，如果这也解释了人们为什么暗地里喜欢雇佣比他们笨一点，或能力差一点的人；个人面试官和公司作为一个整体，可能会害怕雇佣那些知道的更多，或比他们更有才的候选人。因为候选人太优秀而拒绝他们，这样的理由并不能让人接受，所以退一步方法是聚焦在候选人弱点或不同的地方，以此让候选人退缩。

结论

招聘比你想象的还要复杂。如果你被拒了，这不代表你是一个不合格的工程师，因为被拒的原因可能有很多。

如果你不清楚为什么会有招聘中介公司的存在，那么，我来告诉你，它们有时可以阻止本文提到的一些事情的发生。我们将人与赖以生存的工作进行匹配，除了游戏制定者，我们在这场游戏中拥有最大可能性，来消除彼此的障碍，让人们得到工作。