“八股文”已死？2026技術(shù)校招面試官親述：我們現(xiàn)在只問這三個真實項目題
目錄
一、現(xiàn)象：背了三百道題的候選人，第一輪就被刷了
二、本質(zhì)變化：面試官在篩選“做過事的人”，不是“讀過書的人”
三、核心機制拆解：三個項目題到底在測什么
四、典型案例對比：兩個候選人的回答實錄
五、工程落地啟示：沒項目經(jīng)驗怎么辦
六、最后一個問題
上個月公司校招，我坐在面試間里，對面是一個985碩士。簡歷漂亮：GPA前10%，兩段大廠實習，技能欄寫滿了Spring Cloud、Kafka、Redis。
我問了第一個問題：“你簡歷上寫做過秒殺系統(tǒng)，那我想知道，這個系統(tǒng)上線以后，你遇到過什么真實的問題？怎么解決的？”
他沉默了幾秒，說：“呃，其實那個項目是跟網(wǎng)課做的，沒有真的上線?！?/p>
我點點頭，又問：“那你實習的時候，寫過最復雜的一個功能是什么？代碼還在你腦子里嗎？”
他又沉默了。最后說了個“改了一個查詢接口的SQL”。
面完出來，我跟HR說：“這個不行。他知道很多東西，但一樣都沒真的做過?！?/p>
這不是個例。今年我面了二十多個校招生，能讓我覺得“這人是真干過活”的，不超過三個。
很多人還在靠背八股文準備面試，但面試官已經(jīng)換了一套玩法。 我們現(xiàn)在不問HashMap的擴容機制，不問線程池的參數(shù)。不是因為這些不重要，是因為這些東西AI能答得比你好。我們只問三個真實項目題。
一、現(xiàn)象：背了三百道題的候選人，第一輪就被刷了
說幾個今年的真實場景。
字節(jié)某組的一面，面試官直接說：“我們不問八股，你就挑一個你寫得最爽的代碼片段，給我講講你是怎么設(shè)計的?！?候選人懵了，因為他所有的代碼都是跟著視頻敲的，沒有一個片段是他自己獨立設(shè)計的。
阿里的二面，面試官扔了一個github地址：“這是我之前遇到的一個線上bug，代碼在這里，給你十分鐘，你說說問題出在哪?！?候選人連代碼都沒完全看懂。
美團的HR面之前加了一輪“項目深度面”，專門問：你這個項目上線了嗎？多少用戶？遇到最大的技術(shù)挑戰(zhàn)是什么？如果讓你重做，你會改哪里？
校招生的反饋也在印證這個變化。 ?？途W(wǎng)上越來越多的人說：“面試官全程追著項目問，問得非常細，細到某個字段為什么用這個類型，某行日志怎么打的。”
而那些“背了三百道題，手撕了十道算法”的人，發(fā)現(xiàn)自己準備的東西，面試官一個都沒問。
不是八股文完全沒用了，是 它從“通過條件”變成了“不扣分條件”。你背得再好，也只能拿個基礎(chǔ)分。真正決定你能不能進下一輪的，是那三個項目題。
二、本質(zhì)變化：面試官在篩選“做過事的人”，不是“讀過書的人”
為什么會有這個變化？
原因一：八股文的答案已經(jīng)被AI平權(quán)了。
任何一個大模型，你問它“HashMap的put流程”，它能給你輸出一份完美的答案，甚至比絕大多數(shù)候選人說得都好。面試官如果還問這種題，他無法區(qū)分誰是真的理解，誰是剛剛從GPT那兒背下來的。
原因二：大模型時代的業(yè)務復雜度，逼著面試官要找“能動手的人”。
現(xiàn)在的后端系統(tǒng)，動不動就要接大模型API，要做RAG，要處理不確定的輸出。這些東西沒有任何八股文可以背。你只有真正上手寫過，才知道提示詞模板怎么管理，才知道JSON解析失敗怎么兜底，才知道成本怎么控制。
面試官的核心訴求變了：我不是要一個“知道很多”的人，我要一個“能帶著我解決未知問題”的人。
而最能預測這種能力的，就是你過去有沒有“完整地、獨立地解決過一個真實問題”。三個項目題，就是在挖這個東西。
本質(zhì)上，面試從“知識測試”變成了“行為面試”。 你過去的行為，是預測你未來行為的最佳指標。你做過項目，遇到過坑，解決過問題——這些經(jīng)歷形成的判斷力，是AI給不了，也是八股文背不出來的。
三、核心機制拆解：三個項目題到底在測什么
我現(xiàn)在面試只問三個問題。不是固定的措辭，但內(nèi)核不變。
項目題一：“你做過的最有挑戰(zhàn)的一個功能是什么？”
測什么：真實問題的復雜度感知能力。
- 高分回答會描述一個具體的場景（“用戶反饋導出Excel超時”），而不是模糊地說“我做過一個微服務”
- 會解釋為什么有挑戰(zhàn)（“數(shù)據(jù)量從10萬漲到500萬，老方案OOM了”）
- 會說明自己的角色（“我一個人從定位到上線改了三天”）
- 低分回答：說“我做過登錄功能”，或者“我用Redis做緩存”。沒有過程，只有名詞。
項目題二：“這個功能你遇到過什么坑？怎么解決的？”
測什么：工程現(xiàn)場的還原能力 + 問題定位的方法論。
- 高分回答會有清晰的時間線和動作序列（“我先看日志，發(fā)現(xiàn)full GC頻繁，然后用jmap dump了堆，發(fā)現(xiàn)某個HashMap占了80%，再翻代碼發(fā)現(xiàn)沒設(shè)初始容量……”）
- 會講出當時的權(quán)衡（“我本想用弱引用，但考慮到兼容性，最后選了定時清理”）
- 低分回答：“我查了一下，發(fā)現(xiàn)是bug，然后改好了?！?沒有工具名，沒有命令，沒有數(shù)據(jù)。
項目題三：“如果讓你重做，你會改哪里？為什么？”
測什么：復盤能力和技術(shù)品味。
- 高分回答會跳出具體實現(xiàn)，講架構(gòu)層面的改進（“我會把導出做成異步，用消息隊列削峰，前端輪詢下載”）
- 能說出改動帶來的代價（“異步后用戶不能實時拿到結(jié)果，需要加一個通知”）
- 低分回答：“我覺得當時的方案挺好的，沒什么要改的。” 或者只改一些語法層面的東西。
這三個問題，如果候選人能答得扎實，我基本可以判斷：這人入職后，三個月內(nèi)能獨立干活，半年后能帶小任務。如果答得虛，哪怕簡歷上天，我也會打低分。
下面這張圖是三個問題的考察鏈路：
四、典型案例對比：兩個候選人的回答實錄
我拿兩個真實的面評（脫敏）來對比。
候選人X：985碩，簡歷漂亮，但項目全是課設(shè)
問：“你做過最有挑戰(zhàn)的功能是什么？”
答：“我做過一個基于Spring Boot的博客系統(tǒng)。挑戰(zhàn)是用戶評論的嵌套展示，需要遞歸查詢數(shù)據(jù)庫，我用了MyBatis的嵌套查詢解決了?！?/p>
追問：“遇到什么坑？”
答：“遞歸查詢太深會慢，我就改成了只查兩層。感覺還行?！?/p>
追問：“重做會改什么？”
答：“可能前端用Vue重構(gòu)一下，界面好看點?！?/p>
我的面評：全程停留在“作業(yè)級別”。沒有真實用戶，沒有性能壓力，沒有數(shù)據(jù)量。遞歸查詢的深度和效率問題完全沒有量化。不通過。
候選人Y：雙非本科，一個實習項目+一個自己折騰的工具問：“你做過最有挑戰(zhàn)的功能是什么？”
答：“我在實習的時候，有一個需求是把用戶操作日志從MySQL遷移到ClickHouse，因為日志量從每天幾十萬漲到了千萬級，MySQL的寫入和查詢都扛不住了。我負責寫數(shù)據(jù)同步的Worker，保證不丟數(shù)據(jù)、不重復。”
追問：“遇到什么坑？”
答：“最大的坑是同步過程中MySQL主鍵和ClickHouse的排序鍵不一致，導致部分數(shù)據(jù)upsert的時候覆蓋錯了。我先用md5(主鍵)做去重，發(fā)現(xiàn)性能不行，后來改成用Flink的retract機制，先刪后插。最終上線后延遲控制在5秒內(nèi)?！?/p>
追問：“重做會改什么？”
答：“我不會再自己寫Worker了。當時團隊不知道有現(xiàn)成的CDC工具，現(xiàn)在看應該直接用Canal+消息隊列，這樣同步任務的穩(wěn)定性更高，而且支持斷點續(xù)傳。代價是需要多維護一個Canal組件，但能省下我們團隊三個人兩周的自研時間。”
我的面評：三個問題的回答都有“真實感”——有數(shù)據(jù)、有工具名、有失敗嘗試、有對比選型。強烈推薦，直接發(fā)offer。
兩個人的差距不在學歷，不在智商。在于一個人真的在真實場景里解決過問題，另一個人只是在作業(yè)里“演示”過功能。
五、工程落地啟示：沒項目經(jīng)驗怎么辦
很多在校生看到這里會慌：“我確實沒有像樣的項目經(jīng)驗，怎么辦？”
三條路，都是我見過有人走通的。
第一條：把課設(shè)改造成“真項目”。
不要滿足于老師給的需求文檔。自己去加“真實世界的約束”：
- 原本單機跑的，改成支持100個并發(fā)用戶（用JMeter壓一下）
- 原本沒登錄的，加上JWT token和權(quán)限校驗
- 原本數(shù)據(jù)放內(nèi)存的，改成MySQL，然后觀察慢查詢，加索引
- 原本沒有日志的，加上logback，然后模擬一個異常，去查日志定位
每加一個約束，你就會遇到一個真實的問題。把這些問題的解決過程記下來，面試的時候講出來，效果不亞于公司實習。
第二條：去接真正的“臟活”。
找一個開源項目，去提issue。不需要是大項目。很多Python庫、前端組件庫的issue里，有“good first issue”標簽。你去修一個bug，哪怕只是文檔錯誤，你會經(jīng)歷完整的流程：看懂代碼 → 定位問題 → 提PR → 被review → 修改 → 合并。
這個過程本身就是一個項目題的標準答案。面試官問你“最有挑戰(zhàn)的事”，你直接說“我給xx開源項目修了一個bug，過程是這樣的”。
第三條：自己做個工具，解決自己的痛點。
我見過最離譜也最有效的例子：一個同學嫌棄每次寫周報要整理git log太麻煩，自己寫了一個腳本，自動從commit message里提取本周工作，再調(diào)大模型潤色成周報格式。他把這個腳本開源了，40多個star。 面試的時候直接演示，面試官當場說“這個好，能不能給我們團隊也分享下”。
本質(zhì)是一樣的：做出一個“有真實輸入、有明確輸出、能解決實際問題”的東西。 哪怕代碼只有200行，也比一個5000行的課設(shè)作業(yè)有說服力。
六、最后一個問題
回到開頭那個985碩士。他的簡歷現(xiàn)在還在我的面試記錄里，備注是“建議明年再投，先攢項目經(jīng)驗”。
我后來跟HR聊，她說最近收到的簡歷，越來越難篩選。因為大家簡歷上寫的項目都一樣：秒殺系統(tǒng)、RPC框架、在線聊天室。一看就是跟網(wǎng)課做的。
面試官想看到的東西其實很簡單：一個你真正從頭到尾負責過的、遇到過困難的、解決了的真實問題。
最后一個問題留給你，也是我每次面完都會在心里問自己的：
如果讓你現(xiàn)在放下手機，拿一張白紙，把你做過最“真”的那個項目按“背景、動作、結(jié)果、復盤”寫出來，你能寫得比這篇文章里的候選人Y更具體嗎？
（評論區(qū)可以寫一句話描述你的項目中最亮眼的那個功能。我隨機挑幾個回復，給出面試官視角的反饋。）
本文部分內(nèi)容參考了霍格沃茲測試開發(fā)學社整理的相關(guān)技術(shù)資料，主要涉及軟件測試、自動化測試、測試開發(fā)及 AI 測試等內(nèi)容，側(cè)重測試實踐、工具應用與工程經(jīng)驗整理。
