今年三月，技术件我面试了一个小伙子。员招简历漂亮，聘条985毕业，技术件三年大厂经验，员招项目列表里全是聘条“高并发”“分布式”这类词。技术面聊了四十分钟，技术件基础扎实，员招思路清晰。聘条最后我随口问了一句：“你平时怎么排查线上内存泄漏？技术件”他愣了一下，然后开始背jmap和jstat的员招命令参数。背得很熟，聘条但我知道他没真正处理过。技术件

他入职后第二周，员招线上服务OOM，聘条他盯着监控面板满头大汗，最后是我带着他一步步看堆转储文件。他理论基础很好，但遇到真实故障时，那种“从现象倒推原因”的直觉，完全没建立起来。这不是他的问题，是我们招聘流程的问题——我们太看重“会什么”，而忽略了“做过什么”。

所以现在我筛选技术员，第一条硬性标准是：必须有自己独立排查并解决过线上故障的经历。不是参与，不是协助，是独立扛下来。面试时我会问：“描述一次你从接到报警到定位根因的完整过程，中间用了哪些工具，踩过哪些坑。”能把这个故事讲得具体、有细节、有转折的候选人，技术底子通常不会差。反过来，只会背概念的人，一到真实战场就露馅。

第二条，看代码习惯。我让候选人写一个简单的字符串处理函数，不限制语言。大多数人能写对，但有人写完会主动考虑边界条件——空字符串、超长输入、特殊字符。有人写完就交，测试用例一跑就崩。代码习惯这东西，不是靠背设计模式能补的，它是日常写代码时脑子里那根弦紧不紧的问题。我见过工作五年的工程师，写个工具类连null检查都不做，也见过刚毕业的实习生，会主动问“这个接口的并发量预估是多少”。

第三条，学习能力的具体表现。别跟我提“热爱技术”这种空话。我会问：“最近三个月，你主动学了什么跟工作无关的技术？为什么学？学到什么程度？”一个真正有自驱力的人，会说出具体的技术名词、遇到的问题、以及他如何筛选信息源。而混日子的人，通常只会回答“看了些博客”或者“在学Python但还没开始”。

还有一条容易被忽视但很要命的：沟通的清晰度。技术员不是只跟机器打交道。需求评审时要能说清楚技术方案的取舍，线上故障时要能在群里用三句话让非技术人员明白影响范围。我面试时会让候选人解释一个他熟悉的技术概念，假装我完全不懂。能把我这个“外行”讲明白的，沟通能力基本过关；讲了五分钟我还云里雾里的，以后协作起来会非常痛苦。

最后一条，也是最难量化的：对“烂代码”的容忍度。技术员每天都要面对历史遗留的、没有文档的、命名混乱的代码。有些人会边改边骂，有些人会默默重构，有些人会写个测试用例先把行为锁住再动手。我倾向于要第三种人——他们明白技术债务是常态，也知道如何在有限条件下做最稳妥的修改。面试时我会拿出一段真实的烂代码，问候选人：“如果是你，怎么改？为什么？”没有标准答案，但能看出他的工程判断力。

说到底，招技术员不是招考试机器，是招能扛事的人。学历和证书是敲门砖，但真正决定一个人能不能在团队里立足的，是他面对未知问题时的反应速度、代码里的细节意识、以及跟人协作时的表达能力。这些素质，靠几轮面试很难完全看清，所以我会在试用期里刻意安排一些“脏活累活”——修一个没人愿意碰的老模块，或者给一个紧急需求做技术预研。能沉下心把事情做完做好的，才是值得留下来的。