01 确定校招层次目标

东南大学属于985院校,按照“校大”java 校招开发岗分层标准，主要以大厂为主。

02 简历打分

校招后端简历核心就两个评判维度：院校背景 + 主项目。

大厂投递场景下，东南大学作为理工类顶级 985，学历是明确加分项。

主项目为一段实习经历，虽然实习的业务含金量尚可，但简历文字描述问题非常突出。

大厂简历筛选很多时候由面试官直接审阅，扫一眼这段实习，很容易给面试官留下 “实习经历包装过重、真实性存疑” 的印象，直接拉低简历通过率，预估这份简历当前通过率仅 30% 左右。

这部分没有硬伤。研究生是 985 东南大学，本科南京邮电大学底子也很不错，学历这块不会在初筛阶段直接被刷掉，无需额外堆砌多余加分信息，保持现状即可。

第一个项目是实习项目，这里踩了非常典型的大坑。

很多同学分不清实习经历和在校项目的书写逻辑：实习本质是公司内的项目，在校项目是校园课题；二者条目结构大体一致，实习只需要额外补充公司/团队名称，同样必须补充项目业务背景—— 背景介绍是面试官快速看懂业务、确定后续追问方向的基础。

这份简历的实习条目，完全缺失业务背景。

实习里面的要点描述，更是校招高频雷区，极易被面试官判定为过度包装，甚至直接认定简历造假。

大厂面试官常年带实习生，很清楚企业内实习生真实的工作边界。

一旦面试官判断内容不是实习生正常可以接触、落地的业务，就等同于社招的工作经历造假，属于面试红线，面试基本直接终止。

今年秋招这个现象特别明显：从暑期实习到秋招，哪怕你是顶级 985，如果实习内容包装失真，直接会失去面试邀约机会。

举两个典型问题：

写通过分布式锁解决重复下单，做并发压测 100 并发。

面试官会持续深挖：100 并发压测的意义在哪？100 和 1000 并发的差异是什么？为什么在实习场景下只选择这个量级压测？这套方案在真实业务里面临哪些问题？这些追问很容易露馅。

使用策略模式重构微信、支付宝支付调用，写核心代码冗余度降低 40%。这句话是典型网课模板话术。

设计模式的核心目标不是减少代码，很多时候引入设计模式，代码量反而会增加。它的价值是提升项目可维护性、方便后续业务扩展，而不是单纯精简代码。

就像微服务分层，如果不分层，直接调用 mapper，不需要 service 层透传代码；

分层之后代码量变多，但换来的是复用和解耦。这种话术，大厂面试官一眼就能识别是套用课程模板。

第二个在校项目：海洋数据治理项目。

项目最大问题：亮点缺失，和后端开发岗位关联性弱。

条目只简单写链路处理、数据清洗治理、保障数据准确度，属于无效描述，写了等于没写。

面试官招后端开发，核心想看你的项目设计能力、线上问题排查、业务架构落地能力。

纯数据清洗类项目，对于后端开发岗几乎没有竞争力。

记住：简历项目不是越多越好，技能也不是堆越多越好，项目必须和投递岗位强相关，才能成为得分项，无关项目再多，也很难加分。

第三个项目：AI 相关项目。

可以保留，但篇幅严重超标。大厂后端岗面试，面试官偶尔会闲聊 AI 相关内容，但这不属于后端岗核心得分项。不用大段写多流程、召回、向量量化等一大堆细节，精简成 2-3 条要点足够。

只要让面试官知道你有相关了解就行；如果不是投递 Agent、大模型相关岗位，面试官一般不会深度深挖，写太多反而挤占核心后端项目的版面。

这块属于不加分、不减分，但存在优化空间，切忌单纯名词罗列。

简历里写了 Python、TB 级数据清理等内容，这类和后端主线无关的技能，不要单独堆砌名词。

需要重新规整描述，精简非核心技能，优先突出 Java 后端栈核心能力，弱化和投递岗位关联弱的内容，避免技能板块杂乱。