版式
版式（排版和样式）并不是简历内容的一部分，但却会对简历给人的第一印象造成很大影响——“字如其人”，简历版式可以反映其作者是否严谨是否认真。如果版式过于糟糕，那么简历很可能会被直接筛掉。

1. 使用对齐
2. 不必使用居中
3. 谨慎使用粗体
4. 避免不必要的折行
5. 使用制表符辅助对齐

 
1. 使用对齐 对齐（ Alignment ）是良好排版的第一要素 —— 对齐不仅使简历层次分明，也会给人有力的感觉

2.不必使用居中
居中会破坏对齐，减弱整体的层次感，所以我不建议在简历中使用居中。
请牢记：左/右对齐优于居中对齐。

3.谨慎使用粗体
粗体是一个很强大的工具，它可以有效的去引导简历阅读者的视线，并突出重要的内容。但我在阅读简历的时候发现不少人对粗体使用不当——滥用，用错，甚至是全文使用粗体，这使得简历完全无法被正常阅读。
粗体适用于去突出成就（Achievements），例如：
量化的成就：将页面加载速度提升50%
良好的成绩：GPA 4.0/4.0
奖项：ICPC/ACM比赛中获得XX赛区一等奖
他人的推荐语：“XX是我见过的最优秀的实习生”
 
在其它场景下，我不推荐使用粗体，此外注意不要过多使用粗体——粗体是为了突出成就，不是为了突出技术关键字，太多的粗体会导致什么也突出不出来。

4.避免不必要的折行
折行（Wrap）指当一行内容过长时会自动进入下一行。我不是说不可以折行（那就成了古龙小说了:–/），而是说不要使用不必要的折行，不必要的折行会降低简历的密度，破坏简历的层次感，而且会给人没话说有意占行数的感觉。

5.使用制表符辅助对齐
为了进行对齐，我们往往需要添加一些空白符。在这里请使用制表符（tab）而非空格（space），因为：
1.空格往往不会带来严格的对齐（因为简历字体往往不是等宽的）
2.制表符在打印版本下的表现更佳
 
个人信息
个人信息部分决定了简历阅读者对简历的第一印象，请务必在这部分内容多下功夫。

6.不要使用不必要的条目名称
7.使用分隔符增强电话号码的可读性
8.使用可以点击的链接
9.不要使用照片
10.不要写无关个人信息
11.使用客观事实而非主观描述
12.考虑提供他人的评价
13.不必写求职目标
 
6.不要使用不必要的条目名称
条目名称（Column name）这个词很拗口，我举一个例子：“姓名：张大锤”和“电话：135-9112-7890”里的“姓名”和“电话”就是条目名称。
绝大多数的条目名称都是不必要的——“张大锤”一看就是一个名字，“135-9112-7890”一看就是一个手机号码。这种条目信息会让简历变得拖沓啰嗦，请务必删除它们。
此外，请牢记**“个人简历”是简历上最大的废话**——这当然是一封简历，不用你提醒。可笑的是很多所谓的“500强简历模板”还把“个人简历”作为简历抬头（Header）。

7.使用分隔符增强电话号码的可读性
请使用“-”和“()”格式化你的电话号码，例如：把8618601007070改为(+86)186-0100-7070，以便简历阅读者能够正确便捷的拨打你的号码，此外这样的号码也显得更加专业。

8.使用可以点击的链接
使用http://lucida.me而非http://lucida.me
使用mymail@ggg.com而非mymail@ggg.com
这样简历阅读者就可以直接点击，而不是费力的把链接复制粘贴到某个输入栏中。

9.不要使用照片
照片不会对你的简历产生任何正面价值，而且它会破坏简历的结构，请不要在简历中使用照片。

10.不要写无关个人信息
是的，你是在写技术简历，而不是在写入党申请或征婚启事之类的东西，所以请不要在简历中出现下面这些信息：
性别
生日
星座
籍贯
通信地址
民族
政治面貌（WTF!!??）
身高/体重
理想的个人信息应该包括姓名、联系方式（电邮地址和手机号码），如果你有不错的技术博客也可以把它放在上面。

