简历第一页没写完，工程我就知道这个人不会来面试。师简三年换了四家公司，工程每家待不到十个月，师简项目描述全是工程“参与”“协助”“负责部分模块”。这种简历我筛过太多，师简像超市小票，工程列了一堆条目，师简但看不出这个人到底解决了什么问题。工程

我招的师简是后端工程师，不是工程流水线上的装配工。简历上写“精通Java”的师简人，十个里有八个连JVM内存模型都说不清楚。工程真正让我停下鼠标的师简，往往是工程那些写得像事故报告的东西：某个服务在凌晨两点崩了，日志里全是超时，他翻了三天源码，发现是连接池配置和某中间件版本不兼容，改了两行，压测通过。这种细节骗不了人。

前阵子面了个小伙子，简历只有一页半。项目经历里有一段写得很具体：订单导出功能，原来每次导出五万条要四十秒，用户投诉。他查了慢查询日志，发现是分页查询在深翻页时扫了全表。改成游标分页后，降到三秒。他还补了一句，说后来发现导出格式是CSV，但用户其实要的是Excel，于是又加了个流式写入，内存没爆。我当场就约了面试。能把自己踩过的坑讲清楚的人，比列一堆“高并发”“分布式”关键词的靠谱得多。

有些简历喜欢堆技术栈。Kafka、Redis、Docker、K8s，写了一长串。我通常会问一句：Kafka你们用来做什么？如果回答“消息队列”，基本就聊不下去了。真正用过的人会说，我们用它做日志收集，但后来发现重复消费问题很头疼，于是自己写了幂等去重，或者干脆换成了Pulsar。技术选型背后的权衡，比技术名词本身重要一百倍。

还有一类简历，项目描述写得像产品说明书。“负责用户中心模块开发，实现注册登录功能。”没了。这等于什么都没说。我会想：注册并发多少？密码怎么存的？有没有防撞库？登录态怎么保持的？如果这些都没想过，那这个模块大概率是照着教程抄的。我见过一个简历写“优化登录接口”，追问下去，他说原来每次登录都要查三次数据库，后来把用户信息和权限缓存到Redis，QPS从两百提到两千。这种具体数字和前后对比，才是有效信息。

简历上的“自我评价”部分，我基本不看。“抗压能力强”“善于团队协作”“热爱技术”——这些话谁都会写。有那功夫，不如在项目里写一句“连续加班两周排查线上内存泄漏，最后发现是ThreadLocal没remove”。这比一百句形容词都有说服力。

我自己的简历也不好看。毕业那会儿写了两页，把课程设计都塞进去了。后来换工作，越写越短。现在如果让我写，大概只有半页：做过什么系统，遇到什么难题，怎么解决的，结果如何。剩下的，面试聊。简历不是自传，是钩子。钩住面试官的好奇心，让他想见你，就够了。

所以每次筛简历，我都在找那些“有伤疤”的人。伤疤意味着真刀真枪干过，意味着踩过坑、填过坑、知道疼。技术这行，纸上谈兵的人太多，能动手把问题摁死的人太少。简历上那几行字，藏不住这个。