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

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

先了解这问题在问什么

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

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

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

发想回答

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

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

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

参考拟答

以下的范例是改编自 Amazon 官方的《How to best showcase Leadership Principles》，让我们一起看看什么样的回答会让面试官觉得是好的回答

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

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

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

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

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

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