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

這裡有兩個層面的問題，一是如何識別出你的優勢條件，畢竟大多數人大多數時候可能都是在做業務，臨到寫簡歷的時候要求總結日常工作中跟別人不一樣的點，確實挺難的，怎麼辦？第二個問題是你可能已經挖掘到自己的優勢，但是在簡歷裡面怎麼組織內容，怎麼表達才能突出，讓面試官迅速 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 實現按需播放”(如我的另一篇部落格所說) 這種程度，那大可以說你“理解常用視訊封裝、編碼格式，能根據應用場景搭建流暢的視訊播放體系”。

站在一個面試官的角度，單純的堆疊名詞反而容易讓人質疑你的知識深度和對自己的認知的準確性，適當的裁剪往往更能突出優勢。

慎用形容詞

在我第一次寫簡歷的時候，有一篇文章印象很深，細節忘了但是裡面有一個很重要的觀點：不要寫精通！我覺得特別對，因為大多數人對大多數技術的掌握程度並沒有達到這個深度，如果你真的自認有精通的點，那有可能是事實也有可能是不知者無畏。

舉例來說，你覺得你精通 HTML 嗎？那麼：

input 標籤的 type 屬性有哪些可選值？分別對應什麼功能？瀏覽器相容程度如何？
什麼是標籤的語義？為什麼要有語義化？有誰會消費這些語義？怎麼評估語義是否恰當？
aria 屬性是什麼？怎麼編寫合理的 aria 結構？又是誰，以何種方式會消費這些屬性？

又或者，你覺得你精通 vue 嗎？那麼：

Vue2 的雙向資料繫結是什麼？如何實現的？這個過程如何影響 props、computed 屬性？
如果上面的問題你理解了，那麼 Vue3 呢？
Vue 如何將 template 轉換為 render 函式？又是如何識別出標籤對應的元件？元件層級之間的建立順序是怎樣的？渲染順序又是怎樣的？

這個列表還可以無限列下去，所謂學海無涯，謙虛一點總沒壞處的。我個人的做法是絕不寫“精通”，因為我自知對任何一個技術點都遠遠沒有達到精通的程度；但是會寫1-2個熟悉的技術項，並且書寫順序上會盡量靠前；此外會再補充一些理解，對於那些把握不夠的點會忽略不寫。面可以廣一點，例如網路協議、構建工具、開發框架都寫一些，但總量儘量保持到3-5個。

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

總結

簡歷不容易寫，技術人員的簡歷更不容易，為了心儀的工作花多點時間沉澱一份優秀的簡歷是非常有必要的。

我工作了8年，目前在位元組跳動遊戲部門做前端工作，前前後後已經看過幾千份簡歷，有很多簡歷上的問題還是能看出來的，如果你剛好或將要找工作，我很樂意能幫你把把關；如果你剛好想來位元組跳動試試前端崗位，我可以幫你內推到位元組，還可以幫你模擬面試、分享我對位元組各個業務線、工作環境的看法等等

Offer 提速：如何寫出有亮點的簡歷