晋级 7 问 - 技术晋级答辩中常见问题解析_高级项目经理述职答辩问题csdn

在一些大一些且相对正规的互联网企业，每年都会有一到两次的晋级答辩，在晋级答辩的过程中，台上要晋级的同学努力准备好 PPT ，希望在有限的时间内能说明通道评委能相信自己所说，能认可自己是一个和晋级标准能力对应的同学。而台下的评委，则从 PPT 中，从提问过程中确认台上的同学是否符合自己认知范围内某个级别的标准，给出相对客观公平的分数，最后得出一个晋级与否的结果。当然「无利不起早」，一般过了级的同学在加薪以及组织范围内的重要程度会有所提升和偏重。

但是今天我们不聊如何晋级答辩，我们来看看作为一个评委来如何提问。

有人说：「世界上最难的事有两件，一是把自己的思想装进别人的脑袋，二是把别人的钱装进自己的口袋。」

作为一个评委如何提出问题，找到对方想要告诉你的观点/论点以及相应的论据，并评估其准确性，并规避掉大多数的陷阱，这是一个批判思考的过程。

那么我们如何能系统的提出问题，了解到自己想要的信息，或达到自己的目的？

当别人想把思考装进我们的脑袋时，他一般会提出一个问题，并引出一个论点，针对这个论点提供一些论据来佐证，以让你相信他。

首先我们对对方表述的内容做一个结构化的梳理，大概的结构如下：

问题：
结论：
理由：

结论是晋级者在晋级述职时在 PPT 或表述时要传达给评委的多个观点，是晋级者想让评委相信的内容

评委心声：他想让我相信什么 / 他想表述的观点是什么

结论就是一个个观点，这些观点需要其他观点和证据来进行支撑。没有证据支撑的断言，不能称为结论，而只能称为纯观点。

评委心声：你为什么会有这个结论，这个结论是从哪里来的，有没有什么可量化的数据支撑

一般来说，评委大多数都会基于晋级者客观的表现和自我的认知来打分，而晋级者的水平参差不齐，为了不错过那些确实有能力，但是在表达方面有所不足的同学，需要提问得到自己想要的信息。

在晋级同学讲完后，评委一般会基于 PPT 内容来提问，以确认其表述的准确性或希望晋级者能有更好一些的回答表现来证明有自己的做事逻辑和方法论，以确认有类似的问题也能解决，是能力达到了的表现。

晋级答辩对于晋级者和评委来说都是一个考验，晋级者尽可能多的把自己的能力展现出来，而评委尽可能公平公正的评判。
晋级对于评委来说，是工作，也是考试，整个过程相当于连续 N 场的考试，考核评委看人识人的水平，而在这个过程中，评委可能通过倾听晋级者的讲述得到一个初步的评价，同时通过提问来佐证自己的判断，以下是关于评委提问的常见逻辑，其主要出发点并不是为难晋级者，而是想通过提问找到能佐证晋级者能力的项，以做到相对公平。

1. 问定义

在晋级者讲述时经常会有一些模糊指向的词，而这些词在晋级者平常工作中经常遇到，以为评委知道，然而评委第一次接触并不了解。特别是一些表义比较泛的词语，在不同的语境都有着不同的含义，比如“架构”这个词，不同的人在不同的时期，在不同的场景对它的定义就不同。所以评委会在晋级者表述观点中有一些模糊性指向的词语的时候，或者存在意思不明确 / 有歧义的情况时候，做出提问。

比如在我们晋级中常常会说：做了服务性能优化，接口速度快了很多
这里评委可能会问：

• 这里的服务是指什么服务？
• 这里的性能是指什么？
• 优化是做了什么操作
• 快了很多是多少？从多少提升到多少？如何量化的？

服务和性能等词语都是比较泛的，比如性能可能是查询的性能或者写入的性能，并且不同的性能其对应的优化方案完全不一样，有些是技术点的优化，有些可能是整个架构的调整。

晋级提示: 精准用词，减少歧义

2. 问过程

一个事情只有有了好的过程，才会有好的结果，并且没有好的过程的好结果是不可重复的。
对过程提问主要是想了解并确认晋升的同学在项目中的扮演的角色，具体的工作，发挥的作用，以及对项目的掌握度。
特别是一些在 PPT 或者讲述的时间有些信息没有讲清楚的同学，评委此时需要通过提问的方式来把这个项目信息补充完整。常常通过以下的维度来提出问题：

2.1 背景原因

• 为什么要做这个方案 / 系统？背后的思考是什么
• 这个项目要解决的核心痛点是什么？
• 为什么是你来做这个？
• 你在项目中的角色是什么？
• 在项目执行过程你个人的价值如何体现的？

2.2 技术细节

• 某个技术点是如何实现的，讲一下细节？
• XXX 模块为什么要这样设计？有没有更好的方案？
• 这里为什么要用 XXX 缓存？为什么要使用这样的缓存设计？可以不用缓存吗？
• 业务领域为什么要这样划分？当时的思考是怎样的？
• 这里为什么要用 XXX 协议？如果换成 YYY 协议会怎样？

2.3 方案风险

