版式
原则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:考虑征求他人意见
版式(排版和样式)并不是简历内容的一部分,但却会对简历给人的第一印象造成很大影响——“字如其人”,简历版式可以反映其作者是否严谨是否认真。如果版式过于糟糕,那么简历很可能会被直接筛掉。
使用对齐
不必使用居中
谨慎使用粗体
避免不必要的折行
使用制表符辅助对齐
个人信息部分决定了简历阅读者对简历的第一印象,请务必在这部分内容多下功夫。
性别
生日
星座
籍贯
通信地址
民族
政治面貌(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
使用正确的技术名称
这个原则非常简单(甚至有点弱智)——正确拼写技术名称,并使用正确的大小写。我在这里摘取了一些我见过的技术名词错误:
Andoid –> Android
IOS,ios –> iOS
javascript –> JavaScript
coffescript –> CoffeeScript
intelij –> IntelliJ
Dikjstra –> Dijkstra
请严格检查此类错误——这类错误会大大降低你的简历的专业性,并给人非常不好的印象
不要写电脑能力
技术简历需要展现你的技术能力(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语言及程序设计,计算机组成原理,数据结构,算法设计,离散数学,操作系统原理,编译原理,计算机网络,数据库系统原理,面向对象编程,软件工程,图像处理技术,人工智能及其应用,网络工程
更加令人啼笑皆非的是把所有的大学课程放在一起:
大学课程:
高等数学,线性代数,大学物理,概率与数理统计,毛泽东思想概论,思想道德修养,邓小平理论,马列政治经济学原理……
每当看到这样的简历我都在想我是该筛掉你呢还是筛掉你呢还是筛掉你呢?
不要写课程列表,除非你有想特别强调的特殊专业课,而且你在该课上有突出表现(比如“编译原理(实现了带下标检查的扩展C编译器)”就不错)。
考虑使用成绩或排名
如果你的大学成绩或排名还不错,那么请把它放在教育背景中,例如:
2009 ~ 2013学士大连理工大学软件工程GPA: 3.8/4.0,排名:3/153
就不错。
但如果你的成绩一般(80%一下)或排名一般(前20%开外),那么就不要提它们(我就是这么做的)
考虑使用导师(老师)的评语
这条原则和原则, 考虑提供他人的评价相类似,与其说你在学校多么努力,不如让你的专业课老师(导师)给你一个评价。
注意:不要使用辅导员的评价,是的,辅导员在大学很重要,但辅导员对学生的评价往往没有专业参考价值。
考虑使用学业相关的奖项
请把在校期间的重要奖项放在教育背景中,比如“一等奖学金”,“数学建模大赛一等奖”就不错。
我在阅读简历时见到过很多学霸——学校里面获得的奖项接近一页纸之多。这是个好事,不过放太多奖无益于突出重点,所以请参考原则: 不要列出过多的项目:精选3到5个最有说服力的奖项,然后把它们放在教育背景中。
个人爱好
个人爱好对技术简历往往毫无价值,所以这里的原则只有一条——
避免写个人爱好
除非你在个人爱好上取得了相当的成就,否则不要写个人爱好。每个人都喜欢音乐,都喜欢看书,也都喜欢技术,这种屁话套话还是留到入职邮件再说也不迟。
英文简历
海外求职需要英文简历,而英文简历需要专业的英语——阅读你简历的人很有可能只懂英文,如果你的英文太糟糕那么他/她很可能会无视你的技术而直接把你筛掉。
不要出现拼写错误
请打开拼写检查——要知道简历里面的拼写错误是致命的。我在这里给出一些常见的拼写错误:
explaination –> explanation
convenence –> convenience
seperate –> separate
Febuary –> February
embarass –> embarrass
consience –> conscience
mispell –> misspell
enginner –> engineer
不要使用全角字符
务必不要在英文简历中使用全角字符:
使用正确的词汇
国人英文简历的一大通病是用词不当,下面是我阅读英文技术简历时所发现的最常见的三个错误:
使用简洁的句子
受中式思维的影响,我们的英文往往很冗余(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.
这样不但更加简洁,而且用动词开头会让句子显得更加有力,给人以自信的感觉。