工程師面試技巧

　　技術面試常常有很多坑，不管是對面試官還是面試者來說，都是如此。下面是學習啦小編為大家整理的工程師面試技巧，希望對大家有用。

　　技術面試現(xiàn)狀

　　大部分面試過程包括兩個主要步驟：

　?、偕暾埲撕Y選

　　②面對面最終面試

　　申請人篩選的目的是盡早過濾候選人，并節(jié)省面試時間。篩選過程通常先是招聘人員瀏覽候選人的簡歷(約 10 秒鐘)，然后是 30 分鐘至 1 小時的電話面試。與我們合作的公司中約有 18% 的公司會讓候選人進行一項可帶回家完成的編程挑戰(zhàn)(代替電話面試或者作為電話面試的補充)。有趣的是，絕大多數(shù)候選人在篩選步驟就會被拒絕。事實上，在所有與我們合作的公司中，超過 50% 的候選人在簡歷篩選階段就被拒絕了，另外 30% 的候選人在電話面試或編程挑戰(zhàn)中被拒絕。篩選階段可以說是招聘中最反復無常的。招聘人員不堪重負，因此需要快速做出決定。這一步也是證書和模式匹配發(fā)揮作用的地方。

　　面對面最終面試大部分會包括一系列 45 分鐘到 1 小時的談話，每次談話對應不同的面試官。這些談話主要是技術性的(每個公司會有一兩次談話重點考察文化適應度和軟技能)。在候選人離開之后，招聘經理和面試過候選人的所有人會聚在一起開會做出最終是否錄用的決定?；旧希蜻x人至少需要得到一個人強有力的肯定，同時沒有強烈的反對者才會被錄用 [2]。

　　除了常見的面談形式之外，最終面試還有各種不同特點。

　　在與我們合作的公司中有 39% 在面試中會讓候選人在白板上展示解題過程

　　52% 允許候選人使用自己的電腦(剩下還有 9% 既不用白板也不用電腦)

　　55% 讓面試官自己提問題(剩下的 45% 使用標準的問題庫)

　　40% 需要考察候選人學術方面的計算機軟件技能來決定是否錄用

　　15% 不喜歡過于學術的計算機軟件技能(并認為談論學術能力暗示候選人缺乏創(chuàng)造性)

　　80% 允許候選人在面試中使用任何編程語言(其余 20% 要求使用特定編程語言)

　　5% 在面試中會明確評估編程代碼的細節(jié)

　　在與我們合作的所有公司中，參加最終面試的候選人有 22% 能得到工作機會。(這個數(shù)字是從公司的內部候選人通道詢問得來的。通過 Triplebyte 申請的候選人有 53% 在面試之后得到了工作機會。)通過面試的人中約 65% 接受了這個工作機會(即最終被雇用)。1 年以后，公司對大約 30% 的新聘用員工感到滿意，同時已經有 5% 左右的新員工被解雇 [3]。

　　漏判和誤判

　　那么現(xiàn)狀到底存在什么問題呢?畢竟，解雇比例似乎還在可控范圍內。為了搞明白其中的問題，需要考慮面試失敗的兩種情況。面試可能會雇用一名不合適的工程師， 然后過一段時間又解雇掉(此為誤判)。同時面試也可能會錯誤地低估那些本來可能做得很好的人(此為漏判)。糟糕的雇員是很容易被發(fā)現(xiàn)的，而且對公司而言代價昂貴(從薪酬、管理成本和整個團隊的士氣來看)。一個糟糕的雇員還會損耗團隊的精力。相比之下，那些本來能做得很好但沒得到機會的候選人帶來的損失則難以察覺。每次這種情況的出現(xiàn)總會存在爭議。由于這種不對稱性，公司進行面試時更多地傾向于拒絕。

　　這種傾向還會被面試過程中的噪音加強。在 1 小時內判斷編程技能水平從根本上來說是非常困難的。在此基礎上再加上模式匹配和幾次電話考察，以及前面討論過的按公司各種偏好進行的復雜考察，最終留給面試官的是一個包含了大量噪音的信號。

