先说个场面。
第一场，面试人是做推荐算法的，六年经验，讲得很漂亮：他怎么把召回率提了三个点，怎么做消融实验，怎么解决样本偏差。我问他上一个项目上线以后业务方少了多少人天，他说"这个我没统计过，我负责模型侧"。
第二场，面试人是平台后端，八年经验，讲了他设计的多租户隔离、幂等、限流。我问他客户为什么要这套隔离，他说"这是标准做法"。
两场我都往下推进了，两场都在试用期里出了问题。原因不在技术，都在同一件事上：他们各自的成功标准，在这个岗位上不成立。
真正要换的是"成功"的定义
这岗位最难换的不是技能，是判断自己干得好不好的那把尺子。
| 出身 | 原来那把尺子 | 到了现场要换成 |
|---|---|---|
| 算法 | 指标提升 | 业务方那个数字真的变了，而且是别人在用 |
| 后端 | 系统稳定不宕机 | 有人因为这套东西少加了班 |
| 数据 | 报表口径准 | 判断被塞进了动作里，不只是摆在眼前 |
| 测试 | 缺陷拦住了多少 | 上线前你就让结论可复算 |
| 产品 | 方案被采纳 | 你自己把它跑起来了 |
| 售前 | 单子签下来了 | 第二单是因为东西还在跑 |
这张表是我这一篇的核心。下面六段其实只是在说一件事：技术栈缺多少都能补，尺子不换的人会一直用原来的姿势干活，然后在第三个月被业务方否掉。
六类人
一、算法与模型训练出身。
省力的是评测那一层（第 10 篇），几乎不用教，对指标敏感，也知道模型为什么会错。
最容易犯的毛病是把交付当论文：先证明方法聪明，再管有没有人用。常见表现是花两周设计一个更优方案，而不是一小时做一个明天能上线的糙办法。现场要的是后者。
最该补三项：在客户工位旁坐满一周，把第 05 那张清单跑一遍；用别人给的脏数据做评测，不许挑样本；把"能上线"当成及格线，指标提升只是加分。
二、后端与平台出身。
省力的是地图中间那几层——工作流、工具调用、部署、权限（第 09 篇），写生产级代码是本能，别人做出来会塌的东西他们做得稳。
最容易犯的毛病是把业务需求当接口。需求还没定义清楚就开工，交出一个技术上漂亮、没人用的系统。第 01 篇那条分界——谁在定义问题——对他们最刺人，因为他们习惯等一份定义好的东西。
最该补三项：会写验收数字（第 07 篇第一关那四个要素）；会搭一条最小评测，三十条错误样本就开工；敢在会议室里说一句"这条我不做"（第 13 篇那两句话）。
三、数据、数仓与 BI 出身。
省力的是第 11 篇整篇内容：口径、数据地图、谁维护、能不能用，他们天生会问。
最容易犯的毛病是只做到"看清楚"为止。报表摆出来，判断留给别人。而这个岗位要的是把判断塞进流程里——系统直接把哪八条该先看排在调度员列表最上面，而不是给一张看板。
最该补三项：写能被别人部署的生产代码，不只是查询；学工具调用和权限边界；跟一线待一整天，看他们看完报表以后实际干了什么。
四、测试与质量保障出身。
我认为被严重低估的一类。怎么设计用例、什么算回归、怎么让一个结论可复算、怎么证明这次改动没把上次修好的东西弄坏——这本来就是他们吃饭的本事，而这恰好是评测那一层的内核。
两个毛病：只找问题不给方案，评审会上很受欢迎，交付会上让人头疼；以及"等资料齐了再动手"，现场的资料永远不会齐。
最该补三项：生成侧的技术，怎么把模型接上、检索怎么搭；动手写生产代码，不要只写用例；练"信息不足时先做一个糙版本"的肌肉记忆。
五、产品与项目经理出身。
省力的是需求翻译、汇报、范围控制——这三样是第 06 和第 13 两篇的全部内容，他们上手最快。
最大的坑是不动手，或者动手太浅。这个岗位的头一条要求是写生产级代码，第 05 篇引过那个通行定义，里面"软件工程师"四个字不能跳过。做不出能被部署的东西，就只能做半个解决方案工程师。
最该补三项：一个能端到端跑通的项目，从零到有人真在用（第 15 篇讲三个月怎么排）；把习惯从"文档齐了"换成"东西在跑"；找一个工程搭档，让他毫不客气地评审你的代码，持续半年。
六、售前与解决方案出身。
省力的是不慌。客户面前、决策链、不同听众说不同话（第 12、13 篇），这些对他们是既成能力。
坑在落地。演示能力强，长期驻场弱；而且习惯了顺从客户——客户说好就先应下来。第 04 篇里那种挂在销售职类下的"前线部署工程师"，最容易是他们转过去的形状。
最该补三项：硬写三个月代码；接受在现场被人当场纠正（第 13 篇那一分钟）；学会拒绝，并且能说出代价。
三种中途就废掉的形状
背景之外，我见过更多人是在这三种状态里停下的，而且停下时看起来都很合理。
只做技术有趣的那一半。 简历上写的是模型和评测，进现场两周就开始躲开会。这种人不是不能干，是把这行当成了换个方向的研发岗。
把驻场当成被发配。 心态一歪，动作全变形：不肯问客户业务方，不肯参加例会，交付完当天就买机票走。客户感受得到，之后再也不给你真信息——第 11 篇那个取数人就是这么丢的。
一个人扛着不提问。 越是原来的骨干越容易这样。卡住了自己闷两天，怕问出来显得不懂。这行的信息密度全靠嘴问出来，憋着干的人三个月就废。
这三种形状我没法从简历上看出来，现在靠一个动作试：让他跟我下一次现场，一整天。回来的路上聊二十分钟，基本就有答案。
我的排序，和我招错的那次
按经验给一个不太客气的排序：上手最顺的是后端和测试出身，最险的是产品和售前，算法在中间——卡点不在技术，全在心态。这是我自己带团队的观察样本，人不多，别当统计看。
我招错过一个人，到现在记得很清楚。
那是一次内部转岗，我从组里挑了一位指标能力最强的同事进 FDE 团队。他的评测做得比我细，方法设计得比我漂亮。
四个月里他把同一个场景的准确率从 78 提到 91，业务方那边一个字没变——因为他优化的那批样本，和一线每天真正处理的单子，来源不同。他自己从没去看过一线当天在处理什么。
第五个月他提了离职，理由我到现在都觉得说得通："我不知道这东西什么时候算做完了。"
从那以后我筛人换了两个问题。一个问背景："你上一次交付的东西，现在还有谁在用？"另一个问习惯："你愿不愿意在一个没有需求文档的房间里干三个月？"
第一个问题答不上来的人，技术再好我都不要。第二个问题犹豫超过三秒的人，我会认真考虑第二次回答。
转之前先做一次便宜的自查
别急着投简历，也别急着报班。我给的自测办法很省：找一个真在驻场的朋友，跟他坐一整天，你在旁边什么都不用做。
回来问自己三个问题。
你能不能接受一整天不写代码，只是看别人干活，还看得下去？第 05 篇那一周就是这个样子。
客户随口说一句"这个能不能自动化"，你第一反应是接需求，还是反问"现在卡在哪一步"？前者是外包的反射，后者才是这行的反射。
他当众指出你的东西有问题，你当天还能不能再坐回那个工位？第 13 篇那一分钟。做不到不难看，但要提前知道自己做不到。
三题里有一题答"不行"，这行你干得了，但会一直不太舒服。三题全"不行"，我建议先在原岗位找一个离客户最近的活干半年，再来决定。
一句收尾
这一篇想说的判断是：转这行的门槛不在技能表上，在"你怎么知道自己干成了"这件事上。技能半年能补，尺子要换一次，而且换的时候很疼——你要承认自己过去几年引以为傲的那把尺子，在这个现场不值钱。
有一件事我说不准：不同背景的转岗成功率，我手里只有十来个人的样本，排不出可靠结论。真要一个能用的信号，我现在只用那一条——这个人有没有替一个具体的业务数字背过一次账。背过的，转过来都不差；没背过的，我需要问更多问题才能判断。
下一篇给一个三个月的安排：做一个能拿去面试的落地项目，从选题到交付包，每一周该出什么东西。
