資深面試官眼裡的系統設計面試

對於剛畢業初入職場的同學甚至是有一些工作年限的老司機來說，系統設計都是老大難的問題。一方面是系統設計題總數雖然不多，但同一題都能從不同角度考出花來，沒有標準答案。另一方面是系統設計結構性不強，面試官講一下設計個什麼就等著同學解題，同學們不知道怎麼一步步下手破題。

我在業界摸爬滾打近十年，曾在一線大廠做過近百場面試，其中一大部分都是系統面試，希望能夠分享一些自己的乾貨，解答大家一些困惑，也希望拋磚引玉，大家一起討論，不對的地方歡迎大家批評指正。

今天這篇文章會針對Software Engineer System Design Interview，從面試官的角度解構系統設計面試。這篇文章不會給具體的題做過多的分析，也不對網上有很多資料的問題做贅述，而是給系統設計的考察目標，優秀答案的特徵和破題的步驟三個角度給大家分析，作為別的資料的補充。

面試官的考察目標

跟演算法面試類似的，面試官需要能從人群裡分辨出誰強誰弱。演算法面試因為大家都刷Leetcode，如今已經很難分辨誰是當場想出來的，誰是刷過題記住的答案。系統設計面試因為覆蓋面廣，而網上資料又不能面面俱到，對於面試者的區分會更容易一些，這也是為什麼系統設計越來越流行的，越來越年輕化的原因。

由於系統設計對面試官的知識和設計能力要求更高，通常系統設計的面試官更為資深，在debrief中話語權也更大（尤其是在定級別的時候），大家千萬要重視起來，不要因此拿不到想要的offer和級別。

拆開來說，面試官會從以下四個角度去考察：

交流溝通和理解能力 – 跟面試官充分交流理解所設計系統的目標，方便做設計中的tradeoff，在廠裡幹過的就知道日常工作中這個非常重要
設計和架構能力 – 很多我見過的面試者都只注重在這塊而忽略了其他，很可惜
擴充套件性，容錯性，延遲要求 – 跟Opeartion相關的要求，如今Dev和Ops不分家，希望面試者瞭解系統今後能如何擴充套件，易於maintain。
資源需求 – 對於我們所要求的QPS和latency，需要多少臺機器，其中CPU, 記憶體，硬碟等資源都是如何配置

大家看到這裡可能要說，我要是有這個本事把這些都做的面面俱到，我就是頂尖的構架師了，自己做startup也不在話下。不得不說，要求確實很高，但不要忘記面試官除了決定給不給offer，還要決定給幾級的offer, 面試官就是考你怎麼造火箭，然後好給你定級別說去擰幾級的螺絲釘。

當然，以上四點，根據同學們的實際情況，並不用在每一點上都給出完整的回答，面試官會在面試過程中指出深挖的方向，有可能是根據同學的專業或者職業背景，有可能是根據所面試的崗位，有可能是根據面試中同學提到的他熟悉的技術。

優秀答案的特徵

在面試生涯中，我見過的最優秀的面試者比我的級別要高，讓我印象非常深刻，四個字，深不見底。

面試的前半段，面試官會先從廣度下手，要求受試者對題目的大框架給出一個完整的正確的解法。如果受試者給出了足夠好的解法，那麼面試官會從受試者的提過的某一個細部進行深挖，可能是深挖scalability，可能是改變一個需求要求重新做tradeoff，可能是某一個service的細節設計。因為其中的細節足夠多，受試者一般很難準備得面面俱到，面試官可以比較清楚的畫出受試者的能力邊界。前面提到的這個受試者之所以讓我感到深不見底，是因為我才疏學淺，畫不出他的能力邊界，不得不讚嘆大神，在debrief中好好膜拜了一番。

說了這麼多，還是想說平時的積累很重要，面試速成能夠讓你在廣度上做的很好，深度方面還是要多花時間學習。

講完了廢話，講一些可以操作性強的，我們來把前面說的考察目標和優秀回答的特徵做進一步表述。

交流溝通和理解能力

詢問系統的商業目的，建這個系統是為了解決什麼問題（相關的問題比如這個服務的受眾有什麼特點，是商業使用者還是個人使用者。很多時候問不問這個問題就能看出Senior的程度）
詢問系統的功能和技術需求（比如DAU, QPS, Latency，包含哪些子功能。這部分網上內容很多，不贅述了)
定義成功（前面問了那麼多，我們要總結說我們在面試結束前我們的設計要實現什麼功能，達到什麼QPS，latency或者availability指標。寫下來並跟面試官確認。如果這裡牽涉到一些ballpark calculation，跟面試官確認是不是需要算。）
整場面試過程中跟著面試官的引導走（有的同學看到準備過的題就很興奮，文思泉湧面試官都拉不住，會讓人覺得理解能力不足）

設計和架構能力

這是正常面試的核心部分，因為資料比較多，我簡單列個提綱。非常重要，是面試透過的基礎，其中deep dive非常考驗真實水平。

話題
High-level diagram
資料結構與儲存
核心子服務設計
介面設計
專題 deep dive
要點
完整性
正確性
充分討論tradeoff

擴充套件性，容錯性，延遲要求

確認系統在以上三點 Scalability, Fault Tolerance, Latency Requirement是否符合先前定下的需求
根據需求進行改進（推薦在第一輪設計中先不考慮這裡的三點，先拿下設計和架構能力的分數，再做改進）
Log，monitor and alert on key metric (系統投入使用前，把系統關鍵指標 – 之前定義的成功和它的leading indicator，確定下來並且做好監控。）

資源需求（optional）

根據之前定義的成功要求，計算需要多少臺機器，需要多少記憶體硬碟和CPU的能力，量級正確即可（back of envelope calculation)。

破題的步驟

瞭解完了考察目標和優秀答案的特點，最後一個角度就是用什麼樣的順序去答題，以及時間上的分配。

系統設計面試因為流程不明確，有時候先講點什麼再講點什麼沒那麼重要，但是為什麼我們這裡還是要提一個步驟給大家參考呢？答案是為了引導面試官。

雖然面試官在系統設計面試中有比演算法面試更強的引導的責任，但是引導的行為只有在需要的時候才會發生。如果一場面試中，總是受試者提問，面試官回答，受試者滔滔不絕地講，面試官連連點頭，畫面是不是很美？雖說前面的情景很理想化，但是如果我們能很好地把面試官想踩到的點按一個大概的順序去踩到，不僅面試官會更少地打斷受試者的思維，而且面試官也會在面試中很省力給你個好印象。當然，如果引導發生了，那麼一定要根據引導來思維。

廢話說完，以40分鐘的面試時間來算（掐頭去尾除去自我介紹問問題），我面試的大概流程如下。