How to Interview for System Design

Source from 資深面試官眼中的系統設計: https://blog.acecodeinterview.com/intro/

其他資源

1. 為什麼要考系統設計面試?

實際意義大

跟算法面試類似的,面試官需要能從人群里分辨出誰更適合所招聘的職位。系統設計作為日常工作中會經常用到的能力,在考察中有很強的現實意義。可以想像,如果一個組裡需要找資深工程師來幫助升級服務的構架,系統設計能力會決定崗位的歸屬。

區分度高

系統設計面試可以看出受試人對問題多方面的理解,不同水平的受試人對於問題的廣度和深度會有很大差異,很大程度上幫助面試官了解受試人的能力以及確定未來職位的級別。

2. 系統設計考什麼?

  1. 交流溝通和理解能力- 跟面試官充分交流理解所設計系統的目標,方便做設計中的tradeoff,在廠里幹過的就知道日常工作中這個非常重要
  2. 設計和架構能力- 很多我見過的面試者都只注重在這塊而忽略了其他,很可惜
  3. 擴展性(Scalability),容錯性(fault tolerance),延遲要求(latency)- 跟Operation相關的要求,如今Dev和Ops不分家,希望面試者了解系統今後能如何擴展,易於maintain
  4. 資源需求- 對於我們所要求的QPS和latency,需要多少台機器,其中CPU, 內存,硬盤等資源都是如何配置 當然,以上四點,根據同學們的實際情況,並不用在每一點上都給出完整的回答,面試官會在面試過程中指出深挖的方向,有可能是根據同學的專業或者職業背景,有可能是根據所面試的崗位,有可能是根據面試中同學提到的他熟悉的技術。

3. 怎樣答好系統設計題?

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

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

講完了廢話,講一些可以操作性強的,我們結合考察內容,對優秀回答的特徵做進一步表述。

3.1 交流溝通和理解能力

  • 詢問系統的商業目的- 建這個系統是為了解決什麼問題。相關的問題比如這個服務的受眾有什麼特點,是商業用戶還是個人用戶。很多時候問不問這個問題就能看出Senior的程度。
  • 詢問功能性需求(functional requirement) - 包含哪些子功能。
  • 確定非功能性需求(non-functional requirement) - 我們要總結說我們在面試結束前我們的設計要達到什麼QPS,latency或者availability指標。寫下來並跟面試官確認。如果這裡牽涉到一些ballpark calculation,跟面試官確認是不是需要算。
  • 整場面試過程中跟著面試官的引導走- 有的同學看到準備過的題就很興奮,文思泉湧面試官都拉不住,會讓人覺得理解能力不足
ballpark calculation "Ballpark calculation" 是一個用於粗略估算或近似計算的術語。它指的是在缺乏詳細資訊或時間限制下,通過使用大致的數據和合理的推斷來獲得近似結果。 Ballpark calculation 的目的是為了快速獲得一個大概的數字,而不是進行精確計算。它常用於初步評估、快速比較和初步規劃等情境下。例如,在項目計劃初期,可以使用 ballpark calculation 來估算成本、時間或資源需求,以便做出初步的決策。 然而,ballpark calculation 的結果並不準確,因為它基於近似和簡化的假設。因此,在進行重要的決策或具有高度精確性要求的情況下,應該進行更詳細和精確的計算或分析。

3.2設計和架構能力

這是正常面試的核心部分,非常重要,是面試通過的基礎,其中deep dive非常考驗真實水平。討論過程中記住要保證設計的完整性,正確性以及取捨的充分溝通。 答題點主要分成以下五大塊。

  1. High-level diagram
  2. 數據結構與存儲
  3. 核心子服務設計
  4. 接口設計
  5. 專題deep dive

