[译]我最糟糕的技术面试经历

本文由 简悦SimpRead 转码,原文地址 www.jessesquires.com

科技界的每个人似乎都有一个 "可怕的技术面试 "的故事。这个话题在eth......,悄悄地绕了一圈。

科技界的每个人似乎都有一个 "可怕的技术面试 "的故事。这个话题悄悄地在我们行业的乙醚中运行,并定期以推特或博客文章的形式在大气中迸发,变成病毒。尽管人们普遍厌恶我们这个行业的浮躁和无视的面试过程,但似乎很少有人愿意改善目前的标准。最近我的时间轴上的一条推文让我想起了一个我从未讲过的故事。

那是2015年左右的某个时候。我在各个地方面试,我得到了苹果手表团队的面试机会。经过一整个上午,我在(也许?)第4次面试。面试官让我在白板上用C语言写合并排序。当然,我对这个算法很熟悉,可以从概念上解释它是如何工作的。但是,如你所料,在白板上用一种我不是每天都在使用的编程语言准确地重现它,让人感到恐惧。更不用说,我一般都很紧张和焦虑,因为面试。只写了几行,面试官就从我身后叫住了我,一边舒服地坐在椅子上,一边开玩笑说:"你一定是写了很多Swift",因为我不小心漏掉了几个分号。

这句话让我在接下来的时间里很不爽,不仅是因为我正处于一个可笑的白板练习中,而这个练习什么也证明不了,还因为它让我很生气,我不得不冷静地对待。当时,Swift只有几年的历史,而且我在现在的工作中也没有写它。那是在Swift粗糙的早期。我的团队都在避免使用它。我只是在家里尝试用Swift来玩。我每天都在写Objective-C,它确实有分号。但如果你的白板代码不能编译,你一定是个白痴。

正如你可能已经得出的结论,在那个房间里剩下的一小时左右的时间里,结果并不理想。


然而,这个故事有一个特别的讽刺意味。这次采访发生在我的Apples To Apples博文系列(第一部分, 第二部分, 第三部分)之后一两年,我在其中实现了合并排序以及Swift、Objective-C和C中的其他各种排序算法,然后比较了结果。(Swift曾经是真的很慢。)但我并没有从内存中写出这些排序算法。我参考了互联网上无限多的资源来写它们,并确保它们是正确的。我当然没有内化其中任何一个。这不是重点,也不是对时间的良好利用--即使现在也是如此。那些帖子是一个快速练习的乐趣和实验,而且实际上没有人在生产中写过合并的那种。

快进了几年,我最终在Facebook接受了一份工作(大错特错,但这是另一篇文章)。令人惊讶的是,早期Swift团队的一些成员最终离开了苹果,加入了Facebook,从事HHVM或类似的工作,不确定。总之,其中一个人是Nadav Rotem,他曾在编译器优化团队工作。在他给我发信息说他从Apples To Apples博客文章中认出了我的名字后,我们见面喝了杯咖啡,这些文章被火烧和被iOS Dev Weekly链接。我还记得收到了Chris Lattner的信息,感谢我当时写了这些帖子。我了解到,这些帖子已经在内部流传--事实上,一直到克雷格-费德里吉。在那些早期的日子里,苹果急于展示Swift的成功。纳达夫的团队最终使用了我写的代码来改进编译器的优化。


鉴于此,我想我没能通过一个涉及学术性排序算法的面试是非常可笑的,因为没有人会在他们的日常工作中使用这些算法。但我怎么会知道watchOS的基础是建立在合并排序之上的?那是我职业生涯的早期,我很紧张,在那一刻我有点慌了,而且我不得不面对一个混蛋的玩笑。另外,在白板上写代码是他妈的愚蠢的--所以就有了这个。

尽管我没有得到录用通知,但我的招聘人员急于为我争取其他团队的面试。我听说在苹果公司内部所有的团队都是非常不同的。然而,我拒绝了,而是继续接受其他公司的面试。关于这段经历的另一个奇怪之处在于,多年来,我观看了我的面试圈中的一些人在WWDC上的演讲。


自从那次经历后,我在不同公司的面试过程中站了几十次、几十次的两边。我了解到,一个优秀的面试官知道如何提出好的问题,让她对候选人的技能有很多了解,同时确保候选人始终感到舒适和自信。这就是我面试人的方式。

诡计多端的问题和深奥的谜题不会给面试官带来关于面试者的有用信息--她的技能、她的优势、她的弱点、她的发展潜力。这些都是一个伟大的面试官应该寻找的东西。这意味着你要在候选人陷入困境时给予提示,不要用无意义的评论来打断他们。无论你给候选人解决什么问题,作为一个面试官,你的目标应该是让他们尽可能多地解决这个问题,以获得尽可能多的信号。额外的好处是,你走得越远,候选人的感觉就越好,越自信,这也有助于他们为下一个环节做好准备。经验不足的面试者往往需要更多的帮助,这也是可以的。

我们的目标永远不应该是欺骗面试者--那是在浪费大家的时间。而我在那个团队的面试经历就是如此--完全浪费了我和他们的时间。

你可能感兴趣的:([译]我最糟糕的技术面试经历)