来源｜阿里开发者公众号
作者｜董超
今年作为评委参加过比较多的晋升场子，前端和客户端技术栈为主。虽然连续3周的高强度面试场，对体力和脑力挑战很大，但对我个人而言，犹如经历了一场头脑⻛暴，还是非常有收获的：第一，有机会看到蚂蚁不同BG不同业务线的业务挑战和技术成⻓，是不可多得的机会去拓宽视野。有一种在技术分享VIP包厢的既视感。第二，也看到了不同BG、业务线、技术路线、提问⻛格的评委的不同问题，感受到虽然问题问法不同，但大家的关注点还是有很高的一致性的。而这些评委的视⻆和关注点，挺值得分享出来，对日常的工作成⻓还是很有启发的 (包括我自己在内)。
我的一些感受
相较于之前的晋升，今年开始新规，传递的重点信号是：期望候选人的精力做轻，看平日的材料大于听述职的PPT，技术看代码，有越来越多的360的声音。评委看到的材料增加了，不单单是代码量的产出，候选人还可以提供日常的系分文档、架构文档、代码CR记录和代表性代码。虽然对评委而言，需要看的材料从原来的一个PPT，到现在增加了好几倍的代码文档。但这样做的好处是，正确的传递出，晋升看能力，能力看日常。不是搞突击搞包装。
我个人对于候选人的感知上：好的是，越来越多的候选人在大部⻔中的工作边界越来越多清晰，重复的轮子越来越少。技术也越来越多贴近业务了，很少出现技术和业务脱节的情况；相对而言，问题是，对于很多破局期的业务，方向变化快，工程任务重，确实工具人的属性还是不轻。
那么从这次的晋升季中，有什么可以给大家做一个小分享的呢？我自己小结了两个方面，一方面想通过Q&A的形式给大家一个评委视⻆的描述，帮助大家能够相互看⻅；第二个方面，成⻓一定是我们这个组织的重要诉求，个人的成⻓才能带动团队组织的成⻓，所以我也尝试从个人的⻆度给几个小建议，希望能在日常工作中有些帮助。
候选人与评委的Q&A 模拟问答
Q1:评委挑战我的问题很多，是不是我就没戏了？恰恰相反，如果没有什么问题，那么可能才是大问题。因为，作为评委的压力是巨大的，需要给出一个客观公平的评审意⻅，确保这个组织的人才健康发展。在面试前都会仔细查看候选人提交的材料，内心或多或少都会形成几个问题和考察点，在答辩的过程中也会有新增的考察点。所以，如果评委有挑战大家千万不要怕，内心的笃定程度，其实也是评委需要考察的内容。相反，如果没有什么尖锐的问题，那么可能评委已经内心有答案了。
Q2:述职PPT里我写了那么多的成果，评委有没有仔细看过？为什么关注点和我的PPT表达的不一样?
- 首先只要你提交的材料和PPT，评委都会提前收到，我合作过的评委基本都会在评审前就仔细阅读的，另外为了减少跨BG的业务理解成本，本BG的评委会参与的。
- 我自己的视⻆看述职⻛格上，有这么几种类型，如下:
- 技术分享型述职：PPT写了非常多的具体成果和技术架构，就像是一次技术分享。那么疑问会是，哪些成果是你做的，哪些是团队做的？晋升看的是能力，成果展现是能力的必要条件，而不是充要条件。
- 这个时候一般都会聚焦在你做了什么？你的能力体现在哪里？什么因你而不同。比较忌讳完全拿团队或者合作伙伴的贡献说事。
- 过程攻坚型述职：体现很多过程中的演进和攻坚的思考和过程。如果能够不拖泥带水表现关键点，那么是比较好的表现形式，能够看到这个过程中你的能力提升和思维上的转变。
- 这个时候评委一般就会更加关注在面上的思考，比如是不是只单单解决了这个问题，对于其他的业务是否有借鉴？有持续性？解决的问题是否会有产品化或者体系化的沉淀？
- 技术自嗨型述职：技术说的很嗨，技术深度很深，奇技淫巧多，但体现的业务价值不多。
- 这个时候评委最担心的就是为技术而技术，为了体现技术难度而不考虑ROI的投入。
- 业务完成型述职：很多时候候选人的成果等同于业务成果，特别是对于晋升到高级专家，很多工作是业务使然，因你而不同的思考体现不足。
- 这个时候一般都会问很多行业理解到技术目标转化方面的问题。
- 人的精力总是有限的，资源也总是有限的，都需要我们在日常的工作中有取舍有聚焦。这些取舍和聚焦背后都是你对于工作的理解和思考。这些才是评委最最关心的事情。所以，才会有上述的候选人体感。
Q3:作为业务线的同学，和作为基础技术或平台技术的同学，评委在衡量尺度上是不是一样的？
- 首先是层级，每个层级的要求肯定不同。普遍而言，对于技术专家同学，我们都会要求上下游的思考规划能力，有ROI的意识；对于高级技术专家需要有领域的突破，能够定义一个领域的问题并有体系化的解法和影响力，全局思考包括ROI在内。
- 我自己理解又可以分成这样几个类型(视野原因，以下枚举并不太全面，请谅解)：
- 业务技术型：偏业务线，不会片面的要求纯技术深度和技术复杂度，但更关注对业务的领域理解，能够看到不同业务对于技术的差异化诉求，如果更进一步，能够基于对业务的理解，不单单是满足当下，而是可以进一步的基于业务发展的预判，有技术体系化的布局。
- 基础技术或平台型：偏平台技术，和技术基础底盘，那么就会比较关注技术深度和技术突破点。当然，一个必问的问题是，技术本身对业务的增值或者布局储备是什么？一定会强调不要为技术而技术，要有向上的业务价值链接。
- 解决方案型：不是自己研发代码，但会将多个业务线和基础平台的技术能力进行解决方案的组合输出。那么这个时候，我不会太要求纯技术深度，但对于解决方案本身的成本ROI，拓展性，领域里的特殊性，对外的集成成本，自己的运维成本，⻓期运作的流程机制有明确的思考要求。
- 全栈技术型：不少同学会是复合型的，比如大前端，比如算法和工程结果。今年确实看到很多算法和工程结合的case，比如端智能，端模型计算等。不过，有的时候复合并不都是加分项，如果你不能讲清楚算法到底解决了什么问题，基本原理是什么，仅仅是人云亦云的使用，那么是不够的。
- 所以，综上而言，没有一个冷冰冰的标尺，而是会根据具体所在的业务线站位去提出要求。
Q4:业务结果和技术目标都拿到了，为什么不让我过？
如前所述，业务结果和技术目标是绩效重要覆盖的，而晋升是能力，而且评委关注的，一定不是看苦劳，也不
是单单看功劳，还是要看如果从新开始做，你的能力是否还可以支持你的成功，你自己有没有意识到支撑你成
功的关键是什么？而不是靠直觉，靠运气。
Q5:业务线阶段就这样，我是不是就没机会了?确实看到很多业务进入了平台期，还有很多业务是试错阶段，对于技术而言需要贴着业务投入，上线压力大，留给技术自己思考的时间确实不多。这些都是非常现实的问题。这样的场景对个人成⻓而言难度确实是大的。这次晋升中，有一个候选人就深刻的给我们分享了一个他的技术选型失败的案例。但他没有止步于此，还是有很多业务的更深入的技术思考和方向的选择上了，所以评委还是一致看好的。难，但这个时候的自我突破可能会是更大的。Q6:为什么评委的判断和主管的判断会有不一致？晋升的通过结果有不少于主管的判断大相径庭，很多看重的人并没有得到评委的认可，很多初生牛犊倒是一边倒的支持，平心而论也反映了一个问题，主管对于用人多多少少会有一些盲区，因为常常用的爽用的都是⻓处，又有革命友谊，自然情人眼里出⻄施。用人所⻓是正确的，这点没有问题，而且每个人都有自己的⻓板和短板，团队也需要多元化的协同补位。不过回到培养人上，还是要跳出来帮助同学看到不足。晋升场也许就是帮助TL看到同学不足的机会。这点也是对我们的TL提出的要求，如果仅仅看到同学好的一面是不够的。
我个人的几点小小建议
- 注重平时的思考和沉淀，而不是最后临⻔一脚准备PPT。多分享多写写技术文章，对自己对团队有很有帮助。
- 和“不能为技术而技术”一样，也不能为晋升而晋升，平日的积累才是正路。反过来说，如果平日都是在埋头蛮干，临阵磨枪也是反映不出思考的。
- 全栈发展，算法和工程融合，都是非常好的方向。但重要的不是会用，而更重要的是具备不同技术栈的思考方式和思维逻辑。
- ⻆色是别人给的，做好自己的部分之后，可以跳出来看在更大的范围内如何协同拿到更大的结果，这也是所谓的一杆到底的态度。
- 产品研发不单单是接受需求实现，而是要挖掘用户到底要什么，什么是更好的。这也是所谓的产品化的态度。
