https://yennj12.js.org/yennj12_blog_V4/tags/playbook/Recent content in Playbook on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 05 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part33-rkk-anatomy-zh/Fri, 05 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part33-rkk-anatomy-zh/這篇不是教你怎麼回答問題。 是告訴你，當你坐在白板前的時候，我這個面試官在評什麼、聽什麼， 以及為什麼那麼多技術底子很好的人，最後還是沒過。 一、RKK 是什麼輪 FDE 的面試流程通常有幾輪，RKK（Role-based Knowledge）是其中技術含量最高的一輪。 FDE 面試流程（通常）： Phone Screen（初篩） ↓ Hiring Manager Screening（了解背景和動機） ↓ RKK Round ← 本篇重點 （45-60 分鐘，1-2 位面試官） ↓ Googleyness / Leadership Round ↓ Hiring Committee Review RKK 考的是什麼？ 不是考你記了多少 API： ❌ 「LangGraph 的 add_node 怎麼用？」 ❌ 「Pinecone 的 query 函數的參數是什麼？」 是考你在客戶場景下的工程判斷力： ✅ 「這個客戶的需求，你會選什麼架構？為什麼不選另一個？」 ✅ 「如果系統出了這個問題，你怎麼診斷？你怎麼跟客戶說？」 ✅ 「他說他要 Agent，但你聽完他的需求，你覺得他真正需要的是什麼？」 二、45 分鐘的時間結構 每個 RKK 面試官的風格不同，但大多數 Google FDE RKK 都遵循這個節奏： 時間 階段 面試官在做什麼 ───────────────────────────────────────────────────────────── 0:00-0:05 暖場 自我介紹，說明面試結構 觀察：你的溝通方式，是不是聽進去了 0:05-0:20 主題題 提出設計問題（系統設計 or 故障排查 or 架構選型） 觀察：你有沒有先問問題，還是直接開始設計 觀察：你的架構是不是能對應需求，還是在炫技 0:20-0:40 深度追問 針對你的設計連續追問 3-5 個問題 觀察：你知不知道自己設計的邊界在哪裡 觀察：你被追問到不知道的地方，你怎麼處理 0:40-0:50 顧問情境題 一個商業場景問題（客戶反對、成本估算、競品比較） 觀察：你有沒有技術以外的思維 觀察：你說話的對象是面試官還是想像中的 CTO 0:50-0:55 你問我 你有什麼問題要問？ 觀察：你問的問題能不能顯示你真的思考過這個角色 注意：這個時間表是預估，面試官可以隨時調整。 如果你的設計答得很好，追問可能花 30 分鐘。 如果你一開始就答錯方向，面試官會提早切換到下一個問題。 三、五個評分維度 Google 的評分不是「對不對」，而是在五個維度上給 1-4 分。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part34-mock-scenarios-zh/Fri, 05 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part34-mock-scenarios-zh/這篇的用法： 每個情境，先蓋住「模範答案」，自己練習說 2-3 分鐘， 再對照模範答案看哪裡說得不夠深。 不要只用眼睛「讀」，要用嘴巴「說」——面試是口頭表達，不是閱讀測驗。 如何使用這個情境庫 每個情境的結構： 客戶場景 → 你收到的原始問題 隱藏的限制條件 → 面試官設計的陷阱，你要靠「問問題」發現它 追問鏈 → 面試官會按這個順序追問（難度遞增） 模範答案架構 → 拿到 3-4 分的回答應該包含什麼 最常見失分點 → 哪些地方最多人在這個情境答錯 情境一：金融科技客服 Agent（RAG + 合規限制） 客戶場景 客戶：一家有 200 萬用戶的數位銀行 背景：客服團隊有 50 人，每天處理 30,000 個 ticket 60% 是重複性的 FAQ（帳戶查詢、匯款規則、費率說明） 客戶希望用 AI 自動處理 FAQ，讓人工客服專注複雜問題 面試官說：「請設計這個 AI 客服系統。」 隱藏的限制條件（要靠問問題才能發現） 如果你問到「有沒有合規要求？」→ 面試官說： 「是的，這家銀行受金融監管，所有客戶資料不能離開台灣。」 如果你問到「不同客服問題的差異？」→ 面試官說： 「有一類問題是個人帳戶查詢（需要驗證身分）， 另一類是一般 FAQ（不需要身分驗證），兩類要分開處理。」 追問鏈（難度遞增） Q1：「你的 RBAC 設計是在哪個環節做過濾？為什麼？」 Q2：「客戶資料不能出台灣，你的 Vertex AI 呼叫怎麼設計？」 Q3：「AI 回答了一個帳戶問題，但答案是錯的。客戶打電話來投訴。 你的系統有什麼設計可以讓這個問題可以追溯？」 Q4：「這個系統的月成本大概是多少？客戶的 CFO 要看一個數字。」 Q5（顧問題）：「客戶的法遵長說，所有 AI 的回答都必須有人工審核才能發出。 你怎麼處理這個需求？」 模範答案架構 釐清需求（問兩個問題）： 「在開始設計前，我想確認兩件事： 第一，這個系統有合規要求嗎？資料能放在 GCP 嗎，還是有地理限制？ 第二，個人帳戶查詢和 FAQ 查詢，處理邏輯有沒有不同？」 → 拿到：台灣 region 限制 + 兩類問題的分流需求 架構設計： 「我的架構分三層： 第一層：API Gateway + 身分驗證 用 Google Cloud Identity 驗證用戶身分， 區分「已驗證用戶的帳戶查詢」和「匿名 FAQ 查詢」兩條路徑。 第二層：Router 帳戶查詢 → CRM Tool（只讀，帶用戶 token） FAQ 查詢 → RAG Pipeline（查知識庫） 兩者的 LLM 回答都會帶 citation（引用了哪個文件或哪個帳戶欄位） 第三層：Compliance Layer 所有 Vertex AI 呼叫限定 asia-east1（台灣節點） 用 VPC Service Controls 確保資料不出 Region 每個 AI 呼叫記錄到 Cloud Audit Logs」 追問回答： Q1（RBAC）： 「RBAC 在查詢向量 DB 時就過濾，不是查完再過濾。 Post-filter 可能讓 Top-K 全被過濾掉，LLM 拿到的 context 品質不穩定。 Pre-filter 讓向量搜尋只在用戶有權限的文件空間裡進行。」 Q3（可追溯）： 「我的設計是：每個 AI 回答都帶一個 response_id， response_id 對應到 Cloud Logging 的一筆記錄， 記錄了：哪個 query、查了哪些文件、LLM 的完整 prompt 和 response。 如果客戶投訴，工程師可以用 response_id 還原完整的推理過程。」 Q5（法遵長要人工審核）： 「這個需求讓系統的設計發生根本性的改變—— 它把『即時回答』變成了『非同步審核後回答』。 我的回應是：先問法遵長，審核的頻率和範圍是什麼？ 是 100% 審核還是抽查 5%？ 如果是抽查，可以設計一個 Shadow Mode—— AI 即時回答用戶，但所有回答存到 Review Queue， 法遵團隊異步審核，有問題時 flag 並觸發系統改善。 如果真的需要 100% 人工審核才發出， 我會和客戶討論這是否符合用戶體驗的預期—— 因為這意味著回應時間從秒級變成小時級。」 最常見失分點 ❌ 沒有問「資料合規要求」→ 設計出來的架構不能上線 ❌ RBAC 做 post-filter，被追問後說不清楚為什麼不對 ❌ 顧問題只說「這樣做技術上可行」，沒有說「我會和客戶討論 UX 代價」 情境二：保險公司理賠審核 Multi-Agent（ADK + 並行執行） 客戶場景 客戶：台灣前三大保險公司 背景：人工理賠審核需要查三個系統（核保資料庫、醫療記錄、詐欺偵測）， 每個 case 平均需要 3 小時，目標是降到 15 分鐘 客戶已在 GCP 上有所有三個系統的 API 面試官說：「請設計這個 AI 理賠審核系統，並告訴我你的 ADK 架構。」 隱藏的限制條件 如果你問「高風險或不確定的 case 怎麼處理？」→ 面試官說： 「理賠金額超過 500 萬的 case，最終決定必須有人工審核。」 如果你問「三個系統的延遲分別是多少？」→ 面試官說： 「核保 DB 200ms，醫療記錄 800ms，詐欺偵測 1.