• 做方案时有没有参考业界的方案，是哪些方案，方案的优劣是怎样的？
• 为何选择当前这个方案？
• 在评估方案时，考量的维度有哪些，为什么是这些维度？各维度的权重如何？
• 对当前有进行全面的风险分析吗？分析结果是什么？
• 如果分析出来的风险发生，如何应对？

2.4 数据指标

• 为什么要用 XXX 指标？背后的逻辑是什么？
• 这个项目产生的可量化的效果数据是怎样的？当初的预期是怎样的？达成情况如何？
• 项目开始时定的目标是 3 倍，为什么这里是 3 倍而不是 5 倍 10 倍，有什么依据？
• 这些数据是如何得出来的？
• 为什么这里的提升是 30%？能不能到 50% ？如果要到 50% ，需要做什么？为什么当时不做？

晋级提示: 科学决策方案、可量化数据、能重复过程

3. 问难度

不同的级别对于难度的要求不一样，难度这个项能在一定程度上区分是否满足某个级别的要求。
在答辩过程中评委可能会针对相应的级别提出一些有难度的问题，这里的难度不局限于某个技术难点，可能是某些行业内最新的动态，或者某个经典策略/方案/架构，或者最新的架构/语言/范式等等，比如：

1. 项目中你觉得最难的点是什么？ 为什么这个才是最难的？
2. 可以谈一下你对现在业界比较流行的 XXX 的看法吗？
3. 你对业界现在最热的 XXX 怎么看？为什么没有用到你这个项目里面来？

晋级提示: 有难度才有区分度

4. 问大局观

在高阶一些的级别中，对于事情的大局观是一个比较看重的项。
这里的大局观是指从宏观角度看问题，分析问题，从更大的整体来解决问题，实现技术价值的全局最大化，而不仅仅是局限于自己的一亩三分地。常见问题如下：

• 你所在项目的上下游是哪些？整个链路是如何联接的？
• 在这个项目上你有影响产品经理什么吗？如果有的话，是哪些？如何影响的？
• 你对项目最大的影响/改变是什么？当时是如何思考的？

晋级提示: 大局观决定了高度，尽在掌握

5. 问方法论

思考和总结是高阶一些的级别需要特别体现的内容，一般会落地成方法论，表示这个项目我这次能做成，下一次还能做成，有自己做事的节奏和方法。比如你讲某个地方的优化使用了缓存，此时需要对于缓存使用有自己的方法论，对于缓存其适用场景，优劣势，原理都尽在掌握，下次遇到类似的问题还可以解决，而且可能还是不同的方案，但是做事的方法和逻辑一样。

• 从这个项目你学到了什么？你最大的收获是什么？
• 如果还有 XXX 项目，你会怎样做？
• 你做 XXX 决定的逻辑框架是什么？
• XXX 背后的思考是什么？

晋级提示: 持续的成功才是能力

6. 问业务价值

技术最终还是服务于业务产生价值，而在晋级中如何把在做的东西的业务价值体现出来，也是要着重思考的。
如果你在讲述过程中没有提起或者提得不那么明显或清晰，那么评委可能会就此提问，可能的问题如下：

• 这个项目的用户是哪些人？他为用户带来了什么？
• 如何衡量你这个项目的价值？项目价值衡量的维度是否合理？
• 从公司层面（部门/某个大一些的组织）看，你认为这个项目贡献情况如何？
• 你当前组织的业务目标是什么？你这个项目是如何服务于这个业务目标的？如果没有这个项目业务目标会怎么样？

晋级提示: 将技术与业务价值和公司（部门）目标关联上

7. 问学习成长

• 你在 PPT 上有讲架构能力有所欠缺，你打算如何提升这方面的能力？
• 你有提到持续学习，你将如何持续学习，学习什么，有什么计划，预计会有什么样的收益？
• 想象一下，一年后的你是怎样的？三年呢？五年呢？

晋级提示: 学习能力是必备能力之一

8. 技术晋级常见问题

以下是两个常见的问题集

8.1 性能优化

做了 XXX 优化，性能提升了很多

• 为什么要做这个优化？做这个优化的出发点是什么？
• 这里的性能是指什么？
• 提升了很多是多少？从多少提升到多少？如何量化的？
• 性能提升后对用户有什么影响？有什么业务价值？
• 在系统中还有类似的性能问题吗？有没有系统思考过产生这个问题的原因？
• 从研发流程或研发制度上有没有可以优化的点来规避这些性能问题？

8.2 信息系统

做了一个系统

• 为什么要做这个系统？做这个系统的初心是什么？
• 能解决什么问题，能带来什么效果
• 能给公司带来什么价值？如何衡量这个价值？
• 带来的这些价值如何服务于公司级的业务目标？
• 系统的架构是怎样的？
• 系统设计的时候有没有参考业界的方案？
• 当时做方案选型的时候是如何评估的，重点是考察了哪些点？为什么要考察这些点，当时的思考是什么？
• 你在这个系统过程中扮演的是什么角色？
• 系统的优势和不足在哪里？
• 这个系统下一步如何发展

9. 后记

晋级对于我们来说意味着「升职加薪」，意味着我们的能力、知识、技能等得到某种官方的认可。
同时也意味着将来要承担更多的责任，也会被更多的期待。

晋级并不是结束，而是下一个开始。

最后，今天是五一劳动节，祝大家节日快乐。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com