# 面試經驗談 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：

*   強一致性
    
*   高吞吐
    

在沒有先確認業務場景（例如庫存敏感度、容錯空間、是否允許最終一致）的前提下，直接將問題轉向高併發，是一種上下文切換過快的討論方式。

### 更理想的做法

1.  先確認問題的約束條件
    
2.  再討論在該約束下的解法
    
3.  最後才延伸到 scalability / failure case
    

這種討論方式，會讓面試從「評估思考能力」退化成「即時反應壓力測試」，反而無法有效判斷候選人的系統設計能力，甚至可能錯誤地低估其在特定約束條件下的決策品質。

技術討論應該是共築共識，而非設局捕捉

## 大忌2 - 遲到

不管是線上還是實體，我相信大家都能夠體諒突發狀況的發生，但遲到不解釋或表達歉意，對我來說是一個非常扣分的項目。

### 情境

面試時間已過 10 分鐘，面試官才匆忙上線或進入會議，全程未對遲到原因做出任何說明，也沒有表達歉意，直接開始面試流程。

### 問題本質

這並不只是「時間管理」問題，而是基本職業素養的缺失，以及對候選人時間的不尊重。

### 為什麼這是問題

面試本質上是雙向評估，而非單向篩選。

企業在評估候選人的同時，候選人也在評估企業的文化與工作方式。

在沒有任何說明的情況下遲到，會傳遞出幾個負面訊號：

*   對時間缺乏基本尊重
    
*   缺乏溝通與責任意識
    
*   團隊可能存在流程鬆散或文化不對等的問題
    

這會讓整場面試從一個「平等的專業對話」，退化成「單方主導的篩選流程」，進而影響候選人對公司的整體判斷。

### 更理想的做法

即使發生不可避免的突發狀況，也應該做到基本的溝通與補償：

1.  事前或第一時間通知延誤情況
    
2.  簡要說明原因（不需過度細節）
    
3.  表達基本的歉意
    
4.  必要時提供重新安排時間的選項
    

這些都是低成本但高影響的行為，能有效維持面試過程的專業性與雙方的信任基礎。

## 大忌3 - 反向題型

在過去的面試經驗中，遇到過許多有反向題型的企業，反向題型是個雙面刃，可以協助企業辨識出需符合所需人格特質的人才，但用不好就會變成反感題。

### 情境

面試官在高併發系統設計討論中，未提供足夠背景資訊，不斷重複追問：「如果系統還是撐不住流量呢？」

即使候選人提供了五種以上擴充方案，面試官仍追問，直到候選人反問：「那您希望我針對哪個層級（layer）作回答？」

最後得到的回覆是：「我想看看你會不會說『我不知道』。」

### 問題本質

這是反向題型使用不當的典型案例：

原本目的是評估候選人在不確定情境下的應對能力與思考邏輯，但缺乏明確目標和對齊上下文，反而變成壓力測試。

### 為什麼這是問題

*   面試重心從「評估思考能力」偏離，變成單純測試候選人承受壓力的反應
    
*   缺乏背景資訊，使候選人難以判斷適當的假設與邊界
    
*   易引起負面情緒，降低候選人對公司的認同與信任
    

這種方式對雙方都沒有價值：企業未必能得到有意義的評估結果，候選人也可能留下負面印象

### 更理想的做法

如果要使用反向題型，應該控制在**明確目標和透明假設**下：

1.  先說明面試目標：例如「我想了解你在高併發下的思考流程，而不是單純測試答案」
    
2.  提供必要背景資訊與約束條件
    
3.  在追問時，保持開放式討論而非強迫候選人「說不知道」
    
4.  引導候選人展示思考模式、trade-off 評估與假設管理
    

這樣可以發揮反向題型的正向價值，同時避免讓面試變成單純的心理測試或壓力測試。