回答 "告诉我什么时候...... "的协作技能

---

正如我们的行为面试准备概述中提到的，合作是需要准备的 8 大类问题中的一类。

合作问题可能是前端行为面试中最常见的行为问题，因为它们包含了大量相关的特征，为了便于故事/项目的准备，可以将其分组。

在本指南中，您将学习如何处理这些问题：

1. 详细的评价标准
2. 将可能的问题抽象为共同的主题
3. 建议的答案框架
4. 一个很好的样本故事示例
5. 后续问题的可能性质
6. 问题和回答示例

详细的评价标准​

在对这一类别的候选人进行评级时，面试者常常考虑以下标准：

• 处理分歧
• 团队合作
• 与具有不同性格和技能的人合作
• 简单地传达复杂的概念
• 提出有建设性的反馈意见。
• 积极倾听

抽象合作问题​

正如我们的行为面试准备概述中提到的，为那里的每一个行为问题准备具体的答案是不切实际的。 然而，通过将具体问题批量化为类似的主题，并准备涵盖大量问题要求的故事，我们可以将准备的故事数量减少到 3-5 个左右。

合作是这样一个主题，它可以将沟通、团队工作、适应性和指导性等子要求组合起来。 对于每个子要求，我们总结了常见的问题，也抽象出了面试官在这些问题中所关注的特征：

沟通​

问题示例​

• 你能描述一下你不得不向非技术性听众有效传达技术信息的时候，以及你是如何处理的吗？
• 您能否描述一下你不得不调整您的通信风格以便与具有不同背景或观点的人进行有效地沟通的时候？
• 你能举出一个例子，说明你曾在时间紧迫或高度紧张的情况下，不得不沟通重要信息？
• 你如何确保你的信息被受众理解并得到很好的接受？

面试官看重的特质​

• 简单地传达复杂的概念
• 积极倾听

团队合作​

示例问题​

• 您能否描述过去的一个项目，在这个项目中，您必须与困难的利益攸关方或团队合作，以及如何处理它？
• 你能告诉我，你有什么时候需要向团队成员或同事提供建设性的反馈吗？
• 你如何处理与那些没有在最后期限或职责范围内完成工作的队友合作？
• 你能提供一个例子，当你不得不与一个团队一起工作时，成员之间存在分歧？
• 您如何处理与具有不同技能组合和个性的团队合作？
• 你能举一个例子，说明你为了成功完成一个项目而不得不适应团队成员的工作风格吗？
• 您如何确保在小组讨论中听取所有团队成员的意见，并考虑他们的想法？
• 你能否举一个例子说明你必须在一个团队项目上工作不得不与他人妥协以达成解决方案？
• 你能描述一下你不得不与来自不同部门或组织的人合作完成一个项目的时候吗？

面试官看重的特质​

• 作为一个团队工作
• 与不同的工作风格、技能和个性工作
• 处理分歧(他人的和自己的)
• 提出有建设性的反馈意见。

建议的答案框架​

一如既往，STAR 格式 是我们推荐的最简单、最有效的框架，用于构造你的故事。

根据上述抽象，我们可以看到，面试官正在为每一项子要求寻找具体特点。 我们为了展示这些理想特征的建议方法已经创建了一个快速的小册子。

理想的情况是，你应该选择能够尽可能多地涵盖以下特征的故事，这样你就不必记住太多的故事。

简单地传达复杂的概念​

1. 首先了解你的受众的知识水平。 设身处地为他们着想，用他们的语言解释。
2. 了解他们需要知道(和想要知道)什么，优先考虑关键要点。
3. 仅在适当的地方深入挖掘重要细节。
4. 将想法分解成各个组成部分。
5. 使用视觉辅助工具，如示意图或图表。
6. 举例说明。

注意：对于沟通，像简单传达复杂的想法和积极倾听这样的特质，可以通过你的实际面试表现来评估--例如，你是否打断了面试官，你是否正确地倾听和理解了他们的问题，你是否以一种易于消化的方式传达了你的思考过程。

积极倾听​

1. 侧重于理解而不是答复。
2. 在对方说完之前，暂不做判断。
3. 使用非语言线索来显示你的参与。
4. 用你自己的话来总结和重复一遍。
5. 提出澄清的问题。
6. 永远不要打断。

作为一个团队工作​

1. 设定明确的目标并确保每个人都能理解它们。 积极主动地寻求一致和观点。
2. 指派和交流角色和责任。 合作和授权。
3. 设置定期的进度检查和地址拦截器。 始终让适当的利益攸关方参与进来，并与他们及时分享信息。
4. 衡量影响并认可成就。

与不同的工作风格、技能和个性工作​

1. 公开认可每个团队成员可以带来的独特观点和技能。
2. 鼓励公开和诚实地沟通，并积极听取意见。
3. 创造一个欢迎和支持的环境，即使是对不同的意见。 把它们当作成长的机会。
4. 积极主动地将各种观点和意见纳入决策。
5. 为每个团队成员提供平等机会，包括获得渠道、资源和支助。

处理分歧​

1. 促进有关各方之间公开和富有成效的沟通。
2. 将冲突作为加强团队合作和改善当前解决方案的一种方式。
3. 澄清冲突的根源（以及是否确实存在冲突）
4. 让每一方有平等的时间发表自己的看法和担忧而不作出判断(假定是积极的意图)。 如果需要设置基本规则来培养积极的倾听和理解。 将对话从情绪中引向解决方案。 巧妙地解决无益的对话。
5. 总结和验证各方的立场，反思他们的观点。
6. 确定不同立场之间冲突的根本原因。
7. 集思广益，捋顺现有的选项，以最好地满足共同目标。 (找到共同基础的技巧和逻辑)。 使用数据和事实与他人一起驱动解析，权衡利弊，而不是仅仅依靠意见。
8. 商定最佳解决办法，并确定每一方的责任。 召集有关各方支持决议。

提出有建设性的反馈意见。​

1. 私下给出反馈意见。
2. 提醒他们你已经欣赏他们的东西。
3. 描述直接观察到的（而不是推断的）、可以改变的具体行为，例如 "没有研究文件 "与 "没有准备"。
4. 描述上述行为的影响。
5. 指出它是一个成长的机会，而不是一个错误。
6. 提供解决方案。

示例故事​

虽然看起来有大量的所需特征，但你可以用工程团队中非常常见的情况来覆盖其中的 90%：

• 你必须在一个跨职能的团队中工作（例如与商业利益相关者或产品经理或设计师），在一个高压的情况下，优先事项和要求迅速变化。
• 商业/设计和工程之间存在利益冲突，例如商业/设计推动（要求）更严格的最后期限，而从工程的角度来看，急于追求这些最后期限将导致大量的技术债务。
• 你必须就这个问题向商业/设计提供建设性的反馈。
• 在这样做时，你需要将技术概念传达给非技术受众。
• 此外，你还征求了他们的反馈意见，以了解工程如何能够更好地合作，避免再次出现这个问题。 这样做， 你定期与他们一起讨论需求或要求的清单，以查看是否可以放弃任何需求以加快工程交付。 此外，你通过提供定期更新，满足了他们对时间轴问责制的需求。

根据您的情况在具体细节中添加。

情况​

• 在我目前作为开办阶段的前端工程师的工作中，我不得不领导一个非常紧迫的营销项目的发展。 在功能上与营销和设计相交叉。
• 在某种程度上，市场部曾预计该功能将在下周内发货，但由于对合作伙伴的 API 团队的依赖，工程部出现了重大障碍，该团队的交付成果由于最近两名高级成员的离职而被推迟。
• 这种情况变得更加激烈，因为市场部不理解工程部所面临的障碍。

任务​

• 我必须解决这个误解，以确保两个团队之间的工作关系顺利。

行动​

• 为了这样做，我私下和市场部谈过，让他们有时间清楚地解释紧迫性以及市场部对工程部可能存在的担忧或误解。
• 然后，我解释了合作伙伴团队的作用，特别关注他们对该功能的影响，而不是复杂的技术信息。
• 在这样做的过程中，我们能够集思广益，想出不同的方法，即使没有外部的依赖性，我们也可以交付这个功能。
• 同时， 我还与伙伴小组的经理谈到该项目对公司的重要性以及重新安排其工作的优先次序以帮助我们解除障碍的可能性。
• 除此之外，我还征求了关于工程部如何能够更好地与市场部合作的反馈意见，以避免今后发生这种误解。

结果​

• 由于工程部和市场部之间的紧密合作，我们能够及时地交付该功能。
• 随着市场营销对时间表和问责制的优先考虑，我们开始定期提供更新，并讨论了每一个潜在的阻碍因素的替代方案。
• 有了这一点，每项功能都在之后成功地顺利交付。

后续问题的可能性质​

正如我们的行为面试准备概述中所提到的，鼓励面试官更多地依靠后续问题来真正了解候选人的思维过程和动机，这些问题通常属于这些类别：

• 你为什么认为你做了(行为)？
• 你为什么不做(行为)？
• 事后看，你会如何以不同的方式做事？

对于有关合作的问题，面试官很可能会探询一些问题，以帮助他们了解更多的情况：

• 了解某些利益攸关方是否以及为何参与或不参与
  • 哪些利益攸关方参与了讨论，以及为什么？
  • 为什么某些利益攸关方如(某某) 被排除在群组之外？
• 了解群组动态以及它如何影响处理群组的策略
  • 小组中存在哪些个性，它是如何影响动态的？ 这种理解是否影响了你驾驭小组讨论的策略？
• 理解候选人对冲突的心态
  • 你认为这样的冲突如何影响到工作环境？ 你想要避免他们吗？
• 了解决议是如何产生的；候选人是否只是服从他人，而不是依赖事实和数据？
  • 在做决定时，是否有任何数据和信息被利用？
  • 是否对每一种解决办法的利弊进行过分析？

合作问题和答案示例​

上面的故事样本已经回答了上面的大部分（12 个）例子问题。 需要稍加修改的问题将在下文阐述。 如果你还没有，请查看我们的面试处置技巧，以增加你给人留下好印象的机会。

你如何确保你的信息被受众理解并得到很好的接受？​

你可以在回答这个问题时对样本故事稍作修改，重点放在技术信息的解释上：

为了确保我的信息被充分理解，在解释之后，我会提供一些例子来说明我的观点，同时也会向听众提出一些问题，以确认他们的理解。 在我几个月前做的一个项目中，我不得不向业务团队解释为什么一个紧急功能被外部团队的 API 延迟了，以及如何延迟的。 为了做到这一点，我把重点放在企业需要的关键收获上--也就是该功能是如何被这种延迟所影响的，并利用视觉辅助工具以及使用简单清晰的语言。 我还举了一些例子，同时提出问题以确定他们对我的解释的理解。 这使得业务团队能够很好地理解依赖性，从而集思广益，即使没有外部依赖，也能够交付功能。

你如何处理与那些没有在最后期限或职责范围内完成工作的队友合作？​

一旦发现他们的行为可能构成一种令人担忧的模式，我会及时让他们知道。 例如，我在一个项目中的一个队友经常错过修复错误的时间，一旦发生了多次，我就安排与他私下会面，与他们讨论这个问题。 我把重点放在把谈话框定在对他来说是一个成长的机会，在他们已经被赞赏的基础上，也就是他作为一个高级开发人员的知识和指导作用。 而不是描述诸如“过迟”之类的一般行为，我提到了被遗漏的具体票据和遗漏票据所产生的影响，以及对团队士气的影响。 然后我提供了一些解决方案，例如在渠道内为即将到期的票据制定一个新的提醒机器人。 他能够理解我的想法，在那之后，我们的团队能够更好地满足我们的最后期限。