1.求职分析
为什么看上去差不多的技术和资历,有人可以一个月收到二三十个offer,有人只有寥寥几个?
为什么投外包公司,投一个中一个,投好点的公司都是杳无音信?
答案与简历相关。虽然技术有高有低、资历有深有浅,个人客观情况在短时间无法改变(经历造假可鄙),但是,如何将它们呈现在简历中是有技巧的。
回答题主的问题「程序员简历应该怎么写」?我认为,程序员就应该拿技术说话,「技术总结」是一份程序员简历的重中之重。除了大神和大牛,普通的程序员如果能在叙述中中体现自己的风格,在技术总结中展示鲜明的个人形象,会更吸引公司的注意,拿到更多的面试邀请。
!!!下面这些鸡汤,看看就够了,千万别信以为真!
你技术多好,决定了你能拿多少工资
酒香不怕巷子深
是金子总会发光
付出就会有回报
看看就行了,别信以为真
事实上是:
你的收入 != 你的能力
你的收入 = 你的能力 + 你的能力表达水平和能力表达欲望
2.薪资与面试对照关系
2.1 PHP基本使用
PHP基础 框架 curd
2.2 会基本的性能优化
MySQL redis nginx
2.3 更广阔的的知识面
rabbitmq kafka elasticsearch 分布式与集群 微服务 linux-服务器 安全与网络 PHP内核 算法
2.4 架构
分层架构、领域驱动设计、服务导向架构和微服务架构等设计模式
3.简历的构建布局
即打开简历之后的第一印象。就好比我们看见一个人,会有一个整体的感觉,他是fashion的、小清新的还是老道 的?有了第一印象之后再慢慢分解来看。
加分写法:
-
简洁明了,逻辑结构清晰。
-
字体,排版,顺畅,清晰整齐就好。 如果你的简历对不齐,别人是不会指望你的代码能对齐的
-
最好是PDF格式,兼容性强且不易乱序。
减分写法:
-
设计的过于浮夸或者过于简单的。(有的简历五颜六色、非常酷炫,却半天找不到联系方式,抑或是只有个人基本信息和公司名称)
-
写了十几页,半天打不开的,或者加载了半天,打开还乱码。
4.HR如何筛选简历
bat一份简历可能就10s,简历太多实在是没时间看
5.如何写好-专业技能
5.1 杜绝简单、要详尽
比如:有些人简历中介绍时过于简单,直接就是:
-
熟悉rabbitmq
-
熟练掌握mysql
-
熟练掌握nginx
-
熟练微服务
你熟悉php,到底熟悉到什么程度?解决过什么疑难问题?
熟练掌握mysql,到底熟练到什么程度?
熟练掌握微服务,有没有用过,举例一下用过微服务里面的啥?
5.2 使用项目经验印证技术能力
你的技术能力应该在你的项目经历中得到全部体现,技术能力展现你的技能集(Skills Set),而项目经验为其提供证据(Evidence)。打个比方,如果你提到你熟悉MQ,那么你就需要在项目经验中提到MQ,否则我认为你在说谎或者忘记把MQ的项目经验写在简历上,说谎和健忘,两者都不是好事。
5.3 不能遗漏重要技术点
许多人,技术栈明明较广,但简历上写的少,有些是没有更新。
5.4 谨慎使用精通
精通和熟练是非常强的词汇,在简历上写精通类词汇也许会帮你得到面试机会,但你要面对难度更高的面试——招聘者会通过更高难度的问题来确认你真的是精通,而不是在嘴遁。
但如果你真的精通某项技术,那就自信的写上精通,然后用项目经历和面试中的表现说服招聘者,这样往往有助于你拿到好的Offer。
5.5 核心优势要写到前面
比如有些人面试后端, 结果前面几条说的都是写前端
此外,熟悉的技术写到前端,这些技术,在面试的时候可能会被优先提问,面试官看简历一般都是从上往下看
5.6 拿手的要重点写
比如自己对mysql很拿手,但是简历中就一句:熟练掌握mysql
5.7 不要堆砌技术名词
换位思考下都懂
来看一分简历
-
熟悉htm5/css3/js/jquery/ajax等web前端技术;
-
熟悉yii2/laravel框架;
-
熟悉MySql数据库及其优化;
-
熟练Redis等nosql缓存技术,深入理解redis集群底层原理、redis读写分离,redis常用的5种数据结构在各种项目场景中的使用以及选型;深入理解redis持久化原理以及如何结合项目进行使用
-
熟悉Linux系统,能熟练运用shell监控系统运行状态,以及Nginx负载均衡搭建;
-
熟练微信支付等API接口服务封装,并对接口安全以及性能有优化经验;
-
熟悉Websocket,Http,Socket,TCP,UDP协议等技术的应用及实现原理;
-
熟悉go/swoole网络编程,服务端接口开发,kafka消息队列使用经验;
-
熟悉svn/git版本控制,解决常规冲突问题。
像上面这样写的, 一般都会被直接丢了
6.如何写好-项目经验
加分写法:
-
工作经历项目经历可参照万能的STAR法则来写,STAR
Situation: 事情是在什么情况下发生
Task: 你是如何明确你的任务的
Action: 针对这样的情况分析,你采用了什么行动方式
Result: 结果怎样,在这样的情况下你学习到了什么
-
项目经历还需要数据支撑
-
做过什么行业领域,和我们目前的行业是否匹配
-
擅长的技术语言,应用了哪些技术栈
-
经历的项目复杂度,及在项目中承担什么样的角色(人的变化/技术的变化/环境的变化/不同工作经历相同角色的不同点)
-
碰到的问题,如何分析的,如何解决的,上线后的成果如何
-
时间节点
减分写法:看了半天,不知所云,没有任何亮点,没有让人有去和你聊一聊深扒的信息。
项目经验的起承转合
第一行,起。写清楚项目的背景。写一下研究过什么同类的产品,我的产品的优势是什么。这能告诉面试官我不是随意设计一个项目的,是有目的、有规划的。
第二行,承。一般我会写基本的实现。用了什么框架、什么技术。记得要把上下文内容交代清楚。
第三行,转。描述遇到的挑战,是如何解决的。通过这条,说明我这个项目不是应付交差,而是做了一段时间,遇到了问题,并且解决了问题。
第四行,合。描述最终的结果。我是如何交付、呈现、测试这个项目的。告诉面试官我有信心能保证产品的最终完成。最好可以用一些数字来体现结果,而不是空洞的描述。
用这样一个四段论,比全部都在说做了A功能、B功能、C功能,在深度上好太多。
6.1 按照时间对项目经历排序
一般来说,项目经历应该按照时间倒序排序——最新的项目经历放在最前。此外,考虑去掉过于久远(比如说,七八年前)的项目经历,因为你很有可能已经忘了七八年前做过的东西了。
另外一种排序方式是按照项目的重要程度排序——最重要的项目放在最前,但我个人不推荐这种方式,因为往往最重要的项目都在最近,如果你最重要的项目在很多年,那么很有可能你这些年毫无长进。
6.2 不要列出过多的项目
我经常看到非常长的简历:三四页纸,两三千字,十余个项目,恨不得把他/她做过的东西全都铺上去。而事实证明写出这样简历的人水平都不怎么样。
项目经历不是自传,不用把你全部的经历铺上去,也不要写过多的项目经历——三个项目是一个不错的选择,五个就有点多,十个就会没人看。要知道三个优秀的项目远胜十个一般的项目。
6.3 强调成果而非过程
不要在项目经历中过度强调你有多努力。“连续高强度工作三个月”和“在深夜重构了XX项目中的
代码”并不是一个好的项目描述:如果你“连续高强度工作三个月”却无法说明你的工作成果,“在深夜重构了XX项目中的代码”却无法说明重构后代码改进了多少,那我认为你的“努力”毫无意义。
强调你的项目成果(Achievements)而非过程,“将网站访问量提升300%”、“将响应时间从1.5s减少到0.1s以内”都是不错的成果。
6.4 使用量化结果而非抽象描述
我经常在简历上看到“改善了代码的质量”、“提升了启动速度”和“大大增加了网站访问量”之类的描述,我的第一反应就是: 用个数字啊!!
接下来的反应是:
“改善了代码的质量”——改善了多少?你是如何评估的?圈复杂度?测试覆盖度?Bug的数量? ???
“提升了启动速度”——提升了多少?用户的反馈如何?是否在可接受的范围内? ???
“大大增加了网站访问量”——“大大”是什么?访问量增加了多少?访问量原来是多少? ???
如果我找不到上面问题的答案,就会直接无视这些抽象描述——为什么要相信你的一面之词?而且你连话都说不清。
6.5 强调影响力和复杂度
“控制复杂性是计算机编程的本质。”
布莱恩·柯林汉
控制复杂度使程序设计的根本(essense),所以绝大多数IT公司在招聘时都会把应对复杂度放在职位描述里面——你如果能把难题搞定,那么简单题也不在话下。如果你做过的项目足够复杂,那么就证明你能扛得住复杂度,是个好备胎备选(Candidate)。
那么什么样的项目经历称得上复杂呢?我在这里给出一个不严谨的分类,仅供参考:
编程复杂度:操作系统,编译器/解释器,图形学编程,网络协议设计与实现等
算法复杂度:算法竞赛奖项等(不好意思我不熟悉算法所以给不出啥例子 -_-)
设计复杂度:大型网站,企业级应用,分布式应用等
衡量项目的另一个重要依据是影响力(Impact),有的软件项目可能不那么复杂,但是它具有相当大的影响力,例如jQuery、RoR和JUnit:
“在软件开发领域,从来没有这么多的代码要归功于这么少的代码行(JUnit)。”
马丁·福勒
如果你的项目并不复杂,那么请强调它的影响力,用户量超过十万的手机应用和被广泛应用的类库都是很好的项目,尽管它们可能并不复杂。
如果一个项目既没有复杂度,也没有影响力,那么直接删掉它——不要犹豫,它不会为你的简历提供任何价值。
来看一份:
订单系统 2016年3月 - 2017年5月
php高级工程师
项目介绍:
通过统一订单提供用户整合的一站式供应链服务,订单管理、风控管理、钱包管理以及订单跟踪管理,使用户
的物流服务得 到全程的满足。
项目职责:
参与项目设计,项目重构,项目技术调研等工作;负责顾客行为、订单风控、黑名单、CASE、电子钱包、退款等业务模块; 定时任务以及批处理编写优化;
参与性能优化组,分析后台瓶颈,对后台进行性能优化。
尽量不要这样写
7 工作期望&个人评价
加分写法:
-
对自己有一个全方位的一个描述总结,让别人更好的解读你。或者在此处,高亮你的优点特长有哪些。
-
即使不写个人评价,也一定记得写上工作期望。
减分写法:
完全看不出个性特点,写和没写没什么区别。 来几个栗子
栗子1 错误打开方式
为人性格,诚实谦虚,勤奋,能吃苦耐劳,有耐心,有团队意识,能和同学和谐相处,能虚心接受别人的建议的人。
责任心强,善于沟通,具有良好的团队合作精神;专业扎实,具有较强的钻研精神和学习能力;性格比较乐观外向,
喜欢打羽毛球。
栗子2 正确打开方式
我对自己的定位: 主攻前端,同时在其他方面打打辅助。我不希望过于依赖别人,即使没有后端没有设计没有产品经理,我依然想要把这个产品做到完美。毕竟全栈才能最高效地解决问题。
我对工作的态度: 第一,要高效完成自己的本职工作。第二,要在完成的基础上寻找完美。第三,要在完美的基础上,与其他同事 互相交流学习,互相提升。工作是一种生活方式,不是一份养家糊口的差事。
我怎样克服困难: 不用百度是第一原则,在遇到技术问题时我往往会去Google、Stack over flow上寻找答案。但通常很多问题 并不一定已经被人解决,所以熟练地阅读源码、在手册、规范甚至 REPL的环境自己做实验才是最终解决问题的办法。相信事实的结果,自己动手去做。
怎样保持自己的视野:我一直认为软件开发中视野极其重要,除了在 Twitter 上关注业界大牛,Github Trending 也是每周必刷。 另外 Podcast、Hacker News、Reddit 以及TechRadar 也是重要的一手资料。保持开阔视野才能找到更酷的解决方案。
我的优势: 热爱技术、自学能力强,有良好的自我认知。全面的技能树与开阔的视野,良好的心态、情商与沟通能力。
我的劣势: 非科班出身没有科班同学对算法的熟练掌握,但我决定死磕技术,弥补不足。
8 简历技巧与注意事项
8.1 在投递简历的时候要根据应聘的职位进行一些调整
8.2 使用可以点击的链接
8.3 使用客观事实而非主观描述
8.4 精通PHP、Java、Python、C = 呵呵 ”
慎重使用“精通”这个词汇。万一你对面做的面试官是真精通的,你就惨了,会追着你问各种细节来验证你是不是真的精通。没有工作的经验的或者工作经验少的人,一定会被虐翻。 程序员的心理就是,你越是显摆,我越是要证明你挫。
8.5 使用可以点击的链接
8.6 简历强调的应该是成绩 (Achievement)。
而不是你做过啥(what you have done)。很不幸很多简历都写成了what you have done。用数字说明
若你是拖拉机司机,可以这样写,我开过50种不同拖拉机,来自20个不同的生产厂家。 若你是数据分析员,可以这样写,我分析过50个项目的数据,0错误率,提供了风险分析的第一手资料。 若你是洗盘子的,则可以写做,我洗盘子的速度是其他人的1.5倍。一天洗掉了2000个盘子,全部卫生达标。 若你是接电话的,可以写成,平均接电话50通/天,客服反馈满意率>95%。 这样是不是一下就有了明显改观了?必要的时候用数字说明问题,让自己的成绩量化出来。
8.7 简历的格式尽可能的用pdf
经常看到有的人提交 Word 格式的简历。Word 的不同配置,常常使你的简历出现乱码、甚至打不开。试想一下,你好不容易做了一个轮廓鲜明又格式精美的简历。招聘人员把它拉到他们的电脑上来,却只能看到一堆混乱的文字和形状。求此刻招聘人员的心理阴影面积。 所以,通过将你的简历转换为 PDF 格式,可以有效地防止这种情况的发生。
8.8 如果投递外企的话,尽可能一页英文简历
8.9 简历美观,比如不能太长
8.10 尽量不要写面议
8.11 不要写无关个人信息,无关项目信息等
8.12 不要堆砌技术名词
不要堆砌技术名词,技术简历并非多多益善,熟悉什么技术就写什么技术,然后在项目经验里面给出你熟悉该技术的证据(evidence),这样会使你的简历更有说服力。
8.13 持续更新简历
秀的简历应该是与时俱进持续更新的。从现在开始,定一个周期(一个月或三个月),然后以这个周期持续更新简历,这样你可以:
-
随时拥有最新的简历,而不是在求职时挖空心思编写
-
形成一个成长记录,以便自我改善
-
时刻提醒自己持续学习,如果你发现这个周期的简历同上个周期变化不大,你就要好好反思下了
通过更新记录/当前简历/下一步计划,这样可以更有效的指导我们的学习和工作。
9 相关职场问题
比如职业发展,比如年纪大了怎么办?
-
技术专家
-
技术架构
-
优秀技术管理者
-
ceo、老板