不用聊技术细节，光听他描述问题的方式就够了。真正的差距不在会不会写代码，在于出了事之后嘴里蹦出来的第一句话。
能跑就行，别动了
组里有个服务，接口响应时间偶尔飙到 3 秒。查了一圈发现是某个同事写的一段逻辑：先从数据库查出全部订单，在 Java 里做过滤和分页。
你跟他说这个应该在 SQL 层用 WHERE 加 LIMIT 做，不应该全量查出来再内存过滤。他的回答是：能跑就行，别乱改，万一改出问题呢。
一万条数据的时候确实能跑。十万条的时候接口超时，连接池打满，其他接口跟着一起挂。
这类人有个共同特征：分不清"能跑"和"没问题"的区别。测试环境一百条数据跑得飞快，觉得万事大吉了。生产环境数据量翻一百倍，原来的写法就是定时炸弹。不是不会优化，是压根没意识到需要优化，因为他从来不想代码在真实负载下会发生什么。
异常处理见真章
让一个人写段调用第三方接口的代码，看他怎么处理异常，段位一目了然。
段位最低的写法：整个方法体套一个大 try-catch，catch 里写一句 e.printStackTrace()，然后 return null。调用方拿到 null，不知道是接口没数据还是网络超时还是对方返回了错误码。线上排查的时候日志里一堆堆栈，但没有任何业务上下文，不知道是哪个用户、哪笔订单、调的哪个接口炸的。
段位高一点的区分了异常类型：网络超时重试一次，对方返回业务错误码记日志并走降级逻辑，未知异常往上抛让调用方决定怎么处理。日志里带着请求参数和响应内容，出了事一条日志就能定位。
代码量差不了多少，但第一种人线上出故障要查半天，第二种人三分钟定位完毕。
你不用问他会不会写代码，看他怎么对待"出错了怎么办"这五个字就行。觉得这事不重要的人，写出来的系统就是一个又一个 return null，每一个都是埋给后人的地雷。
用微服务的方式写单体
技术选型会上聊得头头是道，注册中心用 Nacos，网关用 Gateway，配置中心、链路追踪一应俱全。
你打开代码一看：所有服务共用一个数据库，服务之间互相调用没有熔断，A 挂了 B 跟着超时 C 跟着排队，一个接口慢拖垮整条链路。部署倒是分开部署了，但每次上线要同时发布四个服务才能保证兼容，发布顺序还不能错。
这叫什么？分布式单体。单体的缺点全留着——改一个功能要动好几个服务，联调成本翻倍。分布式的坑也一个没少——网络抖动、数据一致性、运维复杂度全加上了。
但你要问他架构是什么，他能给你画出一张漂亮的微服务拓扑图。图是真的好看，跟代码没关系。
能把一个团队四五个人、日活几千的项目硬套上微服务全家桶的人，技术判断力基本可以画个问号。不是说微服务不好，是杀鸡用了牛刀，还没握住刀柄。
描述 bug 的方式
同样一个线上问题，两种人的描述方式完全不同。
第一种："这个接口挂了，不知道为什么，昨天还好的。"
第二种："下午两点开始订单查询接口 P99 从 200ms 涨到 2s，看了监控发现数据库连接池等待队列在涨，慢查询日志里多了一条全表扫描，怀疑是今天上午上线的那个新查询没走索引。"
第一种人给你的是一个结果，第二种人给你的是一条排查链路。
这不是经验多少的问题，是思维方式的问题。碰到异常第一反应是"坏了"还是"哪里坏了、什么时候开始坏的、最近改了什么"，这个反应是装不出来的。
评估工期的姿势
产品提了个需求，一种人脱口而出"两天"，另一种人说"我先看看"。
前者只算了写主流程的时间。后者脑子里在过一遍：要不要改表结构？改了表结构老数据要不要刷？跟现有接口有没有冲突？要不要和前端联调？灰度方案怎么做？
最后可能也是两天，但这个两天是算过的，不是拍的。
工期拍太紧不是能力强，是考虑得少。真正快的人不是评估得短，是执行的时候不返工。
面对不会的问题
面试里最见人的一个瞬间：碰到答不上来的题。
一种人开始硬编，东拉西扯说一堆沾边不沾边的东西，试图用信息量掩盖理解的缺失。你追问一句细节，他换个方向继续编。
另一种人直接说"这块我没深入研究过，但我猜测是……因为……"。猜得对不对其次，关键是他知道自己不知道，而且能在有限信息下做推理。
前者让面试官疲惫，后者让面试官想接着聊。
工作中也一样。不会不丢人，不会还装会才丢人。因为装的那一刻不会有人拆穿你，但代码上线之后会。
你发现没有，上面说的这些其实跟"会多少技术"关系不大。
会用 Redis 不代表知道什么时候该用。能写出微服务不代表理解为什么要拆。背得出设计模式不代表能判断哪个场景用哪个。
真正暴露一个人的，不是他知道什么，是他碰到不确定的事情时怎么反应。是直觉性地糊弄过去，还是老老实实说一句"我查一下"。
前者十年经验也是一年的水平复制了十遍，后者三年就能让人放心把事情交给他。
