Technical PM 面試攻略：從 API 設計到架構理解

Technical PM 面試是整個 Product Builder 面試中最容易讓非工程背景的人恐慌的環節。但它考的不是你能不能當場寫程式，而是你能不能在技術對話中不掉隊，並且在技術限制下做出合理的產品決策。

Technical PM 面試怎麼考

Technical PM 面試和 SWE 的 system design 面試看起來像，但評分維度完全不同。

SWE system design 考的是「你能不能設計一個可擴展、高可用的系統」——面試官要看你的架構決策、資料模型、分散式系統知識。Technical PM 面試考的是「你能不能理解工程師在說什麼，並據此做產品決策」——面試官要看你的技術判斷力、溝通精準度、以及在 trade-off 之間做選擇的邏輯。

典型的考法有三種：

白板架構討論。 面試官給你一個產品需求，要你和他一起畫出 high-level 的系統架構。你不需要寫出每個元件的實作細節，但你要能回答「為什麼選 A 不選 B」這類問題。例如：「如果我們要做即時通知，推播和 WebSocket 你選哪個？」

API 設計。 面試官要你為一個功能設計 API 端點。你不需要寫程式碼，但你要能定義資源、HTTP 方法、request/response 格式、錯誤處理策略。

技術情境題。 面試官描述一個技術問題（資料庫掛了、API 延遲飆高、第三方服務 rate limit），問你作為 PM 會怎麼處理。這考的是你在技術危機下的判斷力和優先序。

API 設計思維

API 設計面試是 Technical PM 最常見的考題之一。你不需要記住所有 HTTP status code，但你需要掌握幾個核心原則。

資源導向設計

RESTful API 的核心是把系統想成一組「資源」，每個資源有自己的 URL，用 HTTP 方法表示操作。面試時，先定義清楚你的資源是什麼，再決定操作。

以「設計一個待辦清單 API」為例，你的資源是 lists 和 tasks。建立清單是 POST /lists，取得某個清單的任務是 GET /lists/{id}/tasks，標記完成是 PATCH /tasks/{id}。這比用 POST /markTaskAsDone 這種 RPC 風格好，因為資源導向讓 API 的行為可預測。

版本控制

面試官常問「如果 API 要改版怎麼辦？」。兩種主流做法：URL 版本（/v2/tasks）簡單直覺但 URL 會膨脹；Header 版本（Accept: application/vnd.api+json;version=2）乾淨但客戶端較難 debug。面試時選 URL 版本然後解釋 trade-off 就好——大多數公司（包括 Google、Stripe）都用 URL 版本。

錯誤處理

好的 API 錯誤回應要包含三件事：status code（讓客戶端程式判斷）、error code（讓開發者查文件）、human-readable message（讓開發者快速理解問題）。面試時提到這三層，面試官就知道你有實際合作經驗。

系統架構理解

Technical PM 不需要自己設計架構，但你需要能讀懂工程師畫的架構圖，並在上面做產品決策。以下是面試最常涉及的幾個 trade-off。

同步 vs. 非同步

使用者按下「送出」後，系統要立刻處理完再回應（同步），還是先回一個「收到了」然後在背景處理（非同步）？

面試時的關鍵判斷：如果使用者需要看到即時結果（搜尋、付款驗證），用同步；如果處理時間長且使用者可以等（影片轉檔、報告產生），用非同步加通知。能講出這個判斷邏輯比記住 message queue 的實作細節重要。

資料庫選型的直覺

面試官可能問「這個功能用關聯式資料庫還是 NoSQL？」你不需要講出 B-tree 索引的原理，但你要能判斷：如果資料有明確的結構和關聯（使用者、訂單、商品），關聯式通常是對的。如果資料結構不固定或需要極高的寫入速度（日誌、即時事件），NoSQL 可能更適合。

快取策略

「使用者的首頁載入很慢，你會怎麼做？」面試官想聽的不是「加快取」這三個字，而是你怎麼決定快取什麼、快取多久、快取失效時怎麼處理。熱門內容（趨勢列表、推薦結果）可以快取幾分鐘而不影響體驗；個人化內容（未讀通知數、購物車）不能快取或 TTL 要極短。

與工程師協作

Technical PM 面試的一個隱藏考點是「你和工程師合作的模式是什麼」。面試官想知道你不是那種丟一份 PRD 就消失的 PM。

RFC 流程

面試時提到你用 RFC（Request for Comments）流程來推動技術決策，會非常加分。流程是：寫一份提案文件（問題、方案選項、推薦方案及理由、開放問題），發給相關工程師 review，收集反饋後修改，最後在會議上做最終決定。

面試官會追問「如果你和 tech lead 意見不一致怎麼辦？」。好答案是：先確認分歧的根源——是對技術事實的理解不同（用數據解決），還是對優先序的判斷不同（用商業目標解決），還是對風險的容忍度不同（用漸進式實驗解決）。

估時與排程

面試官常問「工程師說這個功能要做三個月，你覺得太久，怎麼辦？」。錯誤答案是「砍規格」。對的思路是：先理解三個月的工作量拆解——哪些是核心功能、哪些是邊緣處理、哪些是技術債償還。然後和工程師一起討論：如果我們先不做 X 和 Y，只做核心的 Z，能在一個月內上線嗎？上線後補 X 和 Y 的技術難度會不會因此增加？

