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