　　面對這些噪音，為了保持較低的誤判率公司在做決定時必須傾向于拒絕。這樣做會導致公司的面試過程可能錯過優(yōu)秀的工程師，常常過于看重證書而非真才實學，且會讓參加面試的候選人感到反復無常和備受打擊。如果你所在的公司中每個人都為了得到現(xiàn)在的工作重新進行面試，那通過率會是多少呢?這是一個非?？膳碌膯栴}。答案肯定遠不到 100%。那些本來可以很好地完成工作的候選人在被公司拒絕后會受到傷害，而公司在找不到所需人才時也會受到傷害。

　　這里需要聲明一下，我并不是說公司應該要降低面試的門檻。面試本來就需要拒絕一部分人!我也不認為公司更擔心誤判而不是漏判是錯誤的。畢竟糟糕的雇員確實需要付出高昂的代價。我只是認為當一個充滿噪音的信號與避免糟糕的雇員的需求同時出現(xiàn)時，會導致非常高的漏判率，這樣做會傷害到候選人。而這個問題的解決辦法是改善信號。

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

　　1. 明確你要尋找的技能

　　世界上并不存在一套唯一的可以定義一個好程序員的技能。反之，存在著大量各不相同的技能集。沒有工程師可以精通所有技能。事實上，我們在 Triplebyte 經?？吹胶芏鄡?yōu)秀且成功的軟件工程師具備完全不同的技能。那么，進行一次成功的面試的第一步就是決定對于面試的職位來說什么技能是重要的。我建議你問自己以下問題(這些是我們在 Triplebyte 開始為新合作的公司招募人才時會提出的問題)。

　　你需要的是能快速進行開發(fā)和迭代的程序員，還是小心仔細、思維嚴謹?shù)某绦騿T?

　　你想要的是對解決技術問題有興趣的人，還是對開發(fā)產品有興趣的人?

　　你需要的是已經掌握特定技術的人，還是允許聰明的程序員在工作中學習這一技術?

　　學術方面的計算機軟件、數(shù)學、算法能力是重要還是無關緊要?

　　理解并發(fā)、C 內存模型、HTTP 重要嗎?

　　以上問題并沒有正確答案。我們所合作的成功的公司給出的答案兩種皆有。最重要的是要依據(jù)自身的需求做決定。需要避免隨機挑選面試問題(或讓每個面試官自己決定)。當這種情況發(fā)生時，公司的工程文化可能會出現(xiàn)偏斜，即越來越多的工程師具有特定的技能或方法，但那些技能或方法對公司來說可能并不重要，而沒有那些技能的工程師(但是擁有其他重要技能)卻被拒絕了。

　　2. 提問時盡可能貼近實際工作

　　聘請專業(yè)的程序員是為了解決耗時數(shù)周甚至數(shù)月的龐大而涉及面甚廣的問題。但面試官并沒有數(shù)周或數(shù)月的時間來評估候選人。每個面試官通常只有 1 小時。因此，面試官轉而考察候選人在一定壓力下迅速解決小問題的能力。其實這并不是同一個技能。它是相關的(面試不是完全隨機的)，但并不完全相關。制定面試問題的目標就是最小化這種差異。

　　要達到這個目標需要使面試問題盡可能地貼近你想要候選人完成的工作(或你打算評估的技能)。例如，如果你關心的是后端編程，要求候選人開發(fā)一個簡單的 API 端點然后添加功能會是一個更好的問題，而不應該要求他們解決 BFS 詞鏈問題。如果你關心的是算法能力，要求候選人應用算法來解決問題(比如開發(fā)一個簡單的搜索索引，可以基于二叉搜索樹和哈希表，以提高刪除性能)會是一個更好的問題，而不應該要求他們判斷一個點是否包含在一個凹多邊形中。讓候選人在真實代碼庫中編碼并調試通常都優(yōu)于讓候選人在白板上解決一個小問題。

　　也就是說，采用白板方式進行面試是存在爭議的。作為面試官，我不在乎工程師是否記住了 Python 的 itertools 模塊。我關心的是他們能不能思考如何使用迭代器來解決問題。通過讓候選人在白板上解決問題，可以讓他們暫時不用考慮語法是否正確，而是專注于邏輯。但我還是認為這個說法有問題，因為理由仍然不夠充分。讓候選人在計算機上編寫代碼同樣可以獲得所有的好處，只要告訴他們代碼不需要運行即可(甚至更好，可以把它變成開卷的面試，并允許他們在谷歌上查找任何他們想要的信息)。

