都 2026 年快結束了，還在用 Laravel Lifecycle 跟 SQL 語法評斷資深工程師？
最近面試一個 Laravel 職缺，被問到 Laravel Request Lifecycle、Service Provider、SQL JOIN、GROUP BY。
這些問題有錯嗎？
沒有。
但我想問的是：一場評估十多年資歷工程師的面試，如果大部分時間都在確認他記不記得框架細節，那究竟是在評估工程能力，還是在考技術問答？
這不是說基礎不重要，而是面試官必須先想清楚：自己到底想找到什麼樣的人。
一、背得出 Lifecycle，不代表遇到問題就能解決
Laravel Request Lifecycle 當然重要。
但知道請求的執行流程，跟能利用這些知識排查正式環境問題，是兩回事。
一個人可以把 Lifecycle 背得滾瓜爛熟，卻在實際遇到 Middleware 異常、依賴解析失敗或請求流程不如預期時，不知道從哪裡開始查。
反過來說，有經驗的工程師未必能在面試現場，按照文件順序完整背出每個執行環節，卻能透過 Log、Route、Middleware、Container 與原始碼，逐步定位問題。
那麼，哪一種能力對實際交付更有價值？
如果職缺需要研究 Laravel 底層，深入考查 Lifecycle 非常合理。
但如果只是要求候選人背出整套流程，再用回答得多完整來判斷資歷，我會想問：你要找的是能解決問題的工程師，還是記得住文件的考生？
二、SQL 寫得出來，不代表你有能力確保資料正確
JOIN、GROUP BY 是基本功，這沒有爭議。
但真正危險的，從來不是工程師忘記某個 SQL 語法，而是他寫出一段可以執行的 SQL，卻不知道結果早就算錯了。
例如，一筆訂單有多筆付款紀錄。直接 JOIN 後再加總訂單金額，就可能因為資料列被展開而重複計算。
查詢成功了，報表產生了，甚至沒跳出任何錯誤。
但數字是假的。
這時候，真正有價值的能力是找出資料為什麼膨脹、金額為什麼重複、查詢結果是否符合業務規則，以及如何驗證修正後的正確性。
SQL 語法決定查詢能不能執行，資料理解與驗證能力決定結果能不能相信。
如果面試只考 JOIN 怎麼寫，卻不考候選人能不能發現 JOIN 造成的資料錯誤，那這場面試測到的，可能只是語法熟練度，而不是資料處理能力。
三、設計模式很重要，不懂的人確實不適合盲目依賴 AI
這裡我先站在反方說一句話。
如果一個人宣稱自己用 Cursor 開發 Laravel，卻連 Dependency Injection 是什麼、設計模式要解決什麼問題都不知道，那確實有問題。
因為 AI 可以產生程式碼，卻不代表它產生的架構一定合理。
Controller 裡直接塞商業邏輯、SQL、第三方 API 呼叫，AI 寫得出來，測試也可能通過。但當需求持續變動，原本沒有明確責任邊界的程式，就可能變成難以修改、難以測試、牽一髮動全身的技術債。
所以，不懂設計原理就盲目使用 AI，確實可能只是加速製造問題。
但接下來才是重點。
設計模式很重要，不等於面試就應該花大量時間考候選人背定義。
與其問「Repository Pattern 是什麼」，不如問：
這個情境為什麼需要 Repository？直接使用 Eloquent 不行嗎？
什麼時候該拆 Service Layer？什麼時候拆了反而增加複雜度？
如果 AI 把所有商業邏輯塞進 Controller，你會怎麼判斷是否需要重構？
這次重構的收益，是否真的大於修改成本與回歸風險？
這些問題才能看出候選人是否理解設計背後的取捨。
因為真正成熟的工程師，不是看到程式碼就急著套設計模式，而是知道問題在哪裡、有哪些方案，以及每個方案要付出什麼代價。
能背出 Pattern 的名稱，不代表懂架構；知道什麼時候不該用 Pattern，反而更能看出經驗。
四、我知道面試官為什麼喜歡考這些，但方便篩選不等於評估完整
站在面試官的角度，基礎題確實有它的價值。
面試只有一個小時，不可能讓每個人都完整操作一個專案。問 Lifecycle、SQL 與設計模式，可以快速確認候選人有沒有基本功，也能降低找來一個完全依賴 AI、卻沒有能力驗證產出的人的風險。
這個理由完全合理。
但問題是：一套方便面試官出題的題庫，不應該自動變成評估資深工程師的標準答案。
如果基礎問題只是用來確認底線，我沒有意見。
如果候選人連基本原理都說不清楚，當然值得追問。
但如果一位有十多年經驗的工程師，能處理既有系統、整合 API、定位資料錯誤、控制修改範圍，卻因為無法完整背出某段框架執行流程，就被認定能力不足，那我認為評估方式本身就值得檢討。
不是所有記不住細節的人都很有能力，也不是所有背得出答案的人都沒有能力。
問題在於，面試官是否有能力分辨這兩種人。
五、AI 已經能寫程式，資深工程師的價值就更不該只停留在「會寫」
過去，熟悉語法、掌握框架、理解設計模式，再把程式碼寫出來，是工程師的重要能力。
現在，AI 已經能協助完成大量程式碼產生工作。
但程式碼產生得快，不代表需求理解得正確；測試通過，不代表業務規則完整；架構看起來漂亮，也不代表它適合目前的系統。
工程師仍然必須判斷：
需求是否有漏洞？
AI 是否擅自假設不存在的欄位或規則？
這個設計是否過度複雜？
修改會影響哪些既有功能？
如何驗證結果，並控制交付風險？
這些事情都需要技術基礎，但不是把技術名詞背熟就能做到。
AI 沒有讓基礎知識變得不重要，而是讓「只會背、只會寫」更難成為資深工程師的競爭優勢。
六、如果我是面試官，我會考原理，但更會考判斷
我會問 Lifecycle，也會問 SQL，更會問設計模式。
但我不會滿足於候選人講出定義。
我會給他一段既有程式碼，問他問題在哪裡、為什麼這樣判斷、有哪些修改方案，以及各自的風險。
我會讓他面對一個資料不一致的情境，觀察他如何排查，而不是只看他能不能快速寫出一段查詢。
我也會問他如何使用 AI 修改既有系統、如何限制修改範圍、如何驗證產出，以及當 AI 提出的方案不合理時，他是否有能力拒絕。
因為我想找的不是一個什麼都能立刻回答的人，而是一個在答案不明確、文件不完整、需求持續變動時，仍然能做出合理判斷的人。
這才是資深工程師應該展現的價值。
結語
我從來沒有說 Laravel Lifecycle 不重要、SQL 不重要，或設計模式不重要。
我質疑的是：當我們要評估一位資深工程師時，為什麼有時候仍然習慣用背誦知識的方式，代替對實際工程能力的判斷？
基礎知識應該是入場券，不是整場面試的主角。
理解原理，不等於背誦細節；會做架構決策，不等於會默寫框架文件。
如果面試的目的只是確認候選人記得多少知識，那考題確實很好設計。
但如果目的是找到能對系統品質、資料正確性與交付結果負責的資深工程師，就應該考得更深入，而不是只考得更細。
最後，我想問一句：
2026 年的資深工程師面試，究竟是在挑選能解決問題的人，還是在挑選最會回答技術考題的人？
如果連這兩件事都分不清楚，那可能不只是候選人需要重新檢視自己的能力。
面試的評估方式，也值得重新檢視。
#Laravel #AI輔助開發 #AICoding #軟體工程 #技術面試 #資深工程師
沒有留言:
張貼留言