为什么软件工程师找不到工做？
若是没有获得offer，大多数的人都会把责任推到本身身上：“我已经连续被三家公司拒绝了，因此我多是个很糟糕的工程师吧”。因为我从事过一段时间的技术招聘工做，因此我能够告诉你随机因素和其它干扰因素（误报）也起着很重要的做用。拒绝每每是因为随机事情发生和非理性的缘由（真正的消极）。前端
缘由1：候选人由于框架而被拒绝程序员
因为须要招聘一位前端工程师，我挑选了一位面试人员，他对ECMAScript和开源都作过很大贡献。我花了几周的时间才找到这我的，又花了几个小时来对他作正确的评估，包括视频采访。该机构的一名工程师对他提交的代码中审核了十分钟，而后拒绝了他。该公司给他寄来了一封邮件，没有正面拒绝他：面试
“[…]虽然你的简历和求职信是很是有竞争力的，咱们的招聘团队审查完你的申请之后，并无选择进一步考虑。”[…]算法
这是一个很是糟糕的邮件回复，由于没有提交过封面信。读完这些以后，我放下了手头全部的东西，开车到办公室跟那位拒绝了我在2017年面试的最好的前端候选人的工程师交谈。api
首先，面试工程师不能真正告诉我为何他拒绝了候选人，他只是说“代码过分设计”，尽管实际上它的结构是正确的，全部ES6操做符和短函数都是正确的。通过十分钟的讨论后，拒绝的缘由变得更加清晰了：候选人使用了一个面试官未知的MVC框架。我对这位候选人在编码面试中使用的框架印象深入，以致于我没法理解这多是一个问题。前端工程师
一些背景信息能够解释为何咱们使用了一个未知的MVC框架：招聘公司是一个寻找可重复流程的机构，首席工程师（不是面试官）向我抱怨说，他们倾向于“为每一个客户从新发明轮子”。我推荐的候选人用他的空闲时间创建了一个定制框架，解决了该机构面临的一些问题。框架
由于拒绝面试者的这位面试官没有看个人笔记或个人视频采访记录，所以他没有考虑到为何候选人使用这个框架，只是在ATS中写了个“拒绝”。并且，在那一刻，团队领导(支持这位候选人的人)正在度假，没法进行干预。函数
提示：通常来讲，在评估以前先看待其余人对候选人的意见，这是一个很是很差的行为，但在某些状况下，若是可以多了解一点北京信息，这是有道理的。ui
这个故事特别使人伤心，由于CEO给了我另外一份报酬，让我给他们带来“最好的人”。因此，我加倍努力。可是，员工和招聘工程师没有真正评估我推荐的候选人。拒绝候选人的工程师甚至告诉我：“招聘对咱们来讲是最不重要的”。若是你做为招聘人员得到了一份工做，那就会让你更有责任感，但若是你缺少整个团队的支持，那么它的价值就很小了。编码
更糟糕的是，这位候选人在接受这样的对待以后，并不想和其余瑞士雇主进行交流（人力资源部的回应，没有反馈，等待两周时间才能提交代码提交）。
缘由2：前谷歌工程师被拒绝的缘由就是由于不知道贝叶斯公式
一家须要Python工程师的初创公司面试了一位在Google苏黎世分公司的呆了四年的程序员。由于每一个人都认为他会要求Google进行赔偿（赔偿金额差很少20多万法郎，几乎是平均工资的两倍），因此我向初创公司推荐这位工程师时遇到了问题。
然而，他对本身的要求是比较合理的，只想要待在一个和谐的团队里面，负责一些有趣的技术挑战。因此，他每次面试都很高兴，并且大多数人都对他印象深入。他经过了四轮比赛，最后一轮他以一对一的方式和团队里面的每一个人进行交谈。
可是在面试以后，一我的站了起来，明确指出这位工程师因为不知道或者不能解释贝叶斯公式，所以不能被雇用。
每一个人都表现的无所谓，除了技术主管。他就像是游戏中惟一有皮肤的人。他向CEO汇报几个月以来他们没有雇用任何人。因此他用本身的否决权，明确表示若是就是因为不知道这些杂事而把他拒绝掉，这个理由是有多么的愚蠢。最后他们雇用了这我的。后来事实证实这位工程师是公司这么多年招聘的人员中最有价值的资源。
技术主管的结果是正确的：这位工程师安装的开发环境的时间打破了公司的记录，并在第一天就解决了三个错误。每一个人对这件事都印象深入，也为当时雇用了这我的而感到高兴。
Google在招聘时可使用这些具备挑战性的算法，由于这些大品牌公司有资本 - 他们能够拒绝许多原本是优秀员工的候选人，由于想进入Google的工程师每一年不可胜数（谷歌每一年有三百万就业申请）。正如Erin Ptacek曾经说过的那样：“Google所作的这些事简直就是定义了什么叫作疯狂。”
缘由3：程序员被人力资源部门拒之门外
一般我会密切跟踪参与面试人员的状况，以及在招聘过程当中的状况是怎么样的。在我休假的时候，一位CEO表示他会雇用我推荐的工程师。可是此时身在异国的人力资源并无跟进。因为我正在我休假，所以我也没有跟进，面试人员等了好几个星期都杳无音信，他觉得本身被拒绝了，由于没有人跟进（所以若是没有人跟进，这并不意味着就是被拒绝了）。这种状况就是典型的工程错误。
两个月后，我联系了这位工程师，询问发生了什么事情。他和人力资源部门都不明白为何没有人对他进一步跟进。所以，我经过电子邮件抄送了全部涉及到的人，询问咱们是否能完成这个过程。
人力资源通常薪水比较低，工做也比较混乱。内部招聘人员常常负责招聘之外的其余行政工做。这些人一般不太了解技术角色。他们可能只花了15分钟的时间去简单了解一下招聘经理正在寻找什么样的人员，而后就作一些适当的“过滤”。因为缺少语境和对角色的理解，结果每每会不怎么好。
缘由4：候选人被拒绝了，由于他比面试官好
有人在HackerNews对这篇文章进行评论，其中某些观点提到了申请人被拒绝的缘由就是由于太出色了。因此，我写下了一个跟我一块儿的故事：
我还遇到过面试者比面试官好的这种状况。面试者是一个22岁的神童程序员，对开源作过不少的贡献，可是在代码评审阶段被某我的给拒绝了，咱们称暂且称他为“Jon”。拒绝的缘由让我感到震惊，因此我当即组织一个电话会议来讨论这个问题。电话会议一共有三我的：HR，Jon和我。
Jon在会议中说明了他为何拒绝这位神童，缘由听起来有点滑稽，可是我却没法分辨Jon是否定真的。另外，Jon对Github得贡献也比较差，可是他就是负责代码评审的，因此我不得不听他的反馈。
Jon指出了这位神童的代码中存在一些问题，咱们甚至经过共享屏幕上看了这些问题。其实他提到的全部问题都只是风格选择不一样，实际上并非真正的问题。他批评的其余事情只是因为他没有认识到，因此他认为这么写很糟糕，但实际上有很好的理由（之因此会写复杂的try-catch块，就是由于代码交互的API不清晰）。而后我发了脾气。这些批评让我颇有戒心，并让我认识到候选人的代码质量比Jon在Github上的要好。所以我抛开了个人绅士气质。HR在那里阻止了我，告诉我“咱们在这里并非为了评估Jon”。这句话说得很对，我也很差在说什么了，因此我换了个话题，结束了通话。
能够另写一篇文章，介绍一下人们为何偷偷地雇用那些比本身稍微不聪明和/或能力稍弱的人；我的面试者和整个公司均可能会惧怕雇用比本身更熟悉或更熟练的候选人。由于候选人太好而拒绝这是不能接受的;因此一种方法是把重点放在候选人很不擅长的某个领域。这里有一篇关于如何在苏联的学术界是如未尝试这种办法的文章。
经验教训
招聘工做比你想象的更混乱。若是你被拒绝了，这并不意味着你就是一位不好劲的工程师，由于拒绝的缘由能够有不少。
若是你问本身为何会存在招聘机构，好吧，如今想一想就能够知道这些机构存在的缘由就是为了防止这篇文章中提到的一些事情会发生。咱们将人们与工做相匹配，除了创始人以外，咱们拥有最多的皮肤来消除障碍，让人们找到工做。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------