　　面試問題應該反映實際工作還需要注意一點，即面試問題不應該依賴于外部依賴包。例如，要求候選人使用 Ruby 編寫一個簡單的 Web 爬蟲看上去似乎是一個很好的真實問題。然而，如果候選人需要安裝 Nokogiri(一個 Ruby 解析庫，安裝過程可能會很痛苦)，并且在本機擴展中苦苦掙扎了 30 分鐘才搞定，這將變成一次可怕的面試。不僅浪費時間，而且會讓候選人承受巨大的壓力。

　　3. 提問時將問題拆分成多個部分，使之無法泄漏

　　面試提問時還有另一個很好的經驗法則是避免提出可能“泄露”的問題，即避免提出候選人可以提前在 Glassdoor 上看到答案要點的問題，否則他們回答問題就過于輕松了。這顯然能排除腦力衰退者或任何需要極高洞察力的問題。但遠不止如此，這還意味著面試問題需要包含一系列相互依存的步驟，而不是單一的核心問題。另一種有用的考慮方式是問問自己應該如何幫助一個被問題卡住的候選人，并且以積極的印象結束面試。對于一個只有一個步驟的問題，如果你必須給予候選人大量的幫助，那么他們就不能通過面試。而在一個分成多個部分的問題上，你可以在其中一步給予幫助，候選人就可以在剩下其他部分完成得很好。

　　這不僅僅是因為你的面試問題可能會泄漏到 Glassdoor 上，而且(更重要的是)，分成多個部分的問題不會包含那么多噪音。好的候選人也會因為太過緊張而被問題困住。面試官應該能夠幫助他們并看到他們恢復到良好狀態(tài)。基于候選人最近是否看到過類似的問題(可能只是無意看到)，會給評估候選人解決一個編程邏輯塊的能力引入很大的噪音。分成多個部分的問題可以消除部分噪音。同時也為候選人提供了一個機會以展示他們努力的過程。在一個步驟中做出的努力往往有助于他們解決后續(xù)步驟。這在實際工作中將成為一個重要的動力，而在面試過程中捕捉到這一點就能減少噪音。

　　舉個例子，要求候選人在終端上實現(xiàn)游戲 Connect Four(包含一系列步驟)可能比要求候選人旋轉一個矩陣(只有一個步驟，而有一些簡單的竅門)更好。又比如說，實現(xiàn) k 均值聚類(包含相互依存的多個步驟)可能比確定適配直方圖的最大矩形更好。

　　4. 避免提太難的問題

　　如果候選人能很好地解決一個非常困難的問題，那么你可以得到和他的技能有關的很多信息。但是，由于問題太難，大多數(shù)候選人都無法很好的解決問題。那么問題的難度將嚴重影響預期能從這個問題獲得的信息量。我們發(fā)現(xiàn)，面試中問題的最佳難度比大多數(shù)面試官認為的要容易得多。

　　這種影響由于面試候選人時存在的兩個信號來源而被放大：即他們是否給出了一個問題的“正確”答案、他們得到答案的過程或容易程度。我們在 Triplebyte 已經收集了很多相關數(shù)據(jù)(根據(jù)候選人是否得到正確答案以及他們花費了多少努力對問題進行評分，然后衡量哪些評分能預測他們在公司中的表現(xiàn))。我們發(fā)現(xiàn)這里有一個權衡問題。對于更難的問題，候選人的答案是否正確攜帶了大部分信號。相比之下，對于更容易的問題，更多信號來源于候選人解決問題的過程以及他們的努力程度?？紤]到信號的兩個來源，顯然選擇比較容易的問題更好。

　　我們現(xiàn)在遵循的經驗法則是，面試官應該能在他們期望候選人花費的時間的 25% 的時間內解決問題。所以，如果我正在制定一個用于 1 小時面試的新問題，我希望我的同事(沒有任何提示)能夠在 15 分鐘內回答這個問題。再配合前面所說的將問題分成多個部分且盡可能貼近實際工作，我們要得到最佳面試問題其實很簡單。

