這篇不是教你怎麼回答問題。
是告訴你，當你坐在白板前的時候，我這個面試官在評什麼、聽什麼，
以及為什麼那麼多技術底子很好的人，最後還是沒過。
一、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 分。
維度一：技術深度（Technical Depth）
在測什麼：
你對 AI 系統的每個元件，能不能說出它的 trade-off？
被追問第二層、第三層，你還有東西說嗎？
1 分（不及格）：
「我會用 RAG。」
說得出來是什麼，說不出來為什麼，說不出來邊界在哪裡。
2 分（基本水準）：
「我會用 RAG，因為資料需要頻繁更新。Chunking 大概 512 tokens。」
有理由，但淺。
3 分（符合期待）：
「我選 RAG 是因為客戶的文件每週更新，Fine-tuning 成本不划算。
Chunking 的大小我會根據文件類型決定：
FAQ 用小 chunk 保持精準，長報告用語意切分保留上下文。
評估用 RAGAS 的 Context Recall 作為基線指標。」
4 分（超出期待）：
以上，加上主動提到邊界：
「這個設計假設客戶資料在 500MB 以內。
如果超過 10GB，我需要重新評估 Vector Search 的選型，
因為此時 Vertex AI Vector Search 的成本結構比 pgvector 更划算。」
維度二：系統思維（Systems Thinking）
在測什麼：
你看到的是整個系統，還是只有你熟悉的那個元件？
你會自動考慮 Scale、Failure、Cost、Security 嗎？
失敗的樣子：
設計了一個 Agent，完全沒有提 Rate Limiting、Token Budget、Logging。
面試官問「如果系統流量突然增加 10 倍怎麼辦？」，你開始慌了。
成功的樣子：
設計時主動提到：
「這個架構在正常流量下沒問題。
如果客戶有高峰期（例如：月結日前的查詢量可能是平時的 5 倍），
Embedding 服務需要 min-instance 設定，
避免 cold start 拉高 P95 延遲。」
維度三：Trade-off 意識（Trade-off Awareness）
在測什麼：
你能不能說出「我選了 A，代價是 B，在這個場景下可以接受」？
最常見的問題：
候選人說「這個方案最好」而不是「在這個條件下這個方案更合適」。
面試官一追問就破功。
評分差異：
2 分：「我用 ReAct 架構。」（沒有比較）
3 分：「我用 ReAct，因為任務需要動態決策。
Planner-Executor 也可以，但這個場景步驟不確定，
Planner 容易規劃錯。」（有比較，有理由）
4 分：以上，加上：
「如果這個系統之後要支援審計要求，
我會重新考慮 Planner-Executor——
它的執行計畫是顯式的，更容易生成合規報告。
現在先用 ReAct 快速驗證，留下這個遷移路徑。」
（有條件，有未來路徑）
維度四：顧問溝通（Consultant Communication）
在測什麼：
你能不能在技術答案結尾，加一句讓客戶聽得懂的話？
你能不能在不確定的情況下，仍然表現出可信賴的判斷？
失敗的樣子：
面試官問：「客戶的 CTO 說這個方案太複雜，他不信任 AI。」
候選人說：「那就解釋給他聽啊，說 Transformer 的原理...」
成功的樣子：
「CTO 說太複雜，代表他的顧慮不是技術，是風險。
我的回應會是：先做一個 3 週的 POC，
評估指標由你們的工程師決定，我來跑。
如果跑完數字不讓你滿意，我們不繼續。
把決定權還給他，降低他的感知風險。」
維度五：Google Cloud 產品知識（GCP Product Fit）
在測什麼：
當你設計一個 GCP 上的系統，你能不能用 Google 的工具說話？
你有沒有在 GCP 生態裡設計過東西？
失敗的樣子：
所有答案都是 LangGraph + Pinecone + AWS Lambda。
面試官問「Vertex AI 的選項你有考慮嗎？」
候選人說「應該可以用吧」。
成功的樣子：
「這個場景我優先考慮 ADK + Vertex AI Agent Engine，
因為客戶在 GCP，原生整合省掉很多配置。
如果 Retrieval 需要更精細的控制，
我會評估 Vertex AI Search 和自建 RAG 的 recall@k 差距，
再決定是否需要自建 Pipeline。」
四、四個面試階段的細節
階段一：釐清需求（0:05 - 0:10）
面試官說：「請你設計一個 AI 客服系統。」
你要做的第一件事：問問題，不是畫圖。
必問的三個方向：
業務規模：「日均 query 量大概多少？高峰期是什麼時候？」
安全限制：「客戶資料有合規要求嗎？資料能放 GCP 嗎？」
成功標準：「客戶定義的成功是什麼？回應速度？準確率？成本降低？」
面試官在聽什麼：
你有沒有問到「影響架構選擇的問題」，而不是問一堆無關緊要的細節。
不需要問 10 個問題，問 2-3 個能影響設計方向的就夠了。
常見錯誤：
完全不問，直接開始設計 → 扣分
問太多細節（「他們用的是什麼資料庫？」）→ 浪費時間
問了但不等答案就繼續設計 → 更糟
階段二：高層架構（0:10 - 0:20）
你要做的事：
1. 畫出 2-3 層的架構圖（不需要完整，但要清楚）
2. 說清楚每個元件的職責（不只是名字）
3. 主動說出你的 trade-off
白板上的內容：
✅ 有「用戶 → API Gateway → Agent → Tool → LLM → Response」的流程
✅ 每個方框有 1-2 句職責說明
✅ 你說了「我選 X 因為 Y」至少一次
面試官在等什麼：
等你說「這個設計假設了 Z，如果 Z 不成立我會怎麼調整」
這句話是把你從 3 分拉到 4 分的關鍵。
階段三：深度追問（0:20 - 0:40）
這個階段的節奏：
面試官選你設計裡的一個元件，往下追 2-3 層。
範例追問鏈：
「你說用 Vector DB，你選哪個？」
↓
「為什麼不用 pgvector？」
↓
「pgvector 在什麼情況下比 Vertex AI Vector Search 更好？」
↓
「如果客戶的資料後來增長到 1 億筆向量，你的選擇會改變嗎？」
處理「不知道」的正確方式：
❌ 沉默，或亂說
✅ 「我沒有用過 pgvector 做到那個規模，
但根據我對 HNSW 索引的理解，
超過一定規模後記憶體佔用會是瓶頸。
我會查文件確認 Vertex AI Vector Search 的 SLA，
再給客戶一個有依據的建議。」
說出你的推理過程，即使結論是「我需要再確認」，
面試官看的是你的思考方式，不只是答案。
階段四：顧問情境題（0:40 - 0:50）
常見題型：
「客戶說這個方案太貴，怎麼辦？」
「客戶 CTO 說他們現在用 OpenAI，為什麼要換 Google？」
「系統上線後 P95 延遲突然升高，你怎麼跟客戶說？」
這個階段的評分邏輯：
面試官在測你有沒有「技術 + 業務」的雙軌思維。
純技術答案 → 2 分
技術 + 客戶語言 → 3 分
技術 + 客戶語言 + 具體的下一步行動 → 4 分
範例：
問：「客戶說這個方案太貴。」
2 分答案：「可以用 Flash 模型降低成本。」
4 分答案：「先確認他說的『太貴』是什麼意思——
是跟預算比，還是跟他期待的成本比？
如果是前者，我先拿出 TCO 試算，
把 AI 節省的人力成本算進去，
通常 ROI 在 3 個月內就回收。
如果他的 use case 對品質要求沒那麼高，
我會建議先試 Gemini Flash，
成本可以降到原來的 20%，
同時準備一個 A/B test 的計畫，
讓數字說明品質差距是不是可以接受的。」
五、「雇用」和「強力雇用」的實際差距
雇用（Hire）：
├── 技術知識紮實，能回答第二層問題
├── 有 trade-off 意識，不說「這個方案最好」
├── 能用比較清楚的語言解釋架構
└── 顧問情境題答得中規中矩
強力雇用（Strong Hire）：
├── 以上全部，加上：
├── 主動設定邊界和假設（「我的設計假設 X，如果 X 改變...」）
├── 在被追問到邊緣的地方，仍然有系統性的推理，不是亂猜
├── 顧問題的答案讓面試官覺得「這個人真的在跟客戶對話，不是在面試」
└── 問我問題的時候，問的是「這個角色真正困難的地方是什麼」，
而不是「這個職位有什麼 benefit」
六、七個最常見的失敗模式
失敗模式 1：直接開始設計，不問問題
為什麼致命：
面試官設計的問題有「隱藏的 constraint」（例如：資料不能出 VPC）。
你如果不問就設計，設計出來的東西需要大幅修改，
而且暴露了你沒有釐清需求的習慣——這在實際客戶場景是很嚴重的問題。
失敗模式 2：說了架構但沒有說為什麼
我最常聽到的答案：「我會用 LangGraph 的 StateGraph 來設計這個 Agent。」
然後停住了。
我想聽的是：「為什麼是 LangGraph 而不是 ADK？在這個客戶場景下，
哪個特性讓你選了它？」
失敗模式 3：被追問到邊緣就慌了
被追問到「不知道」的地方是正常的——設計空間是無限的。
失分的不是「不知道」，是「不知道就沉默」或「亂說一個答案」。
正確做法：說出你的推理過程，即使結論是「我需要驗證」。
失敗模式 4：技術答案沒有收尾
面試官問了一個顧問情境題，你給了一個很好的技術分析，
然後說：「所以這個架構是最好的。」
沒有說：「所以我會建議客戶先做一個 2 週的 POC，
評估指標由他們定，這樣他有控制感，也有數據支撐決策。」
技術分析要有商業落地的 last mile。
失敗模式 5：只說自己熟悉的工具
整個面試只提 LangChain 和 OpenAI。
沒有提任何 GCP 產品。
面試官問「Vertex AI 的選項你有考慮嗎？」，
你說「我沒用過，但應該差不多吧。」
FDE 是 Google 的角色，你必須能說出 Google 工具的 fit。
失敗模式 6：用技術語言回答顧問問題
面試官問：「客戶的 CTO 說他不信任 AI 的準確率，怎麼辦？」
你說：「RAG 的 Faithfulness 可以用 RAGAS 評估，
通常 Fine-tuning 後的模型 Faithfulness 可以達到 0.85 以上...」
CTO 聽不懂 Faithfulness。
他聽得懂的是：「我們可以設計一個評估機制，
讓你在上線前看到系統對你的 100 個測試問題的回答，
你自己判斷品質是否可接受。」
失敗模式 7：問問題環節問了錯的問題
❌ 「這個職位有沒有 remote 選項？」
❌ 「薪資範圍是多少？」
❌ （什麼都不問）
✅ 「你見過這個角色做得最好的人，他們和一般人最大的差距是什麼？」
✅ 「FDE 在幫客戶設計系統和幫 Google 推廣產品之間，
你怎麼處理兩者的張力？」
問問題是你最後一次展示思考深度的機會。
七、面試前一天的準備清單
技術面：
□ 你能用 3 分鐘講清楚 RAG vs Fine-tuning 的選擇框架嗎？
□ 你能說出 ReAct vs Planner-Executor 的判斷條件嗎？
□ 你知道 ADK 的四種 Agent 類型，以及各自的適用場景嗎？
□ 你能說出 Vertex AI Agent Builder vs DIY RAG 的 go/no-go 條件嗎？
□ 你有一個 context budget 的感覺（1K / 10K / 100K tokens 各是什麼場景）嗎？
顧問面：
□ 你有一個「競品比較」的對話框架嗎？（SCQA 結構）
□ 你有一個「POC Scoping」的流程嗎？（45 分鐘 Discovery）
□ 你能用業務語言說清楚 TCO 和 ROI 嗎？
心態面：
□ 遇到「不知道」，你準備好怎麼說了嗎？
□ 你準備好在設計時主動說「我的假設是 X」了嗎？
□ 你有 2 個好問題要問面試官了嗎？
不需要準備的事：
□ 不需要背 API 的函數名稱和參數
□ 不需要背具體的 benchmark 數字（說「大約」就夠了）
□ 不需要設計一個完美的架構——有清楚的 trade-off 比「完美」更重要
RKK 面試測的是一件事：
你能不能在不確定的情況下，做出有依據的判斷，並且用讓客戶聽懂的語言說清楚。
知識是基礎，但判斷力才是 FDE 的核心。