3.3 擴展性,容錯性,延遲要求

  1. 確認系統在以上三點Scalability, Fault Tolerance, Latency Requirement是否符合先前定下的需求。
  2. 根據需求進行改進(推薦在第一輪設計中先不考慮這裡的三點,先拿下設計和架構能力的分數,再做改進
  3. Log monitor and alert on key metric (系統投入使用前,把非功能性需求和它的leading indicator確定下來並且做好監控)
leading indicator Leading indicator(領先指標)是指在特定情境下,能夠提供關於未來發展、趨勢或變化的早期信號或指標。它可以作為預測未來的先行指標,幫助人們做出相應的決策和行動。 與之相對的是 Lagging indicator(落後指標),它是在特定事件或現象發生後才產生變化,用於反映已經發生的結果或趨勢。Lagging indicator 能夠提供過去發展的信息,但相對於 leading indicator,它的預測能力較弱。 Leading indicator 常用於各種情境,其中包括: 經濟預測:在經濟學中,leading indicators 可用於預測經濟增長、衰退或其他相關趨勢。例如,新訂單數量、工業生產指數、消費者支出等都可以作為 leading indicators,提供關於未來經濟發展的早期信號。 股市分析:投資者和分析師可能使用 leading indicators 來評估股市的走勢。例如,股市的交易量、特定股票的價格變動、市場情緒指標等都可以被視為 leading indicators,用於預測未來股市的發展。 項目管理:在項目管理中,leading indicators 可用於預測項目的進展、風險和成功。例如,關鍵里程碑的完成情況、資源使用率、風險評估等都可以作為 leading indicators,幫助項目團隊提前識別潛在問題並採取適當的措施。
lagging indicator Lagging indicator(落後指標)是指在特定情境下,用於反映已經發生的結果或趨勢的指標或數據。它通常基於過去的事件或行為,提供有關已經發生的情況的信息。 Lagging indicator 的特點是它的變化或結果發生在先行事件之後。它主要用於描述或分析過去的狀態、行動或結果,而不是提供關於未來的預測或早期信號。 Lagging indicator 在各種情境下都有應用,其中包括: 經濟分析:在經濟學中,lagging indicators 可用於描述過去的經濟狀態或趨勢。例如,失業率、通脹指數、國內生產總值(GDP)等都是 lagging indicators,它們反映了過去一段時間內經濟的變化和發展。 市場分析:在市場研究和分析中,lagging indicators 通常用於評估過去的市場表現。例如,公司的盈利報告、銷售數據、市場份額等都可以作為 lagging indicators,提供關於公司或產品在過去時期的表現情況。 行業指標:在特定行業中,lagging indicators 可用於衡量和評估過去的行業趨勢和表現。例如,工業生產指數、勞動生產率、庫存水平等都可以作為 lagging indicators,用於了解行業的變化和發展。 Lagging indicator 的主要用途是提供對過去事件或行動的回顧和分析。它可以用於評估過去的結果、趨勢和表現,並在決策和策略制定中提供歷史數據的參考。然而,由於它反映的是已經發生的情況,它在預測未來或早期警示方面的能力相對較弱。因此,在分析和評估中,通常需要結合使用 lagging indicators 和 leading indicators 來獲得更全面的信息。

4. 資源估算(optional)

估算非功能性需求,計算需要多少台機器,需要多少內存,硬盤,帶寬和CPU的能力,量級正確即可(back of envelope calculation)。

5. 答題流程 + 時間分配

面試中常見的錯誤是答題流程鬆散,在不必要的話題上浪費時間。我見過不計其數的受試者糾結於一個特定話題導致沒有時間完成面試的主體部分。我們來看看怎麼避免這類錯誤。

形成固定的答題流程的作用有二。

  1. 一是引導面試官進入你的答題框架
  2. 二是用固定的流程保證不漏過重要的得分點。

5.1 引導面試官

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

5.2 答題流程

40分鐘的面試時間來算(掐頭去尾除去自我介紹問問題),我面試的大概流程如下。

  1. 【3分鐘】理解需求(詢問系統的商業目的+ 詢問系統的功能和技術需求+ 定義成功)
  2. 【0-5分鐘】資源估算(optional)(計算需要多少台機器,需要多少內存硬盤和CPU的能力)
  3. 【5分鐘】High-level diagram
  4. 【10分鐘】核心子服務設計
  5. 【5分鐘】接口設計
  6. 【5分鐘】數據結構與存儲
  7. 【5分鐘】擴展性,容錯性,延遲要求
  8. 【2-7分鐘】專題deep dive

注意幾點,4,5,6順序沒太大關係。 8可以考慮成額外分數,答對大量加分,答錯少量減分,如果沒時間會跳過,也是少量減分。

看完這個流程是不是感覺分秒必爭,要踩的點很多,沒有時間浪費。 這時候如果面試官聽出來某一步驟有錯誤,就算是回頭改對了, 浪費的時間也會造成一些本能踩到的點因為時間不足踩不到, 所以大家還是好好準備,刷算法題之餘也把系統設計重視起來。

© Kimi Tsai all right reserved.            Updated : 2023-07-12 09:04:53

results matching ""

    No results matching ""

    results matching ""

      No results matching ""