Meta 与PM协作：问题定义、技术取舍和反馈

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 只用本人实际经历，明确自己的动作与团队共同成果；训练情境是回答结构示例，不是可以冒充的履历。
• 结果指标包含基线、观察窗和来源，区分相关变化与能归因于本人的效果。

解题路线

1. 先确认用户问题与成功指标，PM负责产品判断但技术可行性和风险需工程主动提供证据。
2. 将需求分核心目标/实现建议/约束，避免把PM给的第一种方案当不可讨论的唯一实现。
3. 提出替代范围与迭代路线，说明代价、测量和用户影响；用原型或数据帮助取舍，不只报“做不了”。
4. 上线后按共同指标复盘，区分实现完成与用户问题解决；反馈落到下一版优先级。

手动走一遍

练习情境：PM想全量实时搜索，团队先验证用户需要是秒级新帖还是历史精确结果，提出延迟可见的可用第一版与强一致例外，明确文案和验收。

规模与取舍

先给约90秒主线，再按追问展开决策、技术细节、协作人数、时间跨度和结果证据。规模只填写真实用户/团队/数据量，敏感内容可脱敏；未知数字说明缺口，不编造提高比例。

易错点与追问

容易失分的边界

• 把PM描述为不懂技术而否定需求，会掩盖自己缺少问题澄清。
• 只承诺技术实现，没有共同验收与用户反馈。

继续深挖

• 如果PM坚持高风险日期，你如何给可选路径并确认风险owner？
• 你曾经因用户证据改变自己的技术偏好吗？给具体决策。