软件工程师简历范例

招聘人员真正最先扫读的内容

招聘人员在决定是否继续阅读之前，只会花几秒钟浏览软件工程师简历的最上面三分之一：你最近的职位名称、技能行中的语言和框架，以及最近一份工作下的第一条要点。下面的内容要么印证了页面上方已经给出的印象，要么彻底失去读者的注意力。

这意味着页眉和第一条工作经历比页面的任何其他部分都更重要。把最有力、最具体的一行放在每个职位下的第一位，而不是藏在第三或第四条要点里，并把技能行放在靠近顶部的位置，让快速扫读的目光在转向堆叠中下一份简历之前先看到它。

初级范例：用项目代替经验

一位只有一次实习和几个个人项目的初级工程师，仍然可以通过把每个项目当作一份工作经历来写出完整、具体的简历。在名为“Order Tracker”的项目下，一位初级候选人可以这样写：

这是对该模式的一个具体、引用式的示例说明，而不是关于典型结果的断言。

实习经历也遵循同样的规则：说明发生了什么变化，而不只是被分配了什么任务。像

这样的一句话，比“协助工程团队修复错误”能告诉读者更多信息。将这一部分控制在两到三个项目，每个项目一到两条要点，而不是列出你曾经推送过的每一个代码仓库。

中级范例：说明前后变化的影响力要点句

拥有三到六年经验的中级工程师，应该在真正存在前后数字的地方，用前后对比的数字取代基于任务的要点句。对于后端职位，可以这样写：

起说服作用的是这个数字；周围的句子只是提供背景。

另一个不同类型贡献的例子：

并非每条要点都需要百分比——像“与另外两个团队协作”这样的范围陈述依然具体，因为它说明了谁参与其中、花了多长时间，而不是仅仅把这项工作称为“跨团队协作”。

什么时候应该保留独立的项目部分

当你有能展示工作经历无法体现的内容的业余作品时，一个专门的项目部分是值得的：一门你在工作之外使用的语言、一次开源贡献，或者你自己构建并持续维护的个人工具。对初级候选人来说，这部分往往比经验部分本身发挥更大的作用；对高级候选人来说，除非项目与应聘职位异常相关，否则这部分通常是可选的。

把每条项目记录控制在一行背景说明和一到两条要点，密度与一条工作经历相当，如果有代码仓库或在线演示就附上链接。一个列出十个条目却没有任何细节的项目部分读起来像是凑数；三个条目、每个都配一条具体要点，读起来则像证据。

技能与工具：要具体，不要面面俱到

列出你在面试中真正能自如被问及的语言、框架和工具，并按对该职位有意义的方式分组——语言、框架、基础设施等等。省略掉一个你只用过一周的技术是可以的；这份清单应该反映你能谈论的内容，而不是所有曾经出现在简历上的东西。

在确实属实的情况下，让措辞与招聘信息保持一致：如果招聘信息写的是“PostgreSQL”而你确实用过，就写“PostgreSQL”，而不是笼统地写“SQL 数据库”，因为自动化的申请追踪系统和真人读者往往都在寻找这个精确的词。不要因为招聘信息提到了某项技术就把它加进去而自己并未使用过——这个差距会在第一次技术面谈中暴露出来。

常见问题

初级软件工程师简历应该先列项目还是先列经验？

如果带薪工作经验有限，就先列项目，因为那里才有你最有力、最具体的证据；一旦你有真正的实习或工作经历可以展示，就把经验部分移到项目之上，并把更有力的部分保持在页面更靠上的位置。

每个项目或职位应该有多少条要点？

每条记录两到四条要点通常足以展示你构建了什么以及由此带来了什么变化。超过这个数量会开始稀释页面内容，读者对每条记录下前一两行的记忆，远比第四或第五行清晰得多。

每份软件工程师工作都用同一份简历可以吗？

结构可以保持不变，但技能行以及要点句的顺序应该根据每份招聘信息中列出的要求做出调整，因为真人读者和自动化筛选工具往往都在寻找那份招聘信息使用的具体词汇。

如果简历超过两页，中级工程师应该删掉什么？

删掉大约十年以上、且与应聘职位无直接关联的职位经历，精简任何只描述职责而非结果的要点句，只有当项目部分能展示出你的工作经历确实还没体现的内容时，才保留它。