5

前端这几年--答辩晋级这件事

 2 years ago
source link: https://godbasin.github.io/2022/02/27/about-updating/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

最近又是答辩季,程序员最讨厌写的 PPT 又到了不得不写的时候了。之前也有在帮一些小伙伴做准备,所以顺便给大家分享一些晋级答辩的思考和技巧吧~

关于答辩晋级这个内容,最开始我是直接做的视频放在 B 站分享,参考《程序员日志–晋级答辩这件事》

关于做视频和写文章,感觉自己从最初的只会写文章,到现在已经慢慢也会做一些视频了。视频的表达和文章相差很远,我自己的感受是,对于需要反复阅读、技术深度的内容,还是更适合用文章来记录。而视频更适合写一些需要录屏和讲解的模式,加上 PPT 本身的结构化,更容易去给大家梳理清楚逻辑架构,但是很多细节就很难讲清楚了。

如何对待晋级答辩这件事

对于很多大公司的程序员来说,晋级答辩关乎着是否可以升职加薪,而答辩成功与否常常会对个人的工作态度和心态造成较大的影响。

我个人的看法是:认真对待它,但不要过分依赖它。

这句话怎么理解呢?如果你仔细观察身边其他同事,大多数会分成两类:

  1. 平时工作只是完成工作本身,不希望受到答辩影响,但是到答辩的时候却临时抱佛脚。
  2. 过分看重答辩,在平日工作里就抢一些方便答辩的活,如果没有的话甚至自己造各种轮子,而不在乎这些轮子是否合适。

以上两种态度都可以改善,我们可以在平时就认真地把手上的每件事做好,而到了答辩的时候也要认真地对待,但是不要因为答辩这件事影响了自己原本该有的工作态度和对待项目质量的要求。

或许有些人会疑惑,造不合适的轮子,为什么答辩能通过呢?

其实答辩这件事,本身也有认知偏差和主观因素。由于陈述内容是由答辩人自身提供的,所以很多时候都会只把好的一面呈现出来,而使用的技术栈或是造的一些轮子给原有项目造成的影响,或是带来的技术债务,或许就只有项目内的其他成员知道了。

除此之外,因为答辩是由评委来评分的,因此主观上如果评委比较感兴趣的内容,会更容易通过;而如果是评委熟悉的领域,则会被问到很深入和核心的问题,这样的可能性会更高。

所以,更多的时候,我认为答辩是否能通过是很需要运气的,包括我自己通过的几次答辩,都有不小的运气成分在里面。这也是为什么,我想跟大家说不要过分依赖晋级答辩,因为如果你过分看重和孤注一掷,那么不管成功与否,都会对你以后的工作心态产生影响。

那么,正如我视频里所说的,关于答辩这件事,你需要知道:

  1. 答辩是由 70% 的努力 + 30% 的运气组成的。
  2. 答辩考核的除了工作内容,还有工作方式和答辩技巧。
  3. 答辩是结果,不是目的。

既然我们还是需要认真对待答辩这件事,该怎么去进行准备呢?

如何准备答辩

其实,答辩本身也属于项目复盘的一种方式,所以其实我们在平时工作里,就可以用更优的工作方式和节奏,去把事情做好。

平时工作要做好

如果我们在平时工作中,就有认真地思考每一个项目,更加结构化地去关注项目中的每个阶段的话,相比答辩本身能给我们自身带来更多的成长。

我们会常常看到,需要开发在工作的时候基本上是线性的工作方式,即:遇到问题 -> 解决问题 -> 结束。

实际上,我们可以在每个问题上思考更多:

(1) 做一件事的目的,需要贯穿全过程。

很多时候,我们在遇到一个问题的时候,马上就开始找解决方案了。其实我们可以先暂停,去思考下这个问题是如何产生的,我们需要解决的到底是什么程度的问题,做这件事的目的是什么。

而在问题处理完成之后,同样需要回顾当初这个问题的目的是否已经达成,是否还遗留有待解决的问题,等等。

(2) 拓展自身的思维,更加结构化地去做事。

比如,在寻找解决方案的时候,当我们找到一个解决方向的时候,可以先不着急去马上解决,而是需要考虑是否还有其他解决方案?当前方案是否最优?解决方案是否存在局限?是否有更多的探索可能性?

充分做好前期调研之后,再对多个方案进行对比,结合自身项目的情况,找到最适合用于项目中的一个解决方案。

(3) 将一件事情的价值最大化。

很多时候,我们处理完一个问题,这个事情就结束了。对于团队来说,这样的方式其实效率很低,因为不同的团队成员很可能会遇到相同的问题,如果每个人都花费这些时间去获得差不多的结论,那么团队的成长会很慢。

我们可以选择将每次处理问题的过程和解决方案进行总结沉淀,然后分享给其他人。这样,团队内就可以共享每个人努力的成果,这对于团队来说成长是很快的,而对团队中的每个人来说亦是如此。

而沉淀和总结本身,也可以促进个人的成长。在开发的职业生涯是,是否具备这样的能力和认识,是十分关键的。

答辩/项目内容结构

对于答辩本身,我们首先要知道:要能让评委认可你的能力,首先得高效地让评委理解项目中的各个过程。

因此,大多数时候我们的答辩内容都可以分为以下结构:

  1. 项目背景/问题描述。讲清楚做这个项目的背景情况和目的,这是最起码的铺垫。
  2. 难点/挑战点。如果评委感受不到项目中的难点,那么这个项目又怎么证明你的能力呢?
  3. 方案调研/方案对比。工作方式中,做好前期足够的调研和准备,认真对比得到的解决方案,才可以说是合适的方案。
  4. (解决过程)。过程大多数时候无关紧要,但是如果同样存在难点,也可以一并描述。
  5. 项目结果(最终效果/数据论证)。如果有足够的证据佐证,那么这个项目的成果便是无可置疑的。
  6. 展望:遗留问题/后续计划/产生更多价值。从点到面发散这个项目,是否可以做更多?
  7. 个人影响力。

这里就不过多描述了,其实如果你有认真思考以上的点,基本就可以说是有认真对待一个项目,同时自己也能从中获得足够多的成长和沉淀了。

除去答辩本身,以上的这些内容其实在我们日常的工作里,同样需要进行思考和去完成的。也就是说,这样的结构点,并不只是答辩所需,而是需要贯彻到我们工作的每个项目/每个遇到的问题里,这样才能更好地脚踏实地,同时也不需要再为答辩专门做更多的处理了。

如果说我们在平时就已经把工作结构化地做好了,是否意味着答辩就能一定顺利呢?

除了内容本身需要踏实以外,我们还需要掌握一定的答辩技巧,比如:

  • PPT 思路清晰,可以参考上述答辩内容结构来进行梳理
  • 适当使用动画,突出重点。动画的用处在于让对方注意力聚焦在自己讲的内容上,所以要避免过分浮夸的动画
  • 陈述足够熟练/脱稿,自己或是找同事多练几遍
  • 思考项目中的不足/可能提问的问题,准备到如何回答

以上等等。

如果你有时间,可以来看看这个视频(也可以直接去 B 站看原视频哦):

在工作中,我看到过不少由于晋级失败、拿了差考核而开始怀疑自我的小伙伴。我想说的是,工作只是人生的一部分,并不代表着全部,也不可以因为工作的不顺利而否定或是认定自己的一生。

实际上,失败才是大多数人一生的主旋律,我们要尽早学会如何与失望和意外相处,要接受不完美的自己,学会认可自己。世界上有无数的人,失败或是成功,但是只有一个自己,要学会爱上这个自己。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK