前端 Offer 提速：如何写出有亮点的简历
點擊下方卡片關注我、加個星標。
學習源碼整體架構系列、年度總結、JS基礎系列
先來個靈魂拷問：「你與他人相比，有什么能形成明顯區分度的優勢條件？」
這里有兩個層面的問題，一是「如何識別出你的優勢條件」，畢竟大多數人大多數時候可能都是在做業務，臨到寫簡歷的時候要求總結日常工作中跟別人不一樣的點，確實挺難的，怎么辦？第二個問題是你可能已經挖掘到自己的優勢，但是「在簡歷里面怎么組織內容，怎么表達才能突出，讓面試官迅速 get 到點呢」？
這事并不容易，我見過的不少簡歷，特別是5年以下的同學很多都寫的不達預期，有一些是真的平平無奇，有一些是明明有不錯的經歷，但就是沒有表達出來，幾分鐘內很難 get 到亮點。最近剛好有不少人找我內推，我都會盡力幫著看看有沒有什么明顯的問題，在溝通過程中慢慢總結出了一些共性問題，于是有了這篇文章，希望能幫助正在或即將找工作的同學。
本文不會講太多基礎問題，例如格式、字號、字體等問題，這些網上已經有很多文章，沒必要重復討論。本文會更聚焦于內容，聚焦于「如何在有限篇幅內突出你的個人優勢」，包括如何在日常工作中挖掘亮點，如何組織語言讓面試官能夠迅速理解你的亮點，以及需要避開那些可能會造成負面效果的坑。有任何想法意見歡迎留言討論，如果對你確實有幫助希望不要吝嗇您的贊，這對我很重要，能激勵我持續寫更多文章。
如何挖掘亮點
重點是持之以恒的記錄，積累足夠的素材。在此基礎上學會識別對于求職來說什么是加分項，什么不是。
堅持記錄
寫作需要素材，寫簡歷當然也需要素材，簡歷的素材就來自于我們日積月累的工作，可以養成習慣，有意識地將一些經歷以文本的形式記錄下來。
記錄的方式有很多，比如技術博客、項目日志、年度總結甚至是周報，這種書面形式的留存總結能夠隨時 review，所謂好記性不如爛筆頭，這些信息最終可能就變成你簡歷的重要素材。
當然，也沒必要事無巨細記流水賬，可以把有限的精力放在一些重要節點上：
項目啟動時，技術選型的過程、思考、論據、結論
項目結束時，執行過程的復盤、反思、重點難點、數據指標
使用開源框架遇到問題時，調試過程、邏輯推導、解決方案
學習新技術時，
解決性能問題時，優化前后有多大的提升、具體有哪些優化措施，用了哪些工具，如何實行
這些節點都是個人成長的良好契機，把它們記下來，記錄下你在這個過程中都遇到了哪些問題，分別是怎么解決的，寫簡歷的時候翻一番總比憑感覺回想靠譜得多。
識別亮點
在積累足夠多的素材之后，就可以根據面試的公司、業務、目標崗位從素材中選取更可能被面試官相中，也就是所謂“亮點”來組織簡歷了。
亮點應該是那些能讓你顯得與眾不同的經歷，比如說：
做過一些深度的性能優化，并且有比較大的性能收益，能量化提升空間的
做過一些業務邏輯特別復雜、業務影響力特別大的項目
推進過一些制度、工具，深刻影響團隊乃至整個公司的工作流程、工作方式，且整體有提效作用
用一些不太常見的技術，解決過對前端來說比較偏門的問題，例如視頻直播
做過有一定名氣，能真正解決技術問題的開源項目，demo、awesome-xxx 類的不在此列
深入學習一些工具的用法，以此解決了一些工程化、開發效率、性能方面的問題
給知名開源項目，提交過真正復雜有意義的MR，typo 類修復不在此列
鉆研過一些框架的原理，并能持續輸出足夠多的有技術深度的文章，或者明確解決過項目中出現的復雜問題
...
這個列表還可以繼續羅列下去，不同人，甚至同一人隨著經驗、認知的增長在不同時期都會有不同的判斷標準，所以這里沒有標準答案，盡力就好。
什么不是亮點
梳理過程要注意避開哪些不能給你加分的信息，要理智地反思一遍，這段經歷是否足夠復雜？是否足夠表現出你的最高水平？對于這里面用到的技術，你真的掌握的很好，能應對面試嗎？
這里也列舉幾種反模式：
單點技術突破不算亮點，例如解決了某個 UI 框架的單個樣式bug，體量太小
做了很多項目，不能稱之為亮點，只能證明你可能已經工作了很久
技術框架、工具一直停留在用的階段，對內部實現原理完全不清楚
僅僅解決一些很尋常，很普遍，網上有大量現成方案的問題不能算亮點
如何表達亮點
積累足夠多素材之后，接下來需要探究一下如何通過簡歷高效傳達給預期讀者。面試官通常都很忙，特別是很多大廠面試官可能每天要瀏覽幾百上千份簡歷，如何組織內容才能高效傳達你的信息？如何在短時間內抓住面試官的注意力？更進一步的，如何引導后續面試的內容？
首先是基本格式，這方面比較簡單，上網找個你覺得最簡潔清爽的模板就行了，我個人比較喜歡這個。基本格式之外更重要的其實是內容，如何在短短一兩頁內呈現你的能力、專業度、人設等，下面展開聊聊。
樹立技術人設
所謂人設，可以簡化理解為我們做過什么，以及我們將要做什么。
做過什么
落到簡歷上，通常需要以項目經歷、掌握技能這兩個角度呈現，項目經歷是簡歷的核心組成，大多數面試官都非常看重這一part，千萬不要盲目寫，要有條理，有次序，有重點，我個人總結出幾條規則：
有意識地挑選幾段能突出某項、某系列技能的項目經歷，例如你要突出 vue ，那么就應該盡量圍繞這個主題展開，避免一會是vue，一會是 Lua 這種牛頭不對馬嘴的情況，要讓面試官能立即 get 到你的技術專長就是 vue
組織好語言，項目經歷在時間軸上從遠到近，圍繞你所設定的主題逐步細化、深化，例如最開始的項目經歷里面你只是用了這項技術，后續逐漸開始更好地應用生態；更理解實現原理并能夠解決復雜的性能、工程化問題；甚至更進一步開發了一些有價值的開源工具，或者輸出了一些高質量的文檔反哺社區。要讓面試官能夠通過項目經歷感受到你從小白逐步成長的過程
前面兩點都是在表現深度，對于工作3年以上的同學，通常既要求有深度，又要求有一定的廣度、視野，說實話這并不容易做到，有一個方法就是圍繞上面樹立下來的深度，向外擴展補充與前端基礎強相關的工作經歷，比如說 http、TLS、http2、TCP 等網絡棧相關的性能優化、版本升級經歷；或者，內存泄露的排查修復經驗、FPS、FCP、FMP 之類指標過低的優化經驗等等；又或者一些更復雜的開發場景，例如編輯器、編譯器、可視化、復雜動畫、多媒體等等
總結下來，盡量做到一專多能，既有深度又有廣度，深度能夠幫助面試官迅速判斷你的技術棧，降低心智負擔，看起來不累；廣度能夠幫助面試官識別你的學習能力、潛力、對復雜開發場景的承受度等。在基本技術人設之外，最好還能順帶傳達出你對所在行業的認知深度，后面會聊到。
近期準備做什么
很多面試官喜歡問：你未來3-5年的職業規劃是怎樣的？很多人會覺得“職業規劃”這玩意兒挺虛的，不愿意花時間去認真梳理。我的觀點，職業規劃首先是給自己看的，是給你自己設定了一條路徑，日常工作中需要不斷做出選擇，心里的這條路徑越明確，做決定的成本會越低，會看到自己不斷在接近目標。
對于面試官來說，這個問題大部分情況下首先考察你對自己的職業生涯有沒有足夠清晰的認知和目標感，三天打魚兩天曬網就跟頻繁跳槽一樣，沒辦法讓你在垂直領域積累足夠的深度；其次，考察你規劃的天花板，如果沒有表現出技術、職業野心，那容易讓人 judge 你的發展潛力；最后，考察你的規劃與團隊的 match 程度，這就見仁見智了，沒法一概而論。
所以對人對己都很有必要先花點時間，想清楚自己未來3-5年要做什么，做到什么程度，樹立一個明確的職業目標。這個話題有點脫離本文的主題，因為你很難在簡歷中表達出你的職業規劃，不過可以換個角度，在簡歷中以附加材料的形式呈現，比如個人博客、github。
博客的話可以圍繞你設定的職業規劃，連續一段時間圍繞這個主題寫多篇博客，讓面試官感受到你既有想法，又確實有在這個方向上努力。
Github 的話也是一樣的，連續一段時間在這個主題上輸出一些代碼質量較優的倉庫，通常面試官進來第一眼是看star，其次是看代碼風格，如果不能攢到 100 star 以上，就盡量把代碼寫好看一點，這也是加分項。
量化
數字是個大殺器！正確使用各種量化指標能讓你的簡歷更有重心，更有可信度，更容易獲得認可。很多東西可以量化，比如說：
「性能提升」：性能優化通常是一種很綜合很復雜的場景，需要足夠的知識深度，需要靈活運用各種調試工具，所以面試官通常看到這種經歷都會多加關注，如果能推斷出優化前后的指標變化就更好了
「業務提效」：這方面通常是引入或者創造了某類工具，改變或優化原有工作流程達到局部或全局更優解，從而提升整體效率，優化方向不局限于開發團隊內部。這類優化與業務緊密結合，換個業務方向的面試官可能很難從你做的事情 get 到點，如果能提供一些具體的優化數值是有助于讀者做判斷的，可以是流程提效了 xx %、工單完成率提升了 xx，達到xx、響應及時度提升了 xx 之類的
「業務推進」：假如有幸參與到一個發展比較猛的項目，而且你在這個項目中是比較核心的成員，那么可以考慮總結一下從開始到你準備離開的時候，項目的業務指標有多大的增長
「影響力」：影響力這個概念就比較主觀難以量化了，但是也可以用別的指標從旁佐證，比如工作期間做了 xx 次部門內分享、xx 次公司范圍分享、xx 次行業大型分享；或者是，輸出了 xx 份博客之類的
注意，前提是正確，不要為了量化而刻意捏造或者拍一些不存在的數字，拍出來的數字通常很容易識穿，面試時容易露餡，沒必要。建議在日常工作中養成用數據思維，包括業務上的，技術上的，特別做一些優化的時候，記錄優化前后的數值情況，寫簡歷時自然有素材。
業務深度
先分享一下我個人經歷，我曾經在一家特別小而美的人工智能創業公司工作了三年，雖然職能是前端，但是過程中并沒有把自己的工作邊界圈的涇渭分明，經常很發散地去支援服務端、數據甚至是運營團隊的工作，比如：
用 Python + celery 開發定時結算系統，降低對賬成本，壓縮結算周期
用 node + ffmpeg + docker 做了一套視頻流式處理工具，能夠根據配置對一批視頻做抽幀、截取片段、壓縮、轉格式等操作
某個 POC 性質的項目中，用 Python + caffe 調用深度學習模型實現圖像識別服務，配合瀏覽器上調用 media 接口將攝像頭畫面傳回服務器識別出畫面中的物品
短期來看確實沒有明顯收益，但是在我離職寫簡歷時，發現這些經歷串聯起來，讓我對深度學習的工作過程、原理、局限性、工具、指標等概念的理解已經足夠支撐我在面試過程應對各種問題，后面找工作的時候聊到這一部分都會特別順利。
這里不是鼓勵大家去做很多前端領域之外的事情，只是想表達對業務、合作團隊的了解與洞察程度可以映射出你對工作的投入度，而市場通常都會比較青睞投入度高的人。所以在日常工作中可以有意識地用各種方法跨出職能邊界，去了解其他團隊在做什么，怎么做的，平常會用哪些工具技術，有沒有存在什么問題，這些問題有沒有辦法用前端的技術解決，等等。
當你對行業形成足夠立體的認知之后，寫簡歷、面試的時候可能就可以展現出在這個領域的橫向認知，反過來說如果你過去對工作的認知一直停留在前端領域內，隔壁在做什么，怎么做，用什么做；業務線接下來有什么計劃，可能需要用到什么新技術，這些問題都回答不上來的話，面試官容易懷疑你對工作的投入度。
項目經歷怎么寫
不要只寫你做了什么，更重要的是突出你用什么方法，解決了什么問題，收益是什么，要能夠形成一條完整的邏輯閉環，面試官才有足夠信息來判斷你項目經歷的價值。
比如說，對于這樣一段經歷：在 XXX 項目中引入性能及異常上報工具，后續團隊內基于回收的數據有針對性的做了一些優化，我曾經收到一份簡歷是這么寫的：
?集成監控SDK, 包含頁面測速, 錯誤異常, API質量, 白屏異常, URL異常, 收集項目中的各類錯誤信息并上報, 通過 performance API進行測速分析, 封裝基礎庫ajax上報API錯誤信息; 在資源監控系統通過對各個端上報的指標進行清洗, 聚合以及數據分析, 錯誤模塊聚合sourcemap還原源代碼, 便于修復線上問題; 重構項目代碼與調用鏈, 加載時間縮短20%;
?這里面有一些明顯問題：
語言組織太過平鋪直書，感知不到重點
監控SDK是啥？集成方式又是怎么樣的？這里面有多少工作量？有那些難點？
形式與描述不好，閱讀成本高
清洗、聚合、數據分析分別又是啥？前端在這里面做了什么？
錯誤模塊聚合sourcemap？只有錯誤模塊嗎？聚合又是什么鬼？聚合還原完為什么就能“便于修復”線上問題？sourcemap 的原理又是什么？
“重構項目代碼” 與前面說的“集成監控SDK” 是什么關系？為什么要寫在一起？
加載時間具體是指哪個指標？具體做了什么縮短的？
總結下來，我個人覺得問題主要是描述不清晰，很難理解這到底是一件什么事情，怎么做的，最后收益又怎么樣。比較好的方式應該是：
?引入(基于) xxx 搭建性能與異常監控體系，覆蓋 FCP/FP/FMP/TTI/LCP 等性能指標；覆蓋白屏、頁面奔潰、JS 異常、http異常等錯誤場景。
在上述監控體系基礎上，逐步推演出核心性能指標模型，以此為決策依據逐步執行圖像合并、代碼分包、緩存策略優化、首屏渲染優化、SSR 等措施，前端性能平均指標提升 xx%，QPS 提升 xx%
在上述監控體系基礎上，優化項目 CI 工序，接入基于 webpack 的 sourcemap 映射能力，線上問題能夠直接映射回源碼堆棧，線上問題平均修復時間降低 xx%
這不是最好的表述，但是這已經充分說明了：用什么方式方法、具體解決了什么問題、最終收益是什么，相比于前面的寫法，敘述上更嚴謹也更容易理解一些。
如何做減法
簡歷內容在“歷”，但是預設條件是“簡”，不要寫成流水賬，不要事無巨細寫成了自傳。簡歷內容絕非多多益善的，寫的越多閱讀成本越高，越難以抓到重點，所以應當適度精簡。
注意項目路徑
如果你已經有比較豐富的項目經歷，千萬不要不做選擇全部往簡歷懟，不是項目經歷越多越好，應該根據結合個人情況，精心挑選幾段有代表性的，例如：
能表現出技術深度，或者業務復雜度、業務體量的
能表現學習能力的，例如曾經為了使用一個文檔缺失的框架，花了一段時間看完源碼總結出用法，最終能夠
能夠構建起“成長路徑”，這一part在 “樹立技術人設”一節已經講的比較細了
盡量避開這些類型的項目：
單純練手，復雜度、業務價值都特別低的
太過簡單的，例如簡單的活動頁
仿 xxx 型的，培訓班很喜歡搞這種練習題，不少候選人就拿這個當實際項目寫到簡歷上了
慎用技術名詞
前端簡歷中常常會有一 part 總結自己的技術棧，這里一定一定要慎重，我經常遇到很多技術棧特別廣泛，但凡用過的技術都往上面寫的簡歷，一個是看起來、分析起來累；一個是面試過程一問三不知。我建議使用任何技術名詞前可以先問問自己：
這種技術會給你的簡歷加分嗎？
你的使用頻率、了解程度足夠高嗎？足夠應對可能出現的各種技術問題嗎？
這項技術足以讓你與其他候選人拉開距離嗎？
比如說，“我曾經用 grunt 搭建過一套完整的工程體系” 這樣的經歷不能說完全沒有價值，但放在 webpack、vite、snowpack、parcel、rollup 大行其道的當代，這份經歷能給你加分嗎？反而可能會讓面試官質疑你技術更新迭代的速度會不會太慢了？
又比如說，“我曾經寫個一個帶視頻的網頁” 這樣的經歷還不足以支撐你在簡歷里面寫“具備視頻編解碼能力”，如果更進一步“我曾經基于 HLS + FFMPEG 實現動態視頻流服務，配合 video.js 實現按需播放”(如我的另一篇博客 HLS + ffmpeg 實現動態碼流視頻服務 所說) 這種程度，那大可以說你“理解常用視頻封裝、編碼格式，能根據應用場景搭建流暢的視頻播放體系”。
站在一個面試官的角度，單純的堆疊名詞反而容易讓人質疑你的知識深度和對自己的認知的準確性，適當的裁剪往往更能突出優勢。
慎用形容詞
在我第一次寫簡歷的時候，有一篇文章印象很深，細節忘了但是里面有一個很重要的觀點：不要寫精通！我覺得特別對，因為大多數人對大多數技術的掌握程度并沒有達到這個深度，如果你真的自認有精通的點，那有可能是事實也有可能是不知者無畏。
舉例來說，你覺得你精通 HTML 嗎？那么：
input 標簽的 type 屬性有哪些可選值？分別對應什么功能？瀏覽器兼容程度如何？
什么是標簽的語義？為什么要有語義化？有誰會消費這些語義？怎么評估語義是否恰當？
aria 屬性是什么？怎么編寫合理的 aria 結構？又是誰，以何種方式會消費這些屬性？
又或者，你覺得你精通 vue 嗎？那么：
Vue2 的雙向數據綁定是什么？如何實現的？這個過程如何影響 props、computed 屬性？
如果上面的問題你理解了，那么 Vue3 呢？
Vue 如何將 template 轉換為 render 函數？又是如何識別出標簽對應的組件？組件層級之間的創建順序是怎樣的？渲染順序又是怎樣的？
這個列表還可以無限列下去，所謂學海無涯，謙虛一點總沒壞處的。我個人的做法是絕不寫“精通”，因為我自知對任何一個技術點都遠遠沒有達到精通的程度；但是會寫1-2個熟悉的技術項，并且書寫順序上會盡量靠前；此外會再補充一些理解，對于那些把握不夠的點會忽略不寫。面可以廣一點，例如網絡協議、構建工具、開發框架都寫一些，但總量盡量保持到3-5個。
這里可能會有同學，特別是實習生、應屆生擔心技術棧不夠廣會不會反而拿不到面試機會呢？這其實也是一種學習策略的問題，如果你站在面試官的角度，放在你面前的兩份簡歷，一份內容看起來是少但明顯能感覺有足夠深度；另一份堆砌了很技術名詞，但是名詞之間看起來沒有明顯關聯，你會傾向那一份？
總結
簡歷不容易寫，技術人員的簡歷更不容易，為了心儀的工作花多點時間沉淀一份優秀的簡歷是非常有必要的。
最近組建了一個江西人的前端交流群，如果你也是江西人可以加我微信 ruochuan12 拉你進群。
·················?若川出品?·················
今日話題
略。歡迎分享、收藏、點贊、在看我的公眾號文章~
一個愿景是幫助5年內前端人走向前列的公眾號
可加我個人微信?ruochuan12，長期交流學習
推薦閱讀
我在阿里招前端，我該怎么幫你？（現在還能加我進模擬面試群）
若川知乎問答：2年前端經驗，做的項目沒什么技術含量，怎么辦？
點擊上方卡片關注我、加個星標
學習源碼整體架構系列、年度總結、JS基礎系列
總結
以上是生活随笔為你收集整理的前端 Offer 提速：如何写出有亮点的简历的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 前端学习（3254）：react中tod
- 下一篇： 前端学习（3208）：react中的事件