#就地避難在家鍛鍊寫作能力

軟體工程師系統設計面試準備指南

當你有了幾年的工作經驗以後，在找工作時一定會遇到系統設計的面試，有鑒於大部分的面試心得都是針對演算法以及資料結構的程式面試 (包括我之前寫的美國軟體工程師求職心得)，對於系統設計的準備資源還真的不多，本篇要來剖析系統設計面試，介紹面試的流程、正確的心態以及準備的方向，讓大家再也不怕系統設計面試！

Medium 好讀版：https://medium.com/jktech/%E8%BB%9F%E9%AB%94%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E6%BA%96%E5%82%99%E6%8C%87%E5%8D%97-acf6ab1f502f?source=friends_link&sk=ca40acf60b749cb1b32c17a868b0c1a3

#為什麼系統設計很重要？

在程式面試表現優異，可以讓你順利拿到 Offer；但是系統設計會決定你加入公司的職等！這也就是為什麼有些人有十年經驗只能拿到 Mid-Level (L4) 的 Offer，而有些人只有五年經驗卻可以拿到資深工程師以上 (L5+) 的 Offer。

另外，如果你是面試 Staff 或是 Principal 級別以上的話，除了系統設計以外，有些公司還會有 Technical Leadership 的面試，來判斷你是否有能力可以跟不同的部門合作、解決問題的不確定性、帶領資淺的人然後推動並且完成一個跨部門的大型技術專案。

簡單來說，系統設計用來判斷你是 L4 或是 L5+，Technical Leadership 面試用來判斷是 L5 或是 L6+。

#為什麼系統設計很難準備？

大多數應徵者在準備的時候會過度偏重於程式面試，原因也不難理解，程式問題的定義很清楚，有給定的輸入以及預期的輸出，就算你真的想不出來，LeetCode 上的討論區也有參考答案；這種有考古題可以參考的面試，對於台灣教育出來的人來說相對好準備，隨著你解的問題多了，你也會更有信心，不知不覺甚至還會刷上癮了呢！但系統設計卻非如此。

系統設計面試的問題描述通常很模糊 (這是刻意的)，沒有給定的輸入與輸出，比較沒有既定規則可以遵循，然後也沒有一個標準答案，針對不同系統你需要提出不同的解法然後分析優缺點，一樣的問題，面試官也會針對你過去經驗往不同的方向問，有些問題你工作上沒有碰過還真的回答不出來，這也就是為什麼很多人看到系統面試就怕了。

#到底要怎麼準備？

首先我們要先建立一個觀念：沒有任何一個人可以知道所有的技術細節

不管你的面試官有多少年經驗，不管他們再怎麼資深，在變化快速的軟體產業，沒有人可以知道所有事情，一定有你知道而他們沒聽過的事情！

請把系統設計當成分享你過去所學的面試，這個面試的目的在於展示你對於軟體架構能力的廣度跟深度，你必須可以給出大方向的架構，知道有哪些元件 (廣度)，同時針對你熟悉的領域深入探討更多細節 (深度)，並且提出幾個解決方案，分析優缺點，並且針對系統需求選擇合適的解法。

大方承認自己對某些領域的細節不熟，也是完全沒問題的，只要讓面試官了解你知道這個東西，如果要深入了解的話你知道有哪些方向要努力，這樣就夠了，因為在大型的軟體專案裡，一定是高度分工的，不會有人同時精通手機端、前端、後端、Infra 以及嵌入式或是硬體的。

講到這裡，相信你也知道如果真的要準備是準備不完的，這些知識是透過平常工作以及閱讀技術文章長期累積的成果，比較沒辦法臨時抱佛腳。

#具體來說會問什麼問題

舉例來說，一個系統設計的問題會像是這樣：如何設計 Facebook?

這類問題的描述通常會很大而且模糊，面試官不預期而且你也不可能在 45 分鐘內就設計出這些公司花了好幾年這麼多人力設計出來的產品，所以第一步要做的事情是確認需求：是要設計動態牆、Messenger、廣告系統還是推薦系統？流量跟資料量為多少？需要支援全球的使用者嗎？

確認完需求以後，會針對最重要的幾個使用場景設計你的 Data model 以及 API，接著畫出大的系統架構圖，大致上會包含客戶端 (手機版/桌面版)、Load Balancer (Reverse Proxy)、App Servers 以及資料庫，接著可以針對細節下去討論，這邊開始就很自由了。

如果你是專精在資料庫，可以討論要用什麼資料庫以及資料要怎麼存可以讓特定使用場景的讀取以及寫入效能比較好，要怎麼做資料庫的 Replication 跟 Sharding 來服務更多的使用者？

