1. 先放下“谁强谁弱”的执念聊聊判断这件事的本质干了这么多年开发带过团队也面过不少人我越来越发现一个有意思的现象程序员这个群体对“技术强弱”的判断往往非常失真。很多人喜欢用“懂不懂某个冷门API”“会不会背八股文”“GitHub星星多不多”来衡量一个人但真到了项目里一起干活这些指标经常全部失灵。我在招聘和带人的过程中无数次面临同一个问题面前这个人技术到底比我强还是比我弱我要不要听他的建议他的方案靠不靠谱说实话这个问题很难回答。但如果你总是一味觉得“谁都比我强”你会失去判断力被各种半吊子带偏反过来如果你觉得“谁都比我弱”你会错过真正厉害的人也封死了自己的成长路径。所以这篇内容我不打算给你一套“打分表”那种东西没用。我打算从一个切过无数项目、踩过无数坑的从业者角度聊聊我这些年观察下来真正能和“技术强”挂钩的行为特征、思维习惯和判断方法。你别指望看完就能精确测量每个人的技术水位但至少下次面对一个程序员你能在半小时内对他做出比“直觉”靠谱得多的判断。先说说我的核心观点技术强不强不看你知道什么而看你在未知和混乱面前怎么行动。知识储备只是存量遇到问题时的处理方式才是真正的能力体现。一个技术强的人面对他完全没接触过的领域也能有条不紊地拆解问题、找到切入点而一个技术弱的人就算在他熟悉的框架里待了五年遇到一点点变化也可能手足无措。这个底层逻辑想通了后面所有的判断方法都顺了。2. 面试与闲聊中的“高密度信号”判断法很多人觉得只有在项目里共事才能看清一个人的技术实力这话对也不对。日常交流和面试场景里其实藏着大量高价值信号关键看你会不会提取。2.1 遇到不会的问题他是怎么应对的这是我最喜欢用的探针没有之一。你问一个程序员他不懂的问题看他的反应就能看出很多信息。技术弱的人通常有两种表现一种是硬着头皮瞎编把场面撑过去再说另一种是直接说“这个我没用过”然后就沉默了等你抛出下一个问题。技术强的人完全不一样。他会先说“这一块我确实没深入研究过”然后紧跟着来一句“不过按照我对相关技术的理解它大概应该这样工作因为X和Y的原理是相通的”。你看他面对未知的方式是调用底层知识做推理而不是背诵某个具体答案。我在面试里问过很多人“CAS机制了解吗”有的人能背诵一堆理论有的人能现场画图讲清楚但真正让我印象深刻的是一位候选人他说“CAS我了解一些但底层的缓存行填充和伪共享我只知道概念没有实操过。如果我的工作中需要用到我会先去查一下当前CPU架构下缓存行的大小再做针对性优化。”听到这个回答我心里默默给了高分。他没有假装自己全会但给出了一个遇到问题时的完整应对路径。这种人在真实项目里遇到变化他是有思考框架的。2.2 能不能把一个复杂概念讲给小白听这个判断方法特别实用。你让一个程序员解释他熟悉的技术注意观察他把概念讲给不同人听的时候的调整能力。技术弱的人解释东西基本就两种情况要么从概念到概念云里雾里你听完和没听一样要么上来就甩一堆术语把简单的事情往复杂里说好像不把人绕晕就显示不出自己水平高。技术强的人恰恰相反他们有一套“降维翻译”的能力。我认识一位做数据库内核的哥们他跟我解释LSM Tree的时候直接拿“记手账”来类比“你先在草稿纸上记流水账等草稿纸写满了再工工整整誊抄到正式本子上。数据库也是这个思路先快写再批量整理落盘。”几句话一个复杂的数据结构原理就清晰了。能深入浅出说明他不仅在操作层面知道怎么用还在原理层面真正理解了本质。而且这种人有共情能力他能站在听众的位置思考“对方缺什么背景知识”这种能力在团队协作里的价值极高。反过来讲一个人只能跟你说“这是业界最佳实践”“大家不都这么干嘛”你基本可以断定他对这个技术的理解停留在了“会用”层面。2.3 闲聊中暴露出来的知识边界意识还有一种信号藏在闲聊里——一个人是否清楚自己的知识边界。技术弱的人常常有一种迷之自信聊什么都能接话好像全栈无所不能。但你往里深挖一层全是浮沙。比如你问他“你说你熟悉消息队列那Kafka和RocketMQ在消息顺序性上分别怎么保证的为什么Kafka在分区内有序但全局不能保证”他大概率会卡住。技术强的人反而经常说“这个我不太懂”。但注意他说“不懂”的方式很讲究。他会明确区分“我真的一点都不了解”“我了解大概但没实践过”“我用过但没研究过原理”这三种层次。这种层次感说明他对自己的知识体系有清晰的元认知。我特别怕一种程序员什么都说用过。问他Redis他“用过”问他ES他“用过”问他Nacos他“用过”。但如果让他讲讲当年用Redis做过什么复杂场景他只能说出“存了个缓存”。这种人的“用过”含水量极高你跟着他的方案走坑都在后面等着。2.4 面试到反问环节的输出质量这是个很妙的观察窗口。面试快结束的时候我都会问候选人“你有什么想问我的吗”大部分人问的是福利、加班、技术栈这很正常。但技术强的人问的问题里藏着大量信息。有的人会问“你们这个系统现在最大的性能瓶颈在哪里”——这说明他在思考自己进来之后要面对的真实挑战。有的人会问“你们的技术栈里用到了XX我注意到这个组件在某个版本之后有重大的架构调整你们是怎么处理的”——这就很厉害了说明他对技术生态有持续关注而且能快速把新信息和你这边的情况建立连接。有的人会问“如果我能进来前三个月你最希望我解决什么问题”——这种问题说明这个人有很强的目标感他关心的是“贡献”而不是“索取”。反观技术弱一些的候选人要么没有问题说明他对这次机会没有认真思考过要么问的全是“公司年假几天”“有没有下午茶”这类纯福利问题。不是说福利不能问但不应该成为你唯一关心的事情。3. 看代码比听自我介绍靠谱得多聊归聊判断一个人技术强弱最硬核的试金石还是代码。不过看代码也不是简单地“看他写得好不好”你得知道看什么、怎么看。3.1 代码评审里的反应速度与态度我参与过很多次Code Review代码评审这里面能观察到的信息量比很多人想象中大得多。技术强的人在评审别人的代码时关注点跟常人不太一样。他不会盯着“你这个变量命名不规范”“这里少了空格”这种表面问题他一上来就会问“这个方法为什么放在这里它的职责边界是什么”“这个接口的设计未来如果业务量增长十倍会不会有问题”“这个异常处理为什么在这个层级做更上层捕获会更合理吧”这说明什么说明他的脑子是“架构模式”驱动的看代码看到的是结构和流向而不是单个语句。在评审他自己写的代码时更能看出修为。技术强的人面对质疑第一反应通常是先听完再回应他不会急于辩解“我觉得我的方案没问题”而是先理解对方提出的角度再判断是否有道理。如果他发现自己确实没想到某个边界情况他会坦诚接受甚至表示感谢。技术弱的人正好相反。要么对自己的代码有一种“护犊子”心理任何意见都视为攻击要么完全没有主见别人提什么他都改结果把代码改成了一个四不像。这两种其实都是问题——前者缺乏协作精神后者没有技术判断力。我自己踩过一次很深的坑。加入上一家公司的时候我负责一个核心服务模块有位同事资历比我老评审我代码时提了一大堆意见。我当时心里很不服气觉得他是在挑刺。后来硬着头皮按他的思路重构了一版跑了一遍压测性能提升了将近三倍。那次之后我就长记性了评审意见可以不接受但一定要先理解对方的出发点。有些人的技术是“能解决问题的技术”只盯着一行行代码看是看不出门道的。3.2 改Bug的速度与深度改Bug是程序员最日常的工作之一也是判断技术实力的绝佳场景。技术弱的人改Bug有一种典型路径先猜再试试不对就再猜。他们常常在一个问题上反复打转改了A处冒出来B处修了B处又带出C处整个过程像是打地鼠。更糟糕的是有些人发现“改动A能让Bug消失”就以为问题解决了也不管为什么消失的。这种修Bug方式是在给系统埋雷今天的“修复”就是明天的线上事故。技术强的人改Bug会先试着复现再顺着调用链理清因果关系找到根因然后才动手。他们还有个习惯修完Bug之后会接着问“为什么这个Bug没有被测试用例拦住”“测试覆盖为什么会有这么大的漏洞”。他们在意的不是“搞定这一个Bug”而是“怎么样以后少出这一类Bug”。我印象很深的一次是在做一个分布式系统项目时有个数据不一致的Bug在测试环境复现概率极低一到晚上总有零星的告警。团队里一个新来的同事主动接了这个问题。他没有急着去改代码而是花了两天时间梳理了整个链路的时延和日志时间戳最后发现是时钟同步的精度问题导致了事件顺序判断错误。修完后他把分布式环境中时间同步的机制研究了一遍还写了一份文档。技术强不强看这种行事方式一目了然前者在现象层面打转后者在机制层面下功夫。改同一个Bug前者只是“把火灭了”后者是“找到火源并建了一条防火隔离带”。3.3 他的代码里有没有“防御性思维”打开一个人的代码你能直接看出他的思维水平。技术弱的人写代码默认一切都是正常的参数一定能传对下游服务一定能返回本地磁盘一定还有空间。这种“理想世界编程”写出来的代码在真实生产环境里就是定时炸弹。别看平时跑得好好的一旦遇到边界条件就原形毕露。技术强的人写代码默认一切都是不可靠的。他们会对输入做校验会考虑超时和重试的成本会预估数据量增长后的行为变化会在关键的日志点打出足够的信息。但这不是“防御性编程”四个字能概括的本质上是他在写代码的时候脑子里在反复推演“系统可能怎么坏”。我还注意到一种更微妙的区别技术强的人在写防御逻辑的时候会保持一种克制。他不会在每一行都加上空指针判断那只是掩耳盗铃。他会分析出“哪里是最可能出故障的边界”然后在那些关键节点上做保护。这种“精准的防御”是建立在深刻的系统理解之上的不是堆砌保险丝。拿一个最简单的文件上传功能来说技术弱的同学可能会写def upload_file(file): save(file.name, file.content) return success技术强的同学可能会写def upload_file(file): if not file or file.size MAX_SIZE: raise ValidationError(file invalid) file_name sanitize_filename(file.name) try: save_with_atomic_rename(file_name, file.content) except DiskFullError: log_with_metric(disk_full, file_name) raise RetryableError(disk full, retry later) return success你别觉得这个例子太简单真实项目里类似的逻辑差距会让系统的可靠性产生天壤之别。代码不只是写给机器执行的更是写给人看的——包括三个月后的自己。3.4 重构与代码洁癖的平衡还有一个高价值观察点一个人怎么看待“屎山”代码。技术弱的人对烂代码有两种极端反应。一种是很着急恨不得把所有代码都推翻重写美其名曰“架构升级”另一种是视而不见烂就烂着吧能在上面继续堆需求就行。这两种都不对。前者是理想主义泡沫真要在业务压力下推动全量重构大概率会把系统搞崩后者是技术债的奴隶一年之后整个团队的开发效率都会被拖垮。技术强的人对技术债的态度非常务实。他会判断这块代码虽然丑但改动风险极高不值得现在碰那个模块的设计确实跟不上业务规模了可以在下一次大版本迭代里逐渐替换掉。他们会给“坏味道”排优先级而不是一刀切地“全要改”或者“全不管”。这种判断力其实就是和业务对话的能力。一个只关注代码本身的程序员哪怕写得再干净也很难算得上真正的技术强。真正的强者是把技术放到业务环境和系统约束里通盘考虑的人。4. 五个容易被误判的“假强”特征在判断“技术强不强”这件事上很多人会被表面现象唬住。我根据这些年的观察整理了几种特别容易误导人的“假强”信号你以后遇到类似情况心里多一根弦。4.1 简历堆满了新框架却讲不清业务有一种程序员简历上写满了Kubernetes、服务网格、云原生、大模型应用乍一看非常唬人。但你跟他聊业务问他这个系统服务了多少用户、承担了什么核心链路、每年什么量级的增长他答不上来。技术本领归根结底是要服务于业务的。一个只会把技术名词堆在简历上、却对业务目标毫无感知的人很难在复杂的工程决策中做出正确判断。因为他不知道技术的取舍往哪个方向倾斜。反过来一个真正的高手可能在简历上只写了一行“支撑了千万级用户的核心交易系统”但你在深聊中会发现他对业务的每个细节、数据的每一次流转、系统可能出故障的每个节点都了然于胸。这种“业务感知力”是装不出来的。4.2 浏览器收藏夹里的文章收藏家我见过一种人特别爱学习每天刷各种技术公众号、收藏各种深度好文GitHub上star了几百个项目。你问他任何一个技术名词他都能给你讲出个一二三。但一到实操拉胯得特别明显。他讲的“分布式事务解决方案”全部来自某篇博客你让他画一下自己项目里的架构图他画不出来。你让他写一段处理并发扣减库存的代码他憋了半天写出来一个可能把库存扣成负数的高风险实现。这种“知识搬运工”型选手问题在于他把“收藏”和“知道”划了等号又把“知道”和“能做到”划了等号。技术是门手艺活光看不练假把式。判断一个人的技术强弱永远要看他动手做过什么而不是看他读过什么。4.3 敲键盘噼里啪啦的“人肉IDE”还有一种视觉上的迷惑行为敲代码速度飞快Vim玩得溜各种快捷键满天飞屏幕上一行行代码刷刷往外蹦。外行看了觉得这是大神真要命的是有些内行也会被这种“表演”唬住。但冷静想想代码快的本质是什么是把脑子里已经想好的东西快速落地。如果一个人脑子里想的是错的他敲得越快产出垃圾的效率越高。真正的差距不在打字速度在于“写好之前是否想清楚了”。那些看起来慢吞吞、半天憋一行代码的人有时候恰恰是在脑子里推演了更多方案和边界情况。我见过最夸张的例子一位做底层存储的同事写核心代码之前会在本子上画小半天的图但写出来的代码逻辑极其严密极少返工。所以判断技术强弱千万别被手速迷惑。你该看的是代码质量和最终产出而不是键盘发出的动静。4.4 单点能力极强但系统性很差有人算法题刷得飞起LeetCode能解各种hard题但让他设计一个接口他画出来的方案完全不可用。有人SQL写得极其精巧但让他整体看一下数据库的表结构设计他完全没有全局观。这种“单点能力极强、系统性很差”的人特别容易在面试环节拿高分因为面试官通常会在某个技术点上层层追问正好命中他最强的那个点。但到了真实项目里你会发现他处理不了需要多模块协作、多团队协调的复杂任务。真正技术强的人是在“点”上深入之后还能跳出来看“面”的。他既能跟你讨论某个数据结构的选择对性能的微小影响也能站在整个系统的角度思考这个模块放在这里合不合理、接口该怎么划分、数据应该怎么流动。怎么识别这种“系统性”我有个简单办法丢给他一个跨模块的复杂问题看他第一个反应是“这个问题主要难在哪个模块”还是“这个需要拉上A组B组C组一起开个会”。前者说明他在试图自己建立全局认知后者说明他习惯在局部做执行。4.5 什么都会一点的“全栈快餐”型这几年“全栈”被鼓吹得很厉害很多程序员也以此为荣好像前端后端运维大数据样样都能上手就是技术全面。但我观察下来绝大多数所谓的“全栈”其实是“全栈快餐”——每样都知道个皮毛能搭个demo真正遇到生产环境的复杂问题就露怯。他会写React也会写Spring Boot但你问他浏览器渲染机制和GC调优原理他只能泛泛而谈。真正靠谱的技术人通常有自己的一块“根据地”这块地方他扎得极深深到你问什么问题他都能从原理层面给你解答。在这个基础上他会向外扩展其他领域的知识这种扩展是“T字型”的先有深度再有广度。判断方式很简单找一个冷门但关键的细节连续深挖三层。举个栗子他如果说自己熟悉MySQL你就问“InnoDB的默认隔离级别是什么为什么选这个级别它在实现上通过什么机制防止脏读如果要把隔离级别改成串行化底层逻辑有什么不同”能接住三层追问的人才是真有根据地的人。5. 与其只想着“判断别人”不如建立自己的技术坐标系最后这部分我想把视角拉回到你自己身上。判断一个人技术强不强的根本目的不是为了给人打分、给人贴标签而是为了让自己更好地学习、更好地协作。所以比起你如何“看穿”别人更重要的是你如何“对标”别人、从别人身上吸收养分。5.1 把“他比我强”转化为“强在哪、我该学什么”很多人面对技术比自己强的人会本能地产生焦虑或自卑觉得自己怎么追都追不上。我年轻时也这样过直到后来想明白一个道理技术成长不是一场零和博弈别人的强不意味着你的弱。就算他真的碾压你你也能从碾压中获取大量信息。下次你遇到一个你觉得技术很强的人别急着感叹试着做一次拆解练习他到底哪一点让我觉得强是思路清晰、说话有条理还是代码组织能力强还是对底层原理有笃定的理解还是快速定位问题的效率惊人把模糊的“强”拆成具体的维度然后挑一个你目前最需要补的维度盯着学。学完一个再换下一个。这种“对标式学习”比你自己闷头刷技术书高效得多。我就见过一个年轻人跟着一位带他的架构师干了两年从“代码写得乱但Bug少”成长为“代码设计能独当一面”。他做的并不是什么惊天动地的努力就是每次架构师评审代码时他都拿个小本子记下对方提出的那些他没想到的问题拆解、理解、消化。5.2 建立自己的“技术能力框架”与定期校准要准确判断别人你得先有一把自己的“尺子”。这把尺子不是一个模糊的感受而是一个成体系的能力模型。我建议你把自己关注的技术维度列出来分成几大类每一类下面再列出具体表现。比如工程实现能力代码可读性、异常处理完备性、单元测试覆盖率、代码组织的清晰度系统设计能力模块划分合理性、接口设计优雅度、扩展性预留、对性能瓶颈的预判问题排查能力定位问题的效率、是否依赖尝试还是依赖推理、复盘时是否深入根因协作沟通能力表达是否结构化、面对分歧的处理方式、是否能站在对方角度解释技术方案业务理解能力是否了解系统的业务目标、是否能从业务角度解释技术决策、对用户场景的敏感度每隔半年你可以拿这把尺子重新校准一遍你在哪些维度变强了哪些维度还比较虚。同时你也会发现你对“别人技术强不强”的判断也会随着你这把尺子变得更精细而自动变得更准。这个框架很重要。没有框架的人判断别人全凭“性格”“聊不聊得来”“气场”这种判断最容易出错。你可能会不自觉地被那些说话笃定、性格强势的人带跑却看不到他们方案里的漏洞也可能因为“这个人性格内向、不太爱说话”就错过了一个方案能力极强的高手。5.3 技术强弱的终局是解决复杂问题的综合能力说到底技术强弱是一个动态的、多维度的综合判断不存在一条线把所有程序员分成两边。今天在这个领域比你强的人明天到了你的主场上可能也要向你请教。我这些年最大的体会是一个程序员真正的“强”不在于他掌握了多少框架和工具而在于面对一个前所未有的复杂问题时他能不能冷静地拆解它、定位它、解决它并且在这个过程里带动身边的人一起前进。这种能力需要技术深度作为底座需要业务理解作为方向需要沟通协作作为管道。它不是某一个瞬间的灵光乍现而是长期、刻意、多维修炼的结果。所以下次当你再遇到一个问题“这个人技术是不是比我强”我的建议是先别急着下结论花点时间观察他怎么面对未知、怎么拆解问题、怎么对待批评、怎么解释复杂概念。这些细节看多了你自然会有一种基本准确的感觉。而更重要的一步是转过身来问自己我想在哪些维度上变得更强然后带着这个问题投入到下一个项目中去。因为判断别人只是手段让自己真正变得更强才是我们这一行的永恒目的。