這種對話展現的是你理解技術工作的非線性——砍掉一半的規格不等於砍掉一半的開發時間。

技術限制下的產品決策

這是 Technical PM 面試最高階的考點。面試官會給你一個場景，讓你在技術限制和商業目標之間做選擇。

典型題目： 「你的推薦系統模型需要兩天重新訓練一次，但業務部門希望推薦結果每小時更新。你怎麼處理？」

好的回答結構：

1. 釐清真正的需求。 業務部門要的是「每小時更新」還是「反映最新的使用者行為」？這兩個不一定等價。

2. 盤點技術選項。 可以在模型之上疊一層即時規則（如果使用者剛看過 X，優先推 Y 的相關內容），不用重新訓練模型就能反映最新行為。或者可以把模型切成輕量版（小模型每小時更新）和完整版（大模型兩天更新），混合排序。

3. 評估 trade-off。 即時規則最快實作但靈活度有限；雙模型效果最好但工程成本高、維護複雜度倍增。

4. 做出決策並解釋。 「我會先做即時規則，因為實作成本最低、風險最小，而且可以立刻驗證『反映最新行為』是否真的提升商業指標。如果驗證有效，再投資做雙模型架構。」

常見題型與面試策略

面試策略：

先問，再答。 技術問題常常有隱含的限制條件。在回答之前問清楚：使用者量級多大？延遲要求是什麼？有沒有現有的系統要相容？

用 trade-off 框架。 每個技術決策都用「選項 A 的優點是 X，代價是 Y；選項 B 的優點是 P，代價是 Q；在這個情境下我選 A，因為 X 比 P 對我們更重要」這個框架來表達。

承認不知道的東西。 如果面試官問到你不熟的技術，說「這個我不確定實作細節，但我的理解是 X，我會和工程師確認」。比硬掰一個錯誤答案好一百倍。

準備一個技術合作的具體故事。 面試官一定會問「你跟工程師合作最困難的一次是什麼」。準備好一個 STAR 故事，重點放在你怎麼理解技術限制並據此調整產品方向。

接下來

下一篇進入 Growth & Experimentation——怎麼設計 growth loop、跑 A/B test、做 retention 分析。

面試模擬題

題目

「你負責一個即時通訊產品的訊息搜尋功能。工程師告訴你全文搜尋需要 3 個月才能上線，但業務說客戶下個月就要。你怎麼處理？」

來源：自擬（based on Slack/Teams PM 面試）　難度：中等　環節：technical PM round

拆解思路

1. 先釐清問題：問面試官——3 個月的估算是基於什麼技術方案？客戶要的「搜尋」具體是指什麼（全文搜尋？按人/日期篩選？關鍵字匹配？）？業務說的「下個月」是合約 deadline 還是口頭承諾？
2. 建立框架：把「搜尋」拆成技術層次——metadata filter（按人/日期/頻道，幾天可做）、關鍵字匹配（DB LIKE query，1-2 週）、全文搜尋（需要 Elasticsearch 或類似基礎設施，3 個月）。
3. 深入核心：核心 trade-off 是「客戶體驗完整度 vs 上線速度」。不是在「做不做」之間選，而是在「做多少」之間找到 MVP 切分線。
4. 收尾：提出分階段上線方案，每階段都有可衡量的客戶價值，並說明怎麼跟業務和工程分別溝通。

範例回答（面試時可以這樣講）

先理解真正的需求。 我會去問業務：客戶說的「搜尋」到底是什麼場景？如果他們的痛點是「找上個月跟某個人講的那段話」，那按人+日期的 metadata filter 就能解決 80% 的需求，這個工程師幾天就能做。我不會直接接受「客戶要搜尋」這個抽象需求。

跟工程拆分技術方案。 把搜尋分成三層：第一層是 metadata filter（按人/日期/頻道），用現有 DB index 就能做，大約 1 週。第二層是關鍵字匹配，在 PostgreSQL 裡加 trigram index，大約 2 週。第三層才是全文搜尋，需要引入 Elasticsearch，確實要 2-3 個月。我會問工程師：3 個月的估算是不是假設了從第三層開始做？

提出分階段方案給業務。 第一階段下個月上線 metadata filter + 關鍵字匹配，覆蓋大部分使用場景。第二階段兩個月後上全文搜尋。我會帶著使用場景的數據去說服業務：「客戶 70% 的搜尋行為是找特定人的訊息，第一階段就能處理。」同時在客戶端設預期：「基礎搜尋下月上線，進階搜尋 Q2。」

自我核對清單

參考資料

• Google API Design Guide — Google 的 API 設計原則，涵蓋資源導向設計、錯誤處理、版本控制等 Technical PM 面試高頻考點
• Stripe API Reference — API 設計的業界標準範例，常被面試官引用作為好 API 設計的代表
• Gergely Orosz — The Product-Minded Software Engineer — 從工程師視角看 PM 協作模式，理解工程師期待什麼樣的 Technical PM
• Microsoft REST API Guidelines — Technical PM 面試中 API 設計思維的進階參考，涵蓋 versioning、error handling 等架構理解考點
• Exponent — Technical PM Interview Guide — Technical PM 面試的結構化準備指南，涵蓋系統架構理解與工程師協作模式的常見題型