前端 Offer 提速：如何寫出有亮點的履歷

先來個靈魂拷問：「你與他人相比，有什麼能形成明顯區分度的優勢條件？」

這裡有兩個層面的問題，一是「如何識别出你的優勢條件」，畢竟大多數人大多數時候可能都是在做業務，臨到寫履歷的時候要求總結日常工作中跟别人不一樣的點，确實挺難的，怎麼辦？第二個問題是你可能已經挖掘到自己的優勢，但是「在履歷裡面怎麼組織内容，怎麼表達才能突出，讓面試官迅速 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個。

這裡可能會有同學，特别是實習生、應屆生擔心技術棧不夠廣會不會反而拿不到面試機會呢？這其實也是一種學習政策的問題，如果你站在面試官的角度，放在你面前的兩份履歷，一份内容看起來是少但明顯能感覺有足夠深度；另一份堆砌了很技術名詞，但是名詞之間看起來沒有明顯關聯，你會傾向那一份？

​總結​