系統設計面試6個技巧｜我面Google前的準備方法

今天要來跟大家分享一下 軟體工程師的系統設計面試 到底在面什麼 我幾個月前是怎麼自己準備 然後成功的通過Google的 Level 5的系統設計面試 還有一些面試的技巧 如果有經驗的人應該都知道 通常在北美面軟體工程師的職位的時候 都會有好幾輪的面試 那我們說技術性方面的面試 大概分為兩類 第一類就是考算法數據結構的應用 這部分我在之前的一個影片裡面有介紹 要怎麼去準備 如果有興趣的話可以去看一下 另外一部分就是我們今天要聊的 叫系統設計 Season Design 其實硬要說的話也能歸類出第三個部分 我把它稱之為 Technical Deep Dive 但是因為這部分不算是主流 沒有前面兩個那麼好準備 所以以後要是有機會的話再跟大家聊 那系統設計面試到底在考什麼呢 其實最常考的概念就是去設計 分佈式系統 Distributed System 大家都知道像Google Facebook Amazon 這些靠網路服務起家的公司 他們背後的設計理念都離不開 Distributed System 但是有時候也不一定考這個 這是比較常出現的題目跟範圍而已 我自己也當過面試官面過很多人 有些很資深的工程師 他們有很多年的工作經驗 但是面系統設計這一輪的時候 反而做得不好 因為他們沒有準備嘛 很多人覺得自己經驗很豐富 這些東西對他們來講是 Common Sense 但是往往就是因為沒有準備 所以回答的很雜 也沒有規劃也沒有講到重點 因為可能很多的知識或許他們都知道 但是不知道怎麼在短短45分鐘之內 把它精簡的呈現給面試官 再來還有很多技巧都可以 大大的提升面試官對你的好感 並且增加你拿offer的機會 那今天就來跟大家分享一下 一些面試的技巧 還有我自己準備系統設計面試的方法 那今天這集影片呢 我不會講太深技術性的東西 我想以後有機會可以在另外一個頻道 或是另外一個地方 專門做這些影片的教學 如果有興趣的話 你可以在下面留言告訴我你的想法 那我第一次接觸系統設計面試的時候 是在大學 那時候面美國的一家公司 然後他們考我設計一套 系統類似YouTube這種 Streaming的服務 那那個時候就真的是亂講 完全沒有遇到過這種題目 也不知道怎麼準備 其實我自己是覺得系統設計面試 在準備起來會比 Leak Code那種面試更有意思 寫Leak Code寫到後面 真的是會懷疑人生 因為它有時候就像在寫解謎題一樣 會比較容易疲乏 但是系統設計的話 我反而會覺得很有趣 因為它更像是一種討論性的面試 通常沒有什麼對還是錯的答案 而且你根本不用去真的去實行 說真的你就是靠你的想像力 還有嘴炮而已 不像寫code的面試 你要把代碼真的寫出來 然後有時候還要求程式要正確的跑完 沒有錯誤 那我們前面說到 比較常見的就是設計 Distributed System 的應用 舉個經典的例子來說 設計一個簡化版的 Twitter 或是類似 Twitter 的這種服務 就是一個蠻常考的東西 為什麼這類型的題目很常考呢 因為它涉及到基本的前端設計 後端服務器的設計 到 Database 裡面的設計 然後可以討論很多 Scale 方面的問題 例如今天有一百萬個用戶 在同時使用的話 你要怎麼去設計 讓你的服務器不會爆掉 又可以同時服務世界各地的用戶 又或是例如今天在美國 東岸的服務器壞掉 你要怎麼確保用戶體驗 可以不受影響 這些諸如此類的應急措施 那為什麼這些概念很重要呢 尤其是對支撐工程師來說 因為你帶的項目 很有可能就會涉及到這些問題 你要知道像 YouTube Facebook 這種大型的服務器 靠廣告在維生的 要是掛掉了 每一秒基本上都在噴錢 或是像是 Netflix 你要是看電影 每五分鐘就給你卡一次 你一定會很想直接退訂閱 所以我認為系統設計題目 普遍來說最好的 Approach 是先提出一個比較簡單 基本的設計 然後從這個設計再來進行優化 有些人很急著想要去 Impress 面試官 一開始就把那些什麼 Cache、Database Sharding 然後哪裡要用 Low Balance 那些亂七八糟的東西 就放在你的 Design 裡面 然後變得很複雜 這樣做的話有幾個壞處 第一個就是你可能最後會沒有時間 把一個完整的 Working Solution 給呈現出來 因為系統設計可以討論的 Follow-up 的問題真的很廣 每個面試官在乎的方向也不太一樣 有些面試官很在乎你 怎麼去 Define 你的處理結構 或是怎麼去設計你的 API 那有些面試官更在乎你 怎麼去支援 同時有大量的用戶 在同時使用你的產品 所以你很有可能就把自己帶跑題了 然後花一堆時間 在面試官不在乎的地方上面 再來就是假如你一開始 就直接進入很複雜的設計 基本上大部分的時間 都是你自己在講話 就變成面試官在旁邊看戲 那假如你中間犯了什麼錯誤 你到後面可能就要回去改這些東西 就會很浪費時間 因為你把整個設計變得很複雜 就因為系統設計是一個 很開放式的題目 面試官更希望你 從一個比較基礎的答案開始 然後你至少有一個working solution 然後慢慢的根據他提出的要求 或許他會問你一些比較特殊的情況 你要怎麼去handle 然後讓你去修改這個設計 那這輪面試就會變得 你跟面試官有很多的互動還有討論 當面試官跟你的互動越多 互相分享自己的想法 你們聊得越開心 通常代表說這輪面試你越有希望 因為大部分的面試官 更希望招來的人 是可以跟自己一起工作 一起討論不同想法的人 第二個訣竅就是要不斷的問問題 然後盡量表明你的假設 通常面試官會給你一個 很籠統開放式的題目 然後需要求知者去提問 你要把這個scope變得更小更可行一點 把一些不確定性拿出來討論 然後跟面試官達成一個協議 以之前我們說Twitter的那個例子 面試官或許只會告訴你說 我們今天要來設計一個 類似Twitter的服務器 就這樣而已 那你在開始設計之前 你會需要問非常多的問題 還有提出很多假設 例如我們要假設有多少個活躍用戶 每個用戶每天平均發多少個推文 系統需不需要支持用戶 回覆推文 系統需不需要支持用戶點讚之類的 因為通常面試只有45分鐘 面試官不會真的要你去設計一個 很細節的東西 你只要跟面試官達成一個協議 說我們系統會讓用戶發推文 然後用戶可以追蹤其他用戶 然後用戶發的推文 會需要被追蹤的用戶給看到之類的 functional requirements 還有一些non-functional requirements 你會需要跟面試官去釐清 例如用戶每次刷新動態延遲 不會超過300毫秒之類的 這部分面試官審核的就是 那這邊最常犯的錯誤就是 你自己去假設一些 你覺得是理所當然的東西 然後沒有去跟面試官溝通 像是你可能會覺得 用戶可以點讚是一個很基本的feature 但是其實面試官考你的設計重點是在 即時動態那部分 然後如果你又花很多時間 在設計這個點讚的feature上面 就很有可能讓你這一輪面試不及格 第一個你沒完成面試官要考的重點 第二個就是你沒有試圖去溝通 瞭解面試官的重點在哪裡 這些都可以反映出來 你在未來真實做項目的時候 跟產品經理溝通的一些表現 那第三個tip呢 就是focus在基礎的概念上面 然後不要太糾結於某些技術的細節 盡量讓面試官去帶這個節奏 例如你們現在討論到database 你不需要去跟面試官說 我們要用AWS裡面的RDS 裡面的MySQL 大部分的時候你只需要瞭解 SQL跟NoSQL這兩個database的區別就好了 然後為什麼你選擇SQL而不是NoSQL 因為每家公司用的雲端服務 可能都不太一樣 而且你如果面對像Google這種 規模很大的科技公司 他們內部一定有自己的SQL database 可以讓你選 可能是一些你根本沒聽過的東西 所以你不需要去把這些東西講得這麼細 反而有時候會變成對你來講 是一個不利的情況 假如面試官反問你說 為什麼你選擇用MySQL 而不是用Postgres 這時候你又剛好兩個都寫在 你的resume上面 因為你都用過 那你又說不出個所以然 這樣的話這邊就會被扣分 我覺得盡量讓面試官 去帶整個面試的節奏 如果他想要知道 你用過哪些SQL database 他會很明白的直接問你 你不需要自己去挖一個坑 往裡面跳 而且系統設計這部分 考你的更多是一些基礎的概念 而不是你要怎麼去實際實行 例如面試官叫你設計一個 圖書館的查找系統 有些人可能會直接就開始寫一些 class function那些 在這邊我建議你要是不確定的話 就直接問面試官 Do you expect me to write some code and come up with a working solution or are we going to focus more on just the design? 假如他給你的題目很籠統 這些都是你的責任去釐清這些東西 再來下一個訣竅就是 你要主動提出 trade-offs 因為 system design 這種題目 是沒有一個正確的答案的 很多時候會有兩種 甚至三種以上的設計方法都是可行的 但是都有他們的利弊 你需要去權衡 那你要是能去主動的 提出這些設計的利弊的話 會大大的讓你這輪面試加分 舉個例子來說 假如現在聊到 要怎麼去shard你的 database 這邊的話就有很多種切法 你可以把不同的table 放在不同的server上面 但是這樣做的缺點就是 可能會造成不均衡的server load 那你也可以shard by 某一個ID 就是由一個hash function 去決定你這個數據 要存在哪一個server上面 這樣做的優點是什麼 缺點是什麼 這些你都要盡量去主動提出來 絕對會讓面試官對你的好感增加 代表說你懂的概念很廣 而不是隻知道一種設計方式 因為在真實的工作環境下 最好的設計方式通常都不止一樣 每一個項目 他的business requirements 都不太一樣 而身為資深工程師的你 是要有這個基本的概念 跟提出不同trade-offs的能力 再來下一個就是不要去背答案 後面我會講我是用什麼資料去準備的 那你在做準備的時候 會看實際的這些例題 像是怎麼去設計twitter 假如只是無腦的去背答案的話 就算你真的剛好被問到同一題 他稍微只要改一點requirements 你可能就不知道該怎麼回答了 系統設計的題目非常的廣 能問的問題真的太多了 最好的準備方式就是 真正去了解那些經典例題 他是怎麼去被設計的 然後在看那些設計方式的時候 你自己去想一下 does it make sense to you 然後假如你想出更多設計方法的話 那代表你是真的有在思考 而不是無腦的在記答案 那假如你在準備的時候 這些東西你瞭解的非常的吃力 或是你根本不懂一些基本的database的原理 那代表說你可能還沒有到這個級別 可能還需要多一點的工作經驗 畢竟資深design的面試 通常是針對比較資深的工程師 而對經驗較少的工程師來說 focus更多是在coding這方面 那最後一個tip就是 don't argue with your interviewer 有些時候你的面試官 不一定知道的比你還多 或許你是正確的 但是你的目標是在這一輪面試中 盡量拿到strong hire 而假如你花太多時間跟面試官 去爭論一些沒有意義的小東西 是沒有必要的 就算你爭論贏了 證明自己是對的 這也不代表說對方會真心認同你 而且假如你遇到那種 比較自我一點的面試官 他很有可能這一輪就直接把你給掛了 他不會在乎你到底是不是對的 他會覺得說你浪費一堆時間在跟他爭論 而沒有把時間花在其他更重要的地方上面 我有遇到過類似這樣的情況 雖然我知道我應該是對的 但是我一直保持著一個態度就是說 我還是有可能會出錯 我有可能是錯的 我就說 Oh yeah, maybe I just missed something But yeah, you're probably right 那我們就會move on到下一個環節 能虛心接受feedback 也是一個很重要的quality 有時候當下真的誰對誰錯 不是那麼的重要 以上就是我的一些經驗跟建議 希望對你準備系統面試有一些幫助 那我自己當時準備的方法其實很簡單 有一個叫做 Glocken Assistant Design Interview 你自己可以去Google一下 它是一個閱讀的課程 我這邊沒有在幫他打廣告 就只告訴你我自己當時準備的時候 是用了什麼課程 你如果買這個課程的話 我一毛錢也不會拿到 它是一個有點像電子書的課程 它不是影片 它裡面就是大概有15題的經典例題 加上一些基礎的知識 我覺得這個課程幫助我最大的就是 我讀完這些經典的例題之後 大概腦袋中就會有一個模板 可以按照這個模板來走完這一輪面試 從最基本的Requirements Estimate到API Design Database Design Basic High Level Design Detail Design 到最後怎麼去Skill 它算是一個比較循序漸進的模板 去完成一個系統設計 有這個框架之後就不容易手忙腳亂 想法跳來跳去 導致最後自己的設計變得一團亂 它裡面講的這些經典的題目 我大概都看了兩遍以上 我的準備方式就是 我不只要了解它裡面提到的設計方案 我自己還會做筆記 然後去想更多的設計方法 還有它們各種不同的Trade-offs 再來就是它裡面講的東西都比較基本 有些是沒有很細節的去解釋 例如我更想了解Cassandra 它內部是怎麼運作的 我會自己去Google這些東西 然後做筆記 這些就是我當時學習的方式 再來就是我自己本身 對這些Design的東西就蠻感興趣的 所以在準備的時候不會感覺到枯燥乏味 反而我覺得我學到了 真的很多很有用的東西 可以跟我實際工作上面做結合 最後如果你正在準備系統設計面試的話 我建議你可以找身邊的朋友 幫你做幾個Mock Interview 這些都可以讓你熱熱身 然後瞭解一下自己還有哪些地方 需要改進加強 好啦今天的影片就到這邊了 如果你喜歡這集影片的話 可以幫我點個讚 還沒有訂閱的朋友的話 可以認真考慮一下 如果大家有興趣的話 我之後可能會在另外一個地方 真正的帶大家去做一些系統設計 還有Coding的題目 希望能幫助你拿到更多的Offer 那你有什麼想法跟建議的話 都歡迎在底下留言跟我說 那我們下次見囉