Meta 系統設計面試問題
作者 Aaron Cao · 更新於
Meta的設計面試通常會讓你設計一款面向消費者的產品系統——動態消息、訊息服務、通知管道，或是「附近的朋友」功能。面試官對產品需求和資料模型的重視，不亞於對可擴展性的重視，而且這一環節是資深職缺的標配，而非入門等級。
Meta 會問哪些類型的設計問題？
你可能準備了大量分散式系統的知識點，但這個環節不會考這些。這部分講的是真實的題型，它們更接近產品工程，而非基礎設施。反覆出現的模式是：把一個你已經在用的消費級功能，當成開放式問題交給你。
- 設計一個動態消息。排序方式、寫入扇出與讀取扇出的取捨，以及粉絲數上百萬的帳號該如何處理。
- 設計一個訊息或聊天系統。投遞保證、順序、在線狀態，以及跨裝置的離線同步。
- 設計一個通知系統。去重、批次處理、依使用者限流，以及推播、電子郵件、應用程式內通知的分發。
- 設計「附近的朋友」或位置類功能。地理空間索引、更新頻率，以及隱私模型。
- 設計搜尋或熱門趨勢元件。索引新鮮度與查詢延遲之間的取捨。
有些面試流程會把這拆成產品架構變體，更貼近使用者可見的行為。可以問問招募方你面對的是哪一種，因為準備方式會不同。
這 45 分鐘該如何分配？
常見的失敗模式，是第二分鐘就開始畫框圖。一種可行的時間分配是：先釐清需求和範圍，再勾勒API和資料模型，接著畫出高層架構，最後依面試官指向的方向深入。
- 需求優先。面向哪些使用者、哪些平台，是讀多還是寫多，以及明確不做什麼。
- 接著是數字。大致的日活躍量級、請求速率和資料量大小，為後續的取捨提供依據。
- 先有資料模型，再畫圖。一個實體長什麼樣、如何被查詢，通常決定了架構走向。
- 一次深入探討。預計會被引導深入某一個元件，並被問到它會如何失效。
把你的假設說出來。面試官如果不認同某個假設，會當場糾正你，這其實是免費的資訊；而沒說出口的假設，只會顯得像是一個漏洞。
優秀回答和普通回答的差別在哪裡？
普通的回答只是描述一個正確的架構。優秀的回答會說出自己接受了怎樣的取捨、願意容忍怎樣的失效。比如說「我選擇寫入扇出，因為這裡讀多於寫，我接受名人帳號寫入變慢，會用獨立的拉取路徑來處理」，這比一張完美的架構圖更有說服力。
設想一位正在面試資深職位的後端工程師。她被要求設計一個通知系統，前六分鐘只談需求：同一事件使用者是否會收到兩則通知、順序是否重要、保留期限是多久。面試官後來說，去重的討論才是這個環節的決定性部分，而她始終沒有畫完一頁架構圖。
獨自在桌前演練這種敘述方式是最難的部分。你可以在 /mock-interview 頁面向AI面試官練習這類設計題，習慣邊思考邊說出來。
即時助手在哪些地方有幫助，哪些地方沒有？
在語音視訊面試環節，SubcueAI會轉寫面試官的問題，並在你這一側顯示建議的回答架構——在macOS和Windows上是桌面懸浮視窗，在Chromium瀏覽器擴充功能中是側邊欄。沒有機器人加入通話，也不會向會議頁面注入任何內容。對設計類環節來說，它真正的價值是一份清單，幫你記住壓力下容易忘記的要點，例如容量估算或失效模式，而不是讓你照著唸一個現成答案。
但限制也很明確。設計環節通常在共享的白板工具上進行，你的螢幕會被共享，螢幕上的一切對面試官都是可見的。照著唸生成的答案也會立刻穿幫，因為面試官接下來一定會問「為什麼不用另一種方案？」。其他雇主的相關流程，可參考公司面試專題。