行動系統設計 (Mobile System Design, MSD) 面試已成為許多公司招募行動工程師的關鍵環節。這類面試通常時間有限，不超過一小時，卻充滿了廣泛且刻意開放的題目，例如「Design Facebook」、「Design a pagination library」或「Design YouTube」。在如此有限的時間與高期待下，提出正確的問題以釐清需求並聚焦在最重要的面向，變得至關重要。

講師介紹#

Manuel Vicente Vivo ^↗ 是一位資深的 Staff Mobile Architect 與 Android 工程師，曾任職於 Capital One、Google、Bumble Inc. 等知名公司。除了技術專業之外，Manuel 同時也是熱心的導師、出色的演說家，以及作品影響全球數百萬讀者的多產作家。

本書是你的實戰指南，無論你是：

• 準備面試的行動工程師
• 磨練架構思維的技術主管 (Technical Lead)
• 對行動開發感興趣的學習者

透過真實案例 (real-world case studies)、可重複使用的框架 (reusable frameworks) 以及實作策略 (implementation strategies)，你將學會如何以清晰與自信的態度面對複雜的設計問題。

為什麼公司會問 MSD 面試題#

MSD 面試填補了招募流程中的關鍵空缺。資料結構與演算法面試評估的是寫程式能力，而系統設計題則評估那些難以從別處衡量的資深級能力 (senior-level competencies)。這類面試能幫助面試官從多個關鍵面向校準你的能力：

• 在模糊情境下定義需求與範圍的能力。
• 面對複雜且開放的設計挑戰時的拆解與思考方式。
• 強大的問題解決能力與技術知識。
• 對複雜系統設計的不同選項與權衡 (trade-offs) 的洞察力。
• 在團隊環境中的溝通與協作技巧。

MSD 面試刻意設計為存在多種有效解法的情境。雖然許多公司重視的是你的思考過程與推理能力，而非特定解法，但也有公司會期望解法緊貼業界既有模式，或與其內部架構標準一致。

在所有面試中始終重要的是：展現結構化的問題解決方法、做出刻意的設計選擇，並清楚地闡述決策背後的權衡。最強的候選人同時展現出技術深度，以及根據需求與回饋調整方案的適應力。

不同於程式面試，MSD 面試幾乎不會要求你實際寫程式。你偶爾可能被要求畫出虛擬碼 (pseudocode) 或呈現元件之間的資料交換，但重點仍在於架構與設計決策。帶著這個獨特的面試形式觀念，讓我們來看看面試官對不同資深層級的期待。

評分等級說明#

從面試官的角度來看，不同資歷層級的期待差異相當大。雖然每家公司都有自己的評估標準，並強調系統設計的不同面向，但仍有一些業界通用的期待。讓我們看看面試官在每個層級通常會看重什麼。

需要注意的是，這裡討論的層級定義主要基於 Google、Meta、Amazon、Microsoft 這類「大型科技公司 (Big Tech)」，它們的工程職級階梯結構清楚、層級眾多。相對地，較小型的公司與新創常採用更壓縮的職級系統與職稱。

MSD 面試很少用於初階 (junior-level) 招募流程。這類面試評估的是通常需要經驗累積才會發展出的進階能力，因此對於剛起步的工程師來說並非有效指標。

Mid-level（中階）#

中階候選人應展現基本的行動系統設計知識，並在面試過程中主動推動討論。他們被期待能夠：

• 透過詢問需求與限制的相關問題，建立對問題的清楚理解。
• 建立一個元件關係合理的高層次設計 (high-level design)。
• 識別常見的行動模式與適合該問題的技術。
• 設計能支援所需功能的基本 API 結構。
• 展現對基本狀態管理 (state management) 方法的認識。
• 辨識效能、安全性與使用者體驗上的基本權衡。

這個層級的設計挑戰通常聚焦於中等複雜度的完整功能或服務。中階工程師可能偶爾需要面試官提示某些系統面向才會注意到，這完全正常；面試官對此有預期，並會在必要時引導對話。

中階的設計應展現對行動特有議題的認識，例如：

• 網路可靠性 (network reliability)
• 電量消耗 (battery usage)
• 儲存空間限制 (storage limitations)

雖然解法未必會完整涵蓋系統的所有面向，但面試官主要評估的是候選人能否建立一個元件關係清晰、可運作的基礎架構。

Senior（資深）#

資深候選人應展現更高的獨立性與技術深度。他們被期待能夠：

• 在極少引導下推動需求蒐集階段。
• 主動辨識設計中的關鍵面向，而無需提示。
• 建立涵蓋主要功能需求的全面高層架構。
• 辨識並處理非功能性需求 (non-functional requirements)，例如效能、安全性與可擴展性。
• 設計定義清楚的元件，具備明確的 API 合約與溝通模式。
• 在應用程式中進行周延的狀態管理。
• 對權衡做出有依據的決策，並能為自己的選擇辯護。

在這個層級，候選人面對的設計題可能與中階相同，但對深度與廣度的期待更高。資深工程師應該自然地考慮到錯誤處理、邊界情況與潛在失敗場景，而不需要面試官明示。

資深層級的設計應展現對行動平台能力與限制的深入理解。元件應有明確定義的角色與清楚的 API，整體架構應反映行動最佳實踐。他們應展現出對設計決策如何影響使用者體驗、電池續航、資料用量等行動特有議題的敏銳度。

Staff+（首席及以上）#

Staff+ 候選人應在整場面試中展現全面的技術領導力與精通程度。他們被期待能夠：

• 在極少引導下進行徹底且主動的需求蒐集。
• 自信地主導對話，從容應對模糊情境。
• 設計出能高效擴展的系統，展現對系統複雜度與其影響的深入理解。
• 以技術精準與流暢的方式溝通。
• 做出快速且有依據的決策，展現豐富經驗。
• 預見未來挑戰，並為可擴展性而設計。
• 展現考量商業影響與產品演進的策略思維。
• 清楚闡述風險評估與緩解策略。

Staff+ 候選人應主動辨識並處理具挑戰性的面向，獨立探索進階主題，例如：

• 精密的快取策略 (sophisticated caching strategies)
• 離線優先架構 (offline-first architectures)
• 跨平台考量 (cross-platform considerations)
• 效能優化 (performance optimization)
• 失敗復原機制 (failure recovery mechanisms)

這個層級的解法往往涉及使用者體驗、效能與安全性等競爭因素之間的精密權衡。Staff+ 工程師不僅要產出有效的設計，還要展現讓他們在複雜情境中脫穎而出的策略思維。他們的設計應展現對行動架構模式、平台特定優化以及行動應用所處整體生態系的深入理解。

面試官可能刻意引入限制或邊界情況，以評估 Staff+ 候選人在約束下的優化能力。在這個層級，快速適應、辨識設計選擇在整個系統中的連鎖影響，以及清楚闡述決策推理的能力至關重要。

如何有效使用本書#

本書旨在提供一個全面的 MSD 面試方法，同時提供結構化框架與詳細案例研究。為了從這些資源中獲取最大價值，請參考以下的使用方式。

漸進式結構#

本書對概念的介紹遵循刻意的進程。早期章節會投入大量篇幅講解基礎架構選擇與客戶端-後端通訊模式 (client-backend communication patterns)，建立所有行動設計都需要遵循的核心原則。隨著你進入後續章節，這些知識將被視為前提而不再重複，讓內容能專注於每個使用情境的新挑戰。

案例研究與獨特聚焦主題#

行動系統設計是個充滿技術面向的挑戰領域。為了有效涵蓋，我們規劃了一張仔細設計的地圖，為每一章分配獨特的挑戰，讓本書能涵蓋技術面試所需的廣泛主題。

Table 1：每章涵蓋的主要主題

超越面試本身#

你很快會注意到，每一章的細節都遠超過一場一小時面試能涵蓋的範圍。這是刻意的安排。完整的說明能幫助你理解做什麼決定，以及為什麼在特定限制與需求下這些決定合理。這種更深的理解讓你能夠：

• 在面試官追問你的設計選擇時，自信地解釋推理。
• 在面對意料之外的需求或限制時，調整你的方法。
• 辨識權衡並解釋為何某些妥協是必要的。

延伸學習#

在每個案例研究的結尾，你會看到一些主文未涵蓋的額外需求或功能建議。這些延伸題是絕佳的練習機會：

1. 先自行為這些需求設計解法。
2. 再與書中建議的做法做比較。

擁抱多種有效解法#

在本書中，我們根據需求與自身的最佳判斷提出設計決策。

你可能會不同意某些選擇，這完全沒問題。 真實世界的行動系統設計對同一個問題往往存在多種有效解法。

如果你偏好與本書不同的做法，請練習解釋為何你的方案在某些情境下可能更好，同時承認它的限制。把本書當成指南而不是標準答案。這種心態能培養出讓你在面試與真實世界系統設計中都受用的批判思考能力。