　　需要聲明的是，我并不認為為了提高通過率要降低門檻。我想說的是要提出簡單的問題，然后在評估結果中包含候選人回答問題的過程。我認為提出的問題應該簡單，但評判時需要相當嚴苛。這就是我們發(fā)現(xiàn)的可以優(yōu)化信號的方法。它的另一個的好處就是對大部分候選人來說壓力比較小。

　　舉個例子，要求候選人開發(fā)一個簡單的命令行界面，其命令用于存儲和檢索鍵值對(如果他們完成得很好，還可以添加更多功能)可能比要求候選人實現(xiàn)算術表達式的解析器更好。而一個涉及最常見的數(shù)據(jù)結構(列表、散列或者樹)的問題可能比涉及跳躍表、樹堆或其他晦澀的數(shù)據(jù)結構的問題更好。

　　5. 對每一個候選人提同樣的問題

　　面試是為了對候選人進行比較。目標是將候選人分為能夠為公司做出貢獻的人以及不能為公司做出貢獻的人(如果只有一個職位空缺，則選擇最適合的人)。鑒于此，向不同候選人提出不同的問題將難以做出判斷。如果以不同的方式評估同一工作的不同候選人，則會引入噪音。

　　我認為，以特別的方式選擇問題之所以常見，是因為面試官更喜歡這種方式。技術公司的工程師通常不喜歡面試。他們只是偶爾為之，而且面試會讓他們無法專注于本職工作。為了規(guī)范對每個候選人提出的問題，面試官需要花更多的時間來學習問題，并討論如何評分和交付。每次更換問題時，他們都需要重復這一過程。另外，總是問同樣的問題難免會有些乏味。

　　不幸的是，這里唯一的解決方法就是面試官付出努力。一致性是進行成功的面試的關鍵，這意味著要對每個候選人提出相同的問題，并規(guī)范交付。別無選擇。

　　6. 考慮進行多個版本的面試

　　考慮提供幾個完全不同版本的面試，看似與我前面的觀點相沖突。設計面試的第一步是考慮該職位需要什么技能。但是，其中部分答案可能會發(fā)生沖突!例如，需要一些真正的數(shù)學工程師，以及一些非常有創(chuàng)造性或能做到快速迭代的工程師(這甚至可能是對同一個角色的要求)，都是非常常見的。在這種情況下，就要考慮提供多個版本的面試。關鍵是要有足夠大的規(guī)模以便對每個版本都進行完全標準化。這正是 Triplebyte 正在做的事情。我們發(fā)現(xiàn)，你完全可以直接詢問每個候選人他們想要進行哪種類型的面試。

　　7. 不要因證書或資質產生偏見

　　證書和資質并非毫無意義。從麻省理工學院或斯坦福大學畢業(yè)的工程師，或在 Google 和蘋果公司工作過的工程師，總體來說，確實比其他的工程師更優(yōu)秀。問題是絕大多數(shù)的工程師(包括我自己)既不是從這些名校畢業(yè)的，也未曾在這些名企工作過。所以如果一家公司過于依賴這些信息，他們會錯過絕大多數(shù)技能符合要求的申請人。在篩選步驟中結合證書和資質進行篩選有其合理性。但我們在 Triplebyte 不會這樣做(我們進行所有評估時都是 100% 盲背景的)。但若對篩選有意義，也會為證書和資質增加一些權重。

　　然而，讓證書和資質影響最終面試決定則毫無意義。我們有數(shù)據(jù)表明確實存在這種情況。對于在我們的盲背景流程中表現(xiàn)出同樣水平的候選人，其中擁有頂級名校學位的候選人相比那些沒有名牌高校履歷的候選人通過面試的比例高出 30%。如果面試官知道候選人具有麻省理工學院的學位，他們更愿意原諒候選人在面試中表現(xiàn)欠佳的地方。

　　這就是噪音，面試時應盡量避免。最簡單的方法就是將學校和公司的名稱從簡歷中刪除，再交給面試官。部分候選人可能會在面試中提到他們的學?；蚬荆钱斘覀冊诓涣私夂蜻x人背景的情況下進行所有面試，候選人在技術評估過程中提到學?；蚬镜那闆r實際上非常罕見。

