把多年工程工作压缩到一页的方法，不是把每个项目都压缩成读不懂的碎片，而是挑出三到四个最能支撑你所申请职位的项目，把其余项目合并成末尾的一行，并把每个保留下来的项目写成紧凑的一行，而不是一整段。一页试图容纳十二个同等分量的项目，最终没有一个能写好；一页只保留四个满分量的项目，其余顺带提及，读起来反而是一份更有力的简历，哪怕从字面上说得更少。
决定哪些项目值得占一席之地
先按照与目标职位的匹配程度给项目排序，而不是按你对每个项目的自豪程度排序。使用目标职位所用技术栈的项目、解决过类似问题的项目，或者体现你独立负责整个系统而非其中一小部分的项目，都应该排在一个技术上令人印象深刻、但离该职位实际需求较远的项目之前。新旧程度也有影响，只是比匹配度次要：一个较旧但与目标职位高度契合的项目，通常胜过一个较新但不相关的项目。当简历中已经有工作经历部分时，三到四个项目通常足够占满一页；如果一份简历以项目为主、带薪经验尚少，可以扩展到五六个，直到页面开始显得拥挤为止。
一个常见的错误是按投入的精力而不是相关性来排序：一个占用了六个月周末时间的项目，可能仅仅因为投入的时间而让人觉得应该排在首位，即便一个只花两周的小项目其实更直接对应目标职位日常的工作内容。精力对只看到页面上最终一行文字的读者来说是不可见的，所以在最终确定入选的四个项目之前，值得刻意把投入的精力放在一边，只按契合度重新排序。
把较小的项目合并成一行
没能进入前几名的项目不必彻底消失。在项目部分末尾加一行，例如"另外还做过：一个Slack通知机器人、一个用于日志搜索的小型命令行工具，以及两个内部工具脚本"，可以让它们保持可见，而不占用与重点项目同等的空间。这一行确实有作用：它表明重点项目是经过刻意挑选的，而不是你做过的全部工作，也给想了解更多的读者提供了一个在交流中可以追问的切入点，而不必让每个项目都经历同样完整的写法。
写出一行式的项目条目
一行式的项目条目仍然需要回答它是什么、用什么技术构建、以及带来了什么结果，只是把这些压缩到一行而不是三行里。"指标仪表盘：用React和一个小型Node接口从内部事件流中取数，替代了团队原本用来手动追踪同一批数字的三份独立表格"，恰好能装进一行，同时仍然告诉读者具体的信息。相比之下，把一个项目压缩成一个没有任何背景说明的光秃标题，虽然省了空间，却丢掉了当初让这行值得写进去的全部信息。目标是信息密度，而不是为简短而简短：字数更少、说得更少的一行，并不会自动变成更好的一行。
示例说明：一份经过精简的项目清单
示例说明。某位候选人在多年间积累了九个副业和工作相关的项目。精简之前，每个项目各占两行，仅项目部分就几乎占满一整页。精简之后：保留四个项目并写出完整细节，之所以选择它们，是因为它们与目标职位的技术栈和范围最贴近，每个都写成一行，说明它是什么、用了什么、带来了什么变化。剩下的五个被合并进结尾的一行，简短点出每一个的名字。项目部分现在大约只占之前三分之一的空间，而四个重点条目因为不再与另外五个争夺同样的注意力，反而更容易被认真读完。
精简的同时保持页面易读
试图通过把字号或页边距缩小到超出舒适阅读范围来在一页中塞进更多内容，只是把一个问题换成了更糟的问题：一页在技术上能容纳所有内容却读起来很吃力，比一页老老实实需要略长篇幅的简历损失更大。精简应该来自对纳入内容的取舍，而不是让文字本身变得更难读。如果四个完整的项目条目加一行合并说明，在正常阅读字号下仍然放不下，这通常说明应该再删掉第五个项目，而不是继续缩小字号，也可能说明这份简历确实有理由用两页来呈现。
当项目与工作经验争夺同一页空间时
对于一位拥有多年带薪经验、同时又有一长串副业项目的工程师来说，这两个部分正在争夺同样有限的空间，而经验通常应该在这场竞争中优先胜出。评估一位处于职业中期的工程师时，读者通常更看重有报酬、需要承担责任的工作，而不是副业项目，因此把项目部分精简到几个重点条目，而不是削减工作经验条目来腾出空间给更多项目，通常是一页式简历需要额外空间时更安全的选择。
开始制作你的简历
选择一个为工程类工作设计的模板，比如Developer模板，用同样的筛选标准过一遍你自己的项目清单：哪几个项目最直接支撑这个职位，哪些可以合并成结尾的一行来处理。关于在项目问题出现之前简历本身应该多长这个更一般的问题，简历应该写多长介绍了更广泛的取舍，而如何在软件工程师简历上展示个人项目在你确定哪些项目入选之后，会更深入地讲解如何写好单个项目条目。到简历生成工具开始精简和重建吧。