大家好，我是程式設計師魚皮。做知識分享這些年來，我看過太多簡歷、也幫忙修改過很多的簡歷，發現很多同學是完全不會寫簡歷的、會犯很多常見的問題，不能把自己的優勢充分展示出來，導致措施了很多面試機會，實在是很可惜。
為此，我寫了一份《程式設計師寫簡歷指南（保姆級）》專欄，多達幾萬字，幫大家瞭解：
-
如何寫一份規範的程式設計師簡歷？
-
如何在簡歷中增加亮點？
-
有哪些常見的簡歷問題？
-
如何利用寫簡歷來提升自己？
在投遞簡歷或者找他人幫忙看簡歷之前，請先把本專欄 一字不差地完整閱讀一遍 ，並且根據建議先自行修改簡歷，從而增加回復率。
對於不急著找工作的朋友，我也建議 儘早準備一份簡歷 ，並且隨著學習持續完善和最佳化，畢竟機會總是留給有準備的人。
下面分享專欄中含金量最高的一章 —— 簡歷問題和建議彙總。
魚皮花了整整 4 個晚上，對最近改過的幾百份簡歷進行了逐一分析和梳理，最終整理出了一份大家寫簡歷時經常出現的問題彙總文件，多達 50 多個高頻問題 ！如果你的簡歷沒有回覆，大機率是出現了下面的問題，解決掉之後，相信能夠幫大家提升簡歷回覆率。
由於篇幅過長，下面只分享有代表性的部分問題，可以在程式設計導航免費閱讀完整的《寫簡歷指南》：https://code-nav.cn/course/cv
1、整體
1.1 簡歷篇幅過長
建議：一般校招簡歷以 一頁紙 為最佳，保證面試官有耐心看下去。但注意，並不是說強制一頁紙，只是希望大家在簡歷上突出重點、惜字如金，而不是像記流水賬一樣什麼都寫。如果你能寫的內容就是很多的（比如衝擊大廠、工作 3 年以上、求職等級較高），那麼一頁紙以上完全沒問題。
1.3 簡歷篇幅不夠合理
建議：合理分配各部分內容佔用的篇幅，推薦的佔比如下：
-
個人資訊 5 ~ 10%
-
教育背景 10 ~ 15%
-
專業技能 20 ~ 30%
-
專案經歷 30 ~ 40%（工作 / 校園 / 科研等經歷也算在內），對絕大多數同學來說，這部分是 核心 ！
-
其他內容 0 ~ 20%（比如獎項、個人優勢等）
總之，儘量多寫經歷來體現自己的實踐能力、解決問題的能力，少寫一些正確的廢話（自我評價）。
1.4 簡歷模板不夠整潔
建議：一份優秀的簡歷必須在 外觀和內容 上都很出色，做到秀外慧中。所以，挑選一個好的簡歷模板是至關重要的！
簡歷的板塊劃分要清晰、排版要整潔、內容不要太擠或太空；色調不宜過暗或過亮，推薦藍色或淡灰色；色彩不要太豐富，要讓人看起來舒服。
可以嘗試魚皮自己用過的、非常精簡整齊的免費簡歷模板：https://laoyujianli.com/template/1685547340318179330
當然也可以嘗試其他模板，只要保證簡歷的整體結構是從上到下、佈局清晰、排版整齊、簡潔乾淨就好，拒絕花裡胡哨的色塊和圖示。
1.6 簡歷中出現錯別字
建議：整個簡歷中千萬不要有錯別字！尤其是技術名詞或者專業術語。否則會給人感覺非常不認真，競爭激烈時搞不好直接就掛了。
所以寫完簡歷後，一定要自己通讀至少 3 遍，保證行文通順、且無任何錯別字！
1.7 簡歷沒有明確的重點或求職方向
建議：整個簡歷一定要有一個明確的、和求職崗位匹配的方向。
我認識一些學的技術比較多的同學，他們可能又會 Python 又會 Java 又會前端，寫到簡歷上的專案也是各方向的都有，然後又沒有在簡歷的開頭註明 “求職意向”，就導致面試官完全不知道他要找哪個方向的工作。
並不是說會的技術、寫簡歷上的技術太多了不好，而是要有一個側重點。比如找 Java 崗位的工作就把 Java 專案放最上面，用更多的篇幅去介紹。也建議大家找工作前越早明確方向越好，不要到最後什麼都只學了一點，反而平平無奇了。
當然，如果你自己在多個方向學得都不錯，可以準備多份不同的定製化簡歷，並根據不同的崗位、公司和崗位描述來調整最佳化簡歷（比如增加部分細節、調換內容的順序等）。
比如你前後端都會，投遞後端開發崗位時，把後端技術放在前端技術上面去寫，專案經歷、實習經歷等都要側重於後端。
1.9 用詞不專業或不凝練
建議：簡歷上的每一個詞彙，都能夠反映出你的水平。
很多同學的簡歷用詞比較隨意，比如 “我用 axios 庫完成了對資料庫的查詢”。
其實大家都心知肚明，axios 是一個前端請求庫，可以和後臺進行互動，實現對資料的查詢和管理。
但上面那個表達，語言不夠清晰和凝練，還可能會給面試官一種感覺：你真的知道 axios 是什麼？你真的和後端聯調過麼？
所以，一定要保證簡歷上的每個詞都要 準確，不能產生歧義 。另外，儘量減少口語化的內容，不說用 xx 技術做了 xx，而是用（基於） xx 技術實現了 xx。
2、個人資訊
2.1 個人資訊佔用的篇幅過多
建議：一般個人資訊只佔用簡歷整體 5 ~ 10% 的篇幅即可。可以透過在一行內同時寫多個資訊來節約空間，並保證間距合理。
2.4 缺少個人相關連結
建議：因為簡歷的篇幅和內容有限，所以如果你的個人經歷很豐富，推薦在簡歷上補充一些連結，比如個人網站、個人部落格、個人作品集、程式碼倉庫等，體現你的實踐能力。
3、教育背景
3.2 主修課程浪費了空間
建議：本身就是計算機相關專業（或者專業和求職崗位相匹配）的同學不用再佔用空間去寫自己的主修課程了，因為學校教的內容往往比較基礎、而且面試官預設這個專業或者投遞這個崗位的同學都應該會這些課，寫上去也沒有什麼優勢。
但是建議非計算機相關專業（或者專業和求職崗位不匹配）的同學適當列舉關鍵主修課程，優先列舉和求職崗位相關的、取得分數較高的課。
如果有得分較高的課程（比如 90 分以上），可以在課程名後用括號補充分數。
4、技術棧
4.3 同一行列舉了多個不相關的技術
建議：從簡歷的技術棧部分中不僅可以看出你學過哪些技術、掌握哪些技術，還可以看出你對技術的分類和知識點的梳理能力。儘量每一行寫清楚一個技術，或者把一系列相關的技術放在同一行（比如 SSM 框架）；而不要把前端、後端、演算法等知識點混在同一行去寫。
4.4 缺少你對 XX 技術的實踐應用能力
建議：技術棧部分光寫自己會什麼技術、瞭解哪些知識是不夠的，因為大多數面試官重視的是你的實踐能力，即你能不能使用該技術完成工作，而不是紙上談兵。因此可以適當補充半句：“你能用這些技術做什麼？”，從而體現你的實踐能力。公司往往傾向於選擇問題解決能力強、實踐經驗豐富的同學。
4.6 XX 內容寫得過於寬泛和模糊，缺乏可信度
建議：儘量不要寫過於寬泛、模糊不清、無法證明的的內容，比如：
-
熟悉物件導向程式設計
-
有一定後端基礎
-
瞭解常見效能最佳化手段
-
有良好的開發規範
-
具備良好的編碼能力
專業的面試官基本就預設當做你不瞭解、或者不具備這些能力。
你應當把這些寬泛的知識具體化，比如：
-
熟悉物件導向程式設計 => 瞭解哪些軟體開發原則、熟悉哪些設計模式等？
-
有一定後端基礎 => 你學過哪些後端知識？
-
瞭解常見效能最佳化手段 => 具體瞭解或實踐過哪些效能最佳化手段？
-
有良好的開發規範 => 熟悉或使用過哪些開發規範、用過什麼工具來規範團隊開發？
-
具備良好的編碼能力 => 會用哪些開發工具、熟悉哪些程式設計技巧？
寫得更具體一些，才會更有說服力。
5、榮譽獎項
5.1 未重點突出高階別、高含金量的獎項
建議：獲得獎項的級別或含金量很高時，建議把獎項級別加粗來吸引面試官，比如 XX 競賽全國 一等獎 。
6、工作經歷（實習經歷）
6.1 工作描述過於簡單
建議：寫工作內容時，可以適當具體一些，比如補充你在這家公司用了什麼技術、負責了什麼樣的專案、使用過什麼方法和工具、解決過什麼問題等，從而增加真實感。
6.3 缺少工作成果和個人價值的體現
建議：儘量不要寫自己在工作中收穫了什麼、學到了什麼，而是多寫自己做了什麼、做出了什麼成果，尤其是列舉有明確資料的成果，比如 “寫過 XX 篇文件、做過 X 場技術分享、給專案帶來了多少的收入增長” 等，將更能體現自己的能力和價值。
如果目前沒有可寫的成果，建議在之後的工作中多思考如何積累這些內容。
6.4 工作職責不明確
建議：即使你在這家公司做了很多不同崗位的工作，也要有個重點突出的工作職責，而不是什麼都寫。
6.6 XX 工作寫得過於寬泛和模糊，缺乏可信度
建議：儘量讓你的工作描述更有說服力，比如寫 “與產品經理高效溝通”，不如改成去寫：“你是怎麼實現和他人的高效溝通？”，比如用了什麼專案管理工具？或者跟前端協作時用了什麼介面管理工具？
7、專案經歷
7.1 專案工作描述的寫法存在不足
建議：寫專案的工作描述時，不要把所有內容混在一起，而是建議用列表的形式 分點 去寫 ，每個工作 / 亮點獨佔一行，每一點 儘量具體 。寫的越具體，往往越體現真實性。
可用 STAR 分析法（場景、任務、行動、成果）來梳理自己的核心工作。
提供 2 個標準句式，括號部分表示可選填：
-
（在 xx 公司 xx 專案中，）在 xx 情況下，運用 xx 技術，解決了 xx（或者最佳化了 xx），達到了 xx 效果（或者帶來 xx 收益等）。
-
為了解決 xx 問題，選用 xx 技術（或方法）實現了 xx，並使用 xx 技術（或方法）最佳化了 xx，實測提升了 xx 效能（或者降低了 xx 等）。
舉個例子：為適應產品特性、加快迭代速度，後端由 Springboot 重構至 Node.js ，資料庫由 MySQL 遷移至 MongoDB ，實現了前後一體的 集中式配置中心 ，提高了接近 1 倍 的開發效率。
注意每個小點的長度不宜過長，要留給面試官提問的空間。
7.2 技術棧提到的技術沒有在專案中運用
建議：技術棧裡提到的技術和知識點儘量多在專案經歷中體現，否則容易給面試官一種 “只是學過或聽說過，而不會運用” 的感覺。
7.3 專案技術或業務相似度過高
建議：儘量不要寫運用了太多重複技術棧、或者業務相似的專案，最好能夠讓各個專案形成互補。
前端的話可以考慮一個 PC 端 + 一個移動端專案或者技術類專案（腳手架、元件庫等）；後端可以考慮一個業務系統（比如管理系統、電商、社群、部落格等）+ 一個技術類框架（比如 RPC、迷你 Spring、伺服器等）。
7.5 專案介紹太長
建議：注意每個專案裡內容的比重，專案介紹的佔比不要太多，一般 1 - 2 行足夠了。
記住，你不是在做推廣！在簡歷中，面試官更關注的是 你在專案中負責什麼、做了什麼、怎麼透過技術和設計能力去解決問題的 。至於專案本身的介紹，用一兩句話直擊核心就好，重點在於交代 和你工作有關 的內容，其餘的可以在面試時展開介紹。
7.6 專案工作描述過於直白平淡
建議：要想專案有亮點，需要 深一度。不能只寫你完成了什麼工作，而是要有一定的最佳化和擴充套件，讓整句話讀起來有起伏和遞進。
比如你可以在完成某功能的基礎上進一步最佳化，或者改造現有的專案框架、推陳出新，或者提升系統各方面的效能（可用性、穩定性、使用者體驗、吞吐量、時延等）。
建議大家多去了解你專案中用到的技術的同類技術，對這些技術的優缺點和適合的應用場景有個大致的印象。
7.7 專案沒有提供可訪問的線上地址
建議：條件允許的話，強烈建議提供可線上訪問的專案地址（域名儘量簡短，好讓面試官訪問），從而體現你專案的真實性，將會是一個非常不錯的加分項。
因為絕大多數同學寫專案經歷的時候，不放已上線的專案地址。有的時候你寫的點再多、吹得天花亂墜，都不如直接放一個可訪問的專案地址來得實在，能夠直接證明你真的做過這個專案、從而體現你的專案經驗。對於前端同學來說這點更重要，直接給面試官看體驗效果最實在。你做的網站用不用心，一看便知。
7.10 XX 技術不適合應用於當前專案的業務場景
建議：每一個技術的運用都要切合實際的業務場景，不要為了用技術而用技術。
在學習某個技術時必須要明確它的應用場景，而且在選用某個技術時，多思考你為什麼用這項技術而不用同類的。比如你透過調研和對比發現你用的技術在當前業務場景下優勢更明顯，那麼可以在專案的工作描述中補充這些對比以及你的思考，從而體現你的技術選型能力。
8、個人優勢（自我評價）
8.1 自我評價沒有說服力，屬於正確的廢話
建議：自我評價板塊不是必須要寫的。如果要寫，就 必須讓你的自我評價有信服力 ！
不要只說自己哪裡的能力強、怎麼怎麼厲害，而是需要一些事例、資料、證據來證明。
舉些例子：
-
我學習能力強，對新技術有強烈的好奇心 => 補充：曾透過官方文件、自主查閱資料自學了 XX、XX 新技術，並透過 RSS 持續關注該技術最新動態。
-
我樂於從事有挑戰性的工作 => 補充：我曾經擔任 XX 隊長，在 XX 困難的條件下，解決了 XX 問題，取得了 XX 成果。
-
我喜歡分享知識、善於總結 => 補充：連續 XX 天釋出個人部落格，釋出過 XX 個學習總結等等
-
我很帥 => 補充個人照片
這樣寫自我評價，就不再是虛的了，而是真的能讓面試官感受到你的這些優點。
這裡有個小技巧，可以根據目標公司的崗位要求去寫自我評價，做到對號入座。
比如公司要求招有團隊協作經驗的，那就寫：我善於團隊合作，曾經組隊參與 XX、XX 專案，統籌負責了 XX、XX，怎麼提升團隊工作效率之類的。
這樣從招聘者的角度來看，你是有用心準備過的，目的性明確，也是加分項。
OK，以上就是本章分享，內容很多，大家慢慢消化。有幫助的話記得點贊、收藏哦~ 🌹
可以在程式設計導航免費閱讀完整的《寫簡歷指南》：https://code-nav.cn/course/cv