更多服務
2 年面試 900 多位工程师后,我总结了这些经验
作者:AMMON BARTRAM 來源:triplebyte.com 日期:2018-11-19 浏覽

我們在Triplebyte做了很多面試。實際上,在過去的兩年裏,我面試了900多名工程師。這是否能很好地利用我的時間可以辯論!(我有時會冷汗醒來並懷疑它。)但無論如何,我們的目標是改善工程師的聘用方式。



为此,我们进行配景盲访,观察编码技巧,而不是凭据或简历。在工程师通过我们的流程后,他们会直接进入我们合作的公司(包罗Apple,Facebook,Dropbox和Stripe)的最终面試。我們在不知道配景的情况下面試工程师,然后了解他们如何跨多家顶尖科技公司。我认为,这给了我们一些关于面試的最佳数据。


在这篇博文中,我将展示我们迄今为止从这些数据中学到的东西。技术面試在很多方面被打破。这很容易说。(许多博客文章都有!)困难的部门是如何处置它。我的目标是接受这一挑战,并为招聘经理和首席技术官提出具体建议。面試很难。但我认为许多问题可以通过慎重的过程来解决。

現狀

大多数面試流程包罗两个主要步骤:

1. 申請人篩選

2. 面对面的最终面試


申請人篩選的目标是尽早过滤候选人,并在面試中节省工程时间。筛选过程通常包罗招聘人员扫描候选人的简历(大约10秒鍾),然後是30分鍾到1小時的電話。我們合作的公司中有18%也使用帶回家編程的挑戰(代替電話屏幕或者除了電話屏幕之外)。有趣的是,篩選步驟是絕大多數候選人被拒絕的地方。


實際上,在我們合作的所有公司中,超過50%的候選人僅在簡曆掃描中被拒絕,另有30%的人在電話屏幕/帶回家時被拒絕。篩選也是招聘可能最爲反複無常的地方。招聘人員的數量不堪重負,需要做出快速決策。這是憑證和模式匹配發揮作用的地方。


面对面的最终面試几乎普遍包罗一系列45分钟到1小时的课程,每个课程都有差异的面試官。会议主要是技术性的(每个公司有一两个专注于文化契合和软技能)。最终雇用/不雇用决定是在候选人离开后的决策会议上与招聘经理和所有面試候選人的人一起做出的。從本質上講,候選人至少需要一名強有力的支持者,並且沒有強烈的批評者可以提出要約。


然而,除了通用格式之外,最終的面試差異很大。

· 我們合作的公司中有39%在白板上使用標記進行面試

· 52%允許候選人使用自己的計算機(其余9%不一致)

· 55%让面試官选择自己的问题(其余45%使用尺度的问题库)

· 40%的人需要在候選人中看到學術CS技能才气提出報價

· 15%的人不喜歡學術CS(並認爲談論CS是一個候選人不會有效的標志)

· 80%让考生在面試中使用任何语言(其余20%需要特定语言)

· 5%在面試中明确评估语言细节

 

在我們合作的所有公司中,22%的最终面試会带来工作机会。(这个数字来自向公司询问他们的内部候选人管道。通过Triplebyte申请的候选人在53%的面試后获得了报价。)大约65%的报价被接受(导致招聘)。1年后,公司对约30%的员工非常中意,而且已经解雇了约5%。

假陰性與假陽性

那么,現狀有什么差池?究竟,火灾似乎并没有失控。要检察问题,请考虑面試可能有两种失败方式。面試可能会导致工程师被雇用,后来被解雇(误报)。面試可以取消那些本可以做得好的人(假阴性)。糟糕的雇员是非常明显的,对公司而言是昂贵的(工资,治理成本和整个团队的士气)。糟糕的雇佣会吸引团队的精力。相比之下,能够完成工作但没有机会的候选人是看不见的。任何一个案例总是有争议的。由于这种差池称性,公司严峻偏向于面試拒絕。


過程中的噪音會加強這種效果。在1小時內判斷編程技巧從根本上說是困難的。再添加一個模式匹配和一些腸道呼叫的劑量以及上面討論的公司偏好的複雜湯,你留下了非常嘈雜的信號。