　　8. 避免讓面試陷入陰霾

　　面試失敗最糟糕的方式之一就是陷入陰霾。面試不僅僅是在評估候選人的技能，也是團隊在考慮是否接納一個新成員。從后者來看，面試可能會成為一個加入儀式。面試確實壓力很大也很可怕，但是如果我們都這樣想那么候選人也會這樣想。當候選人表現(xiàn)得不好時，這種情況還會加重。作為面試官，看到一個候選人無法解決問題時可能會非常沮喪，尤其當答案看起來如此明顯的時候!你可能會短暫地覺得生氣和沮喪，當然，這只會令申請人徒增壓力。

　　這是你應該極力避免的情況。解決辦法是探討這個問題并對面試官進行培訓。我們會用的一個竅門是，當候選人確實表現(xiàn)得很差時，從評估模式轉向教學模式，前者的目標是評估候選人，而后者的目標則是讓候選人理解問題的答案。切換模式將大有助益。當你處于教學模式時，就沒有任何理由拒絕提供信息或者表現(xiàn)得不友好。

　　9. 做決定時基于技能的長板而非平均水平或短板

　　到目前為止，我只談到單個面試問題，還沒談到最后的面試決定。對于這一點，我的建議是嘗試根據(jù)候選人表現(xiàn)出來的各項技能的長板(涵蓋所有你所關心的技能領域)來做出決策，而不是各項技能的平均水平或短板。

　　或許你已經有意無意地在這么做了。決定錄用還是不錄用的方式是每個面試了候選人的人聚在一起開會，如果至少有一個人強烈要求錄用，而且沒有人強烈反對，就可以給出錄用要約。要讓至少一位面試官強烈地支持錄用，候選人需要在面試的某一環(huán)節(jié)表現(xiàn)良好。從我們的數(shù)據(jù)來看，最強技能一般是與公司面試中至少一個環(huán)節(jié)最相關的特性。然而，要得到錄用要約，候選人還需要沒有人強烈地反對錄用。如果候選人在某個問題上表現(xiàn)得特別愚蠢，就可能會被一票否決。

　　我們在這個環(huán)節(jié)發(fā)現(xiàn)了很多噪音。成為一名技術純熟的工程師有很多不同的途徑，但幾乎沒有候選人可以掌握所有技能。這意味著如果你提出正確的(或錯誤的)問題，任何工程師都可能看起來很愚蠢。只有當候選人在至少一次面試中顯示出某一領域的長處(最強技能)，而且在其他領域沒有明顯的弱點時，才會得到錄用要約。但問題是這中間是存在噪音的。同一個工程師可能因為在網絡相關問題上看起來很蠢而沒能通過面試，也可能因為這個話題沒有出現(xiàn)而出色地通過了其他的面試。

　　我認為最好的解決方案是公司專注于最強技能，并且對于在面試某些部分表現(xiàn)不太好的人也可以適當?shù)靥岢鲣浻靡s。即尋找強有力的理由說同意，而不過多擔心候選人偏弱的技術領域。我不想說得過于絕對?？傆幸恍┘夹g領域對于公司而言是至關重要的。決定你想要的公司文化，使團隊中的每個人都在某一技術領域具備一定水平也是有道理的。但更多地關注最強技能可以降低面試的噪音。

　　到底為什么要面試?我要解答的最后一個問題是——到底為什么要面試?我相信有一些讀者一直在咬牙切齒地說：“為什么要為了一個混亂不堪的系統(tǒng)考慮這么多呢?就采取可帶回家完成的編程項目或者試用的方法就可以了吧!”畢竟，確實有一些非常成功的公司就是采取試用的方法(讓候選人加入團隊工作一個星期)，或者采取可帶回家完成的編程項目完全取代了面談。試用的方法確實是很有意義的。與工程師一起工作一個星期(或者觀察他們如何完成一個實際項目)肯定比在一個小時內觀察他們如何解決面試問題能更好地衡量他們的能力。然而，仍存在兩個問題使試用無法取代標準面試：

