关于简历的建议

先来个灵魂拷问：你与他人相比，有什么能形成明显区分度的优势条件？

这里有两个层面的问题。一是如何识别出你的优势条件——毕竟大多数人大多数时候都在做业务，临到写简历时要总结日常工作中跟别人不一样的点，确实挺难；二是你可能已经挖掘到自己的优势，但在简历里怎么组织内容、怎么表达才能突出，让面试官迅速 get 到点？

这事并不容易。我见过的不少简历，特别是五年以下的同学，很多都写得不达预期：有一些是真的平平无奇，有一些是明明有不错的经历，但就是没表达出来，几分钟内很难看到亮点。最近刚好有不少人找我内推，我都会尽力帮着看看有没有明显问题，沟通过程中慢慢总结出一些共性，于是有了这篇文章，希望能帮到正在或即将找工作的同学。

本文不会讲太多基础问题，例如格式、字号、字体——这些网上已经有很多文章，没必要重复。本文更聚焦于内容，聚焦于如何在有限篇幅内突出个人优势：如何在日常工作中挖掘亮点，如何组织语言让面试官迅速理解，以及需要避开哪些可能造成负面效果的坑。

1. 如何挖掘亮点

重点是持之以恒地记录，积累足够的素材，并在此基础上学会识别：对于求职来说什么是加分项，什么不是。

1.1 坚持记录

写作需要素材，写简历当然也需要素材，而简历的素材就来自日积月累的工作。可以养成习惯，有意识地把一些经历以文本形式记录下来。

记录的方式有很多，比如技术博客、项目日志、年度总结甚至周报，这种书面留存能随时 review，所谓好记性不如烂笔头，这些信息最终可能就变成你简历的重要素材。

当然，也没必要事无巨细记流水账，可以把有限的精力放在一些重要节点上：

• 项目启动时，技术选型的过程、思考、论据、结论；
• 项目结束时，执行过程的复盘、反思、重点难点、数据指标；
• 使用开源框架遇到问题时，调试过程、逻辑推导、解决方案；
• 学习新技术时的心得与实践；
• 解决性能问题时，优化前后有多大提升、具体有哪些措施、用了哪些工具、如何实施。

这些节点都是个人成长的良好契机，把它们记下来——记录你在过程中遇到了哪些问题、分别怎么解决的，写简历时翻一翻总比凭感觉回想靠谱得多。

1.2 识别亮点

积累足够多的素材之后，就可以根据面试的公司、业务、目标岗位，从素材中选取更可能被面试官相中的「亮点」来组织简历了。

亮点应该是那些能让你显得与众不同的经历，比如：

• 做过一些有深度的性能优化，且有比较大的性能收益，能量化提升空间的；
• 做过一些业务逻辑特别复杂、业务影响力特别大的项目；
• 推进过一些制度、工具，深刻影响团队乃至整个公司的工作流程、工作方式，且整体有提效作用；
• 用一些不太常见的技术，解决过对前端来说比较偏门的问题，例如视频直播；
• 做过有一定名气、能真正解决技术问题的开源项目（demo、awesome-xxx 类的不在此列）；
• 深入学习一些工具的用法，以此解决了工程化、开发效率、性能方面的问题；
• 给知名开源项目提交过真正复杂、有意义的 MR（typo 类修复不在此列）；
• 钻研过一些框架的原理，并能持续输出足够多有技术深度的文章，或者明确解决过项目中出现的复杂问题。

这个列表还可以继续罗列下去。不同人、甚至同一人随着经验和认知的增长，在不同时期都会有不同的判断标准，所以这里没有标准答案，尽力就好。

1.3 什么不是亮点

梳理过程中要注意避开那些不能加分的信息，理智地反思一遍：这段经历是否足够复杂？是否足够表现出你的最高水平？对于这里面用到的技术，你真的掌握得很好，能应对面试吗？

这里列举几种反模式：

• 单点技术突破不算亮点，例如解决了某个 UI 框架的单个样式 bug，体量太小；
• 做了很多项目不能称为亮点，只能证明你可能已经工作了很久；
• 技术框架、工具一直停留在「用」的阶段，对内部实现原理完全不清楚；
• 仅仅解决一些很寻常、很普遍、网上有大量现成方案的问题，不能算亮点。

2. 如何表达亮点

积累足够多素材之后，接下来需要探究如何通过简历高效传达给预期读者。面试官通常都很忙，特别是很多大厂面试官可能每天要浏览几百上千份简历，如何组织内容才能高效传达信息？如何在短时间内抓住注意力？更进一步，如何引导后续面试的内容？

