改善你的溝通#

行為面試的問題只是一個框架，你要在上面搭建自己的內容。回答問題本身不是目的，真正的目的是為你的候選資格提出有說服力的論證，同時不要顯得像個推銷員。

本章是給已掌握基本功、想要更主動掌控面試的人：一組進階技法、心智模型與戰術。如果你已熟悉基本的故事結構、也理解「訊號」是什麼，這些概念能幫你從被動反應走向有目的的主導。

黃金法則：引導面試官#

你和面試官共享同一個時間難題：你有 45 分鐘要傳達一段自己再熟悉不過的職涯裡最相關的部分；他們有 45 分鐘要萃取足夠訊號，做出有信心的錄用決定。

多數候選人把這當成單向道：面試官問、你答。但這等於把你的成敗完全交到對方手上。萬一他們的問題沒有引向你最好的例子呢？萬一他們把時間花在較不相關的領域呢？

把面試視為「共同探索」。面試官主導對話沒錯，但你也有主動權。以下技法能幫你把他們引導到對的地方。

放心重導面試官#

有時被問到的問題並非通往你最強訊號的最佳路徑，這時你可以重導。

• 面試官問:「你在這個專案裡有遇到什麼衝突嗎?」
• 較佳回應:「這個專案裡有些小摩擦，但更有意思的衝突其實來自另一個專案，我可以談那個嗎?」

不要濫用重導。一場面試裡策略性地重導一到兩次很好；不斷重導會顯得閃躲。只在你確實有更好的例子、能為對方正在評估的能力提供更豐富訊號時使用。

呈現最有說服力的行動：商人與礦工#

呈現經驗時，你可以當商人，也可以當礦工。兩者手上都有寶石，差別在展示方式。

• 商人把寶石擺在漂亮的陳列座上、完美燈光下、易於觀看的玻璃櫃裡。一切井然有序、隨手可得。客人想看什麼，商人立刻知道最出色的那幾件在哪，直接帶他過去。
• 礦工同樣有珍貴寶石，但它們還埋在山壁裡。客人得自己挖、敲碎岩石，也許挖得到好貨，也許挖不到。

要當商人:

• 熟知自己最好的素材。每個故事，事前就找出最有說服力的行動與轉折點，別讓面試官自己去挖。
• 強調你的能動性。用「我決定……」「我提議……」而不是「團隊做了……」「剛好發生了……」。你的行動才是寶石，要顯眼地展示。
• 讓你的價值一目了然。別把最亮眼的工作埋在冗長故事的中段，要放在面試官不可能錯過的位置。

告訴面試官「菜色」有哪些：專案壁畫#

想像你要看懂牆上一幅細膩的壁畫，卻只能透過一根吸管的孔洞去看：一次只見到零碎片段，不確定該看哪裡，可能把時間花在不重要的角落，錯過中央的重頭戲。

這正是面試官透過口頭溝通(本質上是低頻寬的)去理解你複雜專案時的處境。要引導他們的視線看向對的地方:

• 一開始就給出結構。用類似「目錄」的技巧:「這個專案有三個階段，最難的是第三階段，那時我們必須……」——你等於給了他們一張地圖。
• 知道什麼最重要。事前就辨識出每個故事中，對這個職位最富訊號的部分，講的時候把他們往那裡帶。
• 在高訊號時刻放大。別把故事每一段都當成同等重要，把時間花在最能展現你能力的決策、挑戰與行動上。

依面試官風格調整#

依我的經驗，面試官大致分兩種。你應該能在前幾分鐘判斷出遇到哪一種，並隨之調整。

對話型（The Conversationalist）#

他們問得少而廣，讓你盡量講。他們仔細聆聽、提出有深度的追問，試圖從一個故事萃取多個訊號領域。他們營造舒適氛圍，給你空間分享思路，整場更像同事間的討論而非審訊。對他們而言，一個豐富的故事勝過五個表面的故事。

如何在這類面試官面前成功:

• 無情地管理你的時間。對話型面試官最大的陷阱是他們會放任你講太多。即使你講錯故事、或在重複已建立過的訊號，他們也不會打斷你。
• 留意「這個訊號已經夠了」的線索。如果他們停止做筆記、或不再針對某面向追問，代表該訊號多半已建立，該往下走了。
• 把最重要的故事往前放。別把最好的例子留到第五題——你可能根本走不到那裡。如果他們早早問領導力，就拿出你最強的領導力故事。

檢核型（The Examiner）#

他們快速連發問題、追求簡短回答，常打斷你以進入下一題，可能照著檢核表或評分量表逐項勾選。節奏明快，甚至有點公事公辦。這對他們有效，因為他們需要在緊湊時間內評估大量訊號領域，而且他們學到放任候選人漫談只是浪費時間。他們寧可聽十個情境各講 30 秒，也不要一個專案講十分鐘。他們要的是證據的「廣度」，不是深度。

如何在這類面試官面前成功:

• 保持冷靜。被打斷不代表你失敗了，反而代表他們已從那部分得到所需。別慌張，也別覺得自己做錯了，那只是他們的風格。
• 立刻把價值往前放。對話型面試官容許你慢慢鋪陳，檢核型則沒這奢侈。開門見山講標題:
  • 較差:「這要回到 2022 年，我在 TechCorp 平台團隊，我們有個專案剛起步，需求不太清楚……」
  • 較佳:「我主導了一次沒有明確需求或成功指標的平台遷移。以下是我如何建立結構:首先，我……」
• 壓縮鋪陳。更快進到你的行動。
• 放心把話題重導回來。若他們在你講到關鍵行動或結果前就打斷，把它拉回來:「在往下走之前——那個專案有個關鍵是〔重要行動/決策〕，它後來成了我們處理類似情況的範本。」
• 積極運用選單技巧。當他們問得很廣，給他們選項，讓他們拿到正好想評估的東西。

拿捏細節的多寡#

溝通有很大一部分是在決定「哪些資訊該放、哪些該省」。承接第一部關於細節的討論，這裡提供幾個判斷細節取捨與擺放位置的框架。

細節到底能達成什麼#

除了提供足夠脈絡以理解你的行動、並建立你的可信度之外，細節還能:

• 創造追問的機會。細節是深入挖掘的天然入口，能讓你把對話引向你最強的領域。當你說「我重構了我們的認證流程改用 JWT token」，你就開了一個口——對安全性有興趣的面試官可能追問 token 過期與刷新策略，關注系統設計的可能問無狀態與有狀態的取捨。這在你對故事某些部分較沒把握時特別有用:多強調你最擅長的細節，就能讓那些成為最自然的追問目標。
• 讓故事令人難忘。生動或有趣的細節能讓故事留在面試官腦中。比起「完成了一項任務」，你希望被記成「一個令人印象深刻的人」。例如:「當我在架構評審會上首次提出遷移計畫時，那位在公司待了十二年的首席工程師說這是他看過最完整的技術設計文件。那句回饋對我意義重大，也讓我意識到自己設下了一個必須維持的新標準。」

處理技術細節#

拿捏技術深度是最難的事情之一。太淺，你顯得不夠技術;太深，你會失去聽眾、或顯得無法清楚溝通。

• 依角色調整深度。技術深度應對應你這個角色的影響力關鍵。基礎架構工程師通常要深入系統層級的考量，而產品工程師可能更聚焦在面向使用者的影響與取捨。
• 每次回應只「深潛」一次。若你把技術細節集中在回應的某一段，就在「建立可信度」與「額外細節帶來的時間與混淆」之間取得了平衡。
• 把複雜的東西講簡單。對資深角色而言，能把複雜主題向聰明人講清楚，是卓越溝通的標誌之一。如果你無法把技術工作向一位有紮實技術背景的人解釋清楚，很可能是你自己還沒真正理解。

假設聽眾不是專家，下面這種說法過於複雜，建立了技術可信度，卻沒展現強溝通力:

• 較差:「我實作了一套基於 CRDT 的衝突解決策略，用向量時鐘機制搭配因果排序，確保各副本最終一致，同時為合併函式維持半格特性。」

改成這樣，適度使用比喻:

• 較佳:「我實作了一套衝突解決系統，讓多位使用者能同時編輯又不遺失任何人的成果。想像成 Google Docs——大家可以一起打字，系統會聰明地合併變更。我用了 CRDT，一種專為這種『最終一致性』問題設計的資料結構。關鍵洞見是合併操作必須符合交換律——也就是順序不影響結果——所以我把資料模型設計成具備這個數學特性。」

如何處理術語與縮寫#

每個領域都有術語和縮寫，你得判斷哪些需要解釋、哪些不用。這比較是藝術而非科學。以下是作者個人(自認是資訊充分的技術人)的校準範例:

• 不需解釋:
  • AWS、Docker、Kubernetes、SQL、REST API、微服務（工程角色）
  • A/B 測試、轉換率（產品/成長角色）
  • Figma、design system（設計角色）
• 簡短解釋有幫助:
  • AWS IoT Greengrass:把 AWS 服務延伸到邊緣裝置
  • CRDT:conflict-free replicated data types，為分散式系統設計的資料結構
  • 最終一致性（Eventual consistency）:所有伺服器最終會收斂到相同狀態，但可能暫時顯示不同值
• 需要較長解釋:
  • 你領域中高度專門的協定或工具
  • 公司內部系統或框架
  • 業界少用的學術或研究概念

這條界線會隨時間移動。例如五年前「向量資料庫」對 ML 圈外人多半需要解釋，如今大概已是常識。

給「一口氣」就能講完的解釋#

當你確實需要解釋術語時，控制在一口氣的長度，像個從屬子句，並強調對聽者的重點:

• 較佳:「我用 LaunchDarkly 實作我們的 feature flag——這是一個管理功能開關的第三方服務——讓我們能部署到正式環境，同時控制推出的比例。」

「一個管理功能開關的第三方服務」只花三秒，提供剛好的脈絡，然後你立刻回到重點:這件事為何重要。

再看一個反例:

• 較差:「我實作了一套 canary 部署策略，運用我們的 Spinnaker CD pipeline，為 pod 設定 K8s HPA，透過 service mesh 的 sidecar proxy 整合 Prometheus 指標，依據從 SLI 門檻算出的 SLO burn rate 觸發自動回滾。」

即使對基礎架構工程師，這也太密集——你在丟工具名稱，卻沒解釋真正的問題與解法。較好的版本:

• 較佳:「我實作了一套 canary 部署策略——把變更逐步推給小比例的使用者——沿用我們既有的部署管線。我設定它自動監控錯誤率與延遲，若新版本相較舊版本出現問題就自動回滾。這讓我們就算在上班時段也能有信心地部署，因為任何問題最多只影響 5% 的使用者、且只持續幾分鐘。」

這個版本解釋了概念（canary 部署）、簡單描述了監控（錯誤率與延遲）、聚焦在結果（安全部署）。工具被淡化，方法與影響被凸顯。

善用面試官既有的經驗#

科技職場之間的相似遠多於相異，全世界的團隊都遇到同類的技術、產品、人的挑戰。為了節省時間、提升「每分鐘訊號量」，你可以也應該善用這一點，避免對面試官「技術說教」一件像技術債這樣常見的事:

• 較差:「我當時帶的工程團隊累積了不少為求快而走的捷徑，之後需要修。工程師說要先花時間處理這些技術債才能做新功能。技術債是指你為求快而建、又沒時間回頭清理程式碼，久了就越來越難維護……」
• 較佳:「工程團隊因為累積的技術債，對我們 Q3 的路線圖有意見。與其爭論優先序……」

