溝通題評估你能否把技術想法清楚傳達、並依對象調整方式。在軟體開發裡，溝通往往是專案成敗的關鍵——面試官想確認你能與團隊、利害關係人與客戶有效合作。核心不是「你說了什麼」，而是「對方有沒有真的懂、有沒有繼續信任你」。
❓ Common Questions
- 說說你必須傳達壞消息的一次經驗。
- 說說你需要向某位不回覆的人取得資訊的一次經驗。
- 說說你必須應對一位極度不滿客戶的一次經驗。
- 說說你收到負面回饋的一次經驗。
- 說說你必須向非技術人員解釋複雜技術問題的一次經驗。
- 說說你必須向同事提供建設性回饋的一次經驗。
- 說說你必須向某人道歉的一次經驗。
🧠 Signals
TIP
溝通題的通則：用具體例子展現你如何把技術概念說給非技術人聽（比喻、視覺輔助、淺白語言）、主動傾聽並虛心接受回饋、依對象調整風格，並以誠實、同理、持續跟進收尾。B 書進一步提醒：好的溝通者能橫向／向上／向下溝通，善用書面＋口頭管道，並確保跨團隊與利害關係人對齊。
- 為不同對象調整溝通方式：技術 vs. 非技術、選對管道（email／會議／文件）。
- 主動傾聽、對回饋開放，而非防禦。
- 面對壞消息／不滿客戶時保持冷靜、同理，並持續跟進直到問題解決。
- 主動分享進度、促成有效討論，確保多團隊對齊。
⭐ STAR Example
向非技術 PM 解釋資料庫綱要變更（STARR 精簡骨架：10% 情境 / 60% 行動 / 30% 結果+收穫）
- 情境 (Situation)：正在做一個需修改資料庫綱要（database schema）的新功能，必須向沒有技術背景的專案經理說明這個變更與其影響。
- 任務 (Task)：讓 PM 理解眼前的技術問題，以及它對整體專案目標與時程的影響。
- 行動 (Actions)：先確認她對「資料庫綱要」的熟悉度；用「建築藍圖」的比喻淺白解釋；搭配圖表與流程圖等視覺輔助；針對她擔心的時程影響，主動聆聽顧慮並說明我能如何有彈性地兼顧變更與目標。
- 結果 (Results)：PM 理解了問題與影響，對變更更安心，也對我執行專案的能力更有信心。
- 收穫 (Learnings)：比喻、實例、視覺輔助能讓複雜技術對非技術人變得易懂；同理與傾聽同樣關鍵。
選材準則：對象是非技術／不滿的一方 × 你主動調整了溝通方式 × 結局是理解或信任被建立。
⚠️ Pitfalls
- 把對方不回覆歸咎於對方（「他就是不回我」），而非展現你的主動與升級。
- 說自己「放棄了」或「不再在意所需資訊」。
- 面對負面回饋時採取防禦姿態，而非傾聽與改進。
- 術語過載——對非技術聽眾堆砌名詞，反而證明你不會溝通。
- 把溝通講成單向廣播，缺少傾聽、確認理解與後續跟進。
🗣️ Discussion Log
（尚無紀錄。用 note 討論打磨你自己的溝通故事。）
🔑 Takeaways
- 溝通題的關鍵是「對方真的懂了、且更信任你」，而非你講得多完整。
- 展現依對象調整（比喻／視覺）、主動傾聽、誠實同理、持續跟進四件事。
- 別把不回覆歸咎對方、別防禦、別術語過載、別單向廣播。