首先是基本格式，这方面比较简单，上网找个你觉得最简洁清爽的模板就行，我个人比较喜欢 mcc108/resume。基本格式之外更重要的是内容，如何在短短一两页内呈现你的能力、专业度、人设，下面展开聊聊。

2.1 树立技术人设

所谓人设，可以简化理解为我们做过什么，以及我们将要做什么。

做过什么，落到简历上通常需要从项目经历、掌握技能两个角度呈现。项目经历是简历的核心组成，大多数面试官都非常看重这一部分，千万不要盲目写，要有条理、有次序、有重点。我个人总结出几条规则：

• 有意识地挑选几段能突出某项、某系列技能的项目经历。例如你要突出 Vue，就应该尽量围绕这个主题展开，避免一会 Vue、一会 Lua 这种牛头不对马嘴的情况，让面试官立即 get 到你的技术专长就是 Vue；
• 组织好语言，项目经历在时间轴上从远到近，围绕设定的主题逐步细化、深化。例如最开始你只是用了这项技术，后续逐渐更好地应用生态、更理解实现原理并能解决复杂的性能与工程化问题，甚至进一步开发了有价值的开源工具，或输出高质量文档反哺社区。要让面试官通过项目经历感受到你从小白逐步成长的过程；
• 前面两点都是在表现深度。对于工作三年以上的同学，通常既要求有深度，又要求有一定的广度和视野，这并不容易做到。一个方法是围绕上面树立的深度向外扩展，补充与前端基础强相关的经历，比如 HTTP、TLS、HTTP2、TCP 等网络栈相关的性能优化、版本升级经历；或者内存泄漏的排查修复、FPS/FCP/FMP 之类指标过低的优化经验；又或者一些更复杂的开发场景，例如编辑器、编译器、可视化、复杂动画、多媒体等等。

总结下来，尽量做到一专多能，既有深度又有广度。深度能帮助面试官迅速判断你的技术栈、降低心智负担，看起来不累；广度能帮助面试官识别你的学习能力、潜力、对复杂开发场景的承受度。在基本技术人设之外，最好还能顺带传达出你对所在行业的认知深度。

近期准备做什么。很多面试官喜欢问：你未来 3-5 年的职业规划是怎样的？很多人会觉得「职业规划」这玩意儿挺虚，不愿意花时间认真梳理。我的观点是，职业规划首先是给自己看的——你给自己设定了一条路径，日常工作中需要不断做选择，心里这条路径越明确，做决定的成本越低，也会看到自己不断接近目标。

对面试官来说，这个问题大部分情况下首先考察你对自己的职业生涯有没有足够清晰的认知和目标感——三天打鱼两天晒网就跟频繁跳槽一样，没办法让你在垂直领域积累足够的深度；其次考察你规划的天花板，如果没有表现出技术、职业野心，容易让人 judge 你的发展潜力；最后考察你的规划与团队的 match 程度，这就见仁见智了。

所以对人对己都很有必要先花点时间，想清楚自己未来 3-5 年要做什么、做到什么程度，树立一个明确的职业目标。这个话题有点脱离本文主题，因为你很难在简历中直接表达职业规划，不过可以换个角度，以附加材料的形式呈现，比如个人博客、GitHub。

博客可以围绕你设定的职业规划，连续一段时间围绕这个主题写多篇，让面试官感受到你既有想法，又确实在这个方向上努力。GitHub 也一样，连续一段时间在这个主题上输出一些代码质量较优的仓库——面试官进来第一眼通常看 star，其次看代码风格，如果攒不到 100 star 以上，就尽量把代码写好看一点，这也是加分项。

2.2 量化

数字是个大杀器。正确使用各种量化指标能让简历更有重心、更有可信度、更容易获得认可。很多东西可以量化，比如：

• 性能提升：性能优化通常是一种很综合、很复杂的场景，需要足够的知识深度，需要灵活运用各种调试工具，所以面试官看到这种经历通常会多加关注，如果能给出优化前后的指标变化就更好了；
• 业务提效：这方面通常是引入或创造了某类工具，改变或优化原有工作流程达到局部或全局更优解，从而提升整体效率。这类优化与业务紧密结合，换个业务方向的面试官可能很难 get 到点，如果能提供具体数值会有助于读者判断，可以是流程提效 xx%、工单完成率提升到 xx、响应及时度提升 xx 之类；
• 业务推进：假如有幸参与到一个发展比较猛的项目，而且你是比较核心的成员，那么可以总结一下从项目开始到你准备离开时，业务指标有多大增长；
• 影响力：影响力这个概念比较主观、难以量化，但可以用别的指标从旁佐证，比如工作期间做了 xx 次部门内分享、xx 次公司范围分享、xx 次行业大型分享；或者输出了 xx 篇博客之类。

