1 引子

有幸拿到了宝洁 IT 的社招 offer，也是第一次接触到宝洁八大问这样软实力的相关东西，于是打算将其中搜集的一些资料和自身思考记录一下。

在网上搜索其他人的面经后，发现宝洁的面试流程为笔试 ->二轮技术面。笔试攻略可以去其他地方搜索下，本篇主要讨论二面中考察的八大问和工作场景题。

2 八大问

准备前：明确要准备的问题

先罗列下八大问的内容（重要程序递减，个人向排序）：

1. 领导力：请举例说明你在一项团队活动中如何采取主动性，并且起到领导者的作用，最终获得你所希望的结果。
2. 高目标：举例说明，你如何制定了一个很高的目标，并且最终实现了它。
3. 划定关键点：请详细描述一个情景，在这个情景中你必须搜集相关信息，划定关键点，并且决定依照哪些步骤能够达到所期望的结果。
4. 说服力：举例说明你是怎样用事实促使他人与你达成一致意见的。
5. 团队合作：举例证明你可以和他人合作，共同实现一个重要目标。
6. 问题决策：请举例，你是怎样评估一种情况，并将注意力集中在关键问题的解决。
7. 创新力：举例证明，你的一个创意曾经对一个项目的成功起到至关重要的作用。
8. 学习能力：举例说明你怎样获得一种技能，并将其转化为实践。

如果你的时间有限，可以优先准备领导力和高目标的事例，如果是产品or运营岗可能还需要创新力的事例。一个事例可能会覆盖到以上多个问题（覆盖3-4个最佳），比如说：

• 担任项目 owner（领导力）：中间涉及带领成员推进项目（团队合作），制定任务排期（划定关键点），解决成员分歧（说服力）。
• 解决业务难题（高目标）：中间涉及制定解决方案（创新力，划定关键点），运用新技术来解决难题（学习能力）。
• 学习新技术（学习能力）：中间涉及指定学习目标（划定关键点），决定学习内容的优先级（问题决策）。

针对你准备的每个事例，可以再思考几个子问题：

• 从这件事例中你收获了什么？
• 在这件事例中你做得好的方面是什么？还需改进的方面是什么？

准备中：What + STAR

在准备事例的时候，推荐使用 What + STAR 原则的结构进行准备，并且使用思维导图，像下图所示：

What 是指用简短的一句话概括你做的事请及成果，先让面试官对你接下来陈述的内容有个大致印象，也避免了陈述中途被打断，导致没有说出事例成果这样的尴尬局面。