辨識這些常見模式，能讓你跳過鋪陳，直接切入你的做法有何獨到之處。不過，當你的情況有不尋常的限制、當業界常規不適用（如高度監管的環境）、或問題出現的方式很不典型時，仍應提供脈絡。

反過來，下面這些概念一般人並不理解，除非確知對方是該領域專家，否則務必解釋:

• 領域專屬法規與合規:HIPAA、SOC 2、FDA 核准流程、PCI 的細節
• 產業專屬術語:廣告科技（DSP、程式化競價）、金融科技（ACH、對帳）、醫療（HL7、FHIR）、硬體（良率、晶圓廠產能）
• 公司專屬工具與流程:內部代號、專有框架、自建基礎架構、非標準職稱、獨特組織結構
• 不尋常的商業模式:市集動態、特殊的企業銷售週期、政府採購、非營利限制、小眾變現方式
• 高度專門的技術領域:特定 ML 模型架構、區塊鏈機制、嵌入式系統限制
• 地區或市場專屬脈絡:國家專屬的支付方式、區域監管環境、影響產品決策的文化行為

依問題類型調整細節#

要依「面試官在對話當下需要聽到什麼」來調整回應。做得好，你就能避免過度解釋、保持對話有趣、並確保面試官拿到評估你的正確訊號。關鍵是跟隨面試官的引導，辨識他們在問哪一類問題。

樹幹、樹枝、樹葉問題#

把面試問題想成一棵樹的各部分:

• 樹幹問題（Trunk）:引入新主題，為一連串追問奠定基礎。
• 樹枝問題（Branch）:深入你答案的某個具體面向。
• 樹葉問題（Leaf）:釐清枝微末節，或索取非常特定的資訊。

知道自己在樹的哪個位置，就能相應調整回應、給出剛好的細節量。一個典型序列:

• 樹幹:「說說你最自豪的專案?」〔你用一個 CARL 故事回應，講你如何在討論平台上打造巢狀留言功能〕
• 樹枝:「這個專案裡有遇到什麼有趣的衝突嗎?」〔你講一個靠小規模使用者資料化解的衝突。面試官擔心你憑有限資料就草率決定，於是追問……〕
• 樹葉:「所以你就憑這一小群使用者做了決定?這群有多大?」〔你以額外的 beta 測試回答〕

面試官每問一層就往下鑽得更細，也期待你的回答越來越精煉。

• 樹幹問題 → 用 CARL 建構回應
• 樹枝問題 → 先直接回答，需要時再補一個結構化故事
• 樹葉問題 → 給簡潔、直接的答案

回到前例看實際運作。面對樹枝問題「這個專案裡有遇到什麼有趣的衝突嗎?」較佳的回應會先一句話直接命中——「有，我和 PM 就是否允許任意層級的巢狀留言起了衝突，最後靠蒐集 UX 回饋解決」——先答問題、並凸顯你採取的行動（蒐集資料），再接著把 CARL 故事講完。你之所以對這個樹枝問題用完整 CARL，是因為「衝突化解」本身就是核心訊號領域。

對樹葉問題，面試官只要直接回應。面對「所以你就憑這一小群使用者做決定?這群多大?」較佳回應是:「很小，大概 5 個人，但他們過去判斷都準，而且我們在 Beta 階段也跑了一份問卷、其中就包含留言深度這題。」——你察覺面試官擔心你會倉促決策，於是補上你做過的額外驗證，但很快帶過，不需要 CARL 故事。

在面試的每個階段，目標都是用最少的贅語給面試官正確的訊號。問得廣，就把答案結構清楚;問得細，就給他們正好需要的，不多不少。

該講多快？#

說話速度常被問到——候選人想知道自己是否太快或太慢，面試官也常抱怨其中一種。這雖屬戰術層面，但確實重要:講得快能傳達聰明與自信，講得太慢則會削弱你的可信度。

原書附有 QR code 影片示範作者認為的最慢與最快語速，此處以文字帶過。這個評估假設是母語人士之間的對話;對以第二語言面試的候選人，面試官通常會有所體諒。