很多公司的晋升答辩只有 30 分钟，PPT 陈述 15 分钟，回答评委问题 15 分钟。
因此，如何在这短短的半小时里，用你的表现去说服评委，看起来还是有一定挑战的。
但我个人认为，如果你能吃透「晋升的标准」，再有针对性的去准备，其实难度没有想象中的那么大。
怎么理解「晋升的标准」呢？其实你只需要证明好这样一件事：通过讲述你做了什么？拿到了什么样的结果？来说明你的能力已经达到下个职级的要求了。具体怎么拆解，后文会详细展开。
从这一点来看，晋升其实就是一个命题作文，难度肯定比求职面试小一些，因为晋升 PPT 是你事先准备好的，评委的问题也基本都是围绕你的 PPT 展开，就算超纲也不会很离谱。
因此，如果你所有的准备工作都能围绕「晋升的标准」去反复推敲和优化，每一点都尽可能地做到最好，你就能比别人准备得更充分，胜算自然更大。
先聊一聊如何系统性地准备晋升材料。
对于技术同学来说，一般都是选择自己最有说服力的项目作为答辩内容，然后准备一个 PPT 进行现场陈述。
这一步，很多同学容易犯方向性的错误。为什么这么说呢？
首先，所选的项目没打到点上，那些你以为「很厉害」的项目很有可能并不适合作为答辩的素材（后面会具体举例）。
其次，写 PPT 很像是在写技术设计文档一样，你呈现的技术点并不是评委们想看到的点。
这两个问题只要有一个没处理好，晋升的希望就会变小很多。最有效的破解方法其实并不难，需要你回到评委的评价标准上，先彻底理解「目标职级的要求」，然后再将你做的事情、以及拿到的结果往这个要求上靠。
只有按照这个思路走，方向才不会走偏。下面我详细展开说一下。
大部分公司都会有明确的职级体系以及衡量标准，通常是按照开发能力、架构能力、业务能力、协作能力等维度进行拆解，会详细地列出每一项能力的行为标准（很细、很晦涩）。
这是我前一家公司对于 P6 级别「开发能力」这一项的具体要求：
深刻理解服务在实际运行过程中各个环节的相关原理，如硬件（CPU、内存、硬盘等）、内核（进程调度、内存管理等）、应用（设计模式、同步异步设计）、网络（协议栈等），清楚各个部分对实际服务的影响，并在实际系统开发中灵活应用。
这还只是其中某一项能力的行为标准，如果真要把每个职级各项能力的要求都熟记于心，估计会把评委们逼疯。
因此在真正实践时，评委并不会很死板地使用这个标准，而是抽象出一些「关键词」以及采用「人物对比」的方式去操作，先从自己熟悉的员工中选择几位表现优秀、同时和目标职级相同的人，拿他们与候选人进行横向对比。
以开发同学为例，从评委视角通常会这样来把控各个大级别的要求：
-
初级：
能在他人的指导下完成工作；具备简单模块的开发能力，代码质量达标。
-
中级：
能独立完成日常工作；具备子模块的设计能力，熟练掌握常用的技术栈。
-
高级：
能指导他人完成工作；具备跨模块和子系统的设计能力，有一定的技术深度，对高可用、高并发、高扩展等问题有完整的思路。
-
专家：
能对业务和技术进行整体规划；具备复杂业务场景的系统设计能力，能体系化的分析和解决问题，视野全面。
可以看到：
职级越高，负责事情的复杂度越大，对技术能力的要求也越高。这还只是表象的理解，背后更深层次的解读其实是：从点、到线、再到面，系统性的思考力和把控能力，高度也要跟上。
这个标准基本适用于我们常见的互联网大厂，只是有些公司会将大级别进一步细分成多个子级别而已。大家务必先吃透这个晋升标准，再考虑下面的事情。
技术同学的晋升一般是以「研发项目」作为载体，项目选择的好与坏能直接决定晋升的结果，因此一定要反复斟酌。
对于晋升答辩来说，一个「好」项目一定要具备这两个因素：
上个章节提到了：有些你以为「很厉害」的项目其实并不适合作为答辩的素材，一定是没法同时满足上面那两点要求。
比如说有不错的技术亮点，但是没产生实际价值（或者项目的负面评价很多），在评委看来：要么是没想清楚为什么做？要么是没想清楚该怎么做？
上面说的两个因素，项目贡献往往比专业能力更重要一些，一定要有很具体的东西让评委们看到。如果只是能力够了，贡献还不够，这种情况要通过晋升也是很难的。
此外，不论是项目贡献还是专业能力，一定要和目标职级的要求相匹配。
假如你的目标职级是技术专家（P7 及以上），那所选的项目最好能对业务起到一定的助力作用、或者能横向复制影响到其他业务，技术上则建议从全链路、整体架构这个视角去梳理。
