如何在招募過程中客觀地評估資深工程師候選人在高層系統架構設計方面的能力

兩位候選人遇到相同的題目：設計一個允許用戶分享短視頻的服務。第一位候選人在十分鐘內畫出了清晰的流程圖，列出了所有常用組件，並且自信滿滿地進行講解。第二位候選人則起步較慢，詢問了用戶群體，指出了自己不確定的部分，並給出了不同的存儲方案，且理由充分。面試官A給第一位候選人的評價是「優秀」。旁聽了同一面試的面試官B也給第二位候選人的評價是「優秀」。兩人的評價幾乎沒有重疊之處。

這是一個範例場景，並非已記錄的招募案例。這種情況很常見，大多數工程團隊都會遇到。兩種設計方案都各有道理。差別在於兩位面試官的評分標準：流暢度、速度、對自身偏好架構的熟悉程度，或是推理的品質。本指南面向工程經理和工程賦能負責人，旨在為他們提供一套系統設計面試評分標準，以便兩位面試官能夠基於相同的證據對高級候選人進行評分，從而得出一致的結論。在實際招募決策中使用以下每項標準之前，都應由一位高級工程師進行驗證，並審查其公平性。

系統設計面試評分標準是什麼？

系統設計面試評分標準是一份評分指南，它列出了面試官需要考察的內容、每個分數對應的可觀察行為，以及哪些錯誤無法被其他方面的優勢所彌補。評分標準與面試問題並列，確保每位面試官都能根據相同的標準收集證據。谷歌的結構化面試指南將這些評分工具稱為“評分標準”，並指出研究人員稱之為“行為錨定評級量表”。指南指出，結構化面試具有更高的預測效度，且能縮小不同人群之間的差異，預先準備好的問題、指南和評分標準平均每次面試可節省 40 分鐘。您可以在Google re:Work：結構化面試指南中閱讀完整內容。

公開的例子很容易找到，而且大多數都是為候選人寫的。本指南是為參選者準備的。

要聞速覽

1. 明確你要評估的績效指標

先從工作內容入手，而不是主題。對於資深工程師來說，相關的任務通常是：面對一個模糊的問題，做出並捍衛架構決策，並說明哪些方案可以改變。用一句話概括，並明確指出該職位、等級以及工作環境。支付公司的高級後端工程師和媒體公司的高級平台工程師的要求就截然不同。

同時，也要寫明哪些內容不屬於評估範圍。打字速度、對特定雲端服務商的熟悉程度以及在共享白板上清晰繪圖的能力都是常見的意外考核標準。如果這些並非工作職責的一部分，就不應該影響最終得分。

2. 選擇一項具代表性的、不熟悉的任務

選擇一道能體現實際工作內容且應徵者無法死記硬背的題目。例如，一個廣為人知的題目（例如「設計一個URL縮短器」）鼓勵應徵者進行練習。或者，選擇一道來自你所在領域的題目，去除敏感細節，並請一位資深工程師獨立解答，以便了解合理的答案範圍。

要明白，一個45分鐘的問題只能反映高階工程師工作能力的一部分。它可以展現應徵者如何處理模糊不清的情況、限制條件和權衡取捨，但無法體現他們如何指導他人、如何運行長達數月的遷移專案或如何處理長期故障。在招聘文件中明確說明這一點，以免有人過度解讀分數。

3. 制定可觀察的標準和錨點

圍繞著可以寫下來的證據建構評判標準。以下是一套適用於高階系統設計面試的簡短有效的評判標準：

每個標準以 0 到 2 分評分：0 分錶示缺失或缺乏支持，1 分錶示部分缺失但相關內容已遺漏，2 分錶示完整且符合既定標準。評分標準比評分本身更重要。例如，對於權衡推理，0 分錶示“僅提及某項技術，未說明原因”，1 分錶示“給出了原因，但未說明替代方案的成本”，2 分錶示“在既定約束條件下比較各種方案，並說明每種方案需要放棄什麼”。

將關鍵錯誤單獨定義，例如忽略面試官提出​​的資料保護要求，或提出的設計方案無法滿足既定的硬性限制。平均分數絕不能掩蓋關鍵錯誤。避免以自信或速度來評分；一位思維縝密、不愛張揚的候選人不應因其表達方式而受到懲罰。我們的判斷力和問題解決能力評估指南涵蓋如何編寫推理任務的評分標準。

4. 校準評估人員並進行試點

如果兩個人對評分標準的理解不同，那麼它就不能稱之為評分標準。使用前請務必仔細閱讀以下內容：

1. 請舉個例子。 使用與招募流程無關的同事提供的書面設計，或在徵得對方同意後錄製的模擬面試影片。
2. 獨立評分。 每位評估員在看到其他人的分數之前，都會先寫出每個標準的證據。
3. 比較證據。 如果分數相差超過一分，請找出錨定標準是否含糊不清，或者評估者是否注意到了不同的內容。如有發現，請重新修改錨定標準。
4. 對第二個例子重複上述步驟。 當分歧在於判斷而非措辭時，就應該停止爭論。

谷歌的指南將面試官培訓與校準相結合，以確保面試官在評估中保持一致性和信心，這與我們的理念相同。您可以請一位專家，例如鄰近團隊的工程經理，來審核案例和參考標準，並請您的人力資源團隊審核招募流程，確保其公平性並符合您所在地區的法律法規要求。

