工程師面試技巧

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

　　技術面試現狀

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

　　①申請人篩選

　　②面對面最終面試

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

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

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

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

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

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

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

　　15% 不喜歡過於學術的計算機軟體技能***並認為談論學術能力暗示候選人缺乏創造性***

　　80% 允許候選人在面試中使用任何程式語言***其餘 20% 要求使用特定程式語言***

　　5% 在面試中會明確評估程式設計程式碼的細節

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

　　漏判和誤判

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

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

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

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

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

　　1. 明確你要尋找的技能

　　世界上並不存在一套唯一的可以定義一個好程式設計師的技能。反之，存在著大量各不相同的技能集。沒有工程師可以精通所有技能。事實上，我們在 Triplebyte 經常看到很多優秀且成功的軟體工程師具備完全不同的技能。那麼，進行一次成功的面試的第一步就是決定對於面試的職位來說什麼技能是重要的。我建議你問自己以下問題***這些是我們在 Triplebyte 開始為新合作的公司招募人才時會提出的問題***。

　　你需要的是能快速進行開發和迭代的程式設計師，還是小心仔細、思維嚴謹的程式設計師?

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

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

　　學術方面的計算機軟體、數學、演算法能力是重要還是無關緊要?

　　理解併發、C 記憶體模型、HTTP 重要嗎?

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

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

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

　　要達到這個目標需要使面試問題儘可能地貼近你想要候選人完成的工作***或你打算評估的技能***。例如，如果你關心的是後端程式設計，要求候選人開發一個簡單的 API 端點然後新增功能會是一個更好的問題，而不應該要求他們解決 BFS 詞鏈問題。如果你關心的是演算法能力，要求候選人應用演算法來解決問題***比如開發一個簡單的搜尋索引，可以基於二叉搜尋樹和雜湊表，以提高刪除效能***會是一個更好的問題，而不應該要求他們判斷一個點是否包含在一個凹多邊形中。讓候選人在真實程式碼庫中編碼並除錯通常都優於讓候選人在白板上解決一個小問題。

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

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

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

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

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

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

　　4. 避擴音太難的問題

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

　　這種影響由於面試候選人時存在的兩個訊號來源而被放大：即他們是否給出了一個問題的“正確”答案、他們得到答案的過程或容易程度。我們在 Triplebyte 已經收集了很多相關資料***根據候選人是否得到正確答案以及他們花費了多少努力對問題進行評分，然後衡量哪些評分能預測他們在公司中的表現***。我們發現這裡有一個權衡問題。對於更難的問題，候選人的答案是否正確攜帶了大部分訊號。相比之下，對於更容易的問題，更多訊號來源於候選人解決問題的過程以及他們的努力程度。考慮到訊號的兩個來源，顯然選擇比較容易的問題更好。

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

　　需要宣告的是，我並不認為為了提高通過率要降低門檻。我想說的是要提出簡單的問題，然後在評估結果中包含候選人回答問題的過程。我認為提出的問題應該簡單，但評判時需要相當嚴苛。這就是我們發現的可以優化訊號的方法。它的另一個的好處就是對大部分候選人來說壓力比較小。

　　舉個例子，要求候選人開發一個簡單的命令列介面，其命令用於儲存和檢索鍵值對***如果他們完成得很好，還可以新增更多功能***可能比要求候選人實現算術表示式的解析器更好。而一個涉及最常見的資料結構***列表、雜湊或者樹***的問題可能比涉及跳躍表、樹堆或其他晦澀的資料結構的問題更好。

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

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

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

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

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

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

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

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

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

　　這就是噪音，面試時應儘量避免。最簡單的方法就是將學校和公司的名稱從簡歷中刪除，再交給面試官。部分候選人可能會在面試中提到他們的學校或公司，但是當我們在不瞭解候選人背景的情況下進行所有面試，候選人在技術評估過程中提到學校或公司的情況實際上非常罕見。

　　8. 避免讓面試陷入陰霾

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

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

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

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

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

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

　　我認為最好的解決方案是公司專注於最強技能，並且對於在面試某些部分表現不太好的人也可以適當地提出錄用要約。即尋找強有力的理由說同意，而不過多擔心候選人偏弱的技術領域。我不想說得過於絕對。總有一些技術領域對於公司而言是至關重要的。決定你想要的公司文化，使團隊中的每個人都在某一技術領域具備一定水平也是有道理的。但更多地關注最強技能可以降低面試的噪音。

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

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

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

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

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

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

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

　　程式設計師也會選擇面試。雖然這是一個非常有爭議的話題***肯定有程式設計師不這麼覺得***，我們進行了一項實驗，向候選人提出不同評估型別供他們選擇，發現大多數程式設計師仍然選擇了常規的面試。我們發現只有少數程式設計師對採取試用或可帶回家完成的專案的公司感興趣。無論未來會如何變化，目前技術面試仍是主流。其他型別的評估可以作為很好的補充，但似乎不太可能取代面談而成為評估工程師的主要方式。這裡不恰當地引用丘吉爾的一句話：“面試是對工程師進行評估的最差方法，除非你已經嘗試了無數次其他的方法。”