'/%3e%3c/svg%3e){kind=icon}
简历与工作
本章主要讲一些求职技巧、心态辅导、对公司的选择。以及入职后在工作中的一些指导意见、职业路线规划等。
不好的简历
先看一些不好的简历。
投机简历
曾经看到过一份7年工作经验的高级前端工程师简历，在其自我评价中写道：
项目经验丰富，有XX、XX大型系统产品的前端负责人架构经验，也有谷歌、XX、XX、XX、XX多行业千万级订单项目的负责人管理经验，对于开发项目系统性流程能有效保障，从项目启动到开发完成到检验验收到项目收尾能清晰规范，并完成项目汇报工作。
读完后是什么感觉？是不是感觉这个简历内容很有投机的感觉，让人觉得不踏实。这里列举了一大堆知名公司，好像很厉害，但其实结合这份简历中的其他内容，明眼人一看就知道这段话实际的含义是：做了大量外包项目，而且每个项目的时间都不长。
这种简历，一般都是投机性质的。简历作者会往各个小公司投简历，碰到那种看不破的公司，就容易被忽悠。会被忽悠的公司，一般也没有足够的技术能力去面试其技术水平，就可能被其忽悠出一个较高的薪资。
该简历中类似的文案还有：
使用前端智能化工具gulp进行模块化开发。
内容虚构的简历
来看一位拥有4年工作经历的“百分比先生”的简历：
每次游戏活动能够准时上线，上线后用户体验良好，吸引了30%老玩家回归。
可视化配置的客服系统能够便捷按时开发完成，提高了50%的页面开发效率。
通过开发聚合SDK，将权限与路由统一处理，提高了前端50%的开发效率。
权限平台的开发，让运营人员将权限的操作进行了可视化，提高了70%的工作效率。
数字化平台的推广与接入各个事业部，提高了事业部20%的工作效率。
通过使用课件编辑器，让老师备课到选题进行在线编辑预览，提高了50%的备课效率。
课件编辑器的幻灯片在线播放，提高老师端与学生端20%的工作效率。
接入了试题库以及题目SDK的使用，提高了老师30%的工作效率。
官网上线后的体验极佳，吸引了20%的老玩家回归。
这是一份充斥着各种百分比数据的简历。 正常情况下，数字会让简历显得更有说服力，但这份简历成功地起到了反效果——看着太假了。 老玩家回归和官网上线按理关系并不大。而且所有百分比数字都是10的整数倍。 显然这些数字是简历作者自己凭感觉定的。
频繁换公司的简历
这是一个工作经验2年的简历中的内容节选：
工作经历：
- 上海XXXX科技有限公司（2021.08 - 2022.07）
- 杭州XXXX网络技术有限公司（2021.01 - 2021.06）
- 杭州XXXX开发有限公司（2020.09 - 2020.12）
这个简历中，每份工作经历都很短，最长的才一年左右。短短2年时间内换了3次工作。 这样的简历，就算内容让人觉得技术能力过关，也很难让人有意向去招聘这个人。 因为很可能这个人不适合团队协作，或者抗压能力低，总之就是招这个人风险很高。
什么是好的简历？
这是一份在线简历，简历地址：https://www.orzzone.com/cv。
为什么说这份简历好？因为是我自己的简历（误）。
首先从简历的使用上来说。这份简历完全是按A4纸格式撰写的，右上方也有打印功能，这一点就非常方便投简历的投递使用。另外，打印内容与页面在浏览器里显示的内容一致，这一点使得我们不需要额外调试打印出来的样式，可以直接根据页面在浏览器中呈现出来的样子决定是否需要对某些内容进行调整。
其次，从简历的可读性上来看。这份简历重点突出，重点关键词用了加黑效果，部分还加大字号显示。另外，这份简历用了不少图片，能有效提高看了一天简历的面试官的兴趣。
再次，从摆事实的角度来看看。很多简历里都只有干巴巴的描述文案，我们这份简历里使用了不少数据。而且一看就是计算出来的数据。但是现在简历造假的人太多了，如果有人怀疑简历中数据的真实性质，可以直接让他们去背调即可。
最后，简历的内容才是核心。排版样式和技巧都是辅助的，简历最核心的还是求职者自身的能力展现，如果自身能力不行，再多的技巧也于事无补。所以大家在平时工作中要注意自我提升，编码时多带着些思考。争取一些有意义的或者偏技术性质的kpi来做是很好的一种途径，既提高了在现任公司中的影响力，也对简历的内容撰写有了不少的帮助。
面试准备
备战面试，应该从4个方向进行准备：
- 日常知识体系的搭建：包括各种渠道获取到的知识，比如书籍、视频、文章。
- 日常项目经验的积累：包括公司项目和个人项目。
- 网上面试题的积累。
- 针对自己的简历有重点的去准备对应知识。
知识的总结可以通过画思维导图或者记笔记（比如写这本书）的方式进行，方便日后回顾。
但是日常知识体系的搭建和项目经验的积累是靠平日里一点一滴积累起来的，有很多经验性的东西， 靠看面试题之类的是很难积累起来的，比如代码重构相关的经验、对工程化项目代码的理解等。
新人或者一直做小项目或者一直在做大项目里某个子模块的开发可能会觉得所有能封装的东西都封装起来比较好，这样修改相关需求时往往可以事半功倍。
但是经常在大项目里跨模块开发的人可能就会觉得除非非常通用的东西，很多是不用封装的， 一来经常跨模块开发意味着对很多模块的熟悉度都有限，容易出现改一个地方多个页面出错的问题， 测试的时候因为不是需求相关页面所以根本没测，就变成产线问题了，而当一个组件被很多业务里用到时，如果没有人精心维护这种组件， 这个组件内部的代码很容易变得非常丑陋，到最后没法轻易地知道要传什么属性给这个组件。
你说这两种想法有孰优孰劣吗，我觉得是没有的，这个事情就是要看项目体量，体量小时容错率高（比如不容易漏测试，更大概率用户量小）， 项目的学习/熟悉成本也低，业务复杂度低，这种情况下我觉得就是要尽量封装。 但是体量大了我就不建议尽量封装了，体量大了容错率低，而且对工程项目来说，可维护性才是最重要的。
当然凡事不绝对，比如虽然是个大项目，但是有很多开发参与，每个人又主要各自维护其中个别几个模块，那其实就是多个小项目的情况了，也就适合封装了（小模块内封装模块自己用的，非常通用的封装到外面）。