为了在面对这种噪音时保持低误报率,公司不得不将决策偏向于拒絕。结果是一个错过优秀工程师的过程,仍然经常偏好真实技能的凭证,而且经常对所涉及的人感到反复无常和沮丧。如果贵公司的每个人都必须为他们目前的工作重新面試,那么会有多少百分比?這是一個可怕的問題。答案幾乎肯定低于100%。當候選人被他們本可以做得很好的公司拒絕時,他們會受到傷害,當公司找不到他們需要的人才時會受到傷害。


需要明確的是,我並不是說公司應該在面試中降低尺度。拒绝是面試的重点!我甚至没有说公司错误地认为误报远比假阴性更强。坏员工很贵。我認爲嘈雜的信號與幸免不良雇傭的需要相結合會導致非常高的漏報率,這會傷害到人們。解決方案是改善信號。


面試中減少噪音的具體方法

1.決定你正在尋找什麽技能

沒有一套技能可以定義一個好的程序員。相反,存在著各種各樣技能的海洋。在這些領域,沒有工程師可以強大。事實上,在Triplebyte,我们经常看到优秀,乐成的软件工程师,他们拥有完全不相交的技能。那么,进行良好面試的第一步是决定哪些技能对于角色至关重要。我建议你问自己以下问题(这些是我們在Triplebyte上新公司时提出的问题)。


· 您需要快速,叠代的程序員,還是需要謹慎嚴謹的程序員?

· 您是否想要通過解決技術問題或構建産品來激勵他人?

· 您是否需要特定技術的技能,或者智能程序員能否在工作中學習它?

· 學術CS /数学/算法能力是重要还是无关紧要?

· 理解並發/ C内存模型/ HTTP重要吗?


這些問題沒有正確的答案。我們與乐成的公司合作,每家公司都是雙方公司。但关键是根据您的需求做出有意的选择。要幸免的反模式只是随机选择面試问题(或让每个面試官决定)。


当这种情况发生时,公司工程文化可能会倾向于越来越多的工程师拥有对公司而言可能并不重要的特定技能或方法的方向,而没有这种技能(但其他重要技能)的工程师则被拒絕。


2.盡可能接近實際問題提問

聘请专业程序员来解决数周和数月的庞大而庞大的问题。但是,面試官没有数周或数月的时间来评估候选人。每位面試官通常有1小時。因此,面試官会考虑候选人在胁迫下迅速解决小问题的能力。这是一种差异的技能。它是相关的(访谈不是完全随机的)。但它并不完全相关。最小化这种差异是开发面試问题的目标。


这是通过使面試问题尽可能与您希望候选人做的工作(或您想要丈量的技能)相似来实现的。例如,如果你关怀的是后端編程,那么要求候选人构建一个简单的API端點然後添加功能幾乎肯定比要求他們解決BFS字鏈問題更好。如果您關心算法能力,請求候選人將算法應用于問題(例如,構建一個簡單的搜索索引,可能由BST和哈希映射支持以提高刪除性能)幾乎肯定比要求他們確定是否更好凹點包罗在凹多邊形中。和調試挑戰,候選人在真正的代碼庫中工作,


這就是說,有做在白板上進行面試的說法。作爲一名面試者,我不在乎工程師是否記住了Python itertools模块。我关怀他们是否可以考虑如何使用迭代器来解决问题。通过让候选人在白板上工作,我将他们从正确的语法中解放出来,让他们专注于逻辑。最终我认为这个论点失败了,因为对于差异的格式没有足够的理由。您可以通过同意候选人在计算机上工作来获得所有好处,但告诉他们他们的代码不需要运行(甚至更好,使其成为一个开放的书籍面試并让他们通过Google查找他们想要的任何内容)。


关于面試问题应该反映工作的想法有一个重要的警告。面試问题不受外部依赖的影响是很重要的。例如,要求候选人在Ruby中编写一个简单的Web scraper似乎是一个很好的真实字问题。但是,如果一个候选人需要安装Nokogiri(一个可能很难安装的Ruby解析库)而且他们最终会在当地扩展中挣扎30分钟,这就酿成了一个糟糕的面試。不僅浪費了時間,候選人的壓力也已經消逝了。


3.提出無法提供的多部门問題

面試问题的另一个好的经验法则是幸免可以“放弃”的问题,即幸免问题,即候选人可以在Glassdoor上提前阅读的一些奇妙的信息,以便他们轻松回答。这显然排除了脑筋急转弯或任何需要洞察力的问题。但它逾越了这一点,而且意味着问题需要是一系列相互依赖的步骤,而不是单一的核心问题。考虑这个问题的另一个有用的方法是问问自己是否可以资助陷入困境的候选人,而且仍然以积极的印象结束面試。在一个步骤的问题上,如果你必须给候选人提供重要资助,他们就会失败。在一个多部门问题上,你可以资助一步,然后候选人可以获得其他一切而且做得很好。


這很重要,不僅因爲您的問題會泄漏到Glassdoor上,而且(更重要的是)因为多部门问题不那么嘈杂。好的候选人会变得紧张并陷入困境。能够资助他们并让他们恢复是很重要的。根据他们最近是否看到类似的问题,而且可能只是机会,候选人解决任何一个編程逻辑的能力有很大的噪音。多部门问题可以消除一些噪音。他们还让候选人有机会看到他们的努力雪球。应用于一个步骤的努力通常有助于他们解决后续步骤。这是一项重要的动态,在做实际工作时,在面試中捕捉它会降低噪音。


舉一個例子,要求候選人在一個終端(一系列多個步驟)中實現遊戲連接四可能比要求候選人旋轉矩陣(一步,一些簡單的贈品)更好的問題。並且實現k-means聚類(相互構建的多個操作)可能比確定可以適合直方圖的最大回轉更好。


4.幸免難題

如果一個候選人很好地解決了一個非常難的問題,那就會告訴你很多他們的技巧。但是,由于問題很難,大多數候選人都無法很好地解決問題。因此,從問題中獲得的預期信息量會受到問題難度的嚴重影響。我們發現最佳難度級別比大多數面試者猜測的要容易得多。


面試候選人時,有兩個信號來源:他們是否對問題給出“正确”答案,以及他们的过程/他们如何轻易地得出答案,这一事实放大了这种效应。我們在Triplebyte上收集了有关这方面的数据(对候选人是否到达正确答案,以及他们花了多少努力,然后衡量哪些分数预测公司的乐成进行了评分)。我们发现的是权衡。对于更难的问题,候选人是否正确回答了大部门信号。相比之下,对于更简单的问题,大多数信号都出现在候选人的过程中以及他们挣扎多少。考虑到两种信号源,最佳点是更容易结束。


我们现在遵循的经验法则是,面試官应该能够在他们期望候选人花费的25%的时间内解决问题。所以,如果我正在为1小时的面試开发一个新问题,我希望我的同事(没有任何警告)能够在15分钟内回答这个问题。与我们使用多部门真实世界问题这一事实相结合,这意味着最佳面試问题非常简单明了。


要明確的是,我並不是在爭論通過率降低標准。我主張提出簡單的問題,然後在評估中包罗候選人如何輕松地回答問題。我主張提出簡單的問題,但後來判斷相當嚴厲。這就是我們發現的優化信號。對于大多數申請人來說,它具有降低壓力的額外好處。


舉例來說,要求候選人創建一個簡單的命令行界面,其中包罗用于存儲和檢索鍵值對的命令(如果它們運行良好,則添加功能)可能比要求候選者實現算術表達式的解析器更好。涉及最常見數據結構(列表,散列,可能是樹)的問題可能比關于跳過列表,treaps或其他更模糊的數據結構的問題更好。


5.向每位候選人詢問相同的問題

訪談是關于比較候選人。我們的目標是將候選人分類爲能夠爲公司做出貢獻的人和那些不能做出貢獻的人(以及在雇用單一職位時,選擇最適合的人)。鑒于此,沒有理由向差异的候選人提出差异的問題。如果您以差异的方式評估同一工作的差异候選人,則會引入噪音。

我認爲,以特別的方式選擇問題仍然是常見的原因是因爲這是面試者更喜欢的问题。科技公司的工程师通常不喜欢面試。这是他们间或做的事情,它使他们远离他们的主要焦点。为了使每个候选人提出的问题尺度化,面試官需要花更多的时间来学习问题,并谈论评分和交付。每当问题发生变化时,他们都需要重新做这件事。此外,总是问同样的问题只是一点点乏味。


不幸的是,這裏唯一的答案是讓面試者付出努力。一致性是进行良好面試的关键,这意味着要求每位候选人提出相同的问题,并规范交付。根本没有其他选择。


6.考慮運行多個軌道

