你好，我是华仔。
面评主要分为三个环节，准备、自述和答辩。前三讲我已经介绍了准备环节写PPT的技巧，以及自述环节讲PPT的技巧，这一讲我接着来介绍答辩环节回答评委提问的技巧。
答辩很重要，但是别害怕
在正式开始之前，我必须先强调一点，答辩环节才是直接决定你能否通过晋升的关键。因为即使你在写PPT和讲PPT的时候表现不那么好，答辩环节还是可以弥补的；反过来就不行，如果你的PPT写得很漂亮、讲得也很有条理，但是答辩环节表现不过关，那么还是无法通过晋升。
很多在答辩环节表现不好的人，都会把失败的原因归结于口才不行或者压力太大。
其实以我多年的经验来看，口才不行很少成为晋升失败的原因，因为绝大部分评委都会尽力去挖掘你的亮点。
这有点像一个段子说的：“如果你在大学的考试中考了60分，很可能不是你努力的结果，而是老师努力的结果。”晋升评委也是这样，如果你第一次回答的时候没讲清楚，他们会觉得可能是因为你没听懂这个问题，通常都会换个问法，再给你一次机会。
当然，如果换了两次你都回答不到点上，他们就会被认为你确实没有掌握相关的技能。
不过，压力太大有时候真的会导致晋升失败。我想你可能也有过这样的经历，评委问到某个问题，你答不上来，感觉整个人就蒙了，甚至等到切换成别的问题的时候，你还没有回过神来。
提高抗压能力没什么诀窍，就是平时要多锻炼，比如内部模拟面评、给别人培训、向高级别的管理人员汇报以及在技术大会上做演讲等。
因为决定答辩表现的核心还是平时的积累，正所谓“台上一分钟，台下十年功”，光靠“临时抱佛脚”突击一下，很难侥幸过关。具体怎么在平时的学习和工作中积累呢？我会在后续的学习方法和做事方法部分详细讲解。
但是，因为答辩时间只有40～60分钟，就算你平时有足够的积累，想要在这么短的时间里充分地展现出来，也是需要一些技巧的。
技巧1：明确问题类型，回答关键内容
回答评委提问的时候，有两个很常见的错误。
一是急于回答，评委提问话音未落，你就赶紧开始回答，以为这样可以体现出自己在这方面了解得很清楚。
但是评委可能不这么看。如果你确实答到点子上还好；但是如果没有，评委会认为你没有抓住重点，对问题相关的内容掌握得不太好。
二是越多越好，评委随便问个问题，你都要说好几分钟，甚至非要等到评委打断才能收住。
这么做一方面导致你能回答的问题不多（因为总时间有限），无法充分利用这个环节展现自己的能力；另一方面也会让评委认为你抓不住重点，对工作的理解不够深刻。
正确的做法是，不要急于回答，先明确问题属于哪种类型，想想评委的关注点是什么，然后整理这方面的关键内容，最后再组织语言开口回答。
常见的问题类型和它们对应的关注点和关键内容，我整理在了这个表格里，接下来我们逐一拆解。
1. What类问题
What类问题关注的是结果，回答的关键内容是“做了什么事情 + 拿到什么结果”，其中事情部分最好用3句话能够描述清楚，结果部分尽量用数据来描述。
What类问题问得比较少，因为大部分内容你已经在自述环节讲过了。评委问这类问题，一般是发现了你遗漏的内容，或者对某些细节感兴趣，希望更全面地了解一些信息。比如你在PPT里写了某个业务的日活数据，评委可能会进一步问月活和新用户留存等数据。
这类问题，你用几句话就回答清楚就行了，不要展开长篇大论，把时间控制在30秒以内。你也不需要为了避免评委问这类问题，就在PPT里面把所有的数据都列出来，因为那样会让PPT显得没有重点。
2. How类问题
How类问题关注的是过程，回答的关键内容是“做事情的方法 + 实施的步骤”，其中方法部分要点出关键词，也就是评委提问的引子，而步骤部分要有逻辑，常见的时间逻辑、空间逻辑和业务逻辑等都可以。
比如你在晋升PPT里写的是“采用微服务重构系统”，并且给出了拆分前后的架构图，然后介绍说：“我们采用微服务的方法将原来耦合的业务系统拆分成4个微服务子系统……”
那么评委可能会问：“你们的微服务落地过程，具体是怎么做的？”
在这个例子中，方法部分的关键词就是微服务，步骤部分的逻辑则可以是业务优先级，按照优先级从低到高的顺序进行拆分，第一步拆分A服务，第二步拆分B服务，第三步拆分C服务，总共拆分成4个服务（原有服务 + A + B + C）。
然后，你再补充一下在拆分服务的过程中，你遇到了哪些挑战和困难，分别是怎么应对的，这样就回答得差不多了。
How类问题比较常见，因为自述环节不会展示太多过程的信息。为了全面了解你的能力，对于一些比较复杂的事情，评委一般都会关注具体的落地步骤，以及落地过程中你具体负责了哪些工作，然后再针对这些工作进行考察。
如果你在PPT里已经将步骤列出来了，评委可能就会直接针对具体步骤进行考察。
通常情况下，How类问题用1～2分钟来回答比较合适。
3. Why类问题
Why类问题关注的是原因，回答的关键内容是“技术原理 + 思考过程”。具体来说，Why类问题可以再继续细分。
第一类是技术相关的Why类问题，一般回答相关原理，包括技术理论、技术原则和技术方法论等，比如高可用的CAP理论、网络编程的多路复用、浏览器渲染原理等。
举个例子，评委如果问：“为什么Netty性能高？”你就需要回答和Reactor网络编程模式和零拷贝等原理相关的内容。
这类问题从回答技巧上说，比较简单。因为技术原理都是业界公认的，你能不能回答好，关键在于平时有没有积累，毕竟现场编也编不出来。
第二类是决策相关的Why类问题，一般回答决策背后的思考，包括分析过程、分析方法、分析框架和决策标准等。
举个例子，你做了一个创新的旅游业务，支持互助旅游。什么是互助旅游呢？就是你来我的城市，我带你玩；等到我去你的城市的时候，你再带我玩。在这个业务里，你选择了从大学生群体开始试点。
评委如果问：“为什么你要从大学生群体开始试点呢？”
你就需要从大学生的特点、业务的目标和最终决策的标准等角度来回答这个问题。比如你可以这么说：
“首先，目前中国的在校大学生，包括研究生在内，总共有XX万人，这是一个不小的规模，而且他们都有一定的消费能力。
“另外，大学生群体喜欢尝试新事物，学业压力没有高中那么强，有比较多的个人时间来探索世界，而他们的高中同学往往又分散在不同城市上大学，本身就有比较强的探望和旅游需求。
“总的来说，不论是从群体数量和消费能力考虑，还是从潜在需求方面考虑，大学生都满足我们的创新项目在初创期进行快速尝试和验证的要求，所以我们选择了大学生作为我们的业务试点用户。”
以上回答内容仅仅作为示例，可能并不完善。如果你是讲自己真正做的业务的话，只要你平时有这方面的思考和积累，其实是可以回答很多内容的。
这类问题是比较难回答的，因为思考没有统一的标准，同样一件事情要怎么思考，不同公司和团队的要求可能都不一样，有的要求快速尝试和验证，有的要求仔细分析和论证，没有哪种方法是绝对正确的。
但有趣的地方在于，即使我们平时没有积累，现场也能够说上几句，甚至说一大段。这很容易给我们一种错觉，以为自己每个问题都能回答一大串，晋升应该没问题，结果却往往是晋升失败。
为什么呢？很可能是因为评委并不认可我们的思考。那么怎样才能让自己的思考得到评委的认可呢？答案就是，在平时的工作中积累相关的经验，比如：
- P5/P6参加需求评审的时候，除了关注需求要做什么，也可以多听或者多问，为什么要这样设计。
- P7/P8给高级别人员汇报的时候，学习他们的分析框架、重点关注的地方和思考过程。
- 参加项目或者业务总结会议的时候，看看各方如何评价做得好的和做得不好的，如何分析背后的各种原因。
- 采用后续课程即将介绍的 “3C做事法”“4D总结法”“5W分析法”等做事方法来提升自己思考的系统性和深度。
你需要注意的是，如果你要突破团队已有的成熟的方法，是需要有特别的思考和充分的准备的，不然就会面临被几个评委轮番轰炸的风险。
第三类是综合类问题，跟技术和决策都有关系，你的回答既要包括原理，也要包括思考。
比如评委问：“为什么你们选择Memcache，而不是Redis？”
你既需要回答Memcache和Redis在技术上的核心差异，也需要回答在具体业务选择Memcache的原因。
那么你可以这样说：“我们的业务需要做文本和图片内容缓存，数据结构简单，但可能会出现几百K大小的缓存对象，在缓存内容比较大的时候，Redis的单进程模式会存在多连接IO操作互相影响的问题，性能不如Memcache的多线程模式。”
Why类问题是答辩环节的核心，可以占到问题总数的50% ～80%，而且级别越高，占比越高。原因在于，评委需要通过Why类的问题来考察到底是你自己达到了某个等级的要求，还是说你只不过是完成了别人安排的任务。
这也是评委需要把你的绩效和能力分开来看的原因。你拿到好的绩效，也不能说明能力一定有提升，可能只是因为你的主管很牛逼，而你主要是服从安排，按照他的要求完成任务；也可能只是因为你的运气比较好，正好碰到上升的业务。
通常情况下，Why类问题也是用1～2分钟来回答比较合适。
就算你能回答的内容很多，也不要一上来就滔滔不绝，而是每次都应该回答几个要点。如果评委有兴趣，就会继续问下去；如果评委认为你已经达到要求了，就不会再问了。
同样以Netty为例，如果评委问：“Netty高性能的原理是什么？”
你可以回答Reactor网络编程模式和零拷贝等原理。
评委如果还有兴趣，可能就会继续问：“Reactor网络编程模式性能为什么高？”
这时候你再回答多路复用和多线程等内容就行了。
技巧2：答不上来就想办法回到熟悉的领域
不管你的能力有多强，答辩的时候都有可能遇到自己不会的问题。
但是有的人很害怕遇到这种情况，担心一旦某个问题答不上来，晋升就会失败，于是根据自己的一知半解强行回答。
而且评委的很多问题，我们平时可能在某些场合听到过或者看到过，也不能算完全不知道，所以有些“口才好”的人，甚至还能装作很懂的样子说上好几分钟。
这样做表面上是回答了问题，实际上是给自己挖坑。因为在评委看来，首先你表现了能力上的缺陷，其次你还暴露了态度上的问题。他们只要愿意，稍微追问几个问题，就可以把你问得哑口无言。
遇到不会的问题，正确的做法是，不要编、不要蒙，老老实实承认不会，然后引导评委关注自己其他的技能，回到自己熟悉的领域。因为晋升的时候，你根本不用着证明自己全知全能，只要向评委展示出你的核心能力就够了。
比如你可以说：“抱歉，这部分我没有深入研究，但是我在XX技术上花费了比较多的时间，进行了深入的研究。”
当然，引导评委关注的技能必须是你真正有信心的，不要随口一说又给自己挖坑。如果实在不知道怎么引导，那就干脆不要引导，承认对这个问题不懂就行了。
技巧3：发生争执就及时终止话题
答辩环节还可能出现的一种特殊情况，就是你和评委关于某个问题的答案产生了争执，谁也说服不了谁。
这个时候，千万不要继续吵下去。因为就算后来证明你是对的，在答辩环节跟评委争论也没有任何好处。
首先，大部分评委都会为了证明自己，不断地抓住这个问题跟你一直辩论下去，这样一来你就没有时间回答其他评委的问题，展示你的其他能力了。
其次，一般来说，评委的工作经验比你丰富，对技术的理解比你深刻，所以你出错的概率要高于评委出错的概率。
最后，就算最后证明你是对的，评委是错的，也不可能重新来一次答辩或者修改晋升结果，因为这样相当于直接打评委的脸，影响很不好。
所以如果遇到产生争执，你可以这样说：“这部分内容我可能还没有研究透彻，后面我自己再深入研究一下。”
和技巧2不同的是，这里尽量不要引导说“我对XX技术有深入的研究”，避免跟你争执的评委为了面子，抓住下一个问题继续穷追猛打。
小结
这一讲我跟你分享了面评答辩环节的几个有用的技巧。核心的思想就是，你不需要证明自己什么都会，只要在有限的时间里，充分地展现自己的核心能力就行了。
现在，我们回顾一下这一讲的重点：
- 不要急于回答问题，也不要长篇大论，先想清楚问题类型，然后回答到点子上，这才是最有效的。
- What类问题关注结果，需要回答“做了什么事情 + 拿到什么结果”，时间在30秒以内；How类问题关注过程，需要回答“做事情的方法 + 实施的步骤”，时间1～2分钟。Why类问题关注原因，需要回答“技术原理 + 思考过程”，时间1～2分钟。
- 答不上来的问题不要编，直接承认不会，然后引导评委回到你熟悉的领域来提问。
- 跟评委发生争执的时候尽快“认怂”，及时终止话题，千万不要继续吵下去。
面评技巧部分到这里就讲完了。再次强调一点，虽然这些技巧可以帮助你更好地表现自己，但实际的专业能力和抗压能力还是需要平时在学习和工作中慢慢积累的。
思考题
这就是今天的全部内容，最后留一道课后思考题给你吧。既然答辩环节这么重要，是不是可以把以前参加这个级别晋升的人遇到的答辩问题，整理成类似“Java面试宝典”这样的内容？假如有这样的“晋升答辩宝典”，你觉得它能让你更加容易地通过答辩吗？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
精选留言
2021-01-03 20:43:51
这节课我最大的收获是：
做事情最重要的是你对所做的事情的思考深度。
导师也给了三种思考的层次：
what，关注的焦点是结果。
how，关注的是方法和步骤。
why，关注的是你对 做过的这件事的思考。
前两个(what，how)只要亲自做过，并且做的过程中有一些思考，就可以达到要求。
why则包括 技术原理的why 和 决策相关的why。
我做事总喜欢做完一个，再紧接着做下一个，没有给自己喘息的时间（思考的时间）。看来，完全错了。
以后要多给自己留一些思考的时间。思考很重要。
2021-02-18 17:19:39
2021-01-24 16:51:47
首先，评审会主要是展示个人能力，每个人的能力不同，做的事情不同，看过别人的答辩不代表轮到自己时也会答。
其次，有些事情只有自己真正有做过，才能知道其中的细节和思考，把别人的答案拿来背，很容易就会穿帮。
我导师之前说过一句话：”过评审其实就是自己事先精心准备几个坑，让评委进来踩。评委踩得满意了你就过了。“ 我之前一直觉得还挺有道理，不知道跟老师的看法是不是一致的？
2021-01-01 21:40:40
答辩时，评委提问，听完问题，简单复述一下问题，并跟评委确认，评委期望问题从What/How/Why的哪方面来答复，等确认后，再用总分结构回答，并跟评委确认，是否要继续展开细节
这个估计也能得到评委的理解与好感吧？
2022-06-24 16:51:16
2021-02-16 21:57:31
1. 首先明确这个宝典的目标人群，P5/P6/P7/P8/P9 哪个职级的
2. 主观的技术点大都是通用的，再次回到之前每个职级的COMD能力模型来说，P5、P6 的技术里都提到了一些主观的技术点，这些是技术点就像面试的面经宝典一样，评委大概也就问这些相关的，比如2 个人都是做的业务开发，都用了 Redis，评委可能问的 Redis 相关问题都是差不多一致
3. 管理高职级的相关软素质和带团队也有一定相通性，高职级的可能就脱离了一定的技术主观范围，但是每一个管理者或多或少都遇到一些类似的问题，这些是可以整理出来一套的。
4. 业务相关的，这个可能就需要根据自己做的具体业务具体分析了，可能很难去做一套通用的打法。
就像学习了很多东西之后，我们一直会问如何高效学习这个点，发现很多大佬们各自的方法底层逻辑下大多都是同一套打法，比如费曼学习法、1 万小时定律、刻意练习等等。
2021-04-13 09:18:15
2021-11-07 10:17:41
2021-08-11 08:48:19
2021-01-02 16:12:23
2024-04-08 08:28:48
2022-09-13 22:58:19
后来我每次紧张都安慰自己：这是病，这不重要，不要紧张，紧张声音抖会被人笑话……
这么做会有一点克服的作用，但是治标不治本。请问大家或老师有类似经历吗？是怎么解决的呢？
2022-01-26 21:26:25
2021-07-19 17:37:30
2021-07-14 09:41:43
2021-06-07 02:00:14
2021-02-24 13:02:17
2021-01-25 14:57:38