注意，前提是真实，不要为了量化而刻意捏造或拍一些不存在的数字——拍出来的数字通常很容易识穿，面试时容易露馅，没必要。建议在日常工作中养成数据思维，包括业务上的和技术上的，特别是做优化时记录优化前后的数值，写简历时自然有素材。

2.3 业务深度

先分享一下我的个人经历。我曾在一家特别小而美的人工智能创业公司工作了三年，虽然职能是前端，但过程中并没有把自己的工作边界圈得泾渭分明，经常很发散地去支援服务端、数据甚至运营团队的工作，比如：

• 用 Python + Celery 开发定时结算系统，降低对账成本、压缩结算周期；
• 用 Node + FFmpeg + Docker 做了一套视频流式处理工具，能根据配置对一批视频做抽帧、截取片段、压缩、转格式等操作；
• 某个 POC 性质的项目中，用 Python + Caffe 调用深度学习模型实现图像识别服务，配合浏览器上调用 media 接口，将摄像头画面传回服务器识别出画面中的物品。

短期看确实没有明显收益，但在我离职写简历时发现，这些经历串联起来，让我对深度学习的工作过程、原理、局限性、工具、指标等概念的理解已经足够支撑我在面试中应对各种问题，后面找工作聊到这一部分都特别顺利。

这里不是鼓励大家去做很多前端领域之外的事，只是想表达：对业务、合作团队的了解与洞察程度，可以映射出你对工作的投入度，而市场通常比较青睐投入度高的人。所以在日常工作中可以有意识地用各种方法跨出职能边界，去了解其他团队在做什么、怎么做的、平常用哪些工具技术、有没有存在什么问题、这些问题有没有办法用前端技术解决。

当你对行业形成足够立体的认知之后，写简历、面试时就可能展现出这个领域的横向认知。反过来说，如果你过去对工作的认知一直停留在前端领域内，隔壁在做什么、怎么做、用什么做，业务线接下来有什么计划、可能需要什么新技术，这些都回答不上来，面试官容易怀疑你对工作的投入度。

2.4 项目经历怎么写

不要只写你做了什么，更重要的是突出你用什么方法、解决了什么问题、收益是什么，形成一条完整的逻辑闭环，面试官才有足够信息判断你项目经历的价值。

比如说，对于「在 XXX 项目中引入性能及异常上报工具，后续团队基于回收的数据有针对性地做了一些优化」这样一段经历，我曾收到一份简历是这么写的：

集成监控 SDK，包含页面测速、错误异常、API 质量、白屏异常、URL 异常，收集项目中的各类错误信息并上报，通过 performance API 进行测速分析，封装基础库 ajax 上报 API 错误信息；在资源监控系统通过对各个端上报的指标进行清洗、聚合以及数据分析，错误模块聚合 sourcemap 还原源代码，便于修复线上问题；重构项目代码与调用链，加载时间缩短 20%。

这里面有一些明显问题：

• 监控 SDK 是啥？集成方式怎么样？这里面有多少工作量？有哪些难点？
• 形式与描述不好，阅读成本高；
• 清洗、聚合、数据分析分别是啥？前端在这里面做了什么？
• 「错误模块聚合 sourcemap」——只有错误模块吗？聚合又是什么？聚合还原完为什么就能「便于修复」线上问题？sourcemap 的原理又是什么？
• 「重构项目代码」与前面的「集成监控 SDK」是什么关系？为什么要写在一起？
• 加载时间具体指哪个指标？具体做了什么缩短的？

总结下来，问题主要是描述不清晰，很难理解这到底是件什么事、怎么做的、收益怎么样。比较好的方式应该是：

• 引入（基于）xxx 搭建性能与异常监控体系，覆盖 FCP/FP/FMP/TTI/LCP 等性能指标，覆盖白屏、页面崩溃、JS 异常、HTTP 异常等错误场景；
• 在上述监控体系基础上，逐步推演出核心性能指标模型，以此为决策依据执行图像合并、代码分包、缓存策略优化、首屏渲染优化、SSR 等措施，前端性能平均指标提升 xx%，QPS 提升 xx%；
• 在上述监控体系基础上，优化项目 CI 工序，接入基于 webpack 的 sourcemap 映射能力，线上问题能直接映射回源码堆栈，线上问题平均修复时间降低 xx%。

这不是最好的表述，但已经充分说明了用什么方式方法、具体解决了什么问题、最终收益是什么，相比前面的写法，叙述上更严谨也更容易理解。

3. 如何做减法

简历内容在「历」，但预设条件是「简」——不要写成流水账，不要事无巨细写成自传。简历内容绝非多多益善，写得越多阅读成本越高、越难抓到重点，所以应当适度精简。