　　對公司來說采取試用的方法成本過高。沒有公司能夠為每個申請人都花費一整周的時間。為了決定讓誰來參加試用，公司必須先采取一些其他的面試方法。

　　候選人的試用(和大型的可帶回家完成的編程項目)對候選人來說代價同樣昂貴。即使公司會支付薪水，也不是所有的候選人都有足夠的時間。例如，已經擁有全職工作的工程師可能就沒辦法抽出時間。即使可以抽出時間，也還是有許多人不愿意這么做。如果工程師手上已經有了一些工作機會，那么他們就不太愿意承擔試用的不確定性。我們在 Triplebyte 的候選人身上清楚地看到了這一點。許多優(yōu)秀的候選人(手上已經有了其他工作機會)一般會直接拒絕大型項目或試用考察。

　　綜上所述，試用對于一些候選人來說確實是最佳選擇。我認為如果公司有足夠的能力可以支持多種面試方法，新增一個試用的方法不失為一個好主意。然而，完全取代面談是不可行的。

　　也有人提出跟候選人談論過去的經驗來取代技術面試。如果想知道候選人是否能在未來做好工作，就去看他們過去的工作完成情況，這個邏輯倒也說得通。我們也在 Triplebyte 對這一點進行了試驗，可惜并沒有得到很好的結果。溝通能力(展現(xiàn)自己的能力)最終會掩蓋技術能力?？诓藕玫娜藭浯笏麄兊慕巧?將整個團隊的工作視為自己的功勞)，而謙虛的人則會淡化他們所做的事情，這種情況非常常見。花更多的時間、提更多的問題，或許還是能夠挖掘出真實情況。但是，我們認為在通常面試的時限內，談論過去的經驗并不能取代技術面試。這是一種與候選人消除陌生感并了解他們的興趣的好方法(同時可以評估溝通能力或者文化適應度)，但是并不是一個可行的面試替代方案。

　　編程技術面試的好處!我想以更積極的方式結束這篇文章。對于面試中存在的所有問題，很多是確有其事。

　　面試是直接對技能進行評估。我有一個朋友是教師，他告訴我，教師面試基本上考察的是溝通能力(表現(xiàn)自己的能力)和證書資質。對很多專業(yè)來說似乎都是如此。硅谷還未能做到完全任人唯賢。但是至少我們嘗試直接評估重要技能，并且認為任何具備這些技能的人(無論背景如何)都可以成為優(yōu)秀的工程師。證書資質帶來的偏見往往阻礙了這一點。但是，在 Triplebyte 我們已經盡可能克服這個問題，并幫助很多背景并不優(yōu)秀的人獲得了很好的技術工作。當然，我認為 Triplebyte 在某些領域可能無法做到這一點，例如法律領域。因為這些領域對證書資質的要求太高了。

　　程序員也會選擇面試。雖然這是一個非常有爭議的話題(肯定有程序員不這么覺得)，我們進行了一項實驗，向候選人提出不同評估類型供他們選擇，發(fā)現(xiàn)大多數(shù)程序員仍然選擇了常規(guī)的面試。我們發(fā)現(xiàn)只有少數(shù)程序員對采取試用或可帶回家完成的項目的公司感興趣。無論未來會如何變化，目前技術面試仍是主流。其他類型的評估可以作為很好的補充，但似乎不太可能取代面談而成為評估工程師的主要方式。這里不恰當?shù)匾们鸺獱柕囊痪湓挘?ldquo;面試是對工程師進行評估的最差方法，除非你已經嘗試了無數(shù)次其他的方法。”

　　寫在最后

　　面試很難。人類簡直復雜到令人絕望。從某種程度來說，通過四個小時的面試判斷一個人的能力真是一件愚蠢的差事。我認為我們不得不對此保持謙虛的態(tài)度。任何面試都注定要失敗很多次，因為人實在太復雜了。

　　但這并不意味著要放棄。嘗試使面試過程變得更好總好過什么也不去嘗試。在 Triplebyte，面試就是我們的產品。我們集思廣益提出想法，測試這些想法，并隨著時間的推移不斷改進。我認為這才是改進雇用工程師的過程應該采取的方式。