面試官不問八股，只沿著履歷連環追問：帆軟二面的問法，透露企業怎麼重新定義「會寫程式」

一份來自牛客網的帆軟（FanRuan）二面面試分享，近日在中國工程師求職圈流傳。發文者完整列出整場面試的題目，內容橫跨 Agent 評測方法論、Caffeine 加 Redis 加 MySQL 的多級快取、Lua 腳本與 Redisson 分散式鎖、MySQL 事務隔離、執行緒池與 Tomcat、單例模式，一路到 JVM 的 Full GC 排查。這些主題本身不新鮮，任何一本後端面試題庫都找得到。真正讓這份面經值得細讀的，是題目排列的方式：面試官幾乎不問教科書式定義，而是沿著求職者履歷上的某個設計決策，一層一層往下追問。

這則貼文發布時間為近期，屬於仍在持續發酵的討論。它會被轉發，不是因為題目難，而是因為它示範了一種正在成為主流的面試形態：對照履歷拷打。發文者自己也下了註解，說這場面試「不是在背八股」，面試官追的是「為什麼這麼設計、有沒有必要、去掉某個元件會怎樣」。

「背八股」與「拷打專案」的差別，差在問句的形狀

中國工程師圈把背誦標準答案的面試題統稱「八股文」。這類題目的特徵是問句封閉：MySQL 有哪四種隔離級別、Redis 怎麼持久化、什麼是髒讀。答案有標準版本，考前突擊兩週就能覆蓋大半。

帆軟這場二面的問法明顯不同。以快取那段為例，題目鏈是這樣展開的：你為什麼採用 Caffeine 接 Redis 再接 MySQL？如果系統只有單一實例，Redis 還有必要嗎？去掉 Redis 之後，系統具體哪裡會變差？本地快取已經有了，為什麼還需要 Redis？

注意這些問句的共同點：它們都在要求求職者為自己的設計決策辯護，而不是複述知識。同樣是考 Redis，八股問「Redis 有哪幾種持久化方式」，拷打式問「你的系統裡，Redis 重啟會不會丟資料，丟了會怎樣」。前者考記憶，後者考的是你有沒有真的在那個系統裡待過、想過、痛過。

分散式鎖那段更明顯。面試官明知 Lua 腳本已能保證原子性，仍連續追問：為什麼還需要 Redisson？Redisson 到底保護誰？你有沒有真正想過 Redisson 是多餘設計？這幾乎是把「拿熱門框架堆履歷」的套路攤在桌上檢驗。很多求職者的專案會同時寫上 Lua 和 Redisson，因為教學影片都這麼教，但兩者各自解決什麼層面的問題、哪一個其實可以被拿掉，只有真的理解鎖的語意（尤其是續約、重入、釋放的安全性）才答得上來。

這與我們先前寫過的四十歲工程師以瀏覽器端圖片壓縮創業的故事，指向同一件事：技術選型的說服力，來自你能講清楚每一個取捨，而不是堆了多少技術名詞。

為什麼企業開始這樣面試：一個成本帳

面試形態的轉變，動機其實很實際。背誦題的辨識度正在快速失效。面試題庫網站、AI 對答工具、付費突擊課程，讓「八股滿分」的候選人供給大增。對企業來說，這代表傳統問法的篩選成本上升：花四十五分鐘聽完流暢的標準答案，入職後才發現對方沒有獨立排查問題的能力，這筆錯判的成本由用人團隊承擔。

拷打式面試把風險往前移。追問鏈有一個特性：每一題都建立在上一題的答案之上。你說系統是分散式的，下一題就問單實例場景；你說 RR 解決了幻讀，下一題就拿出你前面說解決不了的矛盾，要你自己解釋。這種結構很難靠背題維持，因為追問的路徑取決於你的回答，題庫無法預先窮舉。

對求職者而言，這也改變了準備的方向。突擊八股的投資報酬率下降，真正值錢的準備變成：把履歷上每一行技術決策，都能講出「當時的情境、 alternatives、選擇的理由、拿掉會怎樣」四段敘事。發文者留言區有人下了一個精準的總結：一問專案，深度就出來了。

從題目內容，看後端工程的能力座標

這份面經如果把題目攤開來分類，大致對應後端工程師的四層能力，順序也值得注意。

第一層是評測與量化。開場的 Agent 評測題組（怎麼建 Benchmark、怎麼量化效果、指標出問題怎麼定位）是近年新增的題型，反映 AI 應用進入企業系統後，「能不能衡量它好不好」變成獨立的工程職責。這類題目沒有標準答案，考的是方法論的完整度：先定義基準、再定義指標、再建立歸因路徑。

第二層是儲存與快取架構，也就是資料在不同介質間的擺放邏輯。第三層是並發與執行模型，從執行緒池參數一路問到 Tomcat 怎麼處理兩個同時到達的請求。面試官甚至給了一個具體情境題：每天上千用戶訪問，執行緒池會配多少？這題的陷阱在於「上千用戶」是總量，工程師要會換算成同時在線與瞬時並發，否則直接報一個 maxPoolSize 數字就暴露了沒有量化思維。

第四層是 JVM 與故障排查，頻繁 Full GC 怎麼定位。這層題目考的是實務經驗的深度，因為 GC 問題的排查路徑（看日誌、看記憶體分布、找洩漏或大物件）只有在真的碰過生產環境事故時才會內化。

把這四層疊起來，企業要的人選輪廓其實很清楚：能設計、能量化、能排查、能為取捨辯護。這恰好也是 AI 輔助編碼工具普及之後，初階工程師被期待上移的能力位置。寫得出程式碼的價值在貶值，判斷程式碼該不該那樣寫的價值在上升。

給求職者的實際啟示

回到讀者能用的判斷。如果你正在準備後端職缺，這份面經的用法不是把它當新一輪八股背下來，而是拿它的追問模式對自己的履歷做壓力測試。

具體做法：把履歷上每一個技術名詞圈出來，對每一個名詞問自己三個問題。當初為什麼選它，而不是另一個方案？如果把拿掉，系統哪個具體環節會變差？它在你的架構裡，到底保護了誰？答不出其中任何一題，那一行就屬於「裝飾性技術」，拷打式面試官會精準地找到它。

面經文化本身也值得多想一層。求職者分享完整題目、社羣接力整理題庫，這個循環讓任何固定問法都會逐漸失效，也逼著面試形態持續演化，從筆試知識題，到開放式場景題，再到現在的履歷拷打。下一輪的演化方向難以預測，但方向感是確定的：越貼近真實工作情境的問法，越不容易被題庫化，也就越會被企業採用。

帆軟這場二面不是特例，是訊號。對求職者來說，最穩固的準備，從來不是更厚的題庫，而是把自己經手過的系統，理解到能承受任何一條追問鏈的深度。