207 lines
13 KiB
Plaintext
207 lines
13 KiB
Plaintext
---
|
||
title: 回答协作行为问题
|
||
description: 了解如何回答用于评估您的协作技能的“告诉我一个时间……”风格的问题。
|
||
seo_title: 协作问题 | 行为面试手册
|
||
seo_description: 了解如何回答协作行为面试问题，适用于前端工程师。参考示例答案。
|
||
social_title: 协作行为问题 | GreatFrontEnd
|
||
---
|
||
|
||
正如我们在 [行为面试准备概述](/behavioral-interview-guidebook) 中提到的，**协作**是需要准备的 8 个主要问题类别之一。
|
||
|
||
协作问题可能是前端行为面试中最常见的行为问题，因为它们包含大量相关的特质，这些特质可以分组以便于故事/项目准备。
|
||
|
||
在本指南中，您将学习如何解决这些问题：
|
||
|
||
1. 详细的评估标准
|
||
2. 将可能的问题抽象成常见主题
|
||
3. 建议的答案框架
|
||
4. 一个好的示例故事
|
||
5. 追问的可能性质
|
||
6. 示例问题和答案
|
||
|
||
## 详细的评估标准
|
||
|
||
在对该类别下的候选人进行评分时，面试官通常会关注以下标准：
|
||
|
||
* 处理分歧
|
||
* 团队合作
|
||
* 与不同个性和技能的人合作
|
||
* 简单地传达复杂的想法
|
||
* 给予建设性的反馈
|
||
* 积极倾听
|
||
|
||
## 抽象协作问题
|
||
|
||
正如我们在 [行为面试准备概述](/behavioral-interview-guidebook) 中提到的，为每个现有的行为问题专门准备答案是不切实际的。但是，通过将特定问题归入**相似的主题**并准备涵盖大量问题要求的故事情节，我们可以将需要准备的故事数量减少到大约 3-5 个故事。
|
||
|
||
协作是这样一个主题，它可以将沟通、团队合作、适应性和可教练性等子要求组合在一起。对于每个子要求，我们总结了常见问题，并抽象出了**面试官在这些问题中寻找的特质**：
|
||
|
||
### 沟通
|
||
|
||
#### 示例问题
|
||
|
||
* 您能否描述一下您必须有效地向非技术受众传达技术信息以及您如何处理这种情况？
|
||
* 您能否描述一下您必须调整您的沟通方式才能有效地与具有不同背景或观点的人进行沟通的情况？
|
||
* 您能否举例说明您必须在时间压力或高压情况下传达重要信息的情况？
|
||
* 您如何确保您的信息被受众理解和接受？
|
||
|
||
#### 面试官寻找的特质
|
||
|
||
* 简单地传达复杂的想法
|
||
* 积极倾听
|
||
|
||
### 团队合作
|
||
|
||
#### 示例问题
|
||
|
||
* 您能否描述一个您不得不与难以相处的利益相关者或队友合作的过去项目，以及您是如何处理的？
|
||
* 您能否告诉我您不得不向团队成员或同事提供建设性反馈的经历？
|
||
* 您如何与未能按时完成任务或履行职责的队友一起工作？
|
||
* 您能否提供一个您不得不与团队合作的例子，团队成员之间存在分歧？
|
||
* 您如何处理与拥有不同技能和个性的团队成员一起工作？
|
||
* 您能否举例说明您不得不适应团队成员的工作方式才能成功完成项目的情况？
|
||
* 您如何确保所有团队成员都能被听到，他们的想法在小组讨论中得到考虑？
|
||
* 您能否举例说明您不得不参与团队项目并与他人妥协以达成解决方案的情况？
|
||
* 您能否描述一下您不得不与来自不同部门或组织的人员合作以完成项目的情况？
|
||
|
||
#### 面试官寻找的特质
|
||
|
||
* 团队合作
|
||
* 与不同的工作方式、技能和个性合作
|
||
* 处理分歧（他人和自己）
|
||
* 提供建设性反馈
|
||
|
||
## 建议的回答框架
|
||
|
||
与往常一样，我们推荐 [STAR 格式](https://www.indeed.com/career-advice/interviewing/how-to-use-the-star-interview-response-technique) 作为构建您故事的最简单、最有效的框架。
|
||
|
||
基于上述抽象，我们可以看到，面试官正在寻找每个子要求的特定特征。我们创建了一个快速备忘单，用于建议展示这些期望特征的方法。
|
||
|
||
理想情况下，您应该选择能够涵盖尽可能多的以下特征的故事，这样您就不必记住太多的故事。
|
||
|
||
### 简单地传达复杂的想法
|
||
|
||
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 团队，工程部门遇到了重大障碍，该团队的交付由于最近两名高级成员的离职而延迟。
|
||
* 这种情况变得激烈，因为营销部门不了解工程部门面临的障碍。
|
||
|
||
#### 任务
|
||
|
||
* 我必须解决误解，以确保两个团队之间的工作关系顺利。
|
||
|
||
#### 行动
|
||
|
||
* 为了做到这一点，我私下与营销部门进行了交谈，并给他们时间清楚地解释营销部门可能对工程部门的紧迫性、担忧或误解。
|
||
* 然后，我解释了合作伙伴团队的作用，重点是他们对该功能的影响，而不是复杂的技术信息。
|
||
* 在这样做时，我们能够集思广益，讨论即使没有外部依赖关系，我们也可以发布该功能的各种方法。
|
||
* 与此同时，我还与合作伙伴团队的经理讨论了该项目对公司的重要性以及重新调整其工作优先级的可能性，以帮助我们解除障碍。
|
||
* 除此之外，我还征求了关于工程部门如何更好地与营销部门合作以避免将来出现此类误解的反馈意见。
|
||
|
||
#### 结果
|
||
|
||
* 由于工程部门和营销部门之间的紧密合作，我们能够及时发布该功能。
|
||
* 由于营销部门优先考虑时间表和问责制，我们开始提供定期更新，并讨论了每个潜在障碍的替代方案。
|
||
* 这样，此后每个功能都成功顺利地交付了。
|
||
|
||
## 可能的后续问题性质
|
||
|
||
正如我们在 [行为面试准备概述](/behavioral-interview-guidebook) 中所暗示的那样，鼓励面试官更多地依赖后续问题来真正了解候选人的思维过程和动机，这些通常属于以下类别：
|
||
|
||
* 你认为你为什么做了（插入动作）？
|
||
* 你为什么没有做（插入动作）？
|
||
* 事后看来，你会如何做不同的事情？
|
||
|
||
对于关于协作的问题，面试官很可能会探究问题，以帮助他们更多地了解：
|
||
|
||
* **了解某些利益相关者是否参与以及原因**
|
||
* 哪些利益相关者参与了讨论，为什么？
|
||
* 为什么某些利益相关者（如（插入利益相关者））被排除在小组之外？
|
||
* **了解群体动态及其如何影响处理该群体的策略**
|
||
* 小组中存在哪些个性，它如何影响动态？ 这种理解是否影响了您驾驭小组讨论的策略？
|
||
* **了解候选人对冲突的心态**
|
||
* 您认为这样的冲突如何影响工作环境？ 您是否更愿意避免它们？
|
||
* **了解解决方案是如何产生的； 候选人是仅仅听从他人，而不是依赖事实和数据？**
|
||
* 在做出决定时，是否利用了任何数据和信息？
|
||
* 是否对每个解决方案的优缺点进行了分析？
|
||
|
||
## 协作示例问题和答案
|
||
|
||
上面的示例故事已经回答了上面大多数（12 个）示例问题。 需要稍作修改的问题将在下面介绍。 如果您尚未这样做，请查看我们的 [关于面试倾向的提示](/behavioral-interview-guidebook)，以增加您留下良好印象的机会。
|
||
|
||
### 您如何确保您的信息被受众理解和接受？
|
||
|
||
你可以稍微修改一下示例故事来回答这个问题，重点解释技术信息：
|
||
|
||
> 为了确保我的信息被很好地理解，在解释之后，我将提供一些例子来说明我的观点，并向听众提出一些问题来确认他们的理解。 在几个月前的一个项目中，我不得不向业务团队解释为什么以及如何由于外部团队的 API 延迟而导致紧急功能被延迟。 为此，我重点关注了业务团队需要了解的关键内容——即该功能如何受到这种延迟的影响，并利用视觉辅助工具以及简单明了的语言。 我还举例说明，同时提出问题以确定他们对我的解释的理解程度。 这使得业务团队能够很好地理解依赖关系，从而即使没有依赖关系，也能集思广益地交付该功能。
|
||
|
||
### 你如何与未能按时完成任务或履行职责的队友一起工作？
|
||
|
||
> 一旦明确他们的行为可能构成令人担忧的模式，我就会及时让他们知道。 例如，我有一个项目团队成员经常错过修复错误的期限，一旦发生多次，我就会安排与他进行私人会议，与他们谈论此事。 我侧重于将谈话框定为他在他已经受到赞赏的方面（即他作为高级开发人员的知识和指导）之上的一个成长机会。 我没有描述诸如“迟到”之类的普遍行为，而是提到了错过的具体票证以及错过它们所产生的影响，以及它对团队士气的影响。 然后，我提供了一些解决方案，例如在渠道内制定一个新的提醒机器人，用于即将到期的票证。 他能够理解我的出发点，并且在那之后，我们的团队能够更好地按时完成任务。
|