ExplainThis 全端開發雙週報 #39

技術面試中，溝通思考過程是不可或缺

嗨～ 歡迎閱讀 ExplainThis 全端開發雙週報。這期的主題是《技術面試中，溝通思考過程是不可或缺》，將會引用先前 Google 資深主任工程師 Addy Osmani 的經驗分享，來談溝通為什麼重要；同時，我們將分享有用的架構，讓大家在面試過程中，能更輕易做好溝通。

在開始前分享一個小更新，近期我們更新了 E+ 的《海外求職指南》指南，新增了更多豐富的內容。如果對於找海外與外商工作感興趣的讀者，歡迎加入 E+ 閱讀 (連結)

技術面試中，溝通思考過程是不可或缺

先前 Google 資深主任工程師 Addy Osmani 曾發文分享 (連結)，他在 Google 十多年的過程中，協助面試無數優秀的候選人，而其中能夠脫穎而出的，不只是有問題解決能力，還要有「展示」問題解決能力的能力。

沒錯，有能力本身是不夠的，你要展示你的能力，不然面試官無從判斷你是否有能力。而要展示自己有問題解決能力，除了正確解出演算法外，需要在過程中有良好溝通。

Addy Osmani 談到，在過程中你需要溝通你的思路，意思是你不能只是寫程式碼，還需要進一步解釋程式碼，以及解釋這樣寫的理由。具體來說，你要將思考過程說出來，逐步解釋你的思考流程，以及解釋你如何解決問題。

他同時推薦，最能夠有效溝通思考流程的方式，是先拆解問題，藉此展示你有能力把問題拆解後逐一擊破。拆解完問題，準備提出解決方法時，記得考慮不同的方案，並解釋這些方案的優缺點、取捨點。如果你選了其中某個來實作，也要解釋為什麼要選那一個，其優點在哪。

當然，如果在一開始沒有想到最佳解，也不用急著。可以先提出一個解法，再討論如何優化。切記要保持靈活，在討論優化的過程中，可能會被問追問的問題，記得適時根據不同的需求來調整自己的解法。

如果在過程中卡住了，不要慌張，因為這是很常見的，可以跟面試官要一點時間來整理思路。同時，也可以跟面試官提你目前的方法和遇到困難的原因，一般來說面試官都會給予一些提示，讓你能往下解出問題。當收到提示時，要樂於接受面試官的回饋，因為這能展示你是個能接受意見，並依此來調整與學習的人。

最後，Addy Osmani 提醒，不要急著跳下去寫程式碼，先仔細理解問題、思考可能的解決方法，再開始寫程式。如果你遇到不確定的部分，不要忘了問釐清問題。要記住，雖然技術能力很重要，但在實際工作上，你的思考能力、溝通和協作能力，也是同樣重要。當你能夠有效展示你的問題解決能力，就能更有效順利通過面試。

上面這些讀完，你可能會覺得很有道理，但是該如何有效具體做好溝通?

關於這個問題，我們非常推薦在整個面試的過程中，可以透過一些框架句型，作為銜接讓自己能夠有效溝通自己的思考。

舉例來說，在一場白板題面試最開始，面試官會開場講題目。相信多數人已經知道，這時候不該直接跳下去解題，一定要問釐清問題。以下我們將說明如何透過框架句型，來確保自己有釐清好問題

首先，重複面試官講的問題，確認你理解對，這時可以用的句型如下
If I understand correctly, the main challenge of the problem lies in [這邊要說出你對題目的理解], right?

在釐清完問題後，要進一步確認輸入 (input)、輸出 (output)，這時可以用
I'd like to ensure I'm on the right track with the input and output format. Could you please confirm if this example matches your expectations? [這邊要說你對輸入與輸出格式的理解，然後搭配幾個案例]

要展示自己思考縝密，推薦可以確認限制，這時可以用
Before I start coding, I’d like to go over the constraints one more time. Specifically, are there any limits I should keep in mind?

如果有確認極端案例 (edge caases) 會更加分，可以用
Based on my understanding, [這邊說出你想到的極端案例] seem like potential edge cases. Would you agree?

如果想特別釐清某個點，可以用
I want to make sure I've got this right. When you say the algorithm should [這邊說某個面試官提到的點], does that mean our primary focus is on [這邊說你對該點的理解] over other factors?

上面這些框架句型，就像是你在溝通時的鷹架，有了這些句型，搭配臨場對於題目的理解，就能夠非常有效與面試官溝通。如果你對完整面試時，可以用哪些框架句型感興趣，我們在 E+ 有更詳細的版本，從釐清問題、提出解法、撰寫程式，到卡住時的互動，每個階段都有好用的銜接句。有興趣的讀者，歡迎加入 E+ 後閱讀 (連結)。

[本期推薦]

• 最近 Netlify 舉辦了 Netlify Compose Conf，邀請到許多有名的講者，好幾個演講都很精彩 (連結)，另外，Next.js 近期除了推出 Next 15，也舉辦了 Next Conf (連結)

• 除了 Next Conf，Vercel 最近分享了他們遷移到微前端架構的經驗 (連結)，如果對微前端架構不熟，可以參考先前我們寫過的介紹 (連結)

• 寫自動化軟體測試的核心目的，是要給軟體產品團隊信心，從這個角度來看，E2E 測試因為在模擬使用者的行為，理想上應該最接近使用者使用軟體產品的形式，所以應該最能帶給軟體團隊信心。不過為什麼目前業界多數推薦多寫一點整合測試呢? 詳細可看這篇 (連結)

• 看到一個 GitHub 上的開源專案，彙整了科技業工作常聽見的英文句子。假如對於到海外或外商工作感興趣的讀者，推薦可以記一下。這邊挑了其中 12 個我們自己很常聽到的，翻譯成中文並附上用途的解說 (連結)

• Node.js Security 先前分享了《Do not use secrets in environment variables and here's how to do it better》一文，談到了一些可能很多人都不知道的環境變數使用概念，讓人學到不少 (連結)

• 近期最熱門 JavaScript 後端框架 Hono 的創作者，在《The story of web framework Hono》寫下 Hono 的故事，同時有介紹幾個 Hono 在開發者體驗上的特點，寫得很精彩 (連結)

• Zed 團隊的 Thorsten Ball 在《How I use git》一文談了他使用 Git 的方法，推薦一讀業界資深工程師的 Git 使用流程 (連結)

• 很多人在思考職涯選擇時，可能會在大團隊與小型團隊中猶豫，《The magic of small engineering teams》一文談了小的工程團隊的優點 (連結)

• 近幾年社群中有個累 Headless UI 推出，headless 這個詞直接理解起來是指無頭的，但那是指什麼? 在《Headless, boneless, skinless & lifeless UI》一文詳細地介紹 (連結)