3.1 注意项目取舍

如果你已经有比较丰富的项目经历，千万不要不做选择全部往简历里怼。不是项目经历越多越好，应该结合个人情况，精心挑选几段有代表性的，例如：

• 能表现出技术深度，或者业务复杂度、业务体量的；
• 能表现学习能力的，例如曾经为了使用一个文档缺失的框架，花了一段时间看完源码总结出用法；
• 能构建起「成长路径」的，这一部分在「树立技术人设」一节已讲得比较细。

尽量避开这些类型的项目：

• 单纯练手，复杂度、业务价值都特别低的；
• 太过简单的，例如简单的活动页；
• 仿 xxx 型的——培训班很喜欢搞这种练习题，不少候选人就拿它当实际项目写到简历上。

3.2 慎用技术名词

前端简历中常常有一部分总结自己的技术栈，这里一定要慎重。我经常遇到技术栈特别广泛、但凡用过的技术都往上写的简历，一个是看起来、分析起来累，一个是面试过程一问三不知。我建议使用任何技术名词前先问问自己：

• 这项技术会给你的简历加分吗？
• 你的使用频率、了解程度足够高吗？足够应对可能出现的各种技术问题吗？
• 这项技术足以让你与其他候选人拉开距离吗？

比如「我曾经用 Grunt 搭建过一套完整的工程体系」，这样的经历不能说完全没价值，但放在 webpack、Vite、Snowpack、Parcel、Rollup 大行其道的当代，这份经历能加分吗？反而可能让面试官质疑你技术更新迭代的速度会不会太慢。

又比如「我曾经写过一个带视频的网页」，这样的经历还不足以支撑你在简历里写「具备视频编解码能力」；如果更进一步「我曾经基于 HLS + FFmpeg 实现动态视频流服务，配合 video.js 实现按需播放」（如我的另一篇博客 《HLS + ffmpeg 实现动态码流视频服务》 所说）这种程度，那大可以说你「理解常用视频封装、编码格式，能根据应用场景搭建流畅的视频播放体系」。

站在面试官的角度，单纯堆叠名词反而容易让人质疑你的知识深度和自我认知的准确性，适当的裁剪往往更能突出优势。

3.3 慎用形容词

我第一次写简历时，有一篇文章印象很深，细节忘了，但里面有个很重要的观点：不要写「精通」。我觉得特别对，因为大多数人对大多数技术的掌握程度并没有达到这个深度，如果你真的自认有精通的点，那有可能是事实，也有可能是不知者无畏。

举例来说，你觉得你精通 HTML 吗？那么：

• input 标签的 type 属性有哪些可选值？分别对应什么功能？浏览器兼容程度如何？
• 什么是标签的语义？为什么要有语义化？有谁会消费这些语义？怎么评估语义是否恰当？
• aria 属性是什么？怎么编写合理的 aria 结构？又是谁、以何种方式会消费这些属性？

又或者，你觉得你精通 Vue 吗？那么：

• Vue2 的双向数据绑定是什么？如何实现的？这个过程如何影响 props、computed 属性？
• 如果上面的问题你理解了，那么 Vue3 呢？
• Vue 如何将 template 转换为 render 函数？又如何识别出标签对应的组件？组件层级之间的创建顺序是怎样的？渲染顺序又是怎样的？

这个列表还可以无限列下去，所谓学海无涯，谦虚一点总没坏处。我个人的做法是绝不写「精通」，因为我自知对任何一个技术点都远远没到精通的程度；但会写一两个熟悉的技术项，并且书写顺序上尽量靠前；此外会再补充一些理解，对于把握不够的点则忽略不写。面可以广一点，例如网络协议、构建工具、开发框架都写一些，但总量尽量保持在 3-5 个。

这里可能会有同学，特别是实习生、应届生，担心技术栈不够广会不会反而拿不到面试机会。这其实也是一种学习策略的问题：如果你站在面试官的角度，面前有两份简历，一份内容看起来少但明显能感觉到足够深度，另一份堆砌了很多技术名词、但名词之间看起来没有明显关联，你会倾向哪一份？

4. 总结

简历不容易写，技术人员的简历更不容易，为了心仪的工作花多点时间沉淀一份优秀的简历是非常有必要的。

我工作了八年，目前在字节跳动做前端工作，前前后后已经看过几千份简历，很多简历上的问题还是能看出来的。如果你刚好或将要找工作，我很乐意帮你把把关；如果你想来字节跳动试试前端岗位，我也可以帮你内推，还可以帮你模拟面试、分享我对字节各个业务线、工作环境的看法。