解決問題不只是「找出技術難題的解法」，更關乎辨識出該解決的正確問題、把它拆成可處理的小塊，並把思路清楚傳達給人。這道題橫跨 Ambiguity（拆解模糊）、Perseverance（受挫仍推進）與 Scope（影響力）多個訊號，是每場 loop 的高頻題。
❓ Common Questions
- 你遇過最難的 bug 是什麼？怎麼修好的？
- 說說你想出創意解法／用簡單解法處理複雜問題的一次。
- 你目前專案中最有挑戰的部分是什麼？
- 說說你開發出新方法或流程、提升任務效率的一次。
- 說說你在工作中遇到重大障礙的一次。
- 說說你在資源或支援不足下完成專案的一次。
🧠 Signals
TIP
這類題的黃金原則：聚焦你的過程，而非只講最終結果。說明你如何切入、用哪些步驟分析與拆解、途中撞到哪些障礙，最後點出心得。
- 拆解模糊（Ambiguity）：把大而不清的問題拆成具體可行的小塊，做出合理假設。
- 根因分析：不停在表象，透過測試、日誌、效能指標追到 root cause（如記憶體洩漏、資料庫瓶頸）。
- 協作：與技術／非技術利害關係人溝通——職場的解決問題本質是協作，不是單打獨鬥。
- 毅力（Perseverance）：第一個方案失敗就換多種做法，根因不明時仍堅持追查。
- 心得：說出未來面對類似問題會怎麼做，展現成長。
⭐ STAR Example
偶發當機的根因追查（CARL 三幕劇：10% 情境 / 60% 行動 / 30% 結果+收穫）
- 情境 (Context)：負責的新功能在特定情況下會讓 App 當機，是讓使用者完全無法使用的重大問題。
- 行動 (Actions)：先通盤檢視程式碼無果 → 跑一系列測試蒐集資訊，發現只在多人同時使用時當機 → 翻查日誌、分析效能指標，鎖定 root cause 是記憶體洩漏 → 重構修掉洩漏並反覆測試驗證。
- 結果 (Results)：即使高負載下 App 也保持穩定，功能運作無虞。
- 收穫 (Learnings)：體會到縝密而有條理的除錯之重要；根因不明時仍要堅持，並善用效能指標與日誌當線索。
選材準則：問題有真實賭注 × 你主導追查 × 過程展現拆解與根因思維。
⚠️ Pitfalls
- 只講最終結果，跳過「你如何一步步分析與拆解」的過程。
- 抱怨或指責他人（隊友、其他團隊、前人程式碼）。
- 談「資源不足」時把責任歸咎他人，而非展現排序、求援與隨機應變。
- 過度著墨負面細節，讓故事語氣消沉。
- 把「創意解法」講成炫技，卻沒交代如何降低引入新技術的風險。
🗣️ Discussion Log
（尚無紀錄。用 note 討論打磨你自己的解決問題故事。）
🔑 Takeaways
- 過程 > 結果：清楚展示切入、拆解、追根因的思路。
- 一定要有協作與溝通，並以「學到什麼」收尾。
- 備一個「根因分析」故事與一個「資源／障礙下仍交付」故事，涵蓋 Ambiguity 與 Perseverance。