如何判断一个程序员技术强不强？看这四点就够了

1. 只看他写代码这是最可靠的试金石判断一个程序员技术强不强很多人喜欢看职级、看年限、看跳槽经历、看GitHub星星数。但说实话这些东西都只是侧写真正靠谱的办法就是直接看他写代码。我见过太多面试时对答如流、把各种框架原理背得滚瓜烂熟的候选人一打开他的代码仓库立刻原形毕露。反过来有些平时话不多、看起来很闷的程序员代码一拿出来逻辑干净利落让人一看就舒服。代码不会撒谎它是程序员思维最真实的外化。1.1 代码的第一层脸面变量命名和函数拆分很多刚入行的人觉得命名只是小事能让代码跑起来就行。但一个真正有经验的技术人看名字就能判断出对方脑子里有没有一张清晰的地图。举一个最简单的例子。两个人的代码都实现了把用户列表里未激活的用户过滤出来第一段代码def get_users(): users [] for u in all_users: if u.status 1: users.append(u) return users第二段代码def get_active_users(): return [user for user in all_users if user.is_active]第一段代码能跑但问题很多u.status 1里的1是什么含义读代码的人必须去翻数据字典才知道。get_users这个函数名说的是获取所有用户但实际返回的是过滤后的用户名字和逻辑对不上。而第二段代码get_active_users和is_active哪怕一个完全不熟悉业务的新人也能一眼看懂它要干什么。这还只是最简单的层面。往下走函数拆分更见功力。技术强的程序员写出来的函数通常短小、职责单一看名字就知道这个函数只做一件事。而技术一般的程序员经常写出几百行的大函数里面塞了数据校验、状态更新、日志打印、消息推送所有逻辑搅在一起。这种代码不是不能跑而是以后谁接手谁想骂人。注意判断时要综合来看。偶尔因为历史原因留下的妥协代码不算数但如果整个项目里到处都是这种一锅烩的函数那基本能说明这个人在设计上的思考不够。1.2 代码的第二层脸面对边界条件和异常的理解普通程序员写着正常流程优秀程序员写着各种可能出错的情况。这是拉差距最大的地方。你注意观察一个人写的代码里有没有这些细节入参校验是否齐全网络请求超时、重试、熔断有没有考虑文件操作的流是否被正确关闭了缓存穿透、击穿、雪崩有没有对应的策略多线程场景下有没有资源竞争的问题这背后反映的是经验积累。一个只写过快乐路径代码的人很难主动想到这些极端情况。而一个在线上出过事故、跟几百万用户数据打过照面的人写代码时天然会多留个心眼。我有个习惯看别人代码时会专门去读他处理异常和边界条件的部分。比如一个处理金额计算的函数技术强的程序员会先判断amount是不是负数、是不是超出了精度范围、是不是哪种币种、需不需要四舍五入技术一般的程序员直接拿过来就做加减乘除。一旦线上出现一笔异常订单两种代码的高下立判。1.3 代码的第三层脸面代码坏味道的敏感度如果你有过在一个老项目里维护代码的经历你一定感受过什么叫坏味道——重复的代码段、过长的参数列表、离散的魔法数字、过深的嵌套、本该是数据的字段被当成类来设计……技术强的人对这些坏味道极其敏感因为他心里有一根重构的弦。他在写一段逻辑时脑子里会有一个判断这段代码三个月后会不会需要加新功能如果加现在的结构会不会变成阻碍当年的设计边界在哪里而技术一般的人往往只在能用这个舒适区里待着。你让他加个功能他就在原有代码上继续叠补丁。叠到后面补丁之间互相打架项目越来越难维护。最后团队花了大把时间去重构本质上就是在为早期的设计懒惰还债。所以判断一个人技术强弱最直接的办法不是问他你技术怎么样而是直接打开他写过的代码库找一段核心业务逻辑哪怕只是阅读你就能得到七八成结论。2. 听他提问和讨论思维深度藏不住如果说代码是静态证据那讨论和提问就是动态考验。在技术评审、方案答辩、或者是平时的方案讨论中一个人提问的角度和回答问题的方式能够非常清晰地展示他的思考层次。我自己经历过很多次技术方案评审最深的感受是技术一般的人提问往往停留在这是什么的层面技术强的人一开口就问为什么这样如果某个条件变了会怎样这个方案的代价是什么。2.1 问What还是问Why暴露的是水平分水岭参与讨论时留意对方提的问题。技术一般的程序员问的问题通常长这样这个用的什么框架这个接口怎么调这个环境怎么部署这些都是操作型问题答案网上都能搜到。会问这种问题说明他心里想的是我怎么把它跑起来。技术强的程序员更关心为什么。比如为什么选 Redis 做缓存而不是本地内存两者的数据一致性怎么保证消息队列做了重试机制那消费端的幂等性怎么处理这个方案为什么不用读写分离是数据量没到还是业务的读比例不够高这些问题背后追问的是约束条件、取舍逻辑、系统边界。问出这种问题的人脑子里装的不只是一段段代码而是一整套系统运作的逻辑框架。提示这里要区分懂业务的技术人和纯技术型的人。有些人代码能力一般但对业务理解极深他提的问题可能不是纯技术角度而是从用户价值、投放效果来反推技术方案是否合理。这种选手同样技术不弱只是技术深扎在业务里。2.2 讨论方案时看他如何处理取舍每一个技术方案本质上都是取舍的产物。一致性、可用性、性能、成本、开发周期这些东西鱼和熊掌不可兼得。技术弱的人往往只有一个答案。你问他某个场景怎么设计他能一口气背出用 Redis 做缓存、MQ 做异步、ES 做搜索之类的标配答案但你再追问一句为什么要分这么多个组件哪些场景可以合并资源不够的时候先砍哪个他就答不上来了。技术强的人讨论时会有话术上的明显特征先复述一遍需求目标再指出约束条件再列出可选的几个方案最后给每个方案标注出代价。他讨论的不是哪个方案最好而是在当前条件下哪个方案最合适。比如讨论订单系统的库存扣减方案技术强的人会说如果并发量日均十万以下数据库乐观锁就够了如果到百万级别可能需要 Redis 预扣库存异步回补。但 Redis 方案有宕机丢数据的风险所以要做对账。我们要先评估业务增速再决定要不要上这套复杂度。这个回答里你能听到层次感量级判断、技术选型、风险评估、兜底策略。这种层次不是背出来的是踩过坑之后沉淀出来的。2.3 看他听不听得懂别人在说什么讨论中还有个特别隐蔽但很能说明问题的点就是倾听和复述能力。技术强的人会先确认对方的观点再表达自己的看法。他可能会说你说的意思是不是……我理解是这样的……如果从另一个角度看会不会……而技术一般的人讨论时倾向于自说自话你说你的我说我的。他不能准确抓到对方的疑问点自然也没办法给出有针对性的回应。这说明他的思维还没有建立模型同步的意识——没有把对方的思维模型跟自己的对齐而不是急着表达。这种能力在日常协作中太重要了。真正拖慢项目进度的往往不是技术难而是沟通错位产品说的A技术理解成B最后做出来个C。技术强的人能快速在讨论中建立共识把不确定的地方明确下来让整个团队的工作效率上一个台阶。所以如果你有机会跟对方参与一次技术讨论千万别浪费。听他提问、听他取舍、听他复述技术到底强不强这场讨论里基本能见分晓。3. 看他怎么解决问题这才是真实水平代码和讨论看的是静态水平和思维水平那处理线上问题的整个过程看的就是实战水平。遇到未知问题一个人是怎么定位、怎么排查、怎么解决的这里面藏的信息量非常大。3.1 定位问题的思路拍脑袋还是按图索骥我见过两类典型的排查方式。第一类是瞎试型。系统出问题了先重启一下不行就查一下日志再不行就网上搜一下报错信息搜出来的方案挨个试。试对了算运气好试错了也不知道为什么。这类人多半对系统内部的运行机制了解不深只能靠小步快跑碰运气。第二类是推理型。他会先梳理整个调用链路请求从哪个入口进来经过哪些服务哪个环节可能出现问题。然后他会分层排查网络层有没有问题、负载均衡有没有异常、应用日志里有没有报错、有没有慢查询、缓存命中率如何、依赖的下游服务是否正常。比如一个接口偶发超时推理型的人会这样排查先看超时时间集中在哪些时间段是不是和某个定时任务、大批量请求重叠。再用链路追踪工具看超时落在哪个调用环节是本地计算慢还是调下游 RPC 慢。如果是调下游慢再看是网络问题还是下游服务自身处理慢。顺藤摸瓜最终定位到是连接池配置太小高并发下连接被占满导致请求排队。这个排查路径没什么神奇的技巧靠的就是对系统每个环节都心里有数。而这套心里有数的背后是多年实践沉淀下来的系统思维。3.2 解决问题的方式治标还是治本定位到问题之后下一步看解决方式。技术一般的人倾向于让眼前的故障消失。接口超时了把超时时间从 2 秒调到 5 秒问题看起来没了缓存穿透了直接把空结果缓存一分钟穿透看起来被挡住了。但如果再深挖下去这些解决方式往往会带来新的隐患。技术强的人解决问题时分两步走先止血再根治。止血是为了让业务先恢复正常手段可以粗糙、临时但必须有效。比如先加个开关把异常功能降级先重启一下服务释放内存先扩容两台机器顶着。这个阶段核心是快。止血之后他会接着做根治。超时问题的根源是连接池过小那就调整连接池参数并压测验证缓存穿透的根源是没有做参数校验和布隆过滤器那就从入口做拦截、加一层布隆过滤。根治阶段的核心是消除根因而不是掩盖症状。能区分这个的人已经能跟普通程序员拉开差距了。因为很多程序员在止血之后就收工了留下的是随时可能复燃的火种。3.3 复盘之后产出了什么判断技术水平的另一个窗口是看他在一次线上事故之后贡献了什么。技术一般的程序员事故处理完就完了最多在公司群里发一条问题已解决。下次再遇到同类问题他还是会踩同一个坑。技术强的程序员事后会做这几件事写详细的事故复盘文档时间线、根因分析、影响范围、修复方案、改进措施缺一不可。提工单或需求把可观测性补上——新增告警、完善监控大盘、补全日志关键字段。检查同类系统里有没有同样的隐患做到一次事故全链路排查。把事故案例沉淀成一个简短的复盘分享让大家都能长个记性。你看技术强不只是体现在修得快上更体现在不让同类问题二次发生的系统性思考上。这种能力和写不写得出漂亮代码无关它是一种工程素养。实操心得我判断一个候选人有没有潜力经常会问一个场景题如果线上服务突然 CPU 飙升到 100%你的排查思路是什么回答里提到先看监控按进程、线程、方法栈逐层排查结合部署时间判断是否有新代码上线的人基本都有实战功底。如果回答是重启一下看看那基本就是还没被线上毒打过。4. 有没有系统思维决定了天花板在哪前面几节讨论的都是具体表现写代码、做讨论、解决问题。但真正区分优秀的程序员和普通的程序员的其实是一种更抽象的东西——系统思维。什么叫系统思维我举个例子。4.1 他只改自己那一亩三分地还是能看到全局假设要在一个老系统上新增一个用户导出功能。技术一般的程序员打开代码找到用户列表接口复制一段查询逻辑写个导出方法联调一下完事。他眼里看到的只有这一个功能。技术强的程序员脑子里弹出的是一张全景图用户表的数据量是多少全量导出会不会把数据库拖垮导出的文件放哪里OSS 的 bucket 权限配置了吗文件生成是同步还是异步要不要做个任务中心给用户一个下载入口导出的字段会不会涉及敏感信息要不要做脱敏和权限校验QPS 高了要不要限流和排队依赖的下游服务有没有兜底这次改动会不会影响现有的其他接口这些问题不是他到场后临时想的而是他脑子里天然有一个系统地图。他开发每个功能时都会自动在这个地图上标记影响范围。这就是技术深度和系统思维的差异。4.2 他会为自己的代码写生存环境还有一个不容易注意的细节就是他有没有为代码的长期运行考虑。技术一般的程序员写完功能就觉得任务结束了。测试让他改个 bug他改完直接扔回去也不管是不是引入了新问题。技术强的程序员写代码时有几件事是顺手做的关键路径打日志日志里包含足够上下文的字段比如请求 ID、用户 ID、业务参数。后续出问题可以从日志里还原现场。加必要的监控和告警哪怕只是往已有的指标里加一个计数器。他知道上线不是结束而是业务现场运维的开始。写必要的单元测试尤其是对核心业务逻辑。这不是为了覆盖率指标而是为了以后重构时有一个安全网。留下足够的设计文档或注释记录为什么这样设计而不只是这里做了什么。这些东西短期看起来都是额外工作但正是这些额外工作决定了这个系统能不能长期稳定地演进。有系统思维的人写的是能生长的代码没有的人写的是当下能跑的代码。4.3 他用成本意识做每一种技术决策系统思维还有一个体现成本意识。这里说的成本不只是钱还包括研发成本、维护成本、认知成本。技术强的程序员选型时不会盲目追新。他不会因为 Redis 出了新版本就立刻升级不会因为 Kubernetes 火就非要把单体架构拆成微服务不会因为某个新框架 star 多就在生产环境里试水。他先问的是这个东西解决了什么问题引入后要付出什么代价团队能不能 hold 住技术一般的程序员可能恰好相反。他的技术选型动机里新潮趋势简历上好看往往占了大头。一个老项目用 Java 8 用得挺好非要引入一套 Reactive 编程模型最后团队没人会写出问题没人能修复杂度还飙升了三倍。这不是说技术旧就是好的而是说选型要匹配场景。技术强的人心中永远有平衡木功能和复杂度、演进和稳定、短期收益和长期成本他心里都有一杆秤。系统思维看不见摸不着但它决定了技术人的天花板。代码写得好的人可能只是执行者但有系统思维的人才是真正能撑起一个项目、一个团队技术方向的核心角色。5. 判断完之后重点是怎么从他身上学到东西聊到这儿判断一个程序员技术强不强的方法其实已经讲得挺全了。但我觉得还有一件事更重要——判断的最终目的不应该是评价人而是从对方身上学到东西反哺自己的成长。5.1 找到锚点而不是找到对手如果你发现身边确实有技术比自己强的人别急着自卑或对抗。心态上把他当成一个锚点一个参照系你才有机会快速成长。具体怎么做很简单又很难主动看他的代码主动请他 review 你的代码多参与他负责的方案讨论。看他是怎么思考的、怎么取舍的、怎么写注释的这些都是在学校里学不到的一线经验。我早年间跟一位技术强的同事合作他做 code review 时几乎不在群里打一句话而是把我拉到一个房间里一行一行地过。一边过一边说这里为什么这样写如果换一种写法会不会更清晰这个方法的性能瓶颈在哪如果数据量翻十倍这逻辑还成立吗那段时间我成长的效率顶得上自己闷头写三年。5.2 建立自己的知识差距清单另外一个方法是给自己建一份知识差距清单。每当你在跟技术更强的人交流时听到一个自己完全不懂或半懂不懂的概念立刻记下来。比如连接池为什么要复用为什么消息队列能削峰数据库索引为什么用 B 树而不是二叉树布隆过滤器的原理是什么记录下来之后一项一项去搞懂。不要停留在背概念的层面要能用自己的话解释清楚甚至能写一段最小示例代码验证一遍。等到所有名词都能被你用大白话讲给别人听时这个差距就算补上了。这个过程很苦但很值得。我自己的经验是保持这个习惯两三年你会明显感觉到自己看问题的方式已经变了——从前看到的是一个功能现在看到的是一个系统。5.3 技术差异的另一面方向不同不必全盘照抄最后再提醒一句不要全盘照抄技术强者的路径。每个人技术成长的路都不同。有人是写业务代码写出来的有人是造轮子造出来的有人是在大流量场景下磨出来的。同样是技术强背后积累的东西千差万别。你判断出对方强之后要搞清楚他强的点跟你当前阶段缺的点是否匹配。如果一个做底层中间件的人你把他的成长路径当成神话去追但你日常工作明明是做业务系统那这份参考价值就非常有限。更好的做法是分析他的思维方式、学习方式、解决问题的方式把方法层面的东西借鉴过来而不是照搬他的技术栈和项目路径。回到最初的问题如何判断一个程序员的技术比你强方法无非就是这四条路径——去看他写的代码、去听他参与的讨论、去观察他怎么处理问题、去感受他有没有系统思维。但说到底判断本身不是终点。看到差距、承认差距、然后一步一步缩小差距这才是一个程序员面对技术比你强这个问题应该有的态度。技术这条路你走得快不快取决于你有没有见过高山以及愿不愿意往上爬。