相信很多人聽到系統設計就一個頭兩個大，但在系統設計 (System Design) 這一關的對答中，公司不僅可以摸清面試者的底細，去看對方是否「真金不怕火煉」，面試者也可以趁機整理自己對於系統設計的想法，展現自己的深厚底子。
但若是沒有真本事的人，可能就會遇到這種情況…
面試官：請你設計一個UberEat的外送進度追蹤系統，你會怎麼做？
求職者：從追蹤每個外送員的手機訊號開始，就好就像電影那樣在追蹤犯人，我們可能要跟CIA申請API權限。
面試官：(…這小子電影看太多了嗎？)
如何避免這種尷尬的情況，請繼續看下去！
為何要有這關？
系統本身就含有上萬行的程式碼，同時也蘊含了許多部署、維護、監控的需求，這些都是工程師必需要瞭解的。因此除了coding interview以外，公司也會希望求職者對於商業世界所運行的production等級的產品有基本的認識。
從流量角度來看，業界中在市面上運作的產品其背後的系統流量之大，遠高出個體戶自製的side project或是學校的專案，因此有許多的現象會是在大規模流量時候才能觀察得到。另外，為了確保能持續提供使用者良好的使用體驗，生產環境中的系統也會設計成高可用性(High Availability)、 Fault Tolerance等機制，即使有問題發生也不至於影響終端用戶的使用體驗。
系統設計除了需要花時間積累之外，更考驗求職者對於運維、監控、災難恢復的基本認識。也因此大部分公司扮演極為重要的關卡，會決定你的level及影響paycheck.
常見敗陣原因
首先，面試官不會期待求職者在60分鐘內完整設計出別家公司花費數年的系統，不僅不切實際且面試官可能也沒這個能耐。除此之外，同樣的一套題目也會因為不同求職者而設計出完全不一樣的系統，因此是沒有標準答案的面試關卡。有了上述前提假設後，以下是常見三種失敗的原因。
1. 不溝通想法與目前思考過程：
有許多求職者這一關卡拿到題目後就一股腦開始做系統設計，除了沒有跟面試官確認要側重的方向之外，也沒有嘗試去掌握題目以外的商業訊息。面試官剛開始通常會暗示性的詢問打算怎麼做，企圖讓求職者分享更多目前的想法。若求職者還是很被動並無法保持想法上的透明與持續，面試官會在溝通能力上的評分打一個大X。
2. 鑽入太多技術細節而失去全局觀：
除非面試官有要求要更深談某些環節的技術細節，不然一股腦的突然專注在技術細節的設計會吃掉過多面試時間，導致面試官沒辦法去評估求職者其他面向的能力。例如：求職者在選擇要設計成asynchronous的架構時，也會考量到是否要用Queue去設計成fan-out架構。若在此環節上刻意糾結實作的細節，會讓整個系統設計關卡逐步變成程式碼撰寫關卡，導致無法衡量求職者在高可用性、監控指標的選擇或擴展性的涉略，最後就是無法評估變成0分。
3. 不夠瞭解技術選擇上的取捨：
每個系統設計一剛開始都會假設有無限資源(ex: 預算、時間、沒有技術債)，讓求職者能按照裡向的狀態下設計出第一版。隨著引入更多現實世界的需求和限制條件，面試官會詢問系統設計中某些元件的替代方案，例如：公司不希望使用太多EC2 Auto Scaling Group以達到高擴展性，你認為Lambda會不會比較適合？以及EC2和Lambda個自在什麼情況下使用會是最適合？求職者有的時候也會丟出市場上流行的技術(ex: Kubernetes)作為任何情況下的萬靈丹，但經過面試官追問後卻很難明確比較其好處與壞處，導致最後評語會落入：He/She only knows how to use it isntead why to use it.
破解方式
既然系統設計並沒有標準答案且是透過人來衡量，自然不能忽略軟實力的重要性。
1. 反覆跟面試官溝通想法與確認需求：
由於每位求職者的背景都會有所不同，因此同樣的一套題目面試官也能夠針對求職者較為擅長的面向去側重，畢竟沒有經驗的部分也很難瞬間速成，不如深挖求職者更有經驗的那塊才更合理。
系統設計剛開始在理解完題意之後，可以順勢跟面試官做確認(俗稱acknowlegement)相關訊息或詢問更多訊息，接著求職者可以先概述自己的做法，並詢問面試官有無其他特殊需求要著重。透過這樣一來一往能讓面試官清楚知道自己的想法和要執行的步驟。
若突然遇到卡住不會的，也可以藉由溝通將自己卡住的點表達出來，並與面試官一起協力跨越困難。這樣的方式不但能保持溝通，還可以讓對方知道至少你有足夠聆聽的能力
2. 先從初步設計著手掌握基本架構再逐步優化：
確認理解題意之後可以著手進行初步的架構設計，以網站應用為例，可先使用傳統三層式架構將前端、後端及資料庫畫出，並針對每一層向面試官稍微解釋想用什麼技術實現。走過一輪後，可以向面試官詢問要特別著重在哪個面向並繼續深入設計。透過這樣不斷與面試官溝通、確認的循環，將求職者與面試官在想法上保持同步。既使求職者一開始知道題目的最佳實踐方式，也會建議從較陽春的設計開始，才能夠將陽春版演化至最佳實踐版的過程一併展現給面試官知道。
3. 知道要採用的技術與對等的技術之間差異：
通常新的技術的出現除了解決了原有技術上的瓶頸外，也會有其他的先天假設需要滿足。以AWS運算服務來看，EC2、Fargate、Lambda都可運行程式碼完成任務，但會因應用的場景不同而有不一樣的效能與成本產生。今天如果要客戶在乎no business impact但又要能即使擴展，全面採用Lambda也許可以滿足自動擴展的能力，但是其單位成本非常高。因此，選擇技術的同時也要詢問為何要使用，才能從How to use it進化到Why to use it.
結論
系統設計是蠻吃經驗的面試關卡，不僅不好速成之外，每個人針對同一個題目的設計風格也會完全不同。面試官也知道不可能要求求職者在60分鐘內完成其他公司花費數年的心血，因此要求更多在求職者是否有各種面向的sense，而非要求職者給出標準答案。由於系統設計會極度仰賴當下的客戶需求(e.g: 預算、流量、用戶的區域分布…)而給出完全不同的設計，因此沒有絕對答案的同時，更考驗求職者能否針對系統可能會遇見的問題先做出設計上的修正。也因此這個面試官卡在許多科技公司中決定了求職者的 level和salary paycheck，透過Github上許多系統設計的經典提和Youtube上的相關資源打底，既使沒有大量的業界經驗也能夠快速掌握一個概況，並能愈來愈從容應對各種不同的考題。