11.使用客观事实而非主观描述
我经常在简历里面看到诸如“我是一个热爱编程的开发者”或是“我精力充沛，热爱学习，能够长时间从事编程工作”之类的个人评价，总之就是把雇主希望看到的性格特点堆在一起，有时感动的我都想哭。
但感动归感动，这些感人肺腑的个人评价我向来直接无视——**我为什么要相信你呢？**引用Linus的话，Talk is cheap,show me the code。
如果要说明你是一个热爱编程的开发者，那么请出你的Github页面或优秀的个人作品；如果要说明你热爱学习，请给出你读过的书或写过的书评。总之，使用客观事实，而非主观描述。

12.考虑提供他人的评价
这条原则是上一条原则的扩充——找你的导师、老板或者同事为你写一个评语，相对于主观描述，他人的评价往往更加可信。如果你的评价者是业内权威，那么效果就会更好。

13.不必写求职目标
我读过的很多简历都有“Objective”（求职目标）这一栏，一般求职者会在这里写他所期待的职位。我个人非常不喜欢求职目标这一栏，因为求职目标给我一种海投简历的感觉。如果走的是内部推荐，或者使用目标公司的求职页面，请去掉求职目标，你应该已经了解投递职位，不需要在简历里面重复。
 
技术能力
技术能力是技术简历里面重要的一环，一般来说简历阅读者会通过这部分内容了解你的技能集（Skill set），从而构成对你的第一技术印象。
14.不要堆砌技术名词
15.对技术进行分类
16.使用正确的技术名称
17.不要写电脑能力
18.按照熟悉程度对技术能力进行排序
19.不要写过于特定的技术
20.谨慎使用精通
21.使用项目经验印证技术能力
 
14.不要堆砌技术名词
技术简历中一个常见误区是堆砌技术名词，一些求职者认为在简历上写的技术越多越好，于是把自己会的、用过的、见过的甚至没见过的技术都堆在一起，比如：
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），这样会使你的简历更有说服力。
 
15.对技术进行分类
技术能力部分的另一个常见问题是缺乏分类或者分类错误，比如：
编程语言：C++,C#,Visual Studio,Shell,Python,Eclipse,Java
这样的简历也会被直接扔进废纸篓——连编程语言和编程环境都分不清，招你作甚。

正确分类后就清楚了很多：
编程语言：C++,C#,Java,Python,Shell
开发环境：Visual Studio,Eclipse
 
16.使用正确的技术名称
这个原则非常简单（甚至有点弱智）——正确拼写技术名称，并使用正确的大小写。我在这里摘取了一些我见过的技术名词错误：
Andoid –> Android
IOS,ios –> iOS
javascript –> JavaScript
coffescript –> CoffeeScript
intelij –> IntelliJ
Dikjstra –> Dijkstra
请严格检查此类错误——这类错误会大大降低你的简历的专业性，并给人非常不好的印象

17.不要写电脑能力
技术简历需要展现你的技术能力（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字样就直接滤掉（靠谱！）。
 
18.按照熟悉程度对技术能力进行排序
这个原则十分简单——使用合适的词汇描述你的技术能力，并按照熟悉程度排序，例如：
编程语言：C++,C#,Java,Python,JavaScript
就不如
编程语言：熟悉C++、C#和Java，了解Python和JavaScript
 
另一种方式是使用比较符：
编程语言：C++ = C# > Java > Python = JavaScript
注意：没有必要在技术能力后面加上使用时间，比如：
技术名称熟练程度使用时间
C++精通8年
Java熟悉5年
 
时间没有意义——搞技术的都明白技术的使用时间和技术的熟练程度没有任何关系（谁知道这货是不是用了1个月C++然后在后面的95个月不断重复第一个月的东西？），只可惜有些HR永远都不懂这个道理，也不肯懂。
 
