程序员：面试中的个人竞争力

前言

最近因为个人原因换了份工作，离开了呆了5年的百度，应邀写一篇关于iOSer找工作面试相关的文章。我回顾了一下从毕业到现在的工作经历，我发现我几乎没怎么面试与找工作过，基本上就一直在百度一呆就是5年。真要说在找工作/面试技巧/Offer选择上我有啥经验，可能值得介绍与分享的非常少，就连这次换工作，我也基本上是面了一家就定下来了。

不过我觉得面试技巧也好/找到理想的工作也好，其实离不开展现你个人的竞争力，展现你个人最好的一面来让自己在竞争中脱颖而出，从而赢得好机会的青睐。所以这篇文章主要和大家聊聊 个人竞争力

很少写鸡汤类的文章，尤其是个人经验个人感悟，有时候听的人总会觉得稍微有点虚。但在百度当面试官，当晋升评委，面试过不少的人，也见识过很多技术人在面试过程中经常犯的错。站在面试官/评委的角度，什么样的能力与素质算得上有竞争力，这些话题虽然有点虚，但也算换个角度给大家一些参考。

其实主要就是想从2个角度来聊一聊

• 展现竞争力：

面试也罢，晋升也罢，归根结底要把自己最好的一面展现出来。但很多技术人都会有一些困扰，做了好多东西深入的研究，但不知道如何表达，一两句话说完了，别人也感受不到这里面你的心血与技术投入。怎么办？

• 增强竞争力：

思考如何展现出个人竞争力的前提，就是要自己不断地培养资深的实力。但日常工作非常琐碎，无休止的迭代画界面，这种枯燥的工作下，毫无技术提升，怎么办？

在展现个人竞争力

既然聊面试，找工作，就是在聊一个如何表现自己的个人竞争力，如何把自己推销出去的话题

在简历上，展现竞争力

写简历我觉得可能很多人存在很大的误区，先总结出两句鸡汤，然后再详细和大家说明一下

• 大家都写，每个人都千篇一律，每份简历上都能看到的东西，除了必不可少的，能不写绝对不要写

• 项目经历多，简历特别长，那就干脆很多项目直接不写。只留下最突出的重点，最表现你思考深度技术深度的项目，其他一句话带过甚至省略

其实简历也不一定完全按着我下面介绍的套路来，但遵循这上面两条鸡汤，你完全可以自由发挥。其实所有的出发点就是你觉得你写出来的这份简历跟别人比，有啥不一样的？能吸引人眼球的？这就是竞争力

基本信息一定要写

什么是基本信息？就是下面这些信息，任何公司的HR系统，都需要录入的，用于录入内部人才库检索，用于联系你。这就是必不可少的信息。照片？可以贴可以不贴呀～这个比较随意～

• 个人信息

  • 姓名/出生年月

• 联系方式

  • 邮箱/电话

• 教育经历

  • 学校名称/学历/时间段

个人技能，熟练XX，精通XX，完全不要写

1个面试官如果一天需要筛选100份简历，能有95份简历写着，熟悉Objective-C，精通Runtime，熟悉Hybrid，精通ReactNative，熟悉XXX等等。槽点就来了，如果你是面试官，看到这些你有什么感觉？

• 精通？你说的精通是深入源码底层各种666的精通，还是79块钱买本书21天精通XXX的精通？

• 你说是精通就是精通了？我为啥要相信呢？你说后面的项目经历能体现出来？那直接看项目经历就好了，在这里写这些不多余么？

• 还有人给自己的技能打了个分，或者画了个进度条。你自己说你达到这个水平，没有面试官会觉得这些评分有参考价值，还是要看实打实的项目经历

• 一口气列了七八行精通这，熟悉那，一大坨文字，格式几乎都一样，面试官很容易视觉疲劳。你就是夹杂着一个 精通 Objective-C 等单词的拼写 ，面试官都可能看都不看一眼

个人技能其实完全可以舍弃，毕竟项目经历才是证明你能力的核心。但如果想表达一些除了日常工作之外的技术栈，那么在这里写一下个人技能也不是不可以。如果你想表达你有多方向技术栈，在这里就只写技术栈涉猎范围，iOS/RN/FE/Node.js等。自己拿捏你最想突出的技术栈或者技术方向，别一口气写了个iOS，然后一个古脑把Runtime，MVVM，组件化，动画特效，性能优化，数据库，什么能想到的名词都堆上去。

• 不要写太多，全是重点等于没有重点，涉猎技术栈范围全写上去等于全不会。

• 不要加任何修饰与描述词汇在这里评价你的水平，水平要考后面货真价实的项目经历。

工作经验，挑重点，不要写流水账

工作经验是简历的重要组成部分，经历过的每家公司一定要写清楚 公司名 /  入职时间 /  离职时间 /  职位 ，这几个内容是重要的不能缺失的，大公司的HR人才库会严格入库记录的。因为很多公司是很看重诚信的，这块建议把所有经历的公司按着时间倒序一一写清楚。（如果有一些特殊原因，比如某段工作经历特别短，那么简历里没体现，建议也要在面试的时候提出）

每家公司其实还需要介绍一下 工作职责 ，负责的业务情况，团队情况（如果你是带团队的），大体使用了什么技术栈（如果你不写个人技能那一块，涉猎技术栈更适合放在这里）。

• 挑重点1: 如果你的工作经历非常多，换过的公司比较多，比较久远的公司就不要写 工作职责 了，写上四大基础信息，一带而过吧。

• 挑重点2: 如果你最近的一次的工作时间非常的长，你在这家公司经历了个人的成长，角色职责也经历了转变与晋升，那么你完全可以把最近的一次工作经历细化，细化出子时间段。XXX时间-XXX时间，普通研发工程师，负责XXX模块业务功能迭代。XXX时间-XXX时间，晋升，负责了XXX更大业务，带了团队。这块可以灵活控制，但只要遵循一个准字，挑重点，不啰嗦！

项目经验，挑重点，体现技术价值

项目经验其实应该区别于工作经验，在这里体现出你亲自做过亲自完成的技术成果，展现你的技术深度，这里才是应该用事实例子来证明你精通XXX的地方。如果你写负责XX项目的日常常规迭代，保证产品稳定，写这么一行废话基本上就等于工作经验里的工作职责，负责了XX业务几个字，那这种项目经验其实根本不用写，在工作经历的职责里已经介绍过了。

项目经验应该写什么？应该写体现你技术深度与技术价值的具体Case，而不是笼统的说负责一个产品业务负责实现迭代上线。在这个Case里越细化越好，越突出你个人做的技术努力越好。这里应该是找你的工作生涯中的亮点项目（技术驱动的Topic/有着高业务复杂度的Feature），抽出来进行单独说明和展现，进行亮剑，展示你的技术肌肉。普通平庸日常的工作干脆就不要提了。

至于什么东西堪称亮点，每个人的看法与经验都不同，不是说得难到什么程度才能摆在这里当作亮点进行强调。而应该是从你所有做过的项目，开发过的模块中，找到你觉得最有价值的，最有深度的内容，挑3-4个，4-5个。对于你来说这些就是你的最拿得出手的亮点，不必管别人眼里什么东西才称得上难点，什么东西才称得上亮点。

举个例子：

• 技术驱动的Topic

因为业务上有XX问题XX背景，纯技术驱动，深入到源码底层，进行改造或者扩展支持，构建了一个XX系统，支持外部这么使用，支持外部那么使用，支持外部灵活扩展，对外提供给外部门，外公司使用。（纯技术上的一些特点，根据自己的case进行描述，亮出自己的肌肉）

• 有着高业务复杂度的Feature

因为业务及其复杂，在各种条件下有着各种处理逻辑，相互之间存在嵌套与依赖，并且还要满足PM的未来扩展和定制需求，基于此设计出来的XX结构，包含了 XXX层 XXX层 XXX层 XXX层，相互之间隔离清晰，代码扩展性强。

以上只是瞎YY的，但需要感受一下如何表达出你做出来的独一无二的技术努力与技术深度，而不是千篇一律的，开发了XX模块，使用了XX库，接入了XXX轮子，你应该表述的是，你是如何理解你使用的轮子，你开发的模块，这里面有哪些是你的思考，这些思考解决了什么问题，创建了什么价值。

其他，个人发挥

简历其实完全可以进行一定的个人发挥，但还是要坚持一点，你要发挥的东西必须是有价值的，与众不同的！如果强行凑内容，显得自己涉猎范围很广，那不如不写

• 业务贡献：

如果你担任了一定的业务与管理职责，尽管不是PM，但有很多业务思考，你觉得这是你的一大优势，足以构成亮点，那么就可以写进去，这年头增长黑客的兴起，这其实是一个很稀缺的能力

• 开源贡献：

有些人就贴了个Github地址，写在简历里很显眼的一行，和项目经历/工作经历同一层级。遵循有亮点就表现出来，没亮点不如不写的原则，不如针对Github里的Repo，挑1～2个出来，介绍一下（如果只想贴个Github地址，不如移到联系方式里，一带而过）

• 个人博客：

有些人贴了个博客地址，也是简简单单一个 URL 放在那里，和项目经历/工作经历同一层级。还是那句话要么突出亮点，要么干脆不写。博客如果坚持更新，你的博文更新频率，1年半年内写了多少篇文章，总共多少W字，都可以在这里进行展示。如果从更新频次或者数量上不够亮点，那么挑你觉得你最好的1～2篇文章（被广泛传播过的/你技术钻研最深的），URL直接附在简历里，简单介绍，让面试官品评

• 个人奖项：

这个东西其实如果是大公司（一些被市场上广泛认可的大公司）的一些很有份量的奖项（内部奖项，绩效），可以在这里提一提。但提的时候应该强调，你的这个奖，整个公司总共多少人，有多少人能获这个奖。你的绩效，整个部门总共多少人，有多少比例能够拿到这个绩效。（这个东西见仁见智，也有可能公司的奖项并不能被面试关认可，自己把握）

简历篇幅

我始终是觉得如何把自己的最重点/最亮点的一面，用1页A4纸充分展现，那么这份简历就足够了。其他的太多日常普通的工作，完全可以不提了，相信我，所有人都在写反复的在一个又一个项目经验里写“完成项目的日常功能需求迭代”，“保证项目的稳定”，“与产品/前端/后端沟通，参与需求评审”，这种所有人都写的东西，其实根没写没有任何区别，面试官用眼睛一扫而过，根本不会停留多少注意力。

但其实也不是强行要压缩在1张A4纸范围内，但我觉得一定不能超过2页A4纸，时间比较久远的经历，非常普通平庸的项目经历，干脆就舍弃吧。

记住一句话：

用最简洁的篇幅，展现出你个人独一无二的亮点。

我一直在强调展现你个人的亮点，个人的竞争力。有可能对于不同公司，不同招聘岗位，看中的简历加分项是不同的，如果条件允许，完全可以对每一份投递的职位都进行特殊的定制，而不必非得一份简历，海投一切职位。

对于不同的职位侧重，在有限的篇幅里，你应该展现出适合这份职位的最有价值的“亮点”

准备多分简历这事不做强求，其实就看你对一些公司一些职位寄予多大的希望了，当你特别特别想去一家公司的时候，这种简历定制绝对值得

在面试交流中，体现竞争力

面试这个环节，在这里还是先灌一个鸡汤，或者说一个面试的指导思想

• 不要纠结结果，关注并且表达出来你的思考过程

确实很多公司面试是希望找到能立刻进入工作，能立刻干活，有丰富经验的人。但相信我，大公司或者说有发展眼光的公司都会很关注一个人的潜力。潜力这个词很虚，面试官如果需要在个把小时内通过沟通了解一个人的潜力，就需要了解一个人的思维过程，进一步判断一个人解决未知为题的思维方法，从而对候选人的潜力进行一个判断。所以表达出你的思考非常重要！

面试官的风格

很多人在交流面试经验的时候，会提起自己遇到的面试官，什么样的风格都有

• 有让你手写代码的

• 有照着面试题问，或者做卷子的

• 有聊技术聊业务，聊项目经历的

• 有自己也不太懂套你技术方案的（传说中有。。。）

• 有装B难为人的（传说中有。。。）

一开始先不以最坏心态来揣测面试官（毕竟如果你觉得面试官咄咄逼人，是否侧面说明这个职位团队不适合你，双向选择），就以平常心来看待如何能将你的优点，你的知识深度展现出来，让无论是什么样的面试官都能get到。你不能要求你一定遇到你习惯的面试官风格，但还是有固定的方式来展现自己。

问题与回答

遇到你十分肯定的问题，自信点直接说出答案。

遇到你内心模棱两可的问题，也完全可以适当的和面试官针对问题进行交流。有可能是问题的前提条件以及范围界定你没理解清晰，也有可能是你拿不准这个问题要考虑到多深的复杂度，所有在你推理思考出答案的过程中有疑问的点，甚至是思考过程中有一处不会，其实都是可以和面试官交流。这个过程中就体现里你的逻辑思考能力，是否能答出最终100%完美的结果并不重要，能让面试官去充分考察你的潜力。潜力这个很虚的词，就是通过不断地与面试官思维上碰撞和交流，让对方感受到的。

遇到完全没接触过的问题，如果你真的这个方向涉猎都很少，不如直接和面试官说，没有太大关系，换下一个。

遇到分歧

这里或许有一些面试官的小花招或者小心思在里面。有些时候你其实说对了，面试官心里也知道你是对的，一个劲的追着你问“你确认是这样么？”。有些时候你看着题目就觉得别扭，或者面试官给的引导就有点奇怪，有可能面试官做的一些设计在里面希望你发现或者提出漏洞。我想说的是不见得所有的面试官都会这样，但不排除确实有这种情况。当然也会有面试官本身理解就错了所以对你提出的质疑也有问题的情况。

在你并不清楚面试官是什么样的套路下，现场表现出来的情况就是，你和面试官之间遇到了分歧。分歧其实没啥，还是我说的从分歧点出发，展示出你的思考过程，逻辑过程，甚至可以在沟通中表达出你以前做过的看过的类似问题，虽然不是直接匹配但能侧面为你的回答佐证。

不要不懂装懂，但如果你经过了你自己的思考后还是对面试官存疑，把你的思考拿出来，无论结果怎样，思考过程都是有价值的。

遇到问项目经历

前边在介绍如何写简历的时候就已经给大家强调，项目经验应该是突出你的亮点，突出你做东西的难度，突出你思考的深度。如果面试官针对你的项目经历来进一步询问，这应该是一个巨大的机会，是一个展示你自己的 show time。简历里几行字表达不出来的东西此时此刻就是最好的呈现时机。

展示你的项目经历的过程，就是展示你在当初做这个项目的思考过程，遵循为什么要做，怎么做，收益怎么样的固定套路来进行表达，这个套路其实也适合职位晋升面试答辩。归根结底，这个套路本就应该是把一个项目做好做漂亮做的有深度的必备深入思考过程。

• 为什么要做？

有什么业务背景？是否有老旧疑难杂症？这个事情是否属于业界难题，业界也不是很成熟？是不是因为我们业务的特殊原因导致势在必行？这里面有什么预见到的坑必须解决？

• 怎么做？

经历过技术选型没？对比过市场上的几种技术方案优缺点？你查阅了怎样深度的相关资料来解决问题？你设计成什么样？结构有多复杂？扩展性如何？你觉得你这么设计有啥优点？深入到了什么深度的代码底层？Cover了多频繁的产品未来可预见的变化需求？

• 收益怎么样？

有多少业务接入了你的这个功能？这个性能，流畅度达到了多少？访问量PVUV多少？这个项目收益怎么衡量的？是否符合预期？

遇到开放性话题，无从回答

开放性话题你不善表达，所以不知道怎么回答？车轱辘话说了很多遍了，思考过程。不会做没有问题，按着自己脑子里已有的知识概念，找面试官反复确认场景和问题，把你脑海中关联的知识点筛选出来，从中进行推理，然后进一步和面试官沟通确认。开放性话题一般面试官也是做好准备进行引导的，如果你收到了一些引导或者提示，可以继续跟着思考下去，哪怕没有直接得到最终答案，把阶段性的思考过程与面试官互动，获得进一步的引导。

