最近有很多同学说觉得最近简历可以，面试的时候也觉得自己发挥的不错，但是每次在面试完等通知的时候却是毫无音讯了，在面试之前，一份好的简历，会让面试官选上你，但是当有一份适合自己的简历，会让你在面试时发挥的更好。
今天准备逆向思维从筛选简历的角度说说写简历时千万不能出现的 3 个问题。
大部分简历一眼瞅过去，都可以被快速划分为三类：淘汰、惋惜、通过。
其中淘汰和惋惜的，或多或少都存在如下 3 个问题：
简历中各种各样的「精通」；
简历中撒谎的痕迹；
简历中出现明显的低级错误；
下面我们就每一点展开的说一下：
9753298431696803765.jpg
一、千万要慎用「精通」
重要的事情说三遍：慎用「精通」，慎用「精通」，慎用「精通」
举个例子：
精通 Windows 操作系统；
其实一般能写上自己精通的同学，肯定很自信吧，那么这么自信的人，一定还算厉害吧？即使不厉害，也比一般人要强吧？
举个例，我有一个之前也是面试测试之类的朋友，他跟我说，每次看到有人写着自己精通Windows 操作系统的简历，他也有约过这样的同学，但是，自从见过几个之后，真的，真是有点失落，所谓的精通是因为一直都用 Windows 系统，操作过程没有出现过解决不了的问题，好点的是曾经帮别人简单维修过电脑。
然后我就问了，你期望的精通是啥呢？他说其实他并不期望找一个精通 Windows 的人，熟悉 Windows 的系统原理就行，比如懂点注册表基础、文件系统基础、进程相关的概念以及基本的网络协议，再深入一点，可以了解下系统内核层和应用层的配合关系，如果这些基础知识都知道，请写「了解 Windows 操作系统基本组成原理。」
可能会有人说，Windows 系统这个例子太特殊，操作系统确实太复杂，我写精通 Office 总可以吧？
那咱知道 Office 套装一共包含那几款应用不？不知道？那精通个什么？
那写精通 Java、C++、Python 或软件测试理论总行吧？我可是做过大项目的人。我不知道你说的大项目到底有多大，但是我知道，对技术越是有深入了解的人，越是能了解自己的渺小，越是能明白自己的无知，也就更加不敢说自己「精通」了。
建议：如果不确定自己是否真的「精通」，那么就不要写「精通」。
如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以加软件测试交流：1085991341，还会有同行一起技术交流。
a8d87912132643ea8086699ac1a792db.jpeg
二、千万不要撒谎
然后我朋友又跟我说有些简历之所以觉得惋惜，是因为简历写得太完美，让他觉得目前的岗位配不上他，比如他的个人技能的内容，几乎包含了 SEO 需要的所有关键字，把所有能吸引人注意的东西都罗列上去了。
不信你看：
熟悉 Java、C、C++、Python、JS、PHP、MySQL、SQLServer、Mongodb 等；
之前的话，这些同学他说他也是会约的，毕竟测试人员经历的项目多了，广度上确实也是一个优势，可是见过几次之后，他说他心里就开始抗拒了，比如问他的了解程度，得到的答复可能是：
大学课程学了 C、C++、Java、SQLServer，后来用的少；
之前公司的自动化框架是 Python 实现的，有添加过一些用例；
测试过一些 web 项目，前端用到 JS 和 PHP，数据库用的 MySQL 和 MongoDB；
好吧，没毛病，只是这种「了解」和他预期中的了解程度并不一样，至少在项目中有实际的使用，比如动手写过东西，哪怕是很简单的操作工具之类，只要是自己独立完成过的都算。
其他还有一些故意增加光环的内容，比如：
做过学生会主席——实际是干事；
带过团队负责过项目——实际是带一个人完成过小项目；
自己定位过一个难搞的问题——实际是辅助开发搞定；
自己写过自动化工具——实际是参与团队的工具开发等等。
这里一定要区分是「我」做的还是「我们」做的，甚至是 TA 做的，这些光环虽然有可能增加面试机会，但如果真是因为这些光环获得的面试机会，那么面试时就不可避免的会被问到这些内容，稍微了解下细节，立马就知道真相了。
所以说，请一定要实事求是，千万不要想蒙混过关。如果你真觉得这些东西重要，那么就在工作过程中加强关注和学习，这样长的才是真本事，面试时才有底气。
a6090992118e4085bfbbaed66fa9ffc7_th.png
三、千万不要出现低级错误
举个例子，有人的自我评价这么写：
本人拥有性格开朗乐观，责任心强，具有较强的学习能力，思维严谨，注重细节,以及注重用户体验等特点。
我是看了几遍才明白「拥有」和「特点」是配对的，不管是长句子，还是短句子，请一定要保持通顺，不然「注重细节」就是自己打脸了。
其实自己看自己写的东西，很难发现问题，这个我是深有体会的，但也不是没法避免，比如逐字逐句的阅读，另外还可以找其他人帮忙 Review，就类似我们测试过程中会涉及需求评审、用例评审，甚至是代码检查，同样都是为了从第三方角度进行把关。
例子里面还有最后的逗号也用错了，作为测试，很多人是看不上手工测试和 UI 测试的，觉得没技术含量，既然这样，我们自己请先不要犯这种类型的低级错误。
同样的，作为测试，我们会在开发和产品出现低级错误时生气，因为自测不过关，浪费了我们的时间，既然这样，我们自己请先不要犯同样类型的低级错误。
我记得有位朋友说过，他筛选海选笔试题有一个独门绝技，可以瞬间淘汰一批粗心的人，关键方法还比较简单，就是先看多选题结果，如果有人所有的多选题都按照单选题去做了，直接淘汰，这已经无关乎答案是否正确、思路是否清晰了，关乎的是态度，认真的态度，类比到实际的项目，就是说需求都没搞明白，根本就谈不上保证产品质量了。
嗯，有道理，一屋不扫何以扫天下？作为测试人员，请务必不要犯我们自己眼中的「低级错误」。
以上内容希望对你有帮助，有被帮助到的朋友欢迎点赞，评论。
网友评论