Technical PM 面試考 API 設計，真正要看的不是你會不會畫架構圖，而是你怎麼在『不能打斷任何一個現有整合』的前提下，還能讓系統往前走。今天練一道改編自 Stripe 真實歷史的題目：『你要把一個布林欄位換成列舉欄位，但已經有數千個第三方整合依賴舊格式，你會怎麼規劃這次變更？』答案框架是 Use Case → Contract → Compatibility → Operability → DX：先搞清楚誰在呼叫、呼叫的契約是什麼，再決定相容策略、維運成本與開發者體驗怎麼兼顧。案例是 Stripe 自 2011 年公司成立起維護所有 API 版本的相容性，不用 v1/v2/v3 大版號，改用以日期命名的 rolling version，把每次破壞性變更封裝進獨立的 version change module，六年內做了近百次破壞性升級，對現有整合幾乎無感。
Technical PM 面試考的不是你會不會畫架構圖，而是你能不能把一個破壞性 API 變更，拆解成客戶分群、相容層設計、分階段淘汰時程這幾個具體決策，並且敢真的設一個會執行的下線日期。今天的框架是 Use Case → Contract → Compatibility → Operability → DX 五層 API 設計框架，搭配 ADR（背景→決策→後果→回頭觸發點）把決策寫下來。練習題是「如何規劃一個破壞性授權變更的 API 淘汰計畫」，拆解思路是先釐清變更性質、用呼叫量數據把客戶分群、評估相容層的可行性、分四階段淘汰（警告→溝通→軟性截止→下線），最後用流量遷移率當領先指標。案例是 Stripe 從 2011 年至今用日期命名版本與版本轉換模組，讓每個帳號在第一次呼叫時自動釘選版本，之後所有破壞性變更都由內部轉換模組吸收，開發者可以永遠留在自己被釘選的版本上；2024 年 9 月起進一步把節奏公開為每月小版本、每年兩次大版本。
Technical PM 面試最容易穿幫的地方,是被問「這個 API 要怎麼升級」時,只會說「多寫一版文件」,答不出工程團隊維護雙版 schema 的實際成本,也答不出怎麼幫還沒升級的客戶爭取時間卻不拖垮整個團隊的路線圖。今天練一道情境題:B2B API 平台的核心 resource 要把單一數字欄位改成巢狀物件以支援多幣別,工程 lead 想直接在下一版強制升級。答案框架是 RFC 流程(Problem → Options → Decision → Cost)把技術決策攤開來討論,搭配 ADR 把「為什麼選這個方案、放棄了什麼」寫成有時效性的紀錄。案例是 Stripe 的日期命名 API 版本系統——每月發相容版本、每半年才發一次可能有 breaking change 的具名大版本(如 2026-08-26.dahlia),讓 2012 年寫的整合程式碼到今天都還能跑,靠的不是「不做 breaking change」,而是把 breaking change 的成本主動吸收在自己身上,而不是丟給客戶。
Technical PM 面試最容易被看穿的地方,是把版本策略講成一句「我們會做 v1、v2」,卻答不出誰該承擔升級成本、多久允許一次 breaking change。今天練一道情境題:企業合約要求 API 六個月內穩定不能無預警改格式,工程團隊目前沒有版本管理。答案框架是版本策略選項比較(路徑版本、header 版本、日期滾動版本)搭配 Cost-Reversibility 權衡矩陣,把每個選項的工程成本與客戶風險攤開來比。案例是 Stripe 用日期命名的滾動版本策略——每月版本只允許相容變更、每半年一次大版本才准破壞相容性,且每個帳號可以釘住自己的版本,讓 API 十幾年沒有真的「壞」過任何一個整合。
Technical PM 題最常見的失分點,是把技術判斷講成「工程說了算」或「我全部自己決定」,講不出怎麼把決策過程開放給團隊、又不失去方向。今天用 RFC 流程收斂多方意見、用 Architecture Decision Record 留下決策的來龍去脈,再練一道「合作夥伴系統逾時後自動重試,造成重複下單」的 API 設計題——怎麼設計讓重試變安全,又怎麼知道修好了。案例是 Stripe 的 Idempotency-Key header:同一個問題,他們在支付 API 上已經解了十年,至今仍是這類題目最常被拿出來對照的答案。
Technical PM 面試不是要你會設計系統，是要你能跟工程師用同一套語言討論取捨。今天用 RFC 流程（Draft-Review-Decision-Implementation）練『怎麼收斂技術討論的範圍』，用 Architecture Decision Record（Context-Decision-Consequences-Alternatives）練『怎麼把一個技術取捨寫清楚、留下可追溯的紀錄』，練一道 Exponent 收錄的 Stripe 技術輪真實題：設計一個 Ledger Service。
Technical PM 面試考的不是你會不會寫程式，是你能不能把一個技術決策（要不要接受 breaking change）講成一個工程師會認同的產品判斷。今天用「釐清→草擬→拆解取捨→回扣產品」四步法搭配輕量版 ADR，練一道 API 版本控管的真實題，並對照 Stripe 用 idempotency key 把「網路重試會不會重複扣款」這個不確定性收斂成一紙契約的做法。
Technical PM 面試考的不是你會不會畫架構圖，是你會不會在畫圖之前先講清楚限制條件。今天練 Clarify → Estimate → Sketch → Trade-off → Mitigation 五步結構，題目是 Google 真實面試題「設計企業版 Google Keep」，案例是 Uber 一則 latency vs consistency 的真實工程協商故事。
Technical PM 面試不要求你寫 production code，但你要能讀懂 trade-off。核心能力：API 設計的基本思維（RESTful、版本控制、錯誤處理）、系統架構的 high-level 理解（微服務、資料庫選型、快取策略）、與工程師協作的溝通模式（RFC 流程、技術 spec review），以及在技術限制下做產品決策的能力。