如果講到快取，哪些地方可以加快取呢 (瀏覽器前端, CDN, App Server, 資料庫)？具體來說寫入快取有哪些方式以及優缺點 (write-through, write-around, write-back)？什麼時候要失效？要讓哪些資料失效？

如果聊到微服務器架構跟 Service Mesh，不同的服務怎麼跟其他的服務溝通? control plane 要怎麼更新 data plane 的設定？如果 control plane 掛了怎麼辦？要怎麼做 service discovery? 哪一種 Load Balancing 策略比較好 (round robin, random, least connection, ring hash, or maglev)？有些服務掛了影響到整個系統怎麼辦？什麼時候需要 circuit breaker ？

如果你是手機開發者，怎麼實現離線瀏覽？手機要有資料庫嗎？要怎麼以及多常跟伺服器同步？API 要怎麼設計？如何實現 Infinite Loading？剛 Po 文以後要怎麼樣在自己手機上馬上看到？

這些問題真的列舉不完，總之看到這裡你會了解為什麼我說這個面試是沒有範圍而且也準備不完的，重點應該放在跟面試官的討論，展現你在技術方面的廣度跟深度，讓面試結束的時候能夠有一個你們兩個人都同意的設計！

#準備材料

系統設計的資源比較分散，以下是我篩選過後覺得有用的資料，按照素材的類型作分類，也歡迎大家留言補充！

#入門影片

針對完全沒有概念的新手，我建議可以先從哈佛的 CS75 Lecture 9 Scalability 開始，裡面講到的很多基礎觀念都相當重要，值得一再複習，這些概念先有了以後再閱讀其他的材料會比較有感覺：

如果你看完這篇文章後還想再多了解系統面試的形式，也可以看一個前 Facebook 工程師分享的影片：

Distributed Systems in One Lesson 也很推，裡面提到不少業界在使用的設計模式：

有一個需要付費的資源是 SystemsExpert，每個影片會講解一個系統設計重要的概念，我個人覺得內容有點淺所以沒有買，但是整理地還算不錯，如果你看完他們免費的影片有興趣還是可以參考一下。

#閱讀文章

影片是一個讓你很好理解大方向概念的方式，但是如果你要深入理解背後的原理還有怎麼運作的細節，還是得透過大量以及深度的閱讀來吸收呀！

system design primer 整理了很多系統設計的資源，資料量很夠， 個人的建議是先快速過一遍，不要細讀，先知道總共有哪些元件，大概是做什麼用的就好，接著針對有興趣的部分在深入研究，建立自己的知識庫。

Grokking the System Design Interview 也是很多人推薦的材料，主要是針對系統設計的問題提供範例解答，他們的答案可以當作一個參考，但面試的時候不要完全照著回答，還是得看跟面試官討論的結果來進行，但這個是需要付費的，有興趣可以用我的推薦碼註冊購買。

如果你不想花錢或是不確定 Grokking 的文章你喜不喜歡，有一個類似的網站 Crack the System Design Interview 整理得也還不錯。

#書籍

唸書是一個有系統性學習的方法，如果你只想選一本書來看，就選這本大家都推的系統設計聖經 — Designing Data-Intensive Applications，簡稱 DDIA，這本書適合的對象是想要長期準備系統設計或是分散式系統的人，裡面舉的例子都是實際上業界遇到的問題，不會有以前讀教科書那種工作又用不到的感覺；但也因為是書，花了一些篇幅在講解背景知識，包含以前的系統是怎麼設計的以及如何演進到現在，對短期要準備面試的人效率會有點低，所以不適合有時間壓力的人。

這本書我目前讀了一半，最大的收獲是它解釋了很多為什麼現代的系統要做這樣的設計，我們針對不同的系統要求可以有哪些解法，這些解法各有什麼優缺點，總之分散式系統就是我們解決了一個問題，但又會產生更多要考量的點，一切都是 trade-off。

但這本書也不是沒有缺點的，首先我覺得是本書的英文沒有很好讀，我常常一段看了好幾遍才知道他想表達的重點是什麼，而且，有些很重要的觀念常常藏在一段文字裡用一句話帶過，但是不太重要的觀念卻使用 Bullet Point 表達；另外這本書話常常講一半，一些觀念提到了一點卻說我們後面再聊，也因為這樣，我在考慮要不要幫大家整理每一個章節的重點，翻成中文分享給大家，有興趣的朋友麻煩拍手留言告訴我！