19.不要写过于特定的技术
什么叫做过于特定（Specific）的技术呢？举个例子：
熟悉单例（Singleton）模式
且不说单例是不是一个好模式，单例模式有什么好熟悉的？这种东西也配写到简历上吗？至少在我看来，“熟悉单例模式”就跟“熟悉for循环”、“精通if语句”一般可笑。
 
20.谨慎使用精通
精通和 Proficient 是非常 Strong 的词汇，在简历上写精通类词汇也许会帮你得到面试机会，但你要面对难度更高的面试 —— 招聘者会通过更高难度的问题来确认你真的是精通，而不是在嘴遁。
但如果你真的精通某项技术，那就自信的写上精通，然后用项目经历和面试中的表现说服招聘者，这样往往有助于你拿到 Strong Offer 。
 
21.使用项目经验印证技术能力
这条原则在原则13不要堆砌技术名词也有提到——你的技术能力应该在你的项目经历中得到全部体现，技术能力展现你的技能集（Skills Set），而项目经验为其提供证据（Evidence）。打个比方，如果你提到你熟悉C++，那么你就需要在项目经验中提到C++，否则我认为你在说谎或者忘记把C++的项目经验写在简历上，说谎和健忘，两者都不是好事。
 
项目经历
项目经历是简历阅读者进一步了解求职者技术能力的重要依据，良好的项目经历应当清晰，简洁，既印证前面提到的技术能力，也反映出求职者应对复杂度（Handle complexity）的能力。
22.按照时间对项目经历排序
23.不要列出过多的项目
24.强调成果而非过程
25.使用量化结果而非抽象描述
26.强调影响力和复杂度
 
22.按照时间对项目经历排序
一般来说，项目经历应该按照时间倒序排序——最新的项目经历放在最前。此外，考虑去掉过于久远（比如说，七八年前）的项目经历，因为你很有可能已经忘了七八年前做过的东西了。

另外一种排序方式是按照项目的重要程度排序——最重要的项目放在最前，但我个人不推荐这种方式，因为往往最重要的项目都在最近，如果你最重要的项目在很多年，那么很有可能你这些年毫无长进。
23.不要列出过多的项目
我经常看到非常长的简历：三四页纸，两三千字，十余个项目，恨不得把他/她做过的东西全都铺上去。而事实证明写出这样简历的人水平都不怎么样——至少就我的个人经验而言。

项目经历不是自传，不用把你全部的经历铺上去，也不要写过多的项目经历——三个项目是一个不错的选择，五个就有点多，十个就会没人看。要知道三个优秀的项目远胜十个一般的项目。

所以问题来了，什么是优秀的项目呢？就技术项目而言，我的评估标准是复杂度（Complexity）和影响力（Impact）：一个项目，如果复杂度和影响力都有那是最好，如果只有一个也不错，如果都没有那就呵呵。我会在原则25强调影响力和复杂度中进一步说明。
 
24.强调成果而非过程
我在我之前的关于锤子手机和锤子手机发布会提到过：
总之，在锤子手机发布会上，我看到的是一个人在不断的强调自己有多努力多认真，但我也知道当某人不断的给你强调他有多努力（effort）时，事实往往是他还没有获得任何实质性成果（progress），简而言之，effort不等于progress。

技术简历也是如此，不要在项目经历中过度强调你有多努力。“连续高强度工作三个月”和“在深夜重构了XX项目中的代码”并不是一个好的项目描述：如果你“连续高强度工作三个月”却无法说明你的工作成果，“在深夜重构了XX项目中的代码”却无法说明重构后代码改进了多少，那我认为你的“努力”毫无意义。

强调你的项目成果（Achievements）而非过程，“将网站访问量提升300%”、“将响应时间从1.5s减少到0.1s以内”都是不错的成果。
 
25.使用量化结果而非抽象描述
我经常在简历上看到“改善了代码的质量”、“提升了启动速度”和“大大增加了网站访问量”之类的描述，我的第一反应就是：
用个数字你会死啊！！！看新闻联播看多了吧亲！！！！
 
