如何撰写 SOLID 开发者简历，成为 2018 年 STAR

该帖子来自我的博客，如果您有兴趣，可以在其中找到我的简历（或多或少）*.pdf。

自11月底以来，我一直在指导IT人士求职和撰写简历。我注意到，很多人都在写这份令人畏惧的简历时感到很吃力（是的，我也是）。所以，以下是我迄今为止提供的知识和最常用的技巧的汇总。

KISS——保持简短和简单

简历是你的营销材料，用来吸引招聘人员或招聘经理来面试你（而不是一篇详尽阐述你的经验/项目的文章）。你的简历会展现你申请职位最重要、最相关的技能。我不是建议你只写一页纸（这种说法早已过时），但两页纸就足够让对方了解你是谁以及你的知识储备了。

使其变得 SOLID（就像 Bob 叔叔的 SOLID 一样）

单一职责原则

一份简历对应一个职位/一个招聘信息。你的简历在申请 IT 架构师和高级软件工程师职位时会有所不同。在 ABC 公司和 XYZ 公司，你的简历也会有所不同。

打开/关闭

通过打开它进行扩展来关闭它进行修改：你想通过在求职信中添加额外的信息来扩展你的简历（是的，我知道它不是 100% 像打开/关闭那样，但我想你可以理解 ;)）

里氏替换

“程序中的对象应该可以被替换为其子类型的实例，而不会改变程序的正确性。”
意思是：如果你在初级阶段能够完成某件事，那么随着经验的积累，你仍然能够完成它。DRY
原则在这里派上用场了。所以请不要重复自己。

不过，这里有一个例外。如果你在每份工作中所做的工作都是你所申请职位的基本需求，那么最好在你的整个职业生涯中都展示出来。例如：申请 JavaScript 开发职位，请描述所有 JavaScript 开发角色/任务。请进行调整，使它们看起来不一样，例如：

ABC 公司软件开发人员

• 开发、维护、调试和修复分布式 Java 和 JEE 应用程序中的错误

XYZ 公司软件开发人员

• 参与基于 Java、Struts、JavaScript、Hibernate 和 DB2 的全栈软件开发

接口隔离原则

多份针对特定职位的简历比一份通用简历更好。（无需补充）

依赖倒置原则

“高级模块不应该依赖于低级模块。两者都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。”

你的抽象概念就是你申请的职位，所以你写的所有内容都应该基于该职位/招聘启事。只保留职位描述中要求你提供的详细信息。同样，KISS 原则在这里也很有效 :)

从主简历开始

主简历就像一个数据库，记录了你迄今为止所做的一切。它能为你未来的简历提供很好的参考，列出所有或最重要的技能和成就。

成就而非任务

很少有成就比仅仅列出你的职责更好。例如：
任务：编写 JUnit 测试；
成就：通过编写 JUnit 测试确保应用程序的预期行为，并确保 85% 的代码覆盖率。

您可以找到很多关于如何将任务转化为成就的通用文章，例如The Muse 上的这篇。

如果您仍然不确定如何处理，这里有一些建议：

成为简历中的明星

想象一下你执行该任务时的情景。你采取了 什么行动？结果如何？

然后以 POR 格式书写：
过去时态 动作动词陈述句的
宾语动作的
结果

并尝试在其中添加一些关键词。

例如： 指导由 4 名开发人员组成的团队使用看板设计、配置和测试 在RedHat Linux上运行的RESTful会员卡管理系统

我欢迎所有问题，所以不要犹豫，尽管问吧 :)