与我之前的观点相反,请考虑提供几种完全差异的面試版本。设计面試的第一步是考虑哪些技能很重要。但是,有些答案可能会有冲突!例如,想要一些非常狡猾的工程师,以及一些非常高效/迭代的工程师(甚至可能是同一个角色),这是很正常的。在这种情况下,请考虑提供多个版本的访谈。关键点在于,您需要到达足够的比例,以便完全尺度化每个轨道。这就是我們在Triplebyte所做的事情。我们发现,您可以简单地询问每位候选人他们更喜欢哪种类型的面試。


7.不要讓自己受到憑證的偏見

證書不是沒有意義的。從麻省理工學院或斯坦福大學畢業,或者在谷歌和蘋果公司工作的工程師,作爲一個團隊,實際上比沒有工作的工程師更好。問題是絕大多數工程師(包罗我自己)都沒有做過這些事情。因此,如果一家公司過于依賴這些信號,他們將會錯過大多數熟練的申請人。在篩選步驟中給予證書一些權重並非完全不合理。我們不會在Triplebyte這樣做(我們所有的評估都是100%配景盲人)。但是在篩選時給予一些重量可能是有意義的。


然而,让凭据影响最终面試决定是没有意义的。我们有数据显示这种情况发生了。对于我们配景盲人流程的特定绩效水平,拥有顶尖学校学位的候选人继续以比没有名牌简历的候选人高出30%的速度通过公司面試。如果面試官知道候选人拥有麻省理工学院的学位,他们更情愿在面試中原谅粗拙的地方。


这是噪音,你应该幸免它。最明显的方法是在将简历中的学校和公司名称提交给面試官之前。有些候选人可能会提到他们的学校或公司,但是我們在不知道候选人配景的情况下进行所有面試,而且在技術評估期間候選人提出這個問題實際上非常罕見。


8.幸免欺侮

面試失败的最貌寝方式之一是他们可以接纳欺侮的方面。他们不只是评估候选人的技能,他们也是关于招收成员的团队或团队。在第二种能力中,它们可以成为一种成年礼。是的,面試既压力又可怕,但我们都是这样做的,候选人也应如此。当候选人体现不佳时,这可能会更加突出。作为一名面試者,當答案看起來如此明顯時,看到一位候選人對問題嗤之以鼻是令人沮喪的!你可以得到短暫的沮喪和沮喪。當然,這只會增加申請人的壓力。


這是你想要離一英裏遠的地方。解決方案是討論問題並培訓面試者。我們使用的一個技巧是,當一個候選人做得很差時,從目標是判斷候選人的評估模式切換到教學模式,其目標是讓候選人理解問題的答案。精神上的切換可以幫助很多。當你處于教學模式時,沒有理由隱瞞信息或除了友好之外的其他任何東西。


9.根據最高技能做出決定,而不是平均技能或最低技能

到目前为止,我只讨论过个别问题,而不是最终的面試决定。我的建议是实验根据候选人显示的最高技能水平(跨越您关怀的技能领域),而不是平均水平或最低水平。


這可能是你已經在做的,無論是有意還是無意!雇用/不聘用雇员的决定方式是,每个与候选人面谈的人都聚在一起到场会议,而且如果至少有一个人强烈支持招聘,而且没有人强烈反对,则会提出要约。为了让一位面試官鼎力支持,候选人需要做的就是面試的一部门。在我们的数据中,最高技能是与公司面試的至少一部门最相关的属性。然而,要成为一个提议,候选人也不需要任何人强烈反对他们。当候选人在一个问题上看起来非常愚蠢时,强烈的努力就来了。


在這裏我們發現了很多噪音。有很多差异的方法可以成爲一名熟練的工程師,幾乎沒有候選人可以掌握所有這些。這意味著如果您提出正確(或錯誤)的問題,任何工程師都會看起來很愚蠢。候选人获得报价,然后,当至少一次面試与一个强度区域(最高技能)排队时,没有区域排列显着的弱点。问题是这很吵。同一位工程师因为他们在关于网络的问题上看起来很愚蠢而未能通过一次面試,因为这个话题没有出现,所以他们面試了其中的顔色。


