请分享一个你曾经收过的回馈,以及收到该回馈后你如何应对

2022年12月8日

💎 加入 E+ 成長計畫 與超過 350+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

在团队合作中,回馈是非常重要的元素。透过给予和接受回馈,可以让团队中的个人变得更好,也可以让团队的协作改善。因此在行为面试中,「过去接受过哪些回馈?以及收到该回馈后你如何应对」是非常重要的题目。

先了解这问题在问什么

在发想回答之前,我们要先思考这个问题背后是想问什么? 以及在回答中带入那些故事,可以获得面试官的亲睐? 可以试着换位思考,假如你要找未来的同事,你希望这个未来同事,收到反馈时,会怎么应对呢?

在 Amazon 官方出的《How to best showcase Leadership Principles》一文当中有针对这个问题做分析,里面提到几个特点是会面试官希望候选人有的特质,其中包含:

  • 愿意聆听他人的反馈,而不是固执己见
  • 会坦承自己做的错误,并反思如何解决
  • 在未来会持续将收到的反馈,运用在相似的场景中
  • 会主动寻求反馈

发想回答

从上面的分析可以看出,要准备这题相对容易许多。只要在故事中包含

  • 收到的反馈
  • 在收到反馈后有自我省思
  • 省思后有进一步做出行动来改善
  • 在未来相似的场景时,有持续用改善的方式应对
  • 收到一次反馈后,未来有主动寻求他人反馈

因此可以试着回想过去你有收过哪些回馈,在这些回馈中,有哪些你有具体做出行动来改善的例子。有的话就可以把它们挑选出来成为故事。

参考拟答

以下的范例是改编自 Amazon 官方的[《How to best showcase Leadership Principles》](https://www.amazon.jobs/en/software-development-interview-prep?INTCMPID=OAAJAZ100026B#/lessons/Fbo1d1Ic_SawawI-Q2tEKsf -PC82NqXR),让我们一起看看什么样的回答会让面试官觉得是好的回答

「我记得在我第一次被要求用 Java 开发某个新功能时,因为那时候我对物件导向的设计不是太熟,且那时我才刚加入团队,为了能够让别人对我有好印象,我花很多时间去研究物件导向的设计,然后把那些读到的内容应用在那个新功能的开发。完成功能后,我自己觉得挺自豪的,因为程式被设计得简洁有可延展。

但因为那是我第一次做物件导向的设计,保险起见下,我请团队中的其他人帮我看我写得程式。看完后,我们的组长找我去聊聊,原来在他与团队其他人的眼中,我把这个新功能写得太过复杂了,他建议我能用更简单的方式来实践。在边聊的过程中,组长同时重构我的程式,他仅用十五行程式就实践了同样的功能,而且他写得方式更易读也更好维护。

那个当下我瞬间被点醒,当时我意识到,我不该在追求炫技的同时,忽略了写程式的本质。我不该把简单的程式过度复杂化,导致其他人难读懂或难维护。我很感谢当时那位组长找我去聊,他给的反馈一直深植在我的脑中。在我后续的程式职涯中,我一直把那次经验铭记在心,每次写程式时都会反过来问自己是不是有避免过度复杂化的问题。

其实不只在写程式上,工作中的其他面向我也常常会把事情过度复杂,这也是过去几年来我一直试图改善的地方。现在我会有意识地检视我做的事情,确保自己没有犯这个问题。 」

上面这个范例回答,提到了他最开始犯的错 (把程式写得过度复杂),接着谈到组长给的反馈 (用更精简更好维护的方式写,而不是为了用设计模式而用)。他不仅在该次事件中改善,也把这个学习应用在未来的工程师职涯中。

如果你也能把你的例子,套到上面这个回答架构中,相信也能说出让面试官亲睐的故事。

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們