多想，把你怎么想的表达出来，你怎么想的过程是有价值的，能够体现你个人逻辑与思维能力的，是一种竞争力。

如果只是闷头不说话，闷头一个人使劲想，你想了再多也传达不到面试官，一个良好的相互交流过程才有助于面试官了解你

在工作生活中，增强竞争力

在准备面试的过程中，按着各种套路手段总结自己的简历的时候，有些人会发现平日里的项目经验都是完成日常的基础业务迭代，提炼不出所谓的亮点，如果没有平日的积累，光靠面试准备抱佛脚俨然是不行的。

在日常的工作生活中，如果你有机会被安排去做一些有深度，有难度，大项目，自然是好的，你可能不需要怎么用心，就能在日常项目开发中顺利的实现个人成长（侧面也说明，一个好的公司，好的部门，好的团队，好的平台对于个体而言是有很大很大的促进因素的）

如果你的日常工作生活，都是无聊透顶的，无休止的画界面，拉网络请求刷 TableView。如何在这样的工作环境下，收获个人技术的提升呢？

总结思考

再平凡的工作，也需要不断的反思，不断的回顾，要有一颗代码洁癖的心，不能容忍不优雅的代码。

简单举几个例子有助于理解，但实际工作中包括但不限于这些例子

• 一次业务迭代因为时间紧任务重，快速怼上代码上线了，当项目完成了，回顾一下这里面的代码有没有仓促，不合理，再时间充裕的情况下把他改好。

• 多次产品业务迭代，都是在修改同一功能模块，每次都改动成本很大，是否说明这个模块在最初的架构设计之中不足以cover可预期的产品功能迭代，是否可以和产品沟通了解一下未来的趋势，然后着手彻底优化一下功能模块的原始架构，让你的代码保持优雅，让未来的需求变更更轻松

• 是否发现项目代码中存在很多看似差不多，只有略微差异，但却被重复复制了很多份散落在工程各处的代码？是否意味着这些糙快猛赶紧上线弄出来的代码应该被重新思考，重新规划与架构？

枯燥的日常工作，不能成为停止总结思考的借口。程序员应该是脑力工作者，不是重复机械性写代码的体力工作者。如果你的工作非常单调，重复，程序员的Style应该是想办法，改进/自研开发工具，让单调/重复的工作变得自动/半自动化，解放自己的生产力。

发现问题

如果你所在的团队，没有机会让你参与一个有深度有难度听起来就NB上天的项目，这也不是问题。没有谁会在刚毕业什么都不懂的时候，就被安排到一个牛逼到爆炸的项目组，坐等导师带着，手把手就蹭着牛逼项目直接从菜鸟变成大神。

真正需要培养的，是一双自驱的发现问题，发现优化点的眼睛。自己寻找方向，自己寻找目标，然后付诸行动。刚刚入门的菜鸟，带着这样的眼睛，从小的地方自驱提出优化，自驱解决。就能证明你比别人的思考更多，更深，更有竞争力，就更容易获得高难度项目的机会。

简单举几个例子有助于理解，但实际工作中包括但不限于这些例子

• 现在业内有了一些新的技术，这些技术我们能用在产品上，能带来收益，自驱进行探索，最终落地形成收益。

• 工程中有一段功能实现已经趋于落后陈旧，代码中存在问题与隐患，自驱提出优化与改进。

• 团队的开发人力总是浪费在一些不需要多少思考的重复性工作上，为了提高研发效率，自驱的提出一些改进的技术Topic。

• 关注研发中的各项统计数据，发现其中的逻辑关联性，自驱的提出一些产品优化的点，哪怕是研发提出来的

• 产品研发中总会面临一些不可抗力，操作系统禁止，手机厂商禁止，权限不通过，因此技术上总会有一些妥协，这些妥协的问题有没有一些自驱的可以绕过的方案？

探寻本源

