找工作时的临门一脚
即使前面完事具备，仍然有很多人找不到工作，而这可能是个不得不面对的事实，就是你的能力水平还没有达到用人单位的要求。毕竟，不是人人都是电脑天才，对于许多人来说，编程也只是一份工作而已。
本书第一章就提到了「热爱」，既然你想找编程的工作，首先你要明确自己是不是真的热爱，如果不是的话，最好不要浪费时间。如果你都没有很热爱编程，为什么要“选”这行呢？对的，重点就在选字，很多人是没有选择的权力和机会的。就像「996」很多人受不了，但也确实无法放弃这份工作，因为找不到更好的，甚至降薪也不行。
因此，我们隐约可以感受到，在互联网一线大厂之外，在那些风光的“技术网红”背后，还有着成千上万的「技术水平一般」的程序员。他们只能靠任劳任怨，努力 coding 来做好这份工作。当然，「技术水平一般」是个很不严谨的说法，这里的一般是相对于团队平均水平，以及同样工作年限的行业平均水平。具体到面试的时候，还取决于面试官对平均水平的感知。
对于这部分同学，有些可能是为了谋份工作，有些积累再做打算；有些可能是工作几年，然后就回老家有安排；还有些是体验下生活，方便继承财产 …
我们姑且不考虑那么长远，只说那些想换个环境，但仍然想做程序员，且当下可能能力还有些不足的程序员，在跳槽之前该如何准备这临门一脚。毕竟技术的积累和专业技能的提升不是一天两天的事，面试之前可以突击准备，但往往收效甚微，稍微深入考察即可知道真实水平。而我下面将要讲的，是比突击技术更有效率的备战方案。即：努力挖掘自身除了技术之外的优秀品质。
此法之所以有效，是因为**即使是面试纯技术岗位，其对技术水平的考察也往往不是最关键的部分。或者可以说，至少不是决定面试成败的首要因素。**技术水平固然重要，但它有一个阈值，而这个阈值取决于以下三个因素：
- 简历的工作年限及项目经历给面试官的预期；
- 应聘团队的同期人员平均水平；
- 当前行业对同期人员平均水平的预期。
对于以上三个因素，我们唯一可以改变的就是简历给面试官的预期。关于如何准备简历，前面已经说过了，这里不再赘述。唯一想强调的是，很多事情的最终效果，都取决于先前的预期。所以对于简历这里，你如果能在通过筛选的标准之上尽量降低面试官的预期，那么将对后续的面试非常有利。
以上这些，只是获得一个面试的机会而已，对于许多人来说，这一步已经很难了。如果你能顺利进入面试阶段，说明至少简历上写的技术水平是合格的。但是，通过简历筛选已经很难了，个别细节夸张一点也是难免的，如果错误地给面试官造成过高预期，八成面试就没戏了。别担心，剩下的两成希望在哪里？对！那就是除了技术之外的优秀品质。
作为资深面试官，**即使面试者技术不是很符合要求，也往往会尝试寻找面试者身上的亮点。**比如一道面试题你不会，但是你在积极思考；一项技术你不会，但是非常果断地说「我可以学」；虽然技术能力不足，但是你从来不出错，没有出现一次发布事故；虽然你普普通通，但是看起来老实憨厚，没那么多幺蛾子 … 这些都是技术之外的优秀品质。团队需要都是电脑天才编程高手吗？不需要。天才和高手毛病多的是咧，未必是个好员工。
那么，到底如何才能发掘自己身上的优秀品质呢？如果我真的优秀，为什么找不到工作呢？淡定。优秀不优秀，都是相对的，人们往往会被某些耀眼的光芒遮蔽，从而打击了自己的信心，甚至否定自己。其实每个人都有自己独特的优秀品质，这不是鸡汤，而是事实，只是你还没有发现或者没有得到认可而已。具体来讲，你很可能具有以下优秀品质：
- 你工作很踏实，不会频繁跳槽；
- 你很努力，任劳任怨；
- 你对待工作很认真细致，很少出错；
- 你很愿意合作，善于沟通；
- 你愿意主动推进工作，并承担相应责任；
- 你乐于助人，喜欢帮助团队成员；
- 你擅长处理团队中的杂事；
- 你擅长活跃团队气氛；
- ，你擅长文档沉淀；
- 你热爱分享；
- 你积极的态度可以感染他人；
- 你做事很靠谱，让人放心；
- 你喜欢请客；
- 你很帅/漂亮；
- 你擅长背锅（haha）。
这些品质都是团队中不可或缺的，你只需要具备任何一条及以上，就有可能被当作亮点发掘。此外，如果在同公司，同一时期的几份简历中技术水平都差不多，那么只要有一条优秀品质就足以让你在竞争中胜出。如果你真的，非常悲惨的，一条也找不到，那就给自己一点时间，重点培养其中几个优秀品质。至于如何培养，条目本身已经不言自明了，尝试照做即可。
真正面试的时候，只有短短的半小时到一小时时间。如何在这短短的几十分钟里充分展现自己，可是一门大学问，怕是三天三夜也说不完。不过对于展现自己的优秀品质，可能用不了那么久。你只需要用心准备一些「小故事」来强化或者扭转面试官对你的印象。我不是教你诈，也不是教你夸张地润色过往的工作，只是想让你在过往的工作经历中仔细搜索，找出那些能印证上述优秀品质的案例，并且简洁而完整地表述出来，不夹带半点虚与委蛇。
举个例子，你的项目经历中写了参加 xx 项目前端开发工作，那么面试官可能会问具体做了什么，你在项目中起了怎样的作用。那么首先，你要陈述项目是什么，都用到了哪些技术。许多同学回答到这里，就不做声了，等待面试官继续发问。其实最重要的第二部分，你还没有回答，即：你在项目中起了怎样的作用？而这部分才是真正体现你能力和亮点的部分，这个问题考察了你对所负责的产品的关注和理解程度、你与上下游是如何协作以及你的沟通协作能力如何、你遇到问题是如何思考和解决的、你是项目的推进者还是仅仅作为开发资源完成工作、项目结束后你是否还有思考总结、是否有采坑经验或方法论输出、对后续团队他人的工作是否有帮助等等。
有的同学说了，如果我真的只是作为开发资源，无脑编码，项目完成之后没有任何思考呢？那我建议这个项目可以不写在简历上，与其列出一个可能让你减分的项目，还不如保留一点想象空间。
再举个例子，你的多个项目里都用到了某框架，看上去你对这个框架已经相当熟悉了。那么面试官可能就会抓着这个框架问到底，如果恰好 TA 也很熟悉的话。此时，如果你能对答如流，那便不在“技术水平一般”的程序员之列了。如果不能，你最好能够针对某些使用过的方法进行深入解答，最好能说出某个面试官不知道的点。再退一步，你可以说“我看过它的源码，有一部分写得特别巧妙，blabla”。你看过吗？是的，必须看过，但是这个完全可以是准备面试的时候，技术备战部分的重点工作。这里体现的是你的钻研精神，一定程度上也反映了你的潜力，因此，即使你现在技术水平一般，也可能被划到潜力股。
同学又说了，如果我真的不熟，也没有深入了解过某方法，更没看过源码怎么办？好办。那就提前深入了解，看源码，把某方法搞透彻。否则就不要在简历上写的满眼都是。写在简历上的，一定是你有信心 hold 住的，或者是比较熟悉的，不熟悉的部分尽量少写，万一面试官挑了几个都是你不熟悉的呢？还有机会了吗？
还举个例子，有些面试官可能会问下平时有没有 github，有没有写些文章分享什么的。很多人说“有，但是没贴在简历上”。如果有耐心的面试官，可能会在电脑或手机上让你打开看一眼，否则这句等于没说。对于自觉技术水平一般的程序员，一定要放低心态，你的 Github 不需要绿油油，你也不需要是 CSDN 博客专家，记住一句：聊胜于无。再退一步，即使被当作矮人里面拔出的大个儿，那也算是鹤立鸡群，起码我是个踏实的人，没有好高骛远。
同学还说了… 同学你先坐下。这件事你不可能做不到，否则不要做什么跳槽的美梦了。如果实在不知道写什么，可以再回到本书前面的，关于写作和分享的章节再读几遍，或许能给你些思路。
上面几个例子都提到了简历，许多教程都在教大家如何优化简历排版，做出一份漂亮的简历。而我这里，不仅强调内容的重要性，更强调了简历内容给面试官的预期与你实际能达到的预期之间的关系。
假设你的简历是一则披萨广告，看上去还不错，面试官点了份外卖。结果送过来以后，没有那么热气腾腾，看上去也没那么可口了，毕竟“图片仅供参考，具体以实物为准”。披萨端到桌上以后，闻起来还是挺香的，面试官决定尝试一口。一口下去，似乎又没什么亮点，普普通通而已，但是吃着吃着，忽然发现，居然有肉耶！这是始料未及的，毕竟很多广告都是把肉摆在上面的，这看上去平淡无奇的披萨，里面居然藏着澳洲牛排！“这披萨还可以，起码有肉啊”面试官说。
那块藏着的肉，就是你想展现的优秀品质，前提是你要把握好预期。如果你没有那么优秀，却把广告打得让人垂涎，最后就很难填补面试官心里的落差了。而如果一件事情开始比较平淡，但是有高潮，结尾也还能接受，就是一次出色的面试经历。对于技术水平一般的程序员，可能你需要达到的效果就是面试官口中的“技术一般，但是人还不错”，或者说“技术一般，但是聊得很投缘”，那就算是成功一半了。
如果你觉得上面的例子都太虚，为什么不 show me the code ? 那么我想再次强调一次，技术考察绝对不是最重要的部分，但你确实绕不过。可以说，对技术基础的考察其实是个采样的过程：通过对一个一个的点，再到线，再到知识面以及整个知识体系的深入考察，做到尽可能地对你的技术水平给出客观公正的评价。
既然是采样，总会有误差。除非面试官每次都按一个知识点清单挨个问你，否则最初采样的点，一定是简历上体现的点。换句话说，你在一定程度上可以影响面试官的采样过程。这也是为什么上文说到一定要写有底气的部分，不熟悉的宁可不写，因为写了就可能被当作采样的点，结果发现你对这个概念其实一无所知。假如把整个面试当作一次采样过程，那这一次，就会拉低整体的预期均值，自己坑了自己。结论就是：简历并不是内容越多越好，要写重点。
再举几个实际的例子。下面我将使用「简历表述」，「可能的风险」以及「更好的方案」，这种格式来表述。
例 1
**简历表述：**能够像素级还原设计稿。
**可能的风险：**如果简历中出现“像素级还原”这种字眼，那么面试官可能会问“你是怎样保证像素级还原的？”，而许多同学可能这一句话就给难住了，因为“像素级还原”在他们心里是一种形容词，而不是真正可以量化的像素级还原。或者你可能知道一些工具，可以把设计稿覆盖在页面上对比像素，那么接下来的问题就是，每个端每个浏览器你都会这样做吗？由此引申，还可能问到你是怎么量取设计稿各个细节尺寸的问题，结果有些同学真的只是靠眼睛看，从来没有量过。或者是用截图工具大概量一下。别说是像素级了，连毫米级都算不上。因此，类似“像素级”这种说法，说白了就是把话说得太满了，很容易被挑毛病或者刨根问底，除非你真的非常有信心。
**更好的方案：**既然话不能说得太满，但我还原设计稿的能力又确实不错，那么可以说“能够在保证兼容性的情况下精准还原设计稿”，然后在面试官问到的时候，再把你如何“像素级”还原的良好工作习惯，以及如何处理兼容性，并保证精准还原设计详细阐述一番的话，就很容易出彩。
例 2
**简历表述：**对前端性能优化有一定了解
**可能的风险：**这个话很低调了吧？是的，话没毛病，但是回答方式可能有坑。首先，当面试官问你“请你说说工作中都应用了哪些跟性能优化有关的东西？”。那么，今年已经是 2019 年了，就不要再拿雅虎 xx 条来糊弄面试官了吧~ 难道你还要回答 CSS 放前面 JS 放后面，图片要合并吗？这种回答没有任何亮点可言，除非面试官说“来，先背一遍雅虎 xx 条吧”。
**更好的方案：**如果除了雅虎 xx 条之外，你在工作中没有任何其他跟性能优化有关的经验，那性能优化这个点也可以不写了。你可以挑选一个可能体现性能优化的项目，顺带说一下你对这方面的理解。有些同学工作经历中一直在做后台系统，甚至完全是对内的系统，所以就说没有做什么性能优化。这种思路本身就是有问题的，对内的也是产品，也要对用户体验负责，难道内部系统就应该理直气壮遭人吐槽吗？所以，如果你不能提前准备关于性能优化的亮点，那么起码要体现出，你是时时刻刻把性能优化印在头脑里，贯穿到你的每一次需求中，即使因为各种原因不能做，也要保持这种意识。
例 3
**简历表述：**熟悉 linux 常见操作
**可能的风险：**首先，了解/熟悉/熟练/精通 这些词往往带有很大程度的主观性，所以非常可能出现面试者本身的感知与面试官的感知不匹配，但是简历也只能这么写，所以如果不是真的很自信，可以压低一档。比如许多文章里也都讲过，简历中不要轻易用“精通”这个字眼，除非是真希望面试官注意到这项技能，不然一定会被重点考察直到问到知识边界为止。这个熟悉 linux 常见操作，可能会让你列举几个知道的命令，基本的文件目录操作，系统性能监控，搭服务器配个站点等等；也可能问你是本地搭建环境自己玩还是买过云服务？平时都在上面搞点啥？是否熟悉阿里云腾讯云等？那么你就要思考一下，你理解的“熟悉”到底到了哪一个层面，能不能 cover 面试官心里的“熟悉”。
**更好的方案：**简历表述没有问题，同样是要提前做好充分准备。或者明确写出：熟悉基本文件操作，LAMP/LNMP 环境等。那么如果等到面试官问到再说不行吗？当然可以，不过要记住，面试时间只有这么多，每一次提问都是一次采样过程，尽快让面试官知道你的真实水平对你是有利的，这样可以争取一些额外的表现时间。即使真实水平立马被否定，至少我们没有浪费彼此的生命。
例 4
**简历表述：**设计，架构 xxx 系统
**可能的风险：**当你用“架构”这两个字的时候，一定要清楚你到底“架构”了什么。因为面试官很大概率在技术水平上会比你高，那么在 TA 脑中的架构，含义一定不同。你可能觉得选了几个框架，组织些文件就叫架构了。而面试官正津津有味地期待与你交流真正的架构经验呢。我甚至还在某些简历里看到有人写到“架构、开发公司产品微信公众号页面”，我是真不知道页面是如何架构的，或许这位同学可以给我讲讲。
**更好的方案：**如果你在公司里不是架构师岗位，或者没有做过什么真正的架构，那么轻易不要用这个字眼。虽然架构师头衔已经烂了大街，但是大家对架构这个字眼还是有杆秤，用不好就死得很惨。跟“精通”是一个道理。你可以用更清晰的表述，比如参与项目的技术选型，参与搭建项目前后端开发框架，解决了高并发下的访问瓶颈，解决了异构系统的数据一致性问题等等。这样显得既专业又精准，可以很直观地看到大概的能力边界。同样，在可能的情况下使能力表述压低预期，并在实际面试过程中尝试表现得超出预期。
总结一下，基于以上的例子我们可以看出，简历表述以及备战有以下注意事项：
- 话不能太满，表示程度的字眼要慎重，宁可降一档，保留足够的想象空间；
- 老套的固定回答或者面经要尽量避免，至少换种说法，不要照搬网上的答案；
- 表述尽量清晰，尽快展现真实实力，争取额外的加分表现时间；
- 尽量避免使用主观差异可能过大的字眼，比如“架构”这种。
好了，关于技术水平一般的程序员，就说这么多。以上这些对于技术水平很好、技术水平卓越的程序员面试同样有用，并不冲突。只是技术水平一般的程序员可能更需要这些。当然，如果想长期从事技术工作，那么核心要务还是提升自己的技术水平，尽快摆脱”技术水平一般“这种印象。同时也不要忘了其他优秀品质的培养，避免成为”技术不错，但是给人感觉不太好“那种应聘者。你确实不怕找不到工作，但是如果想走得更远，与人为善总是没错的。祝你好运！
那么对于如何提升技术水平，跻身优秀程序员行列，你想不想听听《21 天变身高级工程师》？不，你不想。还是让我们聊聊，假如你是个幸运宝宝，通过上面的小技巧成功通过面试进入理想的团队，接下来应当如何生存下去。
毫无疑问的是，最当务之急的事情就是要摆脱“技术水平一般”这个印象。幸好，目前为止只有你的面试官可能会这么想，他一定不会跟全组的同事说：“我们新招了一个技术水平一般的新同事，大家以后要多多关照哈 ~”。如果真有这样脑残的面试官，也好，全组同事对你的预期已经很低了，在这种情况下是很容易让其他人看到成长的。到时候他们就会说：“嗯，xxx 好像进步挺快的 ~”。
所以，你首先要努力不让更多的人觉得你不行，然后再暗自努力追赶到团队的平均水平。既然能通过面试，说明你距离团队的平均水平并不遥远，因此也不必气馁。尽管同事们看起来都很优秀，但真实的差距，往往没有你想象得那么大。
你需要做的是，尽快让同事先看到你优秀的品质，而不是看到你糟糕的技术。比如你喜欢运动，并且还算擅长，那就先找找爱运动的伙伴，展现一下阳光活力的一面；比如你爱旅游，可能把新人自我介绍丰富一下，包装成一个背包客的自白；然后，当你的在技术上的某个点有足够的信心做分享的时候，再去分享技术方面的东西。
平时的工作也是一样，起点低对你来说是件好事。因为上级交给你任务的时候，对你的预期是偏低的，当然，你也可能做得比预期还差，不过这不重要。重要的是，你要知道，在你刚来的这几周，是你给他人留下印象并强化印象的关键时期，因此一定要把握好每一个任务和每一次表现机会，千万别马虎。一旦既定印象形成，就很难逃出这个怪圈了。
那么在技术方面，到底该如何提升，并且表现得超出预期呢？
首先，既然你是“技术水平一般”的程序员，那就要多观察团队里技术水平好的程序员，看看他们是如何工作和学习的。最好能找到一个明确的参照对象，注意不是对象，然后向着 TA 的标准努力。这就是职场中的“别人家的孩子”，有时候领导可能也会跟你说：“你看谁谁谁，最近就表现得不错”。那么后面领导夸 TA 的话，你就要认证听了，那就是你要努力的方向。
其次，上级交代你任务的时候，一般会大概跟你说一下要做成什么样。那么上级口中的“什么样”，就是你符合预期的标准。这里不排除有些细节上级觉得你能做到，但是没有说；也不排除有些东西，上级觉得你可能做不到，肯定也不会说。其中第一种情况是比较危险的，因此在上级交代任务的时候，要主动问清楚，到底要做成什么样。如果上级觉得你能做到，又没提到，你可能真的不会做，那么就成了低于预期。这时候你不可能跟上级说“当时你也没说啊！”。
那么重点来了，如果是第二种，上级觉得你做不到所以才没说，但是你却想到并且做到了，是不是严重超出预期了？有同学说，我哪有那么神？那么神我还在这混？其实不然，有时候这些会藏在上级的只言片语中，比如上级可能会说：“要是能 xxx 就好了”，那么这就是超出预期的标准，拿小本本好好记下来。学不会记不住怎么办？你可以申请说用手机录个音，等您讲完我再听一遍，一般人不会拒绝的。
那如果上级没说这些怎么办？还有同事呀~ 学会利用身边的资源也是基本的能力，你的同事就是你的人脉资源，尤其是在你进步的道路上，对于一个人畜无害水平一般的弱者，谁会拒绝帮忙呢？如果这个任务你不知道怎样还能做得更好，不妨把你的一点思路与同事探讨，或许能有意外的收获。至于腹黑坑人的办公室政治，在没有受到伤害之前，还是不要去想。毕竟程序员都是很单纯的，嗯。
最后，知错就改，下不为例。如果你已经很努力，最后还是犯了错，那也不要紧，新人当然可以犯错，何况是技术水平一般的新人。但是，你能做到下不为例吗？同样的错误，同样的知识点，往往还有许多人一而再，再而三的犯同样的错误。此时此刻，你是希望别人觉得你是真笨，还是希望别人觉得你只是工作不认真？我想，二者你都不能接受，但你可能仍然有自己的理由。闭嘴吧，不要尝试找借口，如果一再犯错，再找借口只能让你的处境雪上加霜。如果你还觉得自己是个上进的宝宝，就狠狠地掐几下（自己的）大腿，问问自己怎么这么没用，怎么这么不细心。否则，就认命吧，在职场中，你只能是个待宰的小绵羊，都比不上隔壁奔跑的小猪猪。
最后的最后，还是要强调一下，上文所述的这些都是小技巧，或者说是小心思，不能贪杯。而作为程序员，你的核心竞争力必然是技术能力，但技术提升总有个过程，我之所以讲这些，是希望技术之外的 东西不要成为你职场成长过程中的障碍，千万不要痴迷于其他方面而忽略了技术本身，这就本末倒置得不偿失了。 下一篇: Chapter 12-01 如何调整工作状态