接下来的反应是：
“改善了代码的质量”——改善了多少？你是如何评估的？圈复杂度？测试覆盖度？Bug的数量？？？？
“提升了启动速度”——提升了多少？用户的反馈如何？是否在可接受的范围内？？？？
“大大增加了网站访问量”——“大大”是什么？访问量增加了多少？访问量原来是多少？？？？
 
如果我找不到上面问题的答案，我会直接无视这些抽象描述——还是那句话，我为什么要相信你的一面之词？而且你连话都说不清。
 
26.强调影响力和复杂度
“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
如果你的项目并不复杂，那么请强调它的影响力，用户量超过十万的手机应用和被广泛应用的类库都是很好的项目，尽管它们可能并不复杂。

如果一个项目既没有复杂度，也没有影响力，那么直接删掉它——不要犹豫，它不会为你的简历提供任何价值。
 
教育背景
教育背景是简历的另一项重要内容，它对于应届生尤其重要——因为应届生往往没有太多的工作经历。
27.不要写大学之前的教育经历
28.不要写课程列表
29.考虑使用成绩或排名
30.考虑使用导师（老师）的评语
31.考虑使用学业相关的奖项
 
27.不要写大学之前的教育经历
我不明白为什么很多人把高中甚至初中都写在简历里——也许你的高中/初中很出色，不过那么多年前的事情就不用再提了吧–_–||

28.不要写课程列表
我在简历的教育背景部分发现的另一个奇怪的现象是课程列表（Courseworks）：求职者把大学专业课程一水排开，放在简历里面，颇是壮观：
专业课程：
计算机科学导论，C语言及程序设计，计算机组成原理，数据结构，算法设计，离散数学，操作系统原理，编译原理，计算机网络，数据库系统原理，面向对象编程，软件工程，图像处理技术，人工智能及其应用，网络工程
更加令人啼笑皆非的是把所有的大学课程放在一起：
 
大学课程：
高等数学，线性代数，大学物理，概率与数理统计，毛泽东思想概论，思想道德修养，邓小平理论，马列政治经济学原理……
每当看到这样的简历我都在想我是该筛掉你呢还是筛掉你呢还是筛掉你呢？
不要写课程列表，除非你有想特别强调的特殊专业课，而且你在该课上有突出表现（比如“编译原理（实现了带下标检查的扩展C编译器）”就不错）。
 
29.考虑使用成绩或排名
如果你的大学成绩或排名还不错，那么请把它放在教育背景中，例如：
2009 ~ 2013学士大连理工大学软件工程GPA: 3.8/4.0，排名：3/153
就不错。
 
但如果你的成绩一般（80%一下）或排名一般（前20%开外），那么就不要提它们（我就是这么做的，-_–#）
 
30.考虑使用导师（老师）的评语
这条原则和原则12.考虑提供他人的评价相类似，与其说你在学校多么努力，不如让你的专业课老师（导师）给你一个评价。
 
注意：不要使用辅导员的评价，是的，辅导员在大学很重要，但辅导员对学生的评价往往没有专业参考价值。
 
31.考虑使用学业相关的奖项
请把在校期间的重要奖项放在教育背景中，比如“一等奖学金”，“数学建模大赛一等奖”就不错。
我在阅读简历时见到过很多学霸——学校里面获得的奖项接近一页纸之多。这是个好事，不过放太多奖无益于突出重点，所以请参考原则23.不要列出过多的项目：精选3到5个最有说服力的奖项，然后把它们放在教育背景中。
个人爱好
个人爱好对技术简历往往毫无价值，所以这里的原则只有一条——
 
32.避免写个人爱好
除非你在个人爱好上取得了相当的成就，否则不要写个人爱好。每个人都喜欢音乐，都喜欢看书，也都喜欢技术，这种屁话套话还是留到入职邮件再说也不迟。