STAR 法则用来描述事例的始末：在什么样的背景下(Situation)、接到了什么任务(Task)、为了达成任务做了哪些具体工作(Action)、最后结果是怎样的(Result）。

• Situation（背景）：交代当前现状和为什么要做这件事
• Task（目标）：需要解决的痛点，列出 Todo List。
• Action（行动）：需要重点强调的部分，需要占到整体篇幅的60%左右，表明你在事例中担任的角色和具体工作内容。
• Result（成果）：事例完成后带来的收益，指标提升/人效降低/获奖。

注意事项：

• 事例经历越靠近越好，好汉不提当年勇。
• 每个问题的事例最好准备两个，面试官有可能会让你再举一个例子。

事例示例

在书写事例的时候，可以把自己想象成面试官，多进行追问。

事例中一般都会涉及工作场景题中的情景，解决方式在下一章节再展开。

系统建设

应对问题：高目标、创新力、划定关键点、学习能力。

追问：

• 如何体现这是高目标？（最好需要有对比）
• 技术选型是如何做的？
• 系统优化时，是如何收集反馈的，有没有nps(净推荐值)之类的指标？
• 性能优化前后有没有量化指标对比？

担任项目 owner

应对问题：领导力、说服力、团队合作。

追问：

• 项目开展遵循的大致流程。
• 如何保证项目的顺利推进？
• 发生分歧时无法说服对方，如何处理？
• 项目上线后不如预期，如何处理？

对于没工作经历的同学，可以考虑校园经历：做小组作业，组织校园活动，下面给出一个担任游园会活动 owner 的示例。

3 工作情景题

针对上面事例中遇到的一些场景问题，需要进行解决，下面对一些经典问题和解决方式进行整理。

注意事项：

• 场景题一般是英文提问，同时也需要英文作答，善用翻译软件（逃）。
• 各个情景题并不是完全独立的，互相也会有相通的地方，需要融会贯通。

项目 DDL 提前/延期，如何处理

• 事前：在项目开始前，就需要做好项目排期管理。
• 确定项目重要节点，定期检查各端的开发进度，遇到进度受阻提前预警。
• 估计工期时就预留 buffer，就算发生突发情况，也有时间进行缓冲应对。
• 事中：
• 当 DDL 提前/延期发生，需要查明原因：
• DDL 提前：
• 如果是供应链出问题，能否加急增加人手解决，或者准备plan B。
• 如果是质量法规之类的红线问题，不建议提前 DDL，处理好之后再上线项目。
• DDL 延期
• 如果是对方手上有多个项目，其他项目优先级是否可以降低。
• 如果是对接团队无法按时交付，拉通对方 leader，寻求高优先级响应。
• 采取补救措施来赶项目进度：
• 协调内部资源，增加人手/加班来加速项目开发。
• 砍项目非核心需求，先交付最重要的部分，剩余的部分二期迭代再补上。
• 找 leader 沟通，让其协助安抚甲方情绪并申请延期。
• 事后
• 复盘 DDL 提前/延期原因，输出复盘文档。
• 承担责任，安抚成员。

如果你推行新方案，但是同事/上司却不配合，如何推进

可以从两个维度分析：

• 对方不认可你这个人：先融入团队，在日常工作中认真负责，得到别人的认可和信任，之后再谈新方案。
• 对方不认可你的方案
• 继续细化项目方案，以结果为导向，给出项目带来的好处和前后预计的对比，并且给出详细且简单的方案执行计划，最好能够准备 PPT 进行输出。
• 收集对方不认可的理由，对方案进行适宜地修改。
• 承诺在方案执行过程中，会全程跟进，当出现问题会第一时间协助解决。

如果是同事不认可，也可以跟 leader 沟通，看 leader 对方案的认可度和建议，并征求在周会或部门会议介绍新方案，靠 leader 的影响力帮助你推动。

和别人产生分歧，如何处理

• 首先平复自身情绪，分析原因，自己意见是否正确、可行。
• 如果是非原则问题，互相体谅，求同存异。
• 其次换位思考，分析对方意见是否正确、可行。
• 冷静分析后再尝试跟对方进行沟通，拉通双方信息。
• 如果是自己错误，及时放弃并承认错误。
• 如果是对方错误，先讨论是否有折中方案，然后尝试说服（可以叫上 leader 等第三方进行讨论）。
• 如果事情无关对错，看是否有折中方案，否则看哪方妥协。
• 项目开发时间短和项目开发内容多的冲突，考虑先上线项目核心内容，迭代开发剩余内容。
• 如果对方是上司，优先服从领导安排，按组织原则办事；事后进行复盘时可以再跟上司探讨。

如何处理多个任务的优先级

通过重要性和紧急性两个维度，可以把划分四个象限，它们的优先级排序为：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急。

重要性可以从以下几个维度进行判断：

• 核心：是否是系统的核心功能、核心接口迭代。
• 任务收益：当前任务的 ROI，有限资源下是否能对业务产生最大化收益。
• 团队：当前任务是否贴合当前团队的 OKR。
• 用户：是否影响大部分用户使用。

紧急性可以根据以下原则判断排序：

线上bug＞不解决会造成一定不良影响的问题＞短时间内可控，但长时间会有不良影响的问题＞解决后会有明显积极影响的问题

还有一些场景题，我也未找到合适的回答，在此抛出：

• 竞争对手上新了你半年后准备上的一款目标客群和定位都相同的产品，如何处理？
• 如果负责一个新项目，跟不认识的人完成不认识的业务，怎么办？
• 如果发现了项目重大漏洞，但项目已经开展了半年，应该说吗？
• 资源有限的情况下如何把项目做下去？

除了单个的情景题，还可能有组合拳，比如：和别人产生分歧，导致项目延期如何处理，需要糅合各问题的答案进行回答（苦笑）。

4 结语

在日常工作中，除了埋头做自己的项目，还需要多思考项目的来龙去脉，站在更高角度思考项目产生的价值，简言之就是在你 leader 的位置上想问题。