我會在Substack上分享更多關於北美職場上的所見所聞，有興趣可以訂閱我的電子報。
雖然在職場上我已經算是上岸，但不時仍有關注市場上關於職位空缺、面試技巧、職涯計劃的資訊。
最近看到Kelly分享一段影片，模擬以應徵者身份參與軟體工程師的技術面試，面試官是Amazon的工程師，理所當然地面試內容就是Leetcode類型的題目。
有看過我之前文章的話或許會知道我對Leetcode類型的面試沒好感，面試時不允許使用AI輔助但工作時卻要求使用AI，而且應徵者需要長時間針對面試題目的操練，面試考核內容與工作能力的關係成疑。
一年前我為找工作而看面試模擬影片，通常我會在影片顯示題目後先暫停，花半小時至一小時試試能不能解，之後才繼續影片。
除了解題的硬實力外，當時我想看的是面試技巧，怎樣向面試官解說我的想法，想不到解法時如何應對等等。
但有趣的是，這次看完影片後，跟一年前的我看同類影片的感受有著天淵之別。
現在的我看到的反而是
Kelly如何從解題過程中演示出她在工作上的表現
也許，這就是為什麼科技巨頭還在以Leetcode題目面試的原因？
面試官最不想看到的
有為技術面試做過功課的都知道，技術面試(尤其是現場解題)最忌就是收到題目後二話不說就開始寫程式碼。
面試是一個讓面試官和應徵者尋找工作夥伴的過程，真正的開發工作極少機會是在收到需求後可以立即寫程式的。
需求會有模糊的地方；
會有跟其他工程師溝通合作的需要；
會有要說服其他人採納自己意見的時候；
所以溝通是面試中不可或缺的一環。
一年前我在準備面試時也知道要溝通，要Think Out Loud，邊說想法邊寫程式。
但在第一次面試時，由於沒有實戰經驗，最終還是搞砸了。
刷題時我有刻意練習邊說話邊寫程式，在面試時亦做到這點，但問題在於面試時我只是單方面進行溝通，面試官給我的提示沒聽進去，對方的困惑擺在臉上我都沒看到，卡關時我依然只是活在我自己的世界當中。
Kelly在這次模擬面試中做了一個很好的示範，我會在以下段落分析她在面試中反映出的能力，如果你正在為技術面試準備的話，或許對你有點幫助。
釐清題目 = 釐清客戶需求
很多時候面試收到的題目並沒有如Leetcode上的仔細，釐清這些模糊的地方就是第一樣要做的事情。
面對客戶需求時，普遍越初級的工程師看到的需求會越仔細，因為釐清需求的工作都被上層處理好了。
比如說數據顯示公司的網上購物平台80%的客戶都有把商品放到購物車但沒有付款，導致成交的訂單數量低下。
經UIUX設計師研究後發現付款程序需要簡化，由10次點擊減至5次點擊就能完成付款。
資深工程師在收到設計後分析在前端、後端不同服務需要的改動。
最後才分派給自己或其他工程師修改程式。
能夠從口中所說的需求解讀出客戶想要解決的問題，我認為此能力比會寫程式更為重要。在開發工作中因缺乏溝通而誤解客戶需求，花了人力物力，最終換來一個沒客戶用的功能，這樣的事例屢見不鮮。
因此面試在寫程式前能夠透過對話來釐清題目中含糊的部份，或表明自己所做的假設，是展現個人溝通能力的必要技巧之一。好得更好的，會在這階段就指出幾項測試用例，用於驗證題目的要求和自己解法的預期答案。
因為能否問對問題，比起單純答對答案，更能看出一個人的職場成熟度
釐清題目限制 = 釐清任務限制
Leetcode解題主要有2項限制，包括空間和時間複雜度。有些題目會預先設限，限制了題目的解法。
但面試官通常在提出題目時並不會預先說明空間和時間限制複雜度，給予應徵者“適當”的自由，但其實這是個陷阱。
寫程式事實上沒有完全的自由，工程師收到任務時通常聽到的第一項限制就是時間限制，開發、測試、寫文件等工作要在幾天內完成。其次就是功能的硬體軟體限制，開發網頁要知道網速的限制，尤其主要客戶為手機用家的時候；開發雲端應用要知道資金限制，因為雲端服務每一分每一秒都在燒錢；開發本地應用要知道硬體限制，CPU和RAM需求過高會縮小潛在客戶群。
所以在面試解題時遇到任何覺得有機會碰到限制的地方，例如空間和時間複雜度、函數參數的類型、能不能動原有的程式碼(如有)，都要把握機會跟面試官溝通，弄清楚題目的限制。
提供解題方案 = 提供任務解決方案
同一條題目，可以有幾種甚至幾十種不同的解法。
Leetcode類型的題目通常最少有2種解法：
- 暴力破解(Brute Force)
- 適用的演算法和資料結構
第一種並不建議採用但依然是可行的解法之一，而第二種應徵者要對演算法和資料結構有一定的認識。
在提供解題方案時，最好提供2種或以上的方法，展現自己能從不同角度思考，從而得出幾種解法的能力。
實際開發系統功能時亦一樣，比如說要建立資料快取以減少網頁讀取時間，可以把快取以txt或JSON的型式存在後端檔案系統上，可以利用Redis建立快取，可以使用第三方CDN，每個方法都各有利弊。
無論是面試還是工作時，可以考慮先提出心中的最佳解法，時間容許的話才提出另外幾種可行的解法，再解釋為何自己所選的解法為最佳解。這樣既能顯示出應徵者多角度思考的能力，又能增加說服力。
解釋解法 = 對齊對解決方案的理解
由於時限關係，此部份在面試時通常會與上一步合起來，在提出解法的時候便解釋思路。
但在開發工作遇到較大型或複雜的專案時，做漏這步或會引起巨大的危機。
- 重工
開發成員對執行內容理解不一致，你做你的我做我的，結果跟預想中的不同，導致要重新溝通重新開發 - 時程延誤
事前沒有對接口進行對齊工序，各自基於各自的假設去做，要接口時才發現問題
以上只是肉眼可見的危機，經常出現此狀況的話短期造成資源浪費，長期可對團隊士氣造成嚴重影響。
專案規模越大，事前準備的工作就越重要。
例如以系統圖顯示現有系統架構及要更改的地方，以軟體設計文件說明不同服務之間的接口，先從概念層面、設計層面獲得共識，執行時就能避免中途突然殺出一個程咬金，要翻盤重新擬定解決方案。
而在面試的時候，此情況就好像應徵者沒有在寫程式前向面試官解釋自己的想法，一昧只顧寫，卡關時面試官又不理解自己在做什麼，想幫也幫不了忙，眼白白看著時間一點一點的過但就是沒有進展，最終只能飲恨而終。
最後才到實作
有人可能會問：
我在看到題目後就想到解法，為什麼不直接寫程式，要浪費時間功夫去弄這麼多？
公司不是要解決問題的人嗎？做這些不是只是降低效率嗎？
沒錯！公司是要解決問題的人，而且坦白說面試的題目由於有時限，如果一開始就想到最佳解的話，這些功夫“表演”成份居多。
說實話Leetcode類型的面試其實並沒有要求應徵者說話，但北美是一個重視溝通能力多於實作能力的地方，在實作前有足夠的溝通能夠把大部份會遇到的問題預先作準備，減低實作時的風險。
聰明的人會利用面試短短的45分鐘來展現自己的能力，證明自己在日後工作是位能為團隊/公司創造價值的人。
面試的主要目的不是在解題，而是說服面試官自己能為公司帶來價值。
在解法得到面試官的認同之後，剩下的就是考驗對語言、框架的熟悉及除錯能力，而身為軟體工程師的你，我相信不用多說怎樣提升這些能力，你的經驗已經給了你一個答案。
職場小挑戰
Kelly在影片的演示當然不是一條必勝方程式。
不同的公司、不同的面試官、甚至不同的職位，都有不同的評分標準。
但Kelly的表現非常充分地展現了作為一個工程師應有的解難能力：
不只是能解題，而是能一步步有系統性並且透明地解決問題。
這項能力，不只能應用在技術面試當中，在職場上更是尤為珍貴的能力。
因此這星期我向你發出的小挑戰是：
在你接下來的一週內，挑選一項工作任務或學習課題，問自己3個問題並寫下答案：
- 真正要解決的是什麼問題？（釐清需求）
- 有什麼限制？（釐清條件）
- 提出最少2個解決方法，並列出各自的利與弊（提出方案並解釋）
這樣的練習，看似簡單，但如果能堅持每項工作都這樣做，能大幅提升你在解題、溝通和說服別人方面的實戰能力。
久而久之，不單是面試，更會變成你的肌肉記憶。
