去年幫一個做後端的同事內推，他技術在同齡人裡算中上，演算法和系統設計都聊得不錯，結果 HR 那邊初篩就沒過。我拿過他的履歷一看，第一反應是：這不應該啊。再仔細讀了一遍，發現問題了——他的履歷不是不好，是「外行看不懂，內行不想看」。
我舉一個地方。他寫了一段公司內部做過的專案：
使用 Spring Cloud 搭建微服務架構，重構了原有的單體系統，解決了業務耦合度高的問題。資料層採用了 MySQL + Redis + Elasticsearch 的組合方案，訊息佇列使用 Kafka 做非同步解耦。
技術棧寫得挺全，但這段話拿到任何一個面試官面前，對方腦子裡只有一個問題：你做了什麼，然後呢？重構完了系統變快了嗎？使用者體感有變化嗎？業務方說什麼了？——全都沒寫。
這其實是工程師寫履歷的通病：我們太習慣用技術語言描述自己的工作了。程式碼寫註解是給別人看的，履歷寫技術方案也像是寫給同事看的。但真正篩你履歷的第一個人往往是 HR，不是技術經理。即使到了技術面，面試官要看的也不是你能列多少技術名詞，而是你用了這些技術到底解決了什麼事。
下面拆 5 個工程師履歷裡最常出現的問題，每個都有改前改後。
案例 1：技術棧寫了一整排，全是名詞
背景： 阿凱，三年 Java 開發，履歷最顯眼的位置放了一行技術棧：
熟練掌握 Java、Python、Go、Spring Boot、MyBatis、MySQL、Redis、Kafka、RabbitMQ、ES、Docker、K8s、Jenkins、Linux……
這行寫得越長，含金量越低。因為面試官看到一排技術名詞的時候，不會覺得你全會，只會覺得你把「用過一次」和「精通」混在一起寫了。更關鍵的是，你到底擅長哪個方向、在哪塊能立刻幹活，完全看不出來。
而且每個工程師都知道：同一個技術，寫了一年 CRUD 和做了一年效能調校，是完全兩個段位。技術棧列表抹平了這個差距。
改後：
主棧： Java / Spring Boot / MySQL（3 年，專注高併發場景下的伺服器端開發）
輔助： Redis、Kafka、Elasticsearch（有獨立選型和調校經驗）
DevOps： Docker、K8s（日常使用，能獨立寫 Dockerfile 和基礎部署腳本）
差異在哪？原來是一鍋燉，現在是三層分級。面試官掃一眼就知道你的核心戰鬥力在 Java 後端，而且不是只會寫業務，有中介軟體調校經驗。那些你只是「用過」的技術可以不寫，或者在面試裡被問到了再聊。履歷上放出來的每一個技術名詞，你都做好被深問的準備——這是工程師履歷的鐵律。
案例 2：把自己寫成了「執行層」，沒體現技術決策
背景： 小何，五年後端開發，前後待過兩家公司。他的每段工作經歷都長這樣：
負責使用者中心、訂單、支付等核心模組的日常開發和維護，參與需求評審和技術方案設計，配合測試團隊完成功能驗證和上線。
你能看出他五年裡和兩年的差別嗎？看不出來。這段話任何一個做後端的人都能寫。他把自己描述成了一個一直在「接需求→寫程式碼→上線」這個循環裡的執行者。
但小何的真實情況完全不是這樣。他在第一家公司的時候，使用者中心模組最早的資料庫設計是他主導的，分庫分表方案也是他提的。第二家公司裡，他推動了團隊從 SVN 遷移到 Git，還搭了第一版 CI/CD 流水線。這些東西他履歷上一個字都沒提，因為他覺得「這不就是正常工作嗎」。
改後：
主導使用者中心從 0 到 1 的資料庫設計，預估業務增長速度後提前規劃分庫分表方案，支撐兩年內使用者量從 50 萬增長至 600 萬+，資料庫查詢效能未出現顯著衰減。
推動團隊從 SVN 遷移到 Git，搭建團隊第一版基於 Jenkins 的 CI/CD 流水線。遷移後程式碼衝突率明顯下降，功能上線週期從雙週縮短至一週內。
第二段尤其關鍵。它展現的不是「我會用 Jenkins」，而是「我看到了團隊流程裡的問題，提出了方案並推動了落地」——這是高級工程師和普通工程師的分界線。面試官在看一個五年經驗的履歷時，核心在找的訊號就是這個：你能不能發現問題並推動解決，而不只是把分配給你的任務做完。
案例 3：GitHub 放了一排連結，什麼都沒說
背景： 小王，兩年經驗的前端，履歷的「個人專案」部分貼了三個 GitHub 連結，後面分別跟了一句簡介：
基於 React 的仿網易雲音樂播放器：連結
一個簡單的部落格系統：連結
參加 Hackathon 的專案：連結
面試官看到這樣一段，99% 的情況不會點開連結。原因很簡單：他沒時間。你給他三個連結但不告訴他裡面有什麼值得看的，他就當沒看到。
而且說實話，這三個專案的含金量差距很大——仿網易雲那個他斷斷續續做了兩個月，star 有一百多個；部落格系統三天寫完的；Hackathon 的專案是他和兩個後端一起做的，他負責了整個前端和一部分 UI 設計。但這些資訊全都沒寫出來，三個專案看起來像三個同等量級的課後作業。
改後：
React 仿網易雲音樂播放器 | 個人專案 | 150+ star
獨立完成從 UI 設計到前端實現的全流程，核心功能包括播放控制、歌詞同步滾動、歌單管理等。使用 React + Redux + Hooks，配合 NeteaseCloudMusicApi 實現真實資料互動。專案上線後在掘金被推薦至首頁，獲得 300+ 點讚。Hackathon 專案「XX」 | 3 人團隊 | 獲二等獎
負責前端架構設計和全部頁面開發，使用 Vue3 + TypeScript，兩天內完成從原型到上線的全流程。專案核心亮點是即時協作編輯功能，使用 WebSocket + CRDT 方案實現。
改完後 GitHub 連結有沒有人點開已經不那麼重要了——因為光看文字描述，面試官已經對專案難度、你的角色和技術深度有了判斷。連結只是備查。
案例 4：技術能力完全沒和業務結果掛鉤
背景： 老李，六年演算法工程師，在一家電商公司做推薦系統。履歷上寫的：
負責推薦系統的演算法迭代，包括召回、排序和重排等模組的優化。使用深度學習模型對使用者行為進行建模，提升了推薦的準確性。參與 A/B 實驗平台的建設。
這段話任何一個做推薦的演算法工程師都能寫。「提升了推薦的準確性」——提升了多少？準確性的定義是什麼？是 CTR 還是轉化率還是 GMV？面試官看完完全不知道你優化的效果到底是什麼量級。
但老李的實際情況很拿得出手：他把首頁推薦 CTR 從 7.2% 提到了 9.8%，而且是在使用者量翻了將近一倍的情況下保持住的。他做的多目標排序模型把加購率和 CTR 的矛盾平衡得很漂亮。這些東西他履歷上一個字沒寫，因為他覺得「那是業務指標，不是我自己的技術成果」。
這就是最大的誤區。技術只有落到業務上才有商業價值，而商業價值是公司願意付高薪請你的唯一原因。一個只會說「我優化了模型」的演算法工程師，和一個能說「我把 CTR 提升了 2.6 個百分點，在千萬級使用者量下穩定運行」的演算法工程師，市場價差至少 30%。
改後：
負責推薦系統全鏈路（召回→排序→重排）的演算法迭代。主導多目標排序模型的升級，平衡 CTR（7.2% → 9.8%，+2.6pp）與加購率，在 DAU 翻倍至千萬級期間保持推薦服務 P99 延遲 ≤ 80ms。
設計並推動 A/B 實驗平台的指標體系搭建，將實驗分析週期從週級別縮短至天級別，全年支援 200+ 次演算法實驗。
案例 5：專案經驗寫成了架構文件
背景： 小唐，四年後端，做的是一個內部資料平台。履歷上的專案經驗這樣寫的：
專案名稱： 企業級資料中台
技術棧： Spring Boot + Flink + ClickHouse + Kafka
專案描述： 該專案採用微服務架構設計，分為資料採集層、計算層、儲存層和應用層。資料採集層支援 MySQL Binlog、API 資料來源和檔案上傳三種方式。計算層基於 Flink 實現流批一體，儲存層使用 ClickHouse 做即時 OLAP 分析。
如果你是一個技術經理，你看完這段話，第一反應是：「這是你們公司的架構文件？」
履歷不是技術方案，面試官不需要知道你的系統分了幾層、每層叫什麼名字。他需要知道的是：你在這個專案裡做了什麼、為什麼做、做到了什麼程度。架構圖可以面試的時候拿出來畫，履歷上寫架構分層等於浪費篇幅。
小唐在這個專案裡其實做了很多值得寫的事：他設計的 Binlog 採集方案效能比原來的方案提升了 4 倍，他一個人啃了 ClickHouse 的物化視圖優化把某個核心報表的查詢時間從 40 秒壓到了 3 秒。
改後：
企業級資料中台 | 核心開發
重新設計 Binlog 即時採集方案，將資料延遲從 5s 降至 1s 以內，吞吐量提升 4 倍，支撐日均 3 億+ 條資料同步。
獨立完成 ClickHouse 物化視圖優化，將 3 張核心報表的查詢耗時從 40s+ 壓縮至 3s 以內，業務方從「每天等報表」變成了「隨時查」。
專案上線後資料接入效率明顯提升，接入一個新的業務線資料來源從原來的 3 天縮短到半天內。
三句話，每一句都有一個具體的問題→解決的軌跡。面試官看第一句就知道這個人會做效能優化，看第二句知道他不是只會用現成工具，看第三句知道他的工作影響到了團隊效率。
工程師履歷的五個專屬原則
1. 技術棧分級，不要一鍋燉
把你的技術能力分成三個梯隊：主棧（靠這個吃飯的）、輔助（有獨立調校經驗的）、了解（會用但不深）。主棧不超過 3 個技術點，輔助 3-5 個，了解的可以不寫。面試官只需要知道你最硬的那幾塊技能。
2. 每個技術決策都回答「為什麼」和「結果如何」
差：使用 Redis 做快取。
好：引入 Redis 快取層，將商品詳情頁 API 回應時間從 680ms 降至 45ms。
不是「用了什麼技術」，而是「因為什麼痛點用了什麼技術，結果發生了什麼變化」。技術只是手段，解決問題才是價值。
3. 沒有不能量化的技術工作，只有沒找到角度
如果你實在找不到一個百分比數字，換角度：
- 你的系統扛了多少併發？（峰值 QPS）
- 你的程式碼影響了多少人？（覆蓋了多少使用者／業務線）
- 你做的事情每天被多少人用？（日均呼叫量／活躍使用者數）
- 你做的事情和原來比快了多少、省了多少？（耗時變化、成本變化）
一個後端說「我做的這個 API 每天被呼叫 800 萬次，上線半年沒出過故障」——這就夠了。
4. GitHub 專案要寫說明，不只是放連結
每個專案最少三行描述：你做了什麼、用了什麼技術、有什麼回饋或影響力。如果你做過開源貢獻，不要只寫「給 XX 專案提過 PR」，寫明你修了什麼 Bug、涉及多少程式碼量、PR 有沒有被 merge。
5. 工作經歷要體現出你在團隊裡是什麼角色
兩年以下：可以是執行者，但要寫出你獨立完成了什麼模組。
三到五年：要能看出你主導過某些技術方案，不只是被分配任務。
五年以上：必須能看出你影響過團隊或業務方向，不管是透過技術基建、流程優化還是帶人。
寫完後，五條工程師專屬自查
- 技術棧那欄掃一眼，能在 5 秒內說出你最核心的方向嗎？
- 你的工作經歷裡，有多少條是「你做了什麼 → 導致了什麼結果」這個結構的？
- GitHub 連結旁邊，有沒有寫明專案亮點和你的角色？
- 你能在自己的履歷裡找到 3 個以上具體的數字嗎？（QPS、使用者量、耗時、效率提升……隨便什麼數字都行）
- 如果你是 HR，完全不懂技術，看完你的履歷能大概說出你做的是什麼嗎？
說實話，工程師寫履歷最大的障礙不是不會寫，而是總覺得「技術牛就夠了，履歷隨便寫寫就行」。但現實是，你的技術再牛，過不了履歷關就沒有展示的機會。花一個下午把自己的履歷按上面的原則過一遍，比你刷十道演算法題的投資回報率高得多。
如果你改了一遍還是不確定效果——自己看自己的東西確實容易「燈下黑」。可以把履歷上傳到 DeepResume 做一次診斷，系統會從技術關鍵詞覆蓋、成果量化和表達清晰度三個維度幫你過一遍，告訴你哪裡還可以更強。