5. 透過一個實際例子進行分析

僅供參考。高級工程師在使用前應驗證案例並回答相關標準。

案例：候選人需要為一款外送應用程式設計一個通知服務：當訂單狀態變更時，客戶會收到更新通知。規模僅被描述為「每天幾百萬個訂單，主要集中在用餐高峰時段」。

這是第一次嘗試。「我會在訂單服務和通知工作進程之間放置一個訊息佇列，將每個事件儲存在資料庫中，然後發送推播通知。」這個架構合理，但應徵者沒有問需要哪些管道，如果通知延遲或發送兩次會發生什麼，以及佇列在高峰負載下會受到什麼影響。

面試官回饋和重試。面試官會問：「延遲通知和重複通知，哪個更糟？」面試官應該針對每個標準制定一套標準的後續跟進流程，確保每位候選人都有平等的機會展示自己的技能。

更強有力的嘗試。「推播訊息重複更糟糕，因為用戶會因此不再信任應用，所以我建議使用順序鍵和狀態鍵來實現冪等發送。對於短信，我會接受偶爾的重複，因為成本更重要。用餐高峰時段的負載意味著隊列應該能夠應對突發情況，並且工作進程應該根據隊列深度進行擴展。我不確定交付時間承諾的嚴格程度，因此在選擇時間簡單的重試設定通道還是為時間緊迫的人

評分。根據評分標準，此答案在權衡推理（兩種選擇、成本、理由）方面得分2分，在問題框架構建（陳述假設、提出問題）方面得分2分，在處理變化方面得分1分（直到面試官添加限制條件）。請注意，面試官評分的是證據，而不是將候選人的設計與自己偏好的設計進行配對。

互動式教學有助於

您在此培養的技能是面試官的技能，互動練習非常適合。在即時校準環節中，展示範例設計，請每位評估者私下對每個標準進行評分，並在討論前公佈評分結果。人們會在聽到房間裡聲音最大的人之前就確定自己的分數，而分歧則能指出需要修改的關鍵點。同樣的範例和評分標準可以供之後加入的新面試官自主學習，並安排即時環節討論存在歧義的情況。 AhaSlides 支援互動學習，並可在即時學習和自主學習之間切換。它是一個演示和學習工具，而不是面試平台或應徵者追蹤系統，因此請將真實的候選人資料保留在您的招募工具中。請將您計劃使用的任何特定創作、回饋或報告功能與您自己的工作流程進行比對。有關如何選擇格式的協助，請參閱我們關於何時使用自適應、互動和即時學習的指南；有關回饋設計，請參閱關於如何設計具有實用回饋的互動練習。

衡量發生了哪些變化

事先確定哪些指標可以證明評分標準有效。以下兩項指標切實可行。首先是一致性：對於同一份錄音或書面設計，獨立面試官在校準後給予的評分是否比校準前更接近一致？明確校準物件、分母和時間節點。其次是相關性：幾個月後，評分是否與新進員工在設計評審的表現有關？如果新員工人數較少，這只能提供一個粗略的參考，因此應將其視為審查評分標準的提示，而非確鑿的證據。如果結果有所改善，在將功勞歸於評分標準之前，請檢查同期是否有其他變化，例如新的角色定義或不同的招募管道。

可能存在的限制

• 代表性。 一個問題代表了工作的一部分。將其與其他證據結合起來，例如工作樣本或關於過去決策的結構化對話。
• 公平。 評分標準可以減少差異，但本身並不能消除偏見。請檢視案例和基準，檢查其中關於背景的假設，並與你的團隊核實各組的結果。
• 面試時間。 校準需要幾個小時。沒有校準，評分標準就只是一份更長的表格而已。
• 角色明確。 如果團隊對「資深」的定義沒有共識，任何評判標準都無法解決這個問題。
• 法律背景。 不同地區的招募評估規定各不相同。在更改流程之前，請務必先查閱當地的具體要求。

常見問題

系統設計面試評分標準應該包含哪些內容？

3 到 5 項標準，例如問題框架、權衡推理、深度、應對變化和溝通，每項標準 0 到 2 分，並單獨列出關鍵錯誤。

如何阻止面試官依照面試官的自信程度來評分？

讓他們在給出分數之前，寫下每個標準的可觀察證據，並將每個分數與行為聯繫起來，例如「比較兩個選項並說明未選擇選項的成本」。

系統設計面試應該持續多久？

面試通常安排在一小時左右，但合適的時長應該讓候選人能夠充分展現你評分標準中的所有要求。可以先進行一次試點測試。

評分標準能否使招募更具客觀性？

這使得審核過程更加一致且易於操作，但判斷仍然至關重要。目標是讓面試官基於相同的理由達成一致，而不是將任何人排除在決策之外。

從哪兒開始

選擇一個空缺職位，並撰寫一句績效描述。擬定三項標準，並附上關鍵要素和簡短的重大錯誤列表，然後請一位資深工程師獨立完成此案例。與面試官進行校準會議，修改引起分歧的關鍵要素，並在少量實際面試中試用該評分標準，然後再廣泛使用。

若要了解如何使用自己的面試官進行即時校準會議，並在之後以自定進度重複使用，請探索 AhaSlides。