我目前在 UMD 讀大三，主修 CS + Business，之前有兩段 defense 公司 SWE intern 經驗，也做過自己的小生意，所以一直在 PM 和 SWE 之間搖擺。之前拿到過 Google APM 的面試機會，但因為 headcount 原因沒有繼續推進。後來投了 Cloudflare PM Intern ，目前已經透過前幾輪，整體感受是這家公司雖然招的是 PM，但面試風格明顯比傳統 PM 更 technical，尤其是第一輪 assignment，完全重新整理了我對 PM 面試的認知。
R1 — Assignment
真沒想到 Cloudflare PM Intern 第一輪居然要動手寫程式碼做一個可執行的 Prototype，而不是單純寫 PRD 文件或者做 Slides。
題目形式： 給定一個真實的產品痛點場景（偏開發者工具方向，涉及 API 管理和可觀測性），要求：
- 分析核心使用者問題，給出你的產品方案
- 真正實現一個可互動的 MVP 原型來驗證你的方案
- 沒有模板、沒有框架限制，自由發揮
解題過程：
- 我先花了大約 30 分鐘做產品側思考：目標使用者是誰？核心痛點是什麼？最小可驗證的解法是什麼？最終確定做一個能實時展示請求狀態 + 錯誤聚合的輕量 Dashboard，並寫了一份半頁的 Product Brief 作為“開發任務書”。
- 快速搭建 MVP 技術棧選擇了 React + Node.js（我最熟悉的組合，能最快交付可執行的東西）。功能上實現了三個核心模組：
- 模擬 API 請求流的資料 mock請求狀態的實時展示（成功/失敗/延遲分佈）錯誤型別的簡單聚合與高亮
雖然沒有做過度 UI 美化，但互動邏輯完整，能跑起來、能點選、能看到資料變化。
- 提交時附上 Product Rationale 程式碼之外，我專門寫了一段說明：為什麼這樣設計？哪些是 P0 必須有的功能？哪些是故意砍掉的？如果繼續迭代下一步會做什麼？
面試官反饋： 面試官回覆說完成度和產品邏輯都比較完整，尤其認可我“主動取捨 + 說清楚理由”的做法。
心得： CS 背景在這輪是真實優勢。純 Business 背景的同學，哪怕不精通全棧，也要提前練習用 no-code 工具或 AI 輔助快速搭出一個可演示的原型。Cloudflare 這類 Dev-Tool 公司對“能落地”的 PM 有明顯偏好。
R2 — Product Lead 面
題目內容： Generic Product Case —— “請為一個特定使用者群體設計一款 App，幫助他們解決 XX 日常場景下的核心問題。”（生活類場景，和 Cloudflare 自身產品無關）
解題過程：
- 充分 Clarify 我先問清楚：是 0→1 新產品還是最佳化已有產品？目標使用者有沒有具體限定？成功的定義是什麼？
- 定義使用者與核心痛點 聚焦在一個具體的子使用者群，用簡短的 User Journey 描述他們在哪個環節被卡住，把痛點說得很具體。
- 提出解決方案（3 選 1） 給出三個方向不同的解法，最後推薦一個，並說明理由：技術複雜度可控、與核心痛點對齊度最高、容易透過 A/B 測試驗證。
- 定義 Success Metric（分層）
- Engagement Metric（短期）：功能使用率、Session 內觸發次數
- Outcome Metric（中期）：完成目標任務的成功率、時間縮短比例
- Business Metric（長期）：對留存率 / NPS 的影響
當面試官追問“如果 Engagement 高但 Outcome 沒改善怎麼辦”時，我回答：這說明功能被用了，但沒有真正解決問題，需要透過使用者訪談確認是設計問題還是問題定義出了偏差。
心得： Product Sense 輪不要死背 Cloudflare 產品線，框架 + Clarify + 結構化思考 遠比背具體產品重要。被追問時慢下來，說“這是一個好問題，我從兩個角度想一下”，給自己緩衝時間完全沒問題。
R3 — PM Interview
這一輪 Product Sense 明顯更難，題目本身帶有約束條件和競爭環境背景（如何在強勢競品市場中找到差異化立足點並推進落地）。
解題過程： 整個 45 分鐘更像一場高質量的 Brainstorm，面試官的 Follow-up 幾乎沒有停過。
被 Push 的幾個關鍵節點：
“你的 Metric 怎麼防止被遊戲化（Gaming）？” 我提出要結合 Quality Engagement 指標（不只看 DAU，還要看是否完成了核心任務，以及停止推送後的自然回訪率）。
“競品推出了類似功能，你怎麼辦？” 我分三步回答：先驗證競品是否真正解決同一個問題 → 看我們的使用者是否流失及流失的是哪類使用者 → 根據資料決定是加速跟進還是堅持差異化。
“你說要做 A/B 測試，怎麼設計這個實驗？” 我詳細說明了實驗組 vs 對照組劃分、觀測週期、顯著性判斷標準，以及提前定義 guardrail metric 來避免 p-hacking。
面試官對我的回答整體比較滿意，尤其認可我在被持續追問下仍能保持邏輯清晰。
心得： 準備 Product Sense 不只是準備一個完整案例，更要練習“被打斷、被質疑、被持續 Push”的場景。找朋友做 Mock，專門練被追問的情況，會非常有幫助。
R4 — ENG Manager 面
這一輪還沒進行，但根據提前溝通和同類面經，我整理了以下備考方向：
- 技術理解類：Cloudflare 核心產品（CDN、Workers、Zero Trust、R2 等）的基本工作原理，能用清晰語言解釋給非技術人員聽。
- 跨團隊協作類：當 PM 需求和工程團隊判斷髮生衝突時，如何處理？
- 產品落地類：給定一個功能需求，如何和工程團隊評估技術可行性？如何處理 scope creep？
準備策略： CS 背景是加分項，但不能只說“我會寫程式碼”。ENG Manager 更想看到你能否站在工程師視角理解問題，同時保持 PM 的產品判斷力。
備考心得 & 資源分享
透過這次 Cloudflare PM Intern 的面試，我總結出幾點重要心得：
- PM 也可能需要 Coding 尤其是 Dev-Tool 公司，第一輪 Assignment 就要動手寫 Prototype。純商科背景的同學至少要練習用 no-code 工具或 AI 輔助快速搭建可演示的原型。
- Clarify 永遠是第一步 每輪面試開始時多問問題，不僅能降低答偏風險，還能給自己爭取組織思路的時間。
- Metric 要分層，不能只說一個數字 好的 Metric 體系應該覆蓋短期 Engagement、中期 Outcome、長期 Business Impact，並且要能解釋它們之間的關係和可能的矛盾。
- 被 Push 是常態，不是你答錯了 面試官的追問往往是在測試你能走多深。保持冷靜，給自己 10 秒緩衝再回答，比慌張給出一個爛答案好得多。
- 流程長不等於沒戲 中間 gap 再長也不要焦慮，繼續準備其他機會比一直重新整理郵箱更有用。
資源推薦： 如果你也在準備 Cloudflare PM Intern、Google APM、Microsoft PM 等產品實習，強烈建議不要只靠自己摸索。 我個人非常推薦 Programhelp。他們的學長有豐富的產品面試輔導經驗，尤其擅長幫助同學打磨 Product Sense、Assignment Prototype、Case 分析和 ENG Manager 面的技術溝通，能提供針對性的模擬面試和 VO實時輔助 。
有需要的同學可以去了解一下 Programhelp 的服務，學長會根據你的背景給出非常實戰的建議。
