如何打造令后端面试官印象深刻的简历？

背景

最近，在公司负责后端相关面试，简历看了不下 50 份，面试 10+，纯手码 2000 多字，说说我对简历的看法，希望给大家一点启发。

教育经历

在众多求职面试中，我发现多数求职者容易忽视教育背景的重要性。有些求职者甚至选择淡化或完全不提及其教育经历，对该方面的不够重视，例如：

求职者只有全日制大专学历，之后再考了成人本科，然后教育经历栏全不写，在个人简介栏写直接写本科；
求职者只有一段全日制的教育经历，简历上写了多段教育经历，如 xxx 大学 xx 学院 xxx 专业，面试时问时，全都是校外培训经历。
简历上教育经历除了学校外，其他都不写，专业、时间、学历层次全没有；
明明是某大学的一个独立学院，简历上直接写某大学（985\211）；

我先说说我的经历，我是全日制硕士科班（计算机科学与技术）出生，第一学历很差，有幸校招时被 “字节跳动”某个岗位选中。我在学历上只写了硕士的经历，没有写第一学历，字节 HR 就立马打电话给我了。

HR ：“xx 同学，我看了你的简历，发现你没有第一学历，是什么学校呢？为什么不写呀？”；
Me ：“您好，我的第一学历是 xxx ”；

HR ：“那你为什么不写呢？学历又不是一个污点。我们这边是看你技术还比较吻合，且比较优秀，才联系你。向你这种不写，其实在我们内部直接过滤掉的，别以为这种小聪明能过 HR 的法眼，我们个个都比你精明，建议下次把教育经历写在第一栏”；

当然原话远不止这些，大家也看到了，这个 HR 对我非常好，能和我说这么多。至此以后，我再也没有把教育经历写在第二栏的经历了。可惜的是，虽然 HR 对我很好，我还是在第三轮技术面试的时候流程终止了。

注意：国家明确没有第一学历的官方统称，只说大部分企业，定为第一学历定为高中毕业后第一份全日制的大学学历。

所以元芳你怎么看？其实 HR 比求职者更猴精，简历有什么问题，他们一眼便知。做小聪明，实际意义不大，学历又不是污点，只能证明你之前的成长而已。

工作经历

这个环节见的最多是，直接将公司的某个项目扒下来，照着公司的项目简介一顿乱写，洋洋洒洒几百字。看十几分钟硬是不知道写了啥？更加不知道求职者在公司干了什么。

因为涉及隐私问题，我不会将其他人简历内部扒下来，我可以给大家一点我的参考建议：

职务 + 项目（简介、类型）+ 技术栈 + 工作内容 + 业绩

xxx 有限公司  PHP 后端开发工程师  2023年12月-至今
负责 xxx 项目、xxx 项目 0-1 研发，在此中项目中担任后端组长。xxx 项目是属于 ToB 类型项目，主要解决线下门店传统收银环节过程诸多的不便，功能包括：商品入库、商品折扣、商品实时收银等功能。主要技术栈为：Hyperf、MySQL、Redis、RabbitMQ。工作内容包括支付核心模块开发，团队代码 Review，技术方案过审，后端知识库沉淀、...。xxx 项目研发成功后实现了日均收银 xxx 金额，可用性达到了 99.99999%，平均故障间隔时间 xxxx。

注意：这个环节只需简单介绍即可，详细的可留到项目经历中。

项目经历

这个环节讲工作经历上的项目详细描述即可，比如：用哪些技术栈解决哪些业务问题，但一定要注意，用最合适的技术，写在合适的场景上。看到过简历上，硬凑上来写八股的，如：用 Redis hash 做队列，用 Redis key 做模糊搜索。

这个环节易出现的问题：

写的像流水账，像写周报类似，没有体现自我的核心价值；
技术栈用的特别多，同类型的冗余，如：Kafka、RabbitMQ 一起用；Laravel、Hyperf 一起用甚至还用了 Go；
只写业务，一个技术栈也没有写，看不出来在干什么；
错别字特很多，多处不规范的，我可能会认为他的代码也不规范；

经历环节建议用成熟的 STAR 原则：

STAR 法则是一种非常有效的简历撰写和面试准备技巧，主要用于描述工作经历和个人成就。STAR是四个英文单词的首字母缩写，分别代表：

S - Situation（情境）：描述你面临的情况或挑战。这为你的故事提供了背景信息，让读者或面试官了解事件发生的上下文；
T - Task（任务）：说明在上述情境下，你需要完成的具体任务是什么。这里要清晰地表达出你的责任和目标；
A - Action（行动）：详细描述你为了完成任务所采取的具体行动。使用动词开头的句子来强调你所做的工作，并尽可能具体化这些行动；
R - Result（结果）：展示这些行动带来了什么样的结果。结果应该是具体的、量化的最佳，比如提高了多少百分比的销售额、节省了多少成本、提升了多少效率等。同时，也可以提及从这个经历中学到了什么或如何帮助你个人或团队成长；

具体怎么使用可以看网上例子，实在不会就去问 DeepSeek，比比皆是。如果项目可公众访问，贴一个链接，也是一个不错的选择。

这里我也给一个例子：

在 xxx 平台订单管理系统升级项目中，面对 xxx 系统处理高并发请求时出现的性能瓶颈问题（Situation），我负责优化现有系统的性能并提升其稳定性（Task）。通过深入分析发现数据库查询效率低下是主要问题后，我采取了优化数据库结构、引入索引策略、实施微服务架构改造以及集成 Redis 缓存机制等措施（Action）。最终，成功将订单处理速度提升了 40%，显著增强了系统在高并发场景下的稳定性和响应速度，有效改善了用户体验，并间接促进了销售额的增长（Result）。