对待所用的技术选型，技术方案，三方框架，也要有一种探寻本源的精神。简单的说对源码有刨根问底的意愿，再往深了说，对编译原理，操作系统，图形渲染等机制有底层探索的意愿，不要甘心于只做一个调包侠。

经常会有人说“管他什么操作系统，底层源码，老夫写代码就是一把梭，复制粘贴，抄起键盘就是干”，也会有人有疑问“关心源码干嘛？会用不就行了”，这其实就是一个知其然，知其所以然的问题。

知其然表示，你只能依靠文档，接口，API说明，去了解熟悉掌握一个框架的使用，如果像CocoaTouch这样的成千上万的API，如果只想做到知其然，难道只能靠官方文档/谷歌搜索/StackOverFlow去开发了么？纯经验论？做过的人告诉你这个东西应该怎么写，你写过了才记住？

知其所以然则表示，在去查阅文档接口的同时，还去深入了解框架底层的运作机理，当有你不了解的需求给过来的时候，尽管你并不知道是否API已经开放了这个功能和能力，但通过对运作机理的理解你能先有大概的判断，甚至能通过底层/中间层的核心中枢代码，反推找到外层那个不好查阅的接口调用，如果相关接口不满足，你也充分有能力去改进支持。甚至哪一天你不满足于三方框架，而根据同样的原理机制，自己实现一套自己用的顺的自研框架。

对于三方框架来说，知其所以然就是他们的源码，那么对于各类开发语言来说，知其所以然是什么呢？是操作系统，编译原理，图形渲染机制等等。

注意这里说的是意愿，不是要人人抱一本龙书，没任何生产实践的情况下硬啃下来全套编译原理，而是希望你在学习了解一个事物一个框架的情况下，不要止步在外层调用，遇到一个case，可以根据这个case尝试深入，带着case去理解底层代码。同理遇到一个case也可以深入到操作系统机制，甚至编译原理之中，君不见很多启动性能优化的方案来源于什么？为什么有的语言能热更新，有的不能？带着case，带着探究本源的意愿，去发现一个个更深的技术领域。

探寻本源 How Why What

这里我先原样Copy一段@真阿当老师的微博，这段微博我真的是非常非常认可

一位同学找我聊进阶的困惑:

“面了下网易，阿里相关的职位，感觉还是有些差距的。我感觉可能是有一个瓶颈期了。

感觉在技术高度，视野的高度不够。很多东西都是我从未思考，或者接触过的。又或者说是存在于我日常中，但我无法感知到。这些层面的东西，在面试的时候是比较懵的。

具体原因很难说，感觉是一种不知道自己不知道的状态。”

这位同学的状态很典型。

曾经我写过一篇文章，讲”元知识”。什么意思呢?知识可以分为”道”与”术”，对应于”why”、“how”和”what”，在技术圈how和what一直在变，还存在很多派别，why基本不变，how变化较慢，what变化最快，也数量最多。

很多人是从what切入的，并且停留在what这里，过了适应期就开始自满了。有些人会去分析how和why。然后有了自己的判断，有了深度。然后有些人会去继续寻找更多的别的领域的why和how，而不是纠结在过多的what里。然后很奇妙的，why和why之间会形成互补和联接，how和how之间殊途同归，学what如有神助般迅速。

举个例子，解耦，封装，多人合作，分层是why，mvc的路由、ORM、模板引擎和OO是how，ROR、django和angular是what。

挖how和why是重点。怎么挖呢?我个人的经验是多读好书，多看资讯，多做练习，多总结，去悟。”悟”这件事，鲜有人在做总结，需要创造性的能力和一堆历练，所以无法像what那样，有满世界的知识搬运工。

我当时看到这个微博的时候就非常的认可，觉得和我想表达的 探寻本源 ，有着同样的论点。尤其是最近经常有很多开玩笑的说法，“别再更新Vue了，感觉学不过来了”，“RN、Weex、又出来个Flutter，感觉学不过来了”，“美团又出了个EasyReact，RAC还没学完”。归根结底，感觉学不过来的都是在关注what，其实真正需要理解与领悟的应该是how 与 why