面試經驗談 2025-2026
從2025年3月開始，我陸陸續續參與了從新創到上市櫃公司的Senior - Tech Lead的相關面試，其中有不乏 尊重面試者、展現高度專業的企業(公司)，當然也有遇到幾場面試鬼故事，這篇文章主要分享我對於軟體工程師面試的方向分享，以及部分鬼故事，以此警惕自己不要成為這樣的面試官。
AI的洪流，改變了SWE的生態
LLM的發展確確實實的影響到了軟體工程師的生態。
過去受限於算力與資料規模，深度學習的發展曾一度趨緩。隨著 GPU 與分散式訓練技術成熟、網路規模資料的累積，以及以 Transformer 為核心的模型架構出現，使得以自監督學習為基礎的大型語言模型得以快速發展並實際落地，進而引發近年的 AI 應用爆發，而首當其衝的便是 - 軟體工程師。
其實仔細想想這件事情並不是偶然，軟體系統主要受限於邏輯與抽象層，而非物理世界的連續性與精密控制問題（如機械結構、動力學、軸承…等）。這使得 LLM 更容易在此領域中發揮作用，因為其擅長處理符號化與結構化問題。這也導致了LLM 甚至於Agent的出現，改變了工程師能力的分佈結構，使得原本需要長時間累積的開發能力，被部分壓縮。
AI 模糊化了 傳統Junior工程師與Senior的邊界，即使是經驗較少的工程師，也可以在 LLM 輔助下快速完成 PoC 或 MVP，而不需要大量的時間經驗積累；但這與 production-ready system 仍存在本質差異。這讓我發現一件事情：工程師的價值不在於解決問題，更著重在定義問題。
過去我們的競爭力來自於實作能力，現在則逐漸轉向：
問題建模能力
系統設計能力
在不確定性下做出技術決策的能力
這也呼應了我曾在Medium上發表的文章，這裡節錄一段重點：
AI 會寫 Code、能跑 test、甚至能優化效能，但它還不能取代的，是「策略思考」、「商業判斷」與「系統整合」。
以後的工程師好像需要帶一點Project Manager的特質了！
成為一個 有策略、能夠洞悉未來、具有問題解決能力 的 "工程師"
這裡的問題解決能力，並不是指 技術性問題的解決能力。在資訊檢索與方案建議上，LLM 已具備高度參考價值， "軟實力" 會成為未來Enginner必備的技能之一。
AI 會寫程式，會自動補全邏輯，甚至能理解架構與效能的優劣。但這並不代表工程師的價值消失了。相反地，當寫程式變得越來越容易，真正稀缺的是「知道要寫什麼」的人。
過去我們的價值來自於「能解技術問題」，未來則來自於「能定義問題」與「設計解法」。也就是說，工具在解決 How to do it，但工程師該進化去處理 What to do 與 Why to do it。
生態改變後，對於Interview有哪些變化
雖然軟體工程師的生態系正在改變，也導致了職務需求的降低，但基本的缺口仍舊存在，市場上還是需要軟體人才來主導系統架構。
重點來了：AI產品落地的速度很快 - 做PoC非常快，但PoC跟系統化是兩個截然不同的世界。
企業主可以透過簡單的提示字、需求來做出一個可以快速驗證市場的PoC，但是一旦想要將這套商業邏輯或產品做成：高穩定性、易擴充能夠負荷極端或特殊情境的「系統」，這時候就需要專業的工程師介入。這也是近兩年來面試的觀察，大部分的技術面試已經從 How to do(如何實踐功能) 轉向 邏輯思維、系統架構設計以及經驗討論了；面試的重點不再是驗證「你會不會寫」，而是評估「你在什麼情境下會做出什麼決策」
目前兩年間面試下來大約15家企業，只有1家公司還保留上機測試。
鬼故事專區
嚴肅的內容說完了，現在就來輕鬆當笑話，聊聊被我定義成鬼故事的經驗吧！這些經驗我會混在一起來談，一方面是希望條列式，也希望可以避免太多 「敘事」的情節。
大忌1 - 專業度不足
技術面試中最難拿捏的，其實是「深度與範圍的界線」，技術充斥著軟體工程師的生活，或許有些問題窮極一生都遇不到，但對於另一位Engineer來說或許就是日常一杯咖啡一樣的問題。
在不同的背景下、不同的企業 即便使用相同的語言Tech Stack也會有一定程度的差異，我認為這是正常且健康的狀況。
但如果涉及到Basic Know-how那就一切不一樣了。
情境
面試官A：以你的經驗，你如何解決或避免超賣的問題？
Bennett：我會先確認系統對資料一致性的要求。如果是強一致性場景，會優先考慮透過 DB Lock 或 transactional 機制來確保正確性。
面試官B：那一萬個請求進來，你的系統不就直接炸掉？
問題本質
這類對話的問題，不在於答案對錯，而在於「討論層級沒有對齊」。
超賣問題本質上是一個典型的 trade-off：
強一致性
高吞吐
在沒有先確認業務場景（例如庫存敏感度、容錯空間、是否允許最終一致）的前提下，直接將問題轉向高併發，是一種上下文切換過快的討論方式。
更理想的做法
先確認問題的約束條件
再討論在該約束下的解法
最後才延伸到 scalability / failure case
這種討論方式，會讓面試從「評估思考能力」退化成「即時反應壓力測試」，反而無法有效判斷候選人的系統設計能力，甚至可能錯誤地低估其在特定約束條件下的決策品質。
技術討論應該是共築共識，而非設局捕捉
大忌2 - 遲到
不管是線上還是實體，我相信大家都能夠體諒突發狀況的發生，但遲到不解釋或表達歉意，對我來說是一個非常扣分的項目。
情境
面試時間已過 10 分鐘，面試官才匆忙上線或進入會議，全程未對遲到原因做出任何說明，也沒有表達歉意，直接開始面試流程。
問題本質
這並不只是「時間管理」問題，而是基本職業素養的缺失，以及對候選人時間的不尊重。
為什麼這是問題
面試本質上是雙向評估，而非單向篩選。
企業在評估候選人的同時，候選人也在評估企業的文化與工作方式。
在沒有任何說明的情況下遲到，會傳遞出幾個負面訊號：
對時間缺乏基本尊重
缺乏溝通與責任意識
團隊可能存在流程鬆散或文化不對等的問題
這會讓整場面試從一個「平等的專業對話」，退化成「單方主導的篩選流程」，進而影響候選人對公司的整體判斷。
更理想的做法
即使發生不可避免的突發狀況，也應該做到基本的溝通與補償：
事前或第一時間通知延誤情況
簡要說明原因（不需過度細節）
表達基本的歉意
必要時提供重新安排時間的選項
這些都是低成本但高影響的行為，能有效維持面試過程的專業性與雙方的信任基礎。
大忌3 - 反向題型
在過去的面試經驗中，遇到過許多有反向題型的企業，反向題型是個雙面刃，可以協助企業辨識出需符合所需人格特質的人才，但用不好就會變成反感題。
情境
面試官在高併發系統設計討論中，未提供足夠背景資訊，不斷重複追問：「如果系統還是撐不住流量呢？」
即使候選人提供了五種以上擴充方案，面試官仍追問，直到候選人反問：「那您希望我針對哪個層級（layer）作回答？」
最後得到的回覆是：「我想看看你會不會說『我不知道』。」
問題本質
這是反向題型使用不當的典型案例：
原本目的是評估候選人在不確定情境下的應對能力與思考邏輯，但缺乏明確目標和對齊上下文，反而變成壓力測試。
為什麼這是問題
面試重心從「評估思考能力」偏離，變成單純測試候選人承受壓力的反應
缺乏背景資訊，使候選人難以判斷適當的假設與邊界
易引起負面情緒，降低候選人對公司的認同與信任
這種方式對雙方都沒有價值：企業未必能得到有意義的評估結果，候選人也可能留下負面印象
更理想的做法
如果要使用反向題型，應該控制在明確目標和透明假設下：
先說明面試目標：例如「我想了解你在高併發下的思考流程，而不是單純測試答案」
提供必要背景資訊與約束條件
在追問時，保持開放式討論而非強迫候選人「說不知道」
引導候選人展示思考模式、trade-off 評估與假設管理
這樣可以發揮反向題型的正向價值，同時避免讓面試變成單純的心理測試或壓力測試。