几句话就能看出一个程序员靠不靠谱
不用看他会写多高级的代码，听他遇到问题时怎么说就行了。真正的差距不在技术本身，在于出事后嘴里最先蹦出来的是什么话。
一、能跑就行，别动了
有个服务，接口有时候要等3秒才能返回。查了半天发现是一个同事写的代码：先从数据库查出所有订单，然后在 Java 代码里做过滤和分页。
你跟他说应该用 SQL 的 WHERE 和 LIMIT 来做，不应该把所有数据查出来再在内存里处理。他的回答是：能跑就行，别乱改，万一改出问题呢。
一万条数据的时候确实能跑。到了十万条，接口超时了，连接池满了，其他接口也跟着一起挂。
这种人分不清“能跑”和“没问题”的区别。测试环境一百条数据跑得很快，就觉得没问题了。生产环境数据量多了几十倍，原来的写法就是定时炸弹。他不是不会优化，是根本没想到需要优化。
二、异常处理见分晓
让一个人写一段调用第三方接口的代码，看他怎么处理异常，水平一下就知道了。
水平最低的写法：整个方法套一个大 try-catch，catch 里只写一句 e.printStackTrace()，然后 return null。调用方拿到 null，不知道是接口没数据，还是网络超时，还是对方返回了错误码。线上查问题的时候日志里一堆堆栈，但看不出是哪个用户、哪笔订单、调的哪个接口出的问题。
水平高一点的会区分异常类型：网络超时了就重试一次，对方返回业务错误码就记日志然后走降级逻辑，未知异常就往上抛让调用方决定怎么处理。日志里带上请求参数和响应内容，出了问题一条日志就能定位。
代码量差不了多少，但第一种人线上出故障要查半天，第二种人三分钟就能找到问题。
你不用问他会不会写代码，看他怎么对待“出错了怎么办”这五个字就行。觉得这事不重要的人，写出来的系统就是一个又一个 return null，每一个都是给后面的人埋的坑。
三、用微服务的方式写单体
技术选型的时候说得很厉害：注册中心用 Nacos，网关用 Gateway，配置中心、链路追踪全都上。
你打开代码一看：所有服务共用一个数据库，服务之间互相调用没有熔断，A 服务挂了 B 服务跟着超时，C 服务也跟着排队，一个接口慢就把整条链路拖垮了。部署倒是分开部署了，但每次上线要同时发布四个服务才能保证兼容，发布顺序还不能错。
这叫什么？分布式单体。单体的缺点全都有——改一个功能要动好几个服务，联调成本翻倍。分布式的坑也一个没少——网络延迟、数据一致性问题、运维复杂全都加上了。
但你要问他架构是什么，他能给你画出一张漂亮的微服务图。图是很好看，但跟代码没关系。
能把一个团队四五个人、日活几千的项目硬套上微服务全家桶的人，技术判断力基本可以打个问号。不是说微服务不好，是杀鸡用了牛刀，还没拿稳刀柄。
四、描述问题的方式
同一个线上问题，两种人的描述方式完全不一样。
第一种：“这个接口挂了，不知道为什么，昨天还好好的。”
第二种：“下午两点开始订单查询接口 P99 从 200ms 涨到了 2s，看了监控发现数据库连接池等待队列在涨，慢查询日志里多了一条全表扫描，可能是今天上午上线的新查询没走索引。”
第一种人给你的是一个结果，第二种人给你的是排查思路。
这不是经验多少的问题，是思维方式的问题。碰到问题第一反应是“坏了”还是“哪里坏了、什么时候开始坏的、最近改了什么”，这个反应装不出来。
五、评估时间的方式
产品提了一个需求，一种人马上说“两天”，另一种人说“我先看看”。
第一种人只算了写代码的时间。第二种人脑子里在过：要不要改表结构？改了表结构老数据要不要处理？跟现有接口有没有冲突？要不要和前端联调？上线方案怎么弄？
最后可能也是两天，但这个两天是算过的，不是随便说的。
工期说得太快不是能力强，是想得太少。真正快的人不是评估时间短，是写代码的时候不用返工。
六、遇到不会的东西
面试里最能看出一个人的瞬间：碰到答不上的问题。
一种人开始硬编，东拉西扯说一堆沾边的话，想用信息量来掩盖自己不会。你追问一句细节，他换个方向继续编。
另一种人直接说“这块我没深入研究过，但我猜可能是……因为……”。猜得对不对另说，关键是他知道自己不知道，而且能在有限信息下做推理。
前者让面试官很累，后者让面试官想接着聊下去。
工作中也一样。不会不丢人，不会还装会才丢人。因为装的时候不会有人拆穿你，但代码上线之后会。
总结
你发现没有，上面说的这些其实跟“会多少技术”关系不大。
会用 Redis 不代表知道什么时候该用。能写出微服务不代表理解为什么要拆。背得出设计模式不代表能判断哪个场景用哪个。
真正暴露一个人的，不是他知道什么，是他碰到不确定的事情时怎么反应。是习惯性地糊弄过去，还是老实说一句“我查一下”。
前者十年经验也是一年的水平重复了十遍，后者三年就能让人放心把事情交给他。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！