除此之外，Google 的 SRE Books 內容也很實在，但是每一個章節的內容是獨立的，建議大家選擇想研究的章節跳著看就好。

最後，Distributed systems for fun and profit 的內容也很好，以分散式系統的理論為主，比較沒那麼針對系統設計面試。

#還想閱讀更多嗎？

我知道光是上面的資源就已經讀不完了，但是行有餘力的話，平時也可以多看看各大公司的技術部落格或是訂閱技術週刊如 TechBridge (台灣) 、HackerNews 以及 InfoQ 等等。

此外，參考別人的經驗也是很好的方式，最近剛好幾個朋友剛找完工作，他們分享的矽谷找資深工程師工作心得分享以及2020 上半年軟工找工經驗分享也都很值得看！

最後，在工作上使用到的技術，除了會用以外，最好也要花時間去研讀技術文件，了解他們設計的考量以及支援的場景，大部分這類型針對開發者的文件寫得會比較深入，所以也是相當好的學習素材；我自己過去一年因為工作上需要整合 Envoy 到我們公司的 Traffic Infrastructure，從他們的文件中學到很多 Service Mesh 跟微服務器的重要概念，學習的深度都是其他資源無法提供的。

#總結

這篇文章我們整理了很豐富的系統設計資源，希望大家不要被這滿滿的資訊量嚇跑。

請記得，我們永遠有各種方法在短期內針對面試做準備，提升面試的表現，但這都只是一時的，沒辦法讓你一夕之間就成為專家；如果想要追求長期的持續成長，那麼沒有捷徑 — 就是養成每天學習以及閱讀的習慣，一開始真的很難看到效果，但是當你持續一週、一個月甚至是一年以後，你會明顯感受到自己的成長，這些投入的時間都是騙不了人的。

如果這篇文章對你有幫助，請拍手留言加訂閱，並且分享給更多有需要的人知道！

很多朋友問我：「怎麼樣才能像你一樣寫一本書出來？」我沒有正確或是最好的答案，不過或許能分享一些怎麼走到今天的經驗談。

學生時代，我很不愛做筆記，或許是因為記憶力很好，課堂中老師講過的東西，沒有特別去聽還會記得住，因此對於不做筆記這件事情，還能夠在腦海裡留下清晰的圖像與文字，早就習以為常。不過，踏入社會之後，不做筆記的菜鳥，會被主管或老闆貼上「不夠認真、不夠用心、不夠投入」的標籤。再者，開會時很多同事喜歡用專業名詞、縮寫、中英混雜的內容，不真的寫下來、記下來，還真沒辦法。

另外，有件事情還是得老調重彈。2000年初進入職場之後的第二份工作，嚴格來講算是真正的第一份，從事網頁設計師一職。誰能想像做個網站，不只是要負責視覺，還得撰寫公司網站的關於我們、產品說明、服務介紹、服務項目、聯絡我們等單元內容。一開始要寫這類文案，可真是折騰到不行，即使我已經在公司一週了，依然不是太清楚整體面貌，該怎麼下筆，沒個方向。

白天從事網頁設計的職務，晚上回了家，又變成網頁設計創作者。藉由網頁設計的主題、風格與版型，每週進行一到兩次的設計變更，做好玩也做興趣，順便用個人網站交朋友。自發性的做網站是從1997年開始，每天下個之後，打開電腦磨練做設計的觀念，打磨自己的設計質感，從特效、用色、排版、繪圖下手，再加上當時很流行安裝留言板、聊天室、計數器，所以順著嘗試寫點程式，找主機去設定安裝屬於自我風格的網路應用服務。

於是，做網站成了興趣，也有點像是軍備競賽。常常會跟網路上的設計大師們過招，看著別人設計出來的作品，也想做出超越對方創意的網站。不過，做網站時也發現自己沒有內容，網站缺少內涵，只有一版又一版的改版設計作品，還有一些影像後製、圖片繪畫的內容，欠缺更多的文字說明，包含了我的想法與理念等等。因此，網站上慢慢多出了最新消息、關於我、作品介紹、業界資訊內容，將原本只是圖像化呈現的網站，增添文字內容元素，提高可讀性。

因應工作沒人能夠寫公司相關文案，再加上自己經營網站需要撰寫內容，兩方都有必然需求之下，從原本只是看科技、資訊、網路、設計、電子產業界的最新消息，變成每天強迫自己寫一篇文，要求自己不論好或不好，拼命的寫，管他有多累或是有多煩，強烈要求自己說到要做到，文章也真的一篇又一篇擠了出來。當時，能支持著我寫作動力的，還有一位很重要的人，他是知名漫畫家《木城幸人》，而他最知名的作品不外乎則是前陣子上映的電影《戰鬥天使：艾莉塔》，漫畫又名《銃夢》。

