開發者（KaiFaX）
這篇文章圍繞著技術簡歷這個話題，從版式、個人信息、技術能力、項目經歷和教育背景等方面出發，給出了編寫高質量技術簡歷所應遵循的47條原則。它們既有益於求職者編寫高質量的簡歷，也有助於招聘者篩選合格的求職者。
為什麼要編寫這篇文章？技術簡歷既是技術人員求職必不可少的一環，也是找工作的第一步，其重要性不言而喻。然而關於如何編寫技術簡歷的靠譜教程卻少之又少，以至於求職者無法編寫出合格的簡歷，而招聘者無法從簡歷中看出求職者的真實水平。
一些人可能會反對：如何編寫技術簡歷還不簡單，網上到處都是嘛！找一個教程，套一個模板，簡歷不就出來了嘛！
上面的教程和模板是我在谷歌和百度搜索「如何編寫技術簡歷」和「技術簡歷模板」得到的結果，它們的共性是完全不適用於技術領域：這些教程和模板會指導你寫出一篇屁話連連空話連篇看似出彩但毫無實質內容的嘴遁簡歷，是的，它們可能適用於一些國有企業，但對於追求實際的外企和民企完全不適用。
技術領域追求簡練、客觀、實際和成就，而不是冗餘、主觀、抽象和過程。如果求職者使用上面的教程或模板編寫技術簡歷，那麼結果註定會非常糟糕；如果招聘者使用上面的教程來甄別求職者，那麼註定會招進一群光說不做的飯桶。我不是在開玩笑——儘管算上實習我只工作了三年，但我已經見證過很多優秀的童鞋因為簡歷被公司拒之門外，也見證過招聘者/HR因為不懂甄別簡歷，搞進來一群莫名其妙的傢伙來面試，既浪費時間，又浪費資源。
所以我決定寫一篇如何編寫技術簡歷的文章，也就是精益技術簡歷之道：
為技術人員提供一個靠譜實用的技術簡歷編寫教程
為招聘人員提供一個便捷高效的技術簡歷甄別教程
結合國外書籍/文章和我自己的經驗，我總結出47項編寫高質量技術簡歷的原則，這些原則既可以作為求職者編寫技術簡歷的準則，也可以作為招聘人員篩選技術簡歷的標準。
此外，隨著越來越多的人開始海外求職，我特別針對英文簡歷編寫了9項原則，以幫助國人編寫合格的英文技術簡歷。
註：本文標題中的的「精益」（Lean）源於精益創業（the Lean Startup）。
注意為了完成這篇文章，我從我的微博關注者中徵集了一系列簡歷（感謝你們的信任！）。下文有可能會出現你們簡歷中的部分內容（當然我會進行改動以便保護你們的隱私），如果覺得不妥，請與我聯繫，我會將其刪除。
下面進入正文。
精益技術簡歷原則關於為了使本文更加嚴謹有序，我在組織簡歷原則時參考了編程書籍中著名的Effective系列（例如Effective C++和[Effective Java](http://www.amazon.cn/gp/product/B001PTGR52/ref=as_li_ss_tl?ie=UTF8&camp=536&creative=3132&creativeASIN=B001PTGR52&linkCode=as2&tag=lucida-23）以及[Framework Design Guidelines](http://book.douban.com/subject/3267575/)的行文風格：
「使用……」、「對……進行……」、「按照……」這些原則屬於必須遵循的原則
「不要使用……」、「不要……」、「避免……」這些原則屬於必須避免的原則
「考慮……」、「不必……」、「謹慎……」這些原則屬於我個人建議的原則，你可以去違反它們，但我個人不推薦這樣做
為了便於閱讀和理解，我將這些原則按照進行了分類：
下面是精益技術簡歷的47條原則：
原則1：使用對齊
原則2：不必使用居中
原則3：謹慎使用粗體
原則4：避免不必要的折行
原則5：使用制表符輔助對齊
原則6：不要使用不必要的條目名稱
原則7：使用分隔符增強電話號碼的可讀性
原則8：使用可以點擊的連結
原則9：不要使用照片
原則10：不要寫無關個人信息
原則11：使用客觀事實而非主觀描述
原則12：考慮提供他人的評價
原則13：不必寫求職目標
原則14：不要堆砌技術名詞
原則15：對技術進行分類
原則16：使用正確的技術名稱
原則17：不要寫電腦能力
原則18：按照熟悉程度對技術能力進行排序
原則19：不要寫過於特定的技術
原則20：謹慎使用精通
原則21：使用項目經驗印證技術能力
原則22：按照時間對項目經歷排序
原則23：不要列出過多的項目
原則24：強調成果而非過程
原則25：使用量化結果而非抽象描述
原則26：強調影響力和複雜度
原則27：不要寫大學之前的教育經歷
原則28：不要寫課程列表
原則29：考慮使用成績或排名
原則30：考慮使用導師（老師）的評語
原則31：考慮使用學業相關的獎項
原則32：避免寫個人愛好
原則33：不要出現拼寫錯誤
原則34：不要使用全形字符
原則35：使用正確的詞彙
原則36：使用簡潔的句子
原則37：避免中式英語
原則38：使用一致的時態
原則39：考慮提供縮寫詞的解釋
原則40：使用Bullets組織長段
原則41：打下良好的英文基礎
原則42：考慮使用超連結
原則43：考慮提供一個「加強版」簡歷
原則44：考慮提供開發社區帳號
原則45：持續更新簡歷
原則46：不斷提升個人能力
原則47：考慮徵求他人意見
版式（排版和樣式）並不是簡歷內容的一部分，但卻會對簡歷給人的第一印象造成很大影響——「字如其人」，簡歷版式可以反映其作者是否嚴謹是否認真。如果版式過於糟糕，那麼簡歷很可能會被直接篩掉。
對齊（Alignment）是良好排版的第一要素——對齊不僅使簡歷層次分明，也會給人有力的感覺，例如：
就不如
居中會破壞對齊，減弱整體的層次感，所以我不建議在簡歷中使用居中。例如：
就不如
是的，這條原則裡使用的圖片來自原則 1. 使用對齊，請牢記：左/右對齊優於居中對齊。
粗體是一個很強大的工具，它可以有效的去引導簡歷閱讀者的視線，並突出重要的內容。但我在閱讀簡歷的時候發現不少人對粗體使用不當——濫用，用錯，甚至是全文使用粗體，這使得簡歷完全無法被正常閱讀。
粗體適用於去突出成就（Achievements），例如：
量化的成就：將頁面加載速度提升50%
良好的成績：GPA 4.0/4.0
獎項：ICPC/ACM比賽中獲得XX賽區一等獎
他人的推薦語：「XX是我見過的最優秀的實習生」
在其它場景下，我不推薦使用粗體，此外注意不要過多使用粗體——粗體是為了突出成就，不是為了突出技術關鍵字，太多的粗體會導致什麼也突出不出來。
折行（Wrap）指當一行內容過長時會自動進入下一行。我不是說不可以折行（那就成了古龍小說了 :-/），而是說不要使用不必要的折行，比如說：
就不如
不必要的折行會降低簡歷的密度，破壞簡歷的層次感，而且會給人沒話說有意佔行數的感覺。請務必避免這樣的折行。
為了進行對齊，我們往往需要添加一些空白符。在這裡請使用制表符（tab）而非空格（space），因為：
空格往往不會帶來嚴格的對齊（因為簡歷字體往往不是等寬的）
制表符在列印版本下的表現更佳
個人信息部分決定了簡歷閱讀者對簡歷的第一印象，請務必在這部分內容多下功夫。
條目名稱（Column name）這個詞很拗口，我舉一個例子：「姓名：張大錘」和「電話：135-9112-7890」裡的「姓名」和「電話」就是條目名稱。
絕大多數的條目名稱都是不必要的——「張大錘」一看就是一個名字，「135-9112-7890」一看就是一個手機號碼。這種條目信息會讓簡歷變得拖沓囉嗦，請務必刪除它們。
此外，請牢記「個人簡歷」是簡歷上最大的廢話——這當然是一封簡歷，不用你提醒。可笑的是很多所謂的「500強簡歷模板」還把「個人簡歷」作為簡歷抬頭（Header）。
請使用「-」和「()」格式化你的電話號碼，例如：把8618601007070 改為 (+86) 186-0100-7070，以便簡歷閱讀者能夠正確便捷的撥打你的號碼，此外這樣的號碼也顯得更加專業。
這樣簡歷閱讀者就可以直接點擊，而不是費力的把連結複製粘貼到某個輸入欄中。
照片不會對你的簡歷產生任何正面價值，而且它會破壞簡歷的結構，請不要在簡歷中使用照片。
是的，你是在寫技術簡歷，而不是在寫入黨申請或徵婚啟事之類的東西，所以請不要在簡歷中出現下面這些信息：
性別
生日
星座
籍貫
通信地址
民族
政治面貌（WTF!!??）
身高/體重
理想的個人信息應該包括姓名、聯繫方式（電郵地址和手機號碼），如果你有不錯的技術博客也可以把它放在上面。
我經常在簡歷裡面看到諸如「我是一個熱愛編程的開發者」或是「我精力充沛，熱愛學習，能夠長時間從事編程工作」之類的個人評價，總之就是把僱主希望看到的性格特點堆在一起，有時感動的我都想哭。
但感動歸感動，這些感人肺腑的個人評價我向來直接無視——我為什麼要相信你呢？引用Linus的話，Talk is cheap, show me the code。如果要說明你是一個熱愛編程的開發者，那麼請出你的Github頁面或優秀的個人作品；如果要說明你熱愛學習，請給出你讀過的書或寫過的書評。總之，使用客觀事實，而非主觀描述。
這條原則是上一條原則的擴充——找你的導師、老闆或者同事為你寫一個評語，相對於主觀描述，他人的評價往往更加可信。如果你的評價者是業內權威，那麼效果就會更好。
我讀過的很多簡歷都有「Objective」（求職目標）這一欄，一般求職者會在這裡寫他所期待的職位。我個人非常不喜歡求職目標這一欄，因為求職目標給我一種海投簡歷的感覺。如果走的是內部推薦，或者使用目標公司的求職頁面，請去掉求職目標，你應該已經了解投遞職位，不需要在簡歷裡面重複。
技術能力是技術簡歷裡面重要的一環，一般來說簡歷閱讀者會通過這部分內容了解你的技能集（Skill set），從而構成對你的第一技術印象。
技術簡歷中一個常見誤區是堆砌技術名詞，一些求職者認為在簡歷上寫的技術越多越好，於是把自己會的、用過的、見過的甚至沒見過的技術都堆在一起，比如：
Technical Skills
Programming Language: HTML, CSS, PHP, JavaScript, SQL, Haskell, Perl, Python, C, C++, Java, Ruby, Prolog, .NET, C#, Assembly, REXX, Verilog, R, Visual Basic, MATLAB, jQuery, Angular, SASS
Operating System: Unix/Linux, Mac, MS-DOS, Windows 7/8, Windows Server 2003/2008/2012, z/VM
Software: Adobe Creative Cloud Dreamweaver, Photoshop, InDesign, Audition. WordPress, OmniUpdate, Google Analytics, Eclipse, NetBeans, LaTex, Microsoft Office Suite, Microsoft Excel, Project, Visio, Visual Studio
是的，一個人可以同時掌握甚至精通多種程式語言，但一般來說這種可能性很小。當我看到這樣的技術描述，我會迅速的跳轉到簡歷的項目經驗環節，如果我無法在項目經驗裡找到對應的技術，我會直接把這個簡歷篩掉。（我把它叫做「未聲明引用」（Undeclared reference）：你說你精通C++，但你卻沒有C++的項目經驗，你確定不是在逗我？）
所以，不要堆砌技術名詞，技術簡歷並非多多益善，熟悉什麼技術就寫什麼技術，然後在項目經驗裡面給出你熟悉該技術的證據（evidence），這樣會使你的簡歷更有說服力。
技術能力部分的另一個常見問題是缺乏分類或者分類錯誤，比如：
程式語言：C++, C#, Visual Studio, Shell, Python, Eclipse, Java
這樣的簡歷也會被直接扔進廢紙簍——連程式語言和編程環境都分不清，招你作甚。
正確分類後就清楚了很多：
程式語言：C++, C#, Java, Python, Shell
開發環境：Visual Studio, Eclipse
這個原則非常簡單（甚至有點弱智）——正確拼寫技術名稱，並使用正確的大小寫。我在這裡摘取了一些我見過的技術名詞錯誤：
請嚴格檢查此類錯誤——這類錯誤會大大降低你的簡歷的專業性，並給人非常不好的印象
技術簡歷需要展現你的技術能力（Technical Skills），而不是電腦能力（Computer Skills），這兩個概念比較拗口，所以我在這裡舉幾個例子：
技術能力包括：編程（C++/Java/Python），開發環境（Visual Studio/IntelliJ/Eclipse），測試（JUnit/TestNG/mockito/truth），用戶體驗（Axure/Expression Blend）等等。
電腦能力包括：日常辦公（Word/Excel/PowerPoint/Office），圖形界面作業系統（Windows 7/8）的使用，瀏覽器（IE/Chrome/Safari）的使用等等。
電腦能力不但會稀釋你的簡歷含金量，還會給人極不專業的感覺。不要在技術簡歷裡面出現任何電腦能力——據說某公司甚至定了一個規矩，只要在技術簡歷裡面看到Office字樣就直接濾掉（靠譜！）。
這個原則十分簡單——使用合適的詞彙描述你的技術能力，並按照熟悉程度排序，例如：
程式語言：C++, C#, Java, Python, JavaScript
就不如
程式語言：熟悉C++、C#和Java，了解Python和JavaScript
另一種方式是使用比較符：
程式語言：C++ = C# > Java > Python = JavaScript
注意：沒有必要在技術能力後面加上使用時間，比如：
技術名稱 熟練程度 使用時間
C++ 精通 8年
Java 熟悉 5年
時間沒有意義——搞技術的都明白技術的使用時間和技術的熟練程度沒有任何關係（誰知道這貨是不是用了1個月C++然後在後面的95個月不斷重複第一個月的東西？），只可惜有些HR永遠都不懂這個道理，也不肯懂。
什麼叫做過於特定（Specific）的技術呢？舉個例子：
熟悉單例（Singleton）模式
且不說單例是不是一個好模式，單例模式有什麼好熟悉的？這種東西也配寫到簡歷上嗎？至少在我看來，「熟悉單例模式」就跟「熟悉for循環」、「精通if語句」一般可笑。
精通和Proficient是非常Strong的詞彙，在簡歷上寫精通類詞彙也許會幫你得到面試機會，但你要面對難度更高的面試——招聘者會通過更高難度的問題來確認你真的是精通，而不是在嘴遁。
但如果你真的精通某項技術，那就自信的寫上精通，然後用項目經歷和面試中的表現說服招聘者，這樣往往有助於你拿到Strong Offer。
這條原則在原則13 不要堆砌技術名詞也有提到——你的技術能力應該在你的項目經歷中得到全部體現，技術能力展現你的技能集（Skills Set），而項目經驗為其提供證據（Evidence）。打個比方，如果你提到你熟悉C++，那麼你就需要在項目經驗中提到C++，否則我認為你在說謊或者忘記把C++的項目經驗寫在簡歷上，說謊和健忘，兩者都不是好事。
項目經歷是簡歷閱讀者進一步了解求職者技術能力的重要依據，良好的項目經歷應當清晰，簡潔，既印證前面提到的技術能力，也反映出求職者應對複雜度（Handle complexity）的能力。
一般來說，項目經歷應該按照時間倒序排序——最新的項目經歷放在最前。此外，考慮去掉過於久遠（比如說，七八年前）的項目經歷，因為你很有可能已經忘了七八年前做過的東西了。
另外一種排序方式是按照項目的重要程度排序——最重要的項目放在最前，但我個人不推薦這種方式，因為往往最重要的項目都在最近，如果你最重要的項目在很多年，那麼很有可能你這些年毫無長進。
我經常看到非常長的簡歷：三四頁紙，兩三千字，十餘個項目，恨不得把他/她做過的東西全都鋪上去。而事實證明寫出這樣簡歷的人水平都不怎麼樣——至少就我的個人經驗而言。
項目經歷不是自傳，不用把你全部的經歷鋪上去，也不要寫過多的項目經歷——三個項目是一個不錯的選擇，五個就有點多，十個就會沒人看。要知道三個優秀的項目遠勝十個一般的項目。
所以問題來了，什麼是優秀的項目呢？就技術項目而言，我的評估標準是複雜度（Complexity）和影響力（Impact）：一個項目，如果複雜度和影響力都有那是最好，如果只有一個也不錯，如果都沒有那就呵呵。我會在原則25 強調影響力和複雜度中進一步說明。
我在我之前的關於錘子手機和錘子手機發布會提到過：
總之，在錘子手機發布會上，我看到的是一個人在不斷的強調自己有多努力多認真，但我也知道當某人不斷的給你強調他有多努力（effort）時，事實往往是他還沒有獲得任何實質性成果（progress），簡而言之，effort不等於progress。
技術簡歷也是如此，不要在項目經歷中過度強調你有多努力。「連續高強度工作三個月」和「在深夜重構了XX項目中的代碼」並不是一個好的項目描述：如果你「連續高強度工作三個月」卻無法說明你的工作成果，「在深夜重構了XX項目中的代碼」卻無法說明重構後代碼改進了多少，那我認為你的「努力」毫無意義。
強調你的項目成果（Achievements）而非過程，「將網站訪問量提升300%」、「將響應時間從1.5s減少到0.1s以內」都是不錯的成果。
我經常在簡歷上看到「改善了代碼的質量」、「提升了啟動速度」和「大大增加了網站訪問量」之類的描述，我的第一反應就是：
用個數字你會死啊！！！看新聞聯播看多了吧親！！！！
接下來的反應是：
「改善了代碼的質量」——改善了多少？你是如何評估的？圈複雜度？測試覆蓋度？Bug的數量？ ？？？
「提升了啟動速度」——提升了多少？用戶的反饋如何？是否在可接受的範圍內？ ？？？
「大大增加了網站訪問量」——「大大」是什麼？訪問量增加了多少？訪問量原來是多少？ ？？？
如果我找不到上面問題的答案，我會直接無視這些抽象描述——還是那句話，我為什麼要相信你的一面之詞？而且你連話都說不清。
"Controlling complexity is the essence of computer programming."
Brian Kernighan
控制複雜度使程序設計的根本（essense），所以絕大多數IT公司在招聘時都會把應對複雜度（Handle complexity）放在職位描述裡面——你如果能把難題搞定，那麼簡單題也不在話下。如果你做過的項目足夠複雜，那麼就證明你能扛得住複雜度，是個好備胎備選（Candidate）。
那麼什麼樣的項目經歷稱得上複雜呢？我在這裡給出一個不嚴謹的分類，僅供參考：
衡量項目的另一個重要依據是影響力（Impact），有的軟體項目可能不那麼複雜，但是它具有相當大的影響力，例如jQuery、RoR和JUnit：
"Never in the field of software development have so many owed so much to so few lines of code (JUnit)."
Martin Fowler
如果你的項目並不複雜，那麼請強調它的影響力，用戶量超過十萬的手機應用和被廣泛應用的類庫都是很好的項目，儘管它們可能並不複雜。
如果一個項目既沒有複雜度，也沒有影響力，那麼直接刪掉它——不要猶豫，它不會為你的簡歷提供任何價值。
教育背景是簡歷的另一項重要內容，它對於應屆生尤其重要——因為應屆生往往沒有太多的工作經歷。
我不明白為什麼很多人把高中甚至初中都寫在簡歷裡——也許你的高中/初中很出色，不過那麼多年前的事情就不用再提了吧 -_-||
我在簡歷的教育背景部分發現的另一個奇怪的現象是課程列表（Courseworks）：求職者把大學專業課程一水排開，放在簡歷裡面，頗是壯觀：
專業課程：
更加令人啼笑皆非的是把所有的大學課程放在一起：
大學課程：
每當看到這樣的簡歷我都在想我是該篩掉你呢還是篩掉你呢還是篩掉你呢？
不要寫課程列表，除非你有想特別強調的特殊專業課，而且你在該課上有突出表現（比如「編譯原理（實現了帶下標檢查的擴展C編譯器）」就不錯）。
如果你的大學成績或排名還不錯，那麼請把它放在教育背景中，例如：
2009 ~ 2013 學士 大連理工大學 軟體工程 GPA: 3.8/4.0，排名：3/153
就不錯。
但如果你的成績一般（80%一下）或排名一般（前20%開外），那麼就不要提它們（我就是這麼做的，-_-#）
這條原則和原則12. 考慮提供他人的評價相類似，與其說你在學校多麼努力，不如讓你的專業課老師（導師）給你一個評價。
注意：不要使用輔導員的評價，是的，輔導員在大學很重要，但輔導員對學生的評價往往沒有專業參考價值。
請把在校期間的重要獎項放在教育背景中，比如「一等獎學金」，「數學建模大賽一等獎」就不錯。
我在閱讀簡歷時見到過很多學霸——學校裡面獲得的獎項接近一頁紙之多。這是個好事，不過放太多獎無益於突出重點，所以請參考原則 23. 不要列出過多的項目：精選3到5個最有說服力的獎項，然後把它們放在教育背景中。
個人愛好對技術簡歷往往毫無價值，所以這裡的原則只有一條——
除非你在個人愛好上取得了相當的成就，否則不要寫個人愛好。每個人都喜歡音樂，都喜歡看書，也都喜歡技術，這種屁話套話還是留到入職郵件再說也不遲。
海外求職需要英文簡歷，而英文簡歷需要專業的英語——閱讀你簡歷的人很有可能只懂英文，如果你的英文太糟糕那麼他/她很可能會無視你的技術而直接把你篩掉。
請打開拼寫檢查——要知道簡歷裡面的拼寫錯誤是致命的。我在這裡給出一些常見的拼寫錯誤：
更多的拼寫錯誤請參考這裡。
務必不要在英文簡歷中使用全形字符：
全形字符會影響英文排版，使其變的很難看
對方的機器上可能沒有對應的字庫，因而無法顯示全形字符
我個人推薦在英文簡歷中只使用ASCII字符集裡的字符。
國人英文簡歷的一大通病是用詞不當，下面是我閱讀英文技術簡歷時所發現的最常見的三個錯誤：
「實現了xx功能」：使用Implement，而不是Achieve
「軟體工程師」：使用Software Developer或Software Engineer，而不是Software Programmer
「我對xxx感興趣」：使用I am interested in ...，而不是I am interesting in，詳見這裡
用詞不當會影響簡歷閱讀者的理解，為其帶來相當負面的印象。為了減少這類錯誤，你應該去閱讀更多的專業英文著作，或者找一個靠譜的人審閱你的簡歷（比如@peng_gong）。
受中式思維的影響，我們的英文往往很冗餘（Verbose），我舉兩個簡單的例子
「during the development period」應該是「during the development」：因為「development」本身已經包含「過程（period）」的意思。
「implemented xxx successfully」應當是「implemented xxx」：既然使用了過去式，那麼你已經把它實現（implement）了，那自然就是「成���」實現。如果想要強調「成功」，那麼可以用「accomplished xxx」。
這裡水一句：一般來說中國人對這種英語完全不敏感，反而很親切（因為更接近中式思維），那為什麼我對這種英語特別在意呢？因為我有幾個倫敦同事特別在意英語的純正性，初到倫敦時，無論是吃飯、聊天還是提交代碼，他們都會無時無刻的糾正我的語法錯誤和發音錯誤（我想我已經被他們糾正幾千多次了-_-#），所以我現在對此類中式英語異常敏感。
此外在簡歷裡面我們有時可以忽略主語（Subject），例如：
Project A:
I implemented the communication module.
I wrote tests for the communication module.
I deployed the module into our system.
可以這麼寫
Project A:
Implemented the communication module.
Wrote tests for the communication module.
Deployed the module into our system.
這樣不但更加簡潔，而且用動詞開頭會讓句子顯得更加有力，給人以自信的感覺。
為了使簡歷中的英文句子更加簡潔，你應該去閱讀更多的英文寫作書籍（例如Elements of Style和On writing well），或者找一個靠譜的人審閱你的簡歷（比如@peng_gong）。
這個原則實際上是原則35. 使用正確的詞彙和原則36. 使用簡潔的句子的擴展，因為這兩個原則都屬於中式英語的範疇。
中式英語的源頭在於用中式思維將中文逐字轉化成英語，儘管我們不會搞出這樣的錯誤：
但是小錯是難免的，我已經不止三次的聽到有人使用"red color"這個神奇的短語了。（red本身就是顏色，所以完全不需要後面的color）如果你打算根除中式英語，你有兩種途徑：
找幾個腹黑倫敦同事。-_-#
閱讀中式英語之鑑
這是我讀過最好的（貌似也是唯一的）講中式英語的書籍。
當然，如果你只是把簡歷改的不那麼中式，你完全可以找一個靠譜的人審閱你的簡歷（比如@peng_gong）。
這個原則很簡單——使用一致的時態：
對於個人評價：使用現代式。
對於項目經歷：使用過去式。
之所以把這麼簡單的原則提出來，是因為我都過的英文簡歷幾乎都違反了這個原則——它們或者在個人評價裡「I was a passionate programmer」（嗯，你過去很激情那麼現在呢？），或者在項目經歷裡「Implement xxx」（一直實現到現在不容易啊童鞋！）。
不是所有人都了解你的工作或研究，所以對於不常用和有歧義的首字母縮寫詞（Acronym），請提供全稱。
注意我說的是不常用和有歧義的縮寫詞，你無需告訴簡歷閱讀者HTML的全稱是HyperText Markup Language，也無需說明MVC是Model View Controller，但你可能需要說明AST是Abstract Syntax Tree，DSL是Domain Specific Language（而不是Digital Subscriber Line）。
如果一段項目過長，請使用Bullets而不是「Firstly..., secondly..., finally...」，例如：
Firstly, I collected, managed and analysed data from the health and the legal sector with Data Mining and Natural Language Processing using Python, Perl, and Java. Secondly, I developed web applications to showcase the findings with Jsp, JavaScript. HTML, CSS, J2EE, Tomcat and MySql that led to successful research demos. Finally, I improved the performance of an Java online education forum analysis tool by redesigning the GUI and utilizing multi-threading.
即便是一個English native speaker，看到這樣的大長段也會發怵，這裡可以利用Bullets改善可讀性：
Collected, managed and analysed data from the health and the legal sector with Data Mining and Natural Language Processing using Python, Perl, and Java.
Developed web applications to showcase the findings with Jsp, JavaScript. HTML, CSS, J2EE, Tomcat and MySql that led to successful research demos.
Improved the performance of an Java online education forum analysis tool by redesigning the GUI and utilizing multi-threading.
歸根到底，寫好英文簡歷需要良好的英文基礎，所以我在這裡推薦幾本不錯的英語基礎書籍：
Practical English Usage：簡潔，精煉，學習英文語法和口語的必備書籍。
Collins Pocket English Thesaurus：個人無責任推薦——每天看一點，這本書不會提升你的詞彙量（Total Vocabulary），但會提升你的有效詞彙量（Effective Vocabulary）。
Elements of Style：英語寫作第一書。無論是寫作，還是編程，都能從本書受益良多。
中式英語之鑑：可能是目前唯一一本講述中式英語的書籍，儘管書中的例子有點政治化，但不妨礙本書是一本好書。
這篇文章的主題並非英語學習，如果你對英語學習有興趣可以去Google和逼乎知乎搜索更相關的答案。
當然，如果你只是想得到一個不錯的英文簡歷，你完全可以找一個靠譜的人審閱你的簡歷（比如@peng_gong）。
剩下的是一些通用原則。
這項原則是原則8. 使用可以點擊的連結的擴充——超連結適用於簡歷全文，而不只適用於個人信息裡的個人主頁和郵箱地址：
如果你的作品/項目有介紹連結，請提供它
如果你的作品/項目有在線演示，請提供它
如果你的作品/項目有用戶反饋，請提供它
使用超連結時要注意一點：使用隱式超連結而非顯式超連結，例如使用Google而非http://www.google.com。因為顯式超連結往往很長而且不可讀，還會破壞列印版簡歷的效果。
這項原則是原則42. 考慮使用超連結的補充，簡歷受限於篇幅（一般是一頁）和格式（一般是PDF），無法提供更多豐富多彩的內容。但你可以用超連結關聯一個外部「加強版」簡歷。
一個典型例子是JJ Ying的在線「簡歷」（使用Parallax效果），這種「加強版」簡歷往往會使簡歷閱讀者眼前一亮，從而大大增加你的簡歷通過率。
如果你有非常活躍的開發社區（例如Stack Overflow，GitHub和Reddit Programming等開發社區）帳號，那麼請在簡歷中提供它們。
注意我說的開發社區帳號，而不是社交網絡帳號：提供人人、微博或Facebook帳號不會對簡歷有任何幫助。
優秀的簡歷應該是與時俱進持續更新的。從現在開始，定一個周期（一個月或三個月），然後以這個周期持續更新簡歷，這樣你可以：
隨時擁有最新的簡歷，而不是在求職時挖空心思編寫
形成一個成長記錄，以便自我改善
時刻提醒自己持續學習，如果你發現這個周期的簡歷同上個周期變化不大，你就要好好反思下了
以我自己為例，我維護著一個Markdown簡歷，每兩個月一更新，通過更新記錄/當前簡歷/下一步計劃，我可以更有效的指導我的學習和工作。
「沒有聲音，再好的戲也出不來」
某廣告語
簡歷原則有助於展示（Demostrate）實力，而不是放大（Amplify）實力——打個比方，你的實力有100分，低劣的簡歷會讓你看起來只有50分，而良好的簡歷則會展現出你100分，但不要指望簡歷會把你變成200分——我承認有些人可以通過說謊/造假/吹牛達到這個效果，但我不推薦這種透支信用的做法。
所以，優秀簡歷的根本是強大的實力，多學習，多做有影響力/複雜度（參考原則26. 強調影響力和複雜度）的項目，而不是在馬上找工作的時候挖空心思編項目堆技能。沒有聲音，再好的戲也出不來。
「當局者迷，旁觀者清」
在投遞簡歷前，最好去徵求他人意見——外人往往可以看出你簡歷的不足，指出低級錯誤，給出不錯的建議。
當然你也可以找一個靠譜的人審閱你的簡歷（比如@peng_gong）。
總結在這裡我把精益技術簡歷的47條原則整理在一起，以便閱讀整理：
原則1：使用對齊
原則2：不必使用居中
原則3：謹慎使用粗體
原則4：避免不必要的折行
原則5：使用制表符輔助對齊
原則6：不要使用不必要的條目名稱
原則7：使用分隔符增強電話號碼的可讀性
原則8：使用可以點擊的連結
原則9：不要使用照片
原則10：不要寫無關個人信息
原則11：使用客觀事實而非主觀描述
原則12：考慮提供他人的評價
原則13：不必寫求職目標
原則14：不要堆砌技術名詞
原則15：對技術進行分類
原則16：使用正確的技術名稱
原則17：不要寫電腦能力
原則18：按照熟悉程度對技術能力進行排序
原則19：不要寫過於特定的技術
原則20：謹慎使用精通
原則21：使用項目經驗印證技術能力
原則22：按照時間對項目經歷排序
原則23：不要列出過多的項目
原則24：強調成果而非過程
原則25：使用量化結果而非抽象描述
原則26：強調影響力和複雜度
原則27：不要寫大學之前的教育經歷
原則28：不要寫課程列表
原則29：考慮使用成績或排名
原則30：考慮使用導師（老師）的評語
原則31：考慮使用學業相關的獎項
原則32：避免寫個人愛好
原則33：不要出現拼寫錯誤
原則34：不要使用全形字符
原則35：使用正確的詞彙
原則36：使用簡潔的句子
原則37：避免中式英語
原則38：使用一致的時態
原則39：考慮提供縮寫詞的解釋
原則40：使用Bullets組織長段
原則41：打下良好的英文基礎
原則42：考慮使用超連結
原則43：考慮提供一個「加強版」簡歷
原則44：考慮提供開發社區帳號
原則45：持續更新簡歷
原則46：不斷提升個人能力
原則47：考慮徵求他人意見
來源：Lucida
原文：http://lucida.me/blog/lean-technical-resume/
轉載文章，向原作者致敬！如有侵權或不周之處，敬請勞煩聯繫若飛（微信：1321113940）馬上刪除，謝謝！
1. 回復「m」可以查看歷史記錄；
2. 回復「h」或者「幫助」，查看幫助；
開發者已開通多個微信群交流學習，請加若飛微信：1321113940 進群
開發者：KaiFaX