我认为,最好的解决方案是让公司专注于最高技能,而且对面試部门看起来很糟糕的人提供更多的便利。這就是,尋找有理由說出肯定的理由,而不是擔心候選人很弱的技術領域。我不想對此絕對。當然,技術領域對公司而言至關重要。並且決定你想擁有一種文化,團隊中的每個人都在某個特定領域處于一定水平,這可能是有道理的。但更多地關注最高技能確實會減少面試噪音。


爲什麽要面試

我应该回答的最后一个问题是爲什麽要面試?我確信有些讀者一直在咬牙切齒,並說“爲什麽要想一个破碎的系统呢?只需使用带回家的项目!或者只是试用就业!“究竟,一些非常乐成的公司使用试用工作(候选人加入团队一周),或完全取代现场项目的面对面面試。试用就业很有意义。花一个星期在工程师旁边工作(或者看看他们如何完成一个实质性项目)几乎可以肯定地提供一个更好的衡量他们的能力,而不是看他们解决面試问题1小時。


然而,有两个问题使得试用工作不能取代尺度面試:


1. 试用期对公司来说是昂贵的。没有公司可以与每个申请人一起度过整整一周。要决定谁到场试验,公司必须使用其他一些面試流程。


2. 对于候选人来说,试用就业(和大型带回家项目)是昂贵的。即使他们获得酬劳,也不是所有候选人都有时间。例如,一名从事全职工作的工程师可能根本无法休假。即使他们可以,许多人也不会。如果工程师已经有了工作机会,他们就不太情愿负担工作试验的不确定性。我們在Triplebyte候選人中清楚地看到了這一點。許多最佳候選人(手頭有其他優惠)根本不會做大型項目或工作試驗。


試用就業的結果是提供一些候選人的絕佳選擇。我認爲如果你有支持多個曲目的規模,添加一個試用就業軌道是一個好主意。然而,作爲訪談的完全替代,這是不行行的。


与候选人谈论过去的经验有时也被提出作为技术面試的替代品。为了确定候选人是否可以在将来做好工作,逻辑就是,看看他们过去做了些什么。我們在Triplebyte測試了這個,不幸的是我們沒有取得很好的效果。溝通能力(推銷自己的能力)最終成爲比技術能力更強的信號。


找到口口相传的人夸大自己的角色(为团队的工作赢得信任),以及谦虚的人,他们淡化他们所做的事情,这种情况太常见了。如果有足够的时间和足够的质疑,应该可以深入了解这一点。但是,我们发现,在定期面試的时间范围内,谈论过去的经历并不是面試的一般替代品。这是一个与候选人打破僵局并了解他们的兴趣(推断沟通能力和文化适应性)的好方法。但这不是一个可行的完全取代面試


編程面試的好處!

我希望以更積極的方式結束這篇文章。對于面試中出錯的一切,對他們來說有很多是對的。

访谈是直接的技能评估。我有老师的朋友,他们告诉我,老师的面試基本上是衡量沟通能力(推销自己的能力)和证书的尺度。这似乎适用于许多职业。硅谷并不是一个完美的精英。但我们至少会实验直接衡量重要的技能,并保持开放的想法,任何拥有这些技能的人,无论配景如何,都可以成为伟大的工程师。凭证偏见经常阻碍这一点。但是我们已经能够在Triplebyte中克服這個問題,並且幫助很多具有非常規配景的人獲得了很好的技術工作。我不認爲Triplebyte是可能的,例如,在法律領域。對憑證的依賴太高了。


程序员也选择面試。虽然这是一个非常有争议的话题(当然程序员有差异的感受),但当我们开展提供差异类型评估的实验时,我们发现大多数程序员仍然会选择定期面試。我们发现只有少数程序员对使用试用或带回家项目的公司感兴趣。无论好坏,編程面試似乎都在這裏說。其他類型的評估是很好的補充,但它們似乎不行能取代面試作爲評估工程師的主要方式。要錯誤引用丘吉爾,“面試是评估工程师最糟糕的方式,除了所有其他经常实验过的方法。”


結論

面試很难。人类无可救药地复杂化。在某种水平上,在4小時的面試中推断人的能力只是一个愚蠢的差事。我认为保持谦虚很重要。任何面試过程都会在很多时候失败。人太复杂了。


但這不是放棄的理由。Triplebyte,我們的面試是我們的産品。我們集體討論想法,測試它們,並隨著時間的推移而改進。我認爲,這是改善工程師聘用方式所需的方法。