他的畫風跟考究科技、科幻的細節，令我看了極為嚮往，直呼不可思議。即使到了現在2019年再看，絲毫不減該作品在科幻領域所帶出的先進思維，更不用說那些細膩又寫實的畫風，令我沈浸在那世界之中好長一段時間。這麼厲害又讓我佩服的作者，在其中一集的附錄裡提到他家人、朋友、同學都說走上漫畫這條路並不容易，賺不到錢，還有他那純粹插畫風格很難上得了檯面，要他儘早放棄這個念頭。可是作者沒有放棄，自從那天之後他強迫自己每天動手繪畫，持之以恆不中斷，也是他堅持走下去，才有《銃夢》這部鉅作誕生。

為了要寫好公司相關內容、為了要增加個人網站內容、為了要向《木城》效法，於是我開啟部落格，展開長達十多年每日寫沒有停筆的生活。十年間，每天寫一篇文章，從各式各樣不同類型的內容下手，不管有沒有人看，反正有靈感就寫。再加上公司要求我做好筆記，索性的將會議記錄變成自我練習的機會，每日會議都強制自己寫會議記錄，從一開始要兩三個小時之後才能交出會議記錄，到後來經過大量練習，開會時就先組織好所有的內容，邊寫邊歸類、歸納會議內容，將原本是你一言我一語的會議討論，變成有組織調理及結構化的書面紀錄。

每天強迫自己與文字相處，並彙整腦海中的資訊，將其輸出成為文字的習慣，整整做了十五年以上。並應用在製作簡報、講義、論文、書籍之中，間接培養出將文字圖像化，再將圖像結構化的本領，並且將原本篇幅說明式的文字，繪製成為架構圖、關係圖、魚骨圖、矩陣圖等，進而讓原本的文字可以用更為精簡、容易理解的方式來呈現與說明，將文字想要傳達的精神、核心，變得可以更為貼近在看的人。

要怎麼寫出一本書？怎麼辦到？

天天寫作，持續創作，持之以恆，並且經歷過超乎想像的「練習」，這練習可不是只有寫作而已，而是「即使在不舒服、不高興、不順遂的狀況下，沒有理由繼續寫下去，遇到再多的阻礙、障礙都不要給自己藉口，更不要用疲勞、疲累來告訴自己今天算了，而是每天給自己一個簡單的目標，而這簡單目標要能持續十年以上」才能免強稱作「稍微認真的練習過後」，也許書就這麼一本又一本寫出來，你原本以為的不可能，逐漸變為可能，成為真正可行又具有價值的內涵。

「天下無難事，只怕無心人。」

#純靠北工程師vm

20多年的RD年資也超過我三倍了,但是作為資深RD主管卻啥都要我教.
跟Linux版的設計工具不熟到甚至不知道要怎麼開,幫你開了裡面的submodules也不會用,一個月前不是才說你用這個東西做了多屌的設計嗎? 不是說20多年來幾乎都是用linux版的工具嗎?
跟架構不熟也真是夠了,幫你畫架構圖讓你可以報告,結果因為自己對標準interface和component不熟導致理解錯誤還怪我畫錯,講不通說要自己改,過了兩天才興高采烈地跑來跟我說說你覺得是這樣才對,阿這不就是我當天跟你講半天你不認同的架構嗎?兩天後就變成你想到的了?我是要慶幸還好你想通了所以我們不用實作那種看到鬼的架構嗎?
搶了高度客製化的系統案子來做,才發現你對BUS, driver, kernel以及系統記憶體啥的整套根本毫無概念,自己寫程式裡面的位址是virtual 還是physical 都搞不清楚,系統規格裡還包含了容許使用者執行標準spec裡明確說不支援的行為,20多年成長的只有膽子嗎?一問果然你對這種通用的spec也不熟..
project到部門採購等雜事都丟給下面的自己除了拿部門進度跟上頭邀功以外,每天就寫一些跟project沒啥關係又基礎到不行,github上隨便撈都有一堆的程式還要誇耀說沒親自做過怎麼能說會...
專案遇到瓶頸但合作的部門也有同樣的function team有一堆高手也不給問,深怕拉低自己在公司上層的評價...
這樣也一年穩領兩百多萬每天11點上班19點下班...

🥙 全平台留言 https://kaobei.engineer/feed/1138
📢 匿名發文請至 https://kaobei.engineer