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