目錄
今日主題
Technical PM 面試最容易踩的陷阱，是把它當成弱化版的工程師面試——聽到「設計一個系統」就急著畫方框和箭頭。但面試官要看的從來不是架構完不完整，是候選人有沒有先框出限制條件再動筆。Google 的內部數據顯示，78% 沒過系統設計環節的 PM 候選人,問題不是技術深度不夠，而是跳過釐清需求直接畫圖。
第二個常被忽略的維度是「升級判斷」（escalation judgment）：知道什麼時候該自己拍板、什麼時候該拉工程或資安主管進來，這個訊號在面試官眼裡，權重常常比畫出一張漂亮的架構圖還高。
核心框架速記
PM 系統設計五步法（適用「設計一個 X 系統」類題目）
工程師被評分的標準是正確性，PM 被評分的標準是排序判斷——面試官想看的不是你能不能撐到 10M QPS，是你能不能說清楚為什麼 1M QPS 就夠、以及這個上限如何對齊產品路線圖。
| 步驟 | 要做什麼 | 反面教材 |
|---|---|---|
| 1. 釐清需求 | 先問功能與非功能需求：離線支援？即時協作？加密？稽核紀錄？ | 一聽到題目就直接畫微服務圖 |
| 2. 估算規模 | 框定量級：「不是設計給 1 億人用，是 50 萬人、八成在東南亞、網路不穩」 | 用預設的「假設 1000 萬 DAU」套公式 |
| 3. 畫高層架構 | 只畫框和箭頭，先不進細節 | 一開始就在爭 Redis 還是 Memcached |
| 4. 抓關鍵取捨 | 講清楚成本：「這會增加 120ms 延遲、每月多 1.8 萬美元雲端成本、需要三個新的 API 合約」 | 只講「加快取就會變快」不講代價 |
| 5. 提緩解與升級判斷 | 定義失敗模式和升級門檻：「同步延遲超過 2 秒就通知維運，並停用自動續約」 | 遇到問題只回「我們會加更多 worker」 |
建議計時：釐清需求 5 分鐘、畫架構 10 分鐘、講取捨 5 分鐘——時間分配本身就是一個訊號，面試官在看你會不會把力氣花在對的地方。
技術判斷三訊號（面試官實際在打分什麼）
| 訊號 | 好答案長什麼樣 | 差答案長什麼樣 |
|---|---|---|
| 限制條件意識 | 「我們解的是 50 萬使用者、GPS 訊號不穩、多用現金支付」——先框限制再談方案 | 直接套用「標準」架構,不管實際場景 |
| 取捨表達力 | 「放寬一致性、改成顯示最後已知位置＋新鮮度標籤——我們的 SLA 是可用性,不是精確度」 | 只說「這樣比較快」，講不出犧牲了什麼 |
| 升級判斷 | Amazon 案例：消費端積壓 10 萬則訊息時答「先取樣記錄，而非盲目加 worker」；資安相關先拉資安主管而非自己決定加密方案 | 遇到規模問題只會說「加機器」，把所有技術判斷都丟給工程 |
今日練習題
題目
「幫企業版設計一套類似 Google Keep 的多人協作筆記工具。說明你會怎麼開始設計，以及你的技術判斷和取捨。」
來源：Johnny Mai 整理的 Google PM system design 面試真題（原題為「Design Google Keep for enterprise」） 難度：中高 環節：system design / technical round
拆解思路
- 釐清需求：企業版跟消費版的第一個差異是身份和合規——問面試官：需要離線編輯嗎？多人要即時協作還是非同步就好？資料要不要靜態加密？要不要有稽核紀錄（誰改了哪一行、什麼時候）？這四個問題的答案會直接決定架構走向，弱的候選人會跳過這步直接畫服務框。
- 估算規模：不要套「億級使用者」的預設值。先框定「我們解的是中大型企業客戶，單一組織平均 500-5000 名使用者，尖峰時段每分鐘寫入量估在幾百筆」，這個量級決定你要不要一開始就上分散式資料庫。
- 畫高層架構（不進細節）：同步服務、儲存層、衝突解決機制三塊先畫出來就好，不用一開始就爭要用哪個資料庫。
- 抓關鍵取捨：即時協作需要強一致性,但離線編輯必然會產生衝突——這裡的核心決策是選 CRDT（自動合併,體驗好但實作複雜）還是 last-write-wins（實作簡單,但使用者可能無聲丟資料）。企業客戶對「無聲丟資料」的容忍度極低,這通常是選 CRDT 的理由,但要講出代價：工程複雜度上升、上線時間拉長。
- 提緩解方案與升級判斷：定義失敗模式，例如「同步延遲超過 2 秒，就把編輯狀態降級為唯讀並提示使用者，而不是讓兩份版本悄悄分岔」；牽涉到加密或合規範圍的決定，要主動說「這裡我會先拉資安或法務對齊，不是我一個人拍板」。
範例回答（面試時可以這樣講）
先框限制，不急著畫圖。 企業版跟消費版最大的不同是身份和合規要求,所以我會先問四件事：需不需要離線編輯、協作是即時還是非同步、資料要不要靜態加密、要不要保留誰改了什麼的稽核紀錄。假設答案是「都要」，這代表我不能只做一個薄薄的即時同步層,底層需要有版本歷史和衝突解決機制。規模上我會假設中大型企業客戶,單組織幾千人,尖峰寫入量是幾百筆一分鐘——這個量級用不到過度工程化的方案。
最關鍵的取捨在離線編輯衝突。 兩個人在飛機上各自離線改同一則筆記，回到線上後怎麼合併？我會選 CRDT 而不是 last-write-wins，因為企業客戶對「我的修改被悄悄覆蓋」的容忍度極低——一次無聲丟資料的客訴，代價遠高於多花兩週工程時間做好合併邏輯。但我會誠實講代價：CRDT 讓上線時間拉長，也需要工程團隊有相關經驗，如果團隊沒做過，我會建議先在小範圍 beta 客戶驗證,而不是直接全量上線。
失敗模式和升級判斷是我會主動提的。 如果同步延遲超過 2 秒，我不會讓系統悄悄分裂成兩個版本讓使用者自己發現，而是把編輯狀態降級為唯讀並提示「有其他人正在編輯，稍後同步」。加密方案這塊我不會自己拍板，會先拉資安主管對齊企業客戶的合規要求，因為這類決定一旦做錯，修正成本是以資料遷移計的。
自我核對清單
| 核對項目 | 有提到？ |
|---|---|
| 前五分鐘花在釐清需求,而不是直接畫架構 | |
| 規模估算有框出量級,不是套用預設的「億級」數字 | |
| 至少講出一個具體取捨,並說出代價（不只說好處） | |
| 定義了失敗模式與對應的緩解或降級方案 | |
| 有展現升級判斷（什麼時候該拉其他角色進來,而不是自己決定） | |
| 加分：把技術決策換算成使用者體驗或商業代價（延遲、成本、信任） |
今日案例
Uber：一次關於「精確」與「可用」的工程協商
Uber 曾有 PM 提出要讓司機的即時到站時間（ETA）在所有裝置上強一致同步。工程師的回應很直接：這需要強一致性，但強一致性在訊號不穩定的地區會直接失敗。
這位 PM 沒有堅持原方案，而是重新定義了目標：改成顯示「最後已知位置」加上一個新鮮度標籤，讓使用者知道這筆資料是幾秒前更新的。她的說法是——「我們的 SLA 是可用性，不是精確度」。這句話把一個看似讓步的技術決策,重新框成一個主動的產品判斷。
面試連結：這是回答「講一個你跟工程師意見不合、後來怎麼解決」的絕佳素材結構——重點不在「我說服了工程師」，而在「我把工程限制轉譯成一個新的、依然成立的產品承諾」。面試官在聽這類故事時,真正在打分的是你有沒有把技術限制轉成使用者能理解的語言,而不是誰在會議上贏了。
延伸閱讀
- Johnny Mai — System Design for PMs: A Deep Dive into Key Concepts — 系統設計五步法、Google/Meta/Amazon/Stripe 的真實面試片段全文
- Johnny Mai — How to Answer Technical Questions as a PM — 技術問題在面試中的三種出現形式,以及 Meta 內部訓練文件的 60% no-hire 數據
- Exponent — 52 Real Product Manager Interview Questions (2026 Guide) — Stripe/Google 等公司的技術輪真實流程與候選人回報
參考資料
- Johnny Mai — System Design for PMs: A Deep Dive into Key Concepts (2026-05-02) — 五步結構、時間分配建議、Google「Design Google Keep for enterprise」真題、Uber ETA latency vs consistency 案例、Stripe/Amazon 升級判斷案例
- Johnny Mai — How to Answer Technical Questions as a PM (2026-04-29) — 技術問題三種出現形式與佔比、Meta 60% no-hire 內部數據、Google 78% 系統設計失敗率數據
- Exponent — 52 Real Product Manager Interview Questions (2026 Guide) — Stripe PM 技術輪候選人回報:「準備一個你熟到骨子裡的系統,能上白板講架構、資料流和一個具體技術取捨」
Loading...