Mock的三条铁律
一句话总结
Mock不是演练，而是校准。第一条铁律：你的Mock对象决定了你能触达的真实水位，找错人等于在错误的坐标系里反复确认自己是对的。第二条铁律：Mock的反馈质量与你们之间的权力关系成反比，最值钱的点评往往来自没有利益纠葛的第三方。
第三条铁律：Mock的次数存在边际效用拐点，超过某个阈值后，表演性会替代真实性，面试官能嗅出这种"过度排练"的腐败气息。这三条铁律共同指向一个判断：大多数人对Mock的理解停留在"多练"的层面，而真正区分offer与拒信的，是你能否识别Mock的本质——它不是让你更熟练，而是让你更不可预测地真实。
适合谁看
正在准备硅谷一线科技公司PM面试的人。具体画像如下：已经过完简历关，进入onsite或virtual loop阶段；至少经历过1-2轮正式面试，拿到过"strong no-hire"或"lean no"的反馈；手头有3-5个Mock对象，但感觉"练了却没用"；对面试流程有基本认知，但说不清每一轮到底在筛什么。
如果你还在写简历，或者还没投出第一份申请，这篇文章对你太早。如果你是 hiring manager 正在设计面试流程，这篇文章对你太窄。目标读者的典型困境是：每周Mock两次，持续了六周，复盘时发现同一类问题反复出现，而Mock对象每次都只给表面建议。你需要的是判断——不是"多练"，而是"为什么练了没用"。
为什么多数Mock是在强化错误
不是练得不够，而是练的方向被默认设定锁死了。
我见过最典型的场景：候选人A在Google的朋友每周陪她Mock产品设计题。六周后她拿到正式面试，挂在了同一个题型上。Debrief时面试官的评语是："她的框架太像Google内部培训材料了，像是在背答案。
"问题出在哪？Mock对象是她朋友，朋友用的是Google PM的标准解法，她练的是"像Google PM那样答题"，而面试官在找的是"这个人怎么真正思考"。
这就是第一条铁律的残酷性：Mock对象的水平天花板，就是你的真实天花板。不是说他水平低，而是他的"正确"会压缩你的探索空间。
你Mock时听到的最多的是"这里应该加个success metric"，于是你记住了"success metric"这个检查点，但你没理解的是：在什么场景下不提success metric反而更好。Google的资深面试官在hiring committee讨论中经常争论的一个点正是这个——候选人是否展现出了"在约束条件下取舍"的能力，而不是"把所有检查点都跑一遍"的勤勉。
第二个被忽视的维度是权力关系。你请在职PM Mock，他给你反馈时已经预设了"我是对的"——这不是他的错，是角色使然。但最有价值的反馈往往来自另一种关系：对方懂行，但无所谓你挂不挂。
我见过最有效的Mock发生在两个候选人之间：他们都刚面完Facebook没过，互相拆解时发现，彼此倒在完全不同的地方。这种"同侪诊断"的锋利度，远超一个在职PM出于善意给出的泛泛建议。
第三条铁律关于次数。某候选人在Meta onsite前Mock了27次，计时、录屏、逐字复盘。正式面试时他在System Design轮被给了no-hire，反馈是："他的回答太polished了，像是排练过100遍，我追问一个他没准备过的corner case，他完全僵住。
"这就是拐点——当Mock从"模拟真实"变成"追求确定性"，你就开始培养一种表演型人格，而好的面试官专门猎杀这种人格。不是"练得越多越好"，而是"练到你能自然应对意外为止"。那个点通常在8-12次高质量Mock之后，因人而异，但27次明显过了。
> 📖 延伸阅读：AI Agent vs传统微服务设计面试对比：状态机与工具调用模式
铁律一：Mock对象决定水位
不是找更厉害的人，而是找"对"的人。
硅谷PM面试的隐性结构是这样的：每一轮有明确的考察维度，但同一维度在不同公司的权重和问法截然不同。Google的PM面试手册里，System Design轮评估的是"technical depth + product sense的交叉点"，而Meta的同类型轮次更看重"speed of iteration + willingness to ship imperfectly"。
如果你Mock对象全是Google的，你练出的肌肉记忆在Meta可能是负分。
具体场景：一个典型的hiring manager对话。候选人B的recruiter转述HM的原话："他在Product Sense轮的表现让我犹豫——他一直在等我的反馈才往下走，像是在寻求批准。我需要的是能push back的人。
"B的Mock对象是一位Google L6 PM，那位PM的Mock风格是"我来纠正你"，于是B养成了"先抛想法再看眼色"的习惯。这不是Mock对象的错，是B没有意识到：Mock对象的interview风格正在被内化成自己的风格。
正确的Mock对象配置应该像投资组合：30%来自目标公司的在职PM（了解真实考察点），30%来自同类型公司的近期候选人（了解当下趋势），30%来自完全无关领域的资深人士（打破路径依赖），10%留给录音后的自我复盘（没有人，只有你自己）。
不是"找个Google的就行"，而是"这个Google的PM有没有能力且愿意告诉你，Google内部已经淘汰的旧框架是什么"。
一个具体的BAD vs GOOD对比：
BAD：Mock结束后，对方说"你框架挺完整的，就是metric部分可以再想想"。你记下"metric"，下次面试前背了20个metrics。
GOOD：Mock结束后，对方问"你为什么假设这个feature一定能提高retention？如果它反而 cannibalize 了现有功能呢？"你愣住，然后真的去想了。下次面试，当面试官抛出类似challenge时，你的反应不是"我背过这个"，而是"让我想想"——这个停顿本身，就是hiring committee在找的信号。
铁律二：反馈质量与权力关系成反比
不是反馈越多越好，而是"谁给的"比"说什么"更重要。
大多数Mock陷入的一个误区是：把反馈当成可累加的物品。这周收集了5条，下周再收集5条，仿佛20条就能兑换一个offer。实际上，反馈的效力取决于给出者与你的关系结构。
我亲历过一个debrief会议的真实对话。面试官1："候选人C的Mock背景很强，她朋友是Uber的PM，她用的框架很标准。"面试官2："但这正是问题——她的回答没有个人痕迹，像是被过度打磨过。"Hiring manager插话："你们注意到她第二轮和第五轮的回答结构几乎一样吗？
连'that's a great question'出现的节点都相同。"全场沉默。这就是Mock过度结构化的后果：一致性变成了可预测性，而可预测性在高级别面试中是致命的。
与之相对，我见过最有价值的反馈来自一种"弱关系"Mock。候选人D在准备Netflix面试时，找了一位前产品经理，此人已转做VC，对D的面试结果没有任何利害关系。
他们的Mock对话是这样的：VC听完D的product design回答，沉默了很久，然后说"你刚才说的每一个点都是对的，但如果是Netflix的HM，他现在在想'这个人会怎么和我的engineer吵架'，你完全没展示这个。"D后来调整了策略，不是展示"我多会设计产品"，而是展示"我怎么在约束条件下做艰难决定"——这正是Netflix那轮通过的关键。
不是"找资深的人给反馈"，而是"找对你没有预期zzle-down motivation的人给反馈"。资深但希望你进Google的人，会不自觉地让你更像Google PM；资深且无所谓你去哪的人，才会指出"你现在的样子在Google可能过，但在Amazon会挂"这种跨公司视角。
> 📖 延伸阅读：简历逆向工程 vs 传统简历写作：创业CTO职位比较
铁三：存在边际效用拐点
不是"越多越好"，而是"过了那个点，你在训练表演"。
具体数字：硅谷一线公司PM面试的完整流程通常是5-7轮，每轮45-60分钟。Product Sense/Design轮通常45分钟，System Design轮60分钟，Behavioral轮45分钟，Analytical/Metrics轮45分钟，Leadership/Culture Fit轮45分钟。
整个loop可能横跨两天或一个全天。Mock的目标是让你在这个时间压力下保持认知弹性，而不是让你把答案打磨到像播音。
拐点出现的信号是什么？候选人E的案例很典型。他在Meta onsite前Mock了15次，前8次每次都有实质性进步——框架更紧凑了，metric更具体了，time management更好了。第9到第12次，进步曲线扁平化。
第13次开始，他的Mock对象（一位Amazon L7）指出："你现在的回答像是在播放录音，我打断你时你明显在找对应的章节。"这就是拐点。他没有停下来，又练了5次，正式面试时遇到面试官的一个非常规追问（"如果这个feature只能做给1%的用户，你的设计会怎么变？"），他的第一反应不是思考，而是焦虑"这个不在我的题库中"——这个微表情被捕捉到了。
不是"Mock到完美"，而是"Mock到能容忍不完美"。正确的版本是：Mock到你能在一个从未见过的问题上，用30秒组织出一个"足够好"的答案，然后花剩下的时间展示你如何迭代它。面试官在找的不是"正确答案"，而是"这个人面对不确定性时的思维质量"。
一个具体的操作标准：记录你Mock时的"意外时刻"比例。如果10次Mock中，面试官的追问有8次你能预判到，你需要换Mock对象了。理想的比例是：你经常需要真的想一想，而你的"想一想"过程本身，就是面试要考察的内容。
准备清单
- 搭建Mock对象组合：1位目标公司在职PM（了解当下考察重点）、1位同类型公司近期候选人（了解竞争水位）、1位跨领域资深人士（打破思维定式），比例按铁律一配置，避免单一来源依赖
- 每次Mock后强制追问一个问题："这个反馈如果反过来做，会是什么情况？"——逼出对方真正的判断边界，而非安全建议
- 系统性拆解面试结构，PM面试手册里有完整的Google/Meta/Amazon多轮实战复盘可以参考——不是要你照搬，而是建立"面试官在这一分钟真正在看什么"的肌肉记忆
- 设置Mock次数上限：高质量Mock不超过12次，超过后强制转入"压力测试模式"—— Mock对象随机打乱题型顺序、中途插入打断、最后5分钟临时换题
- 录制至少3次Mock视频，间隔一周以上回看：寻找"表演痕迹"——固定口头禅、相同的手势、模板化的转折词，这些是高频率Mock的副产品，需要主动清除
- 在正式面试前48小时停止所有新题Mock，只做旧题复盘：不是练反应，而是让大脑从"搜索模式"转入"整合模式"
- 准备一份"不可预测性清单"：列出你作为候选人最独特的3个经历或视角，确保在Behavioral轮至少触发一次，让面试官意识到"这个人不是标准产品"
常见错误
错误一：把Mock当成"模拟考试"而不是"诊断工具"
BAD：候选人F每周Mock两次，每次完整走流程，打完分就结束。六周后他发现自己的"product design"分数始终稳定在7/10，但不知道为什么到不了9。他的应对是：继续Mock，期待量变引起质变。
GOOD：候选人G在第三次Mock后暂停，花了整整一个周末分析"这三次我问面试官要feedback时，对方犹豫的瞬间"。她发现犹豫集中在同一个问题："你的solution和竞品的区别是什么？"她意识到这不是一个知识缺口，而是一个勇气缺口——她害怕承认自己的设计有借鉴成分。针对性解决后，下一次Mock这个问题直接消失。
错误二：Mock对象单一化，导致"口音"固定
BAD：候选人H的所有Mock都找的一位Apple PM。他的回答逐渐苹果化：重硬件体验、轻数据驱动、强调craftsmanship。申请Netflix时，面试官的反馈是："他的产品直觉不错，但似乎不理解我们的决策逻辑——为什么不做A/B test就 ship？"
GOOD：候选人I的Mock对象横跨Google（数据驱动）、Stripe（API设计敏感度）、以及一位前创业公司CEO（资源约束下的取舍）。他的回答没有固定"口音"，但能在任何语境中快速调取对应框架。
正式面试Amazon时，他主动提到"这个场景下Google会这么做，但考虑Amazon的flywheel，我会选择..."——这种跨公司视角是hiring committee的高分信号。
错误三：追求Mock的"舒适感"而非"不适感"
BAD：候选人J选择Mock对象的标准是"聊得来、气氛好"。他的Mock过程愉快，反馈温和，每次结束都有"我又进步了一点"的错觉。正式面试Amazon的bar raiser轮时，对方连续追问12个why，他在第7个时崩溃。
GOOD：候选人K专门找了一位以"tough"著称的Mock对象，第一次Mock后觉得"被扒了一层皮"。但她的反馈精准指出了K在"defend your decision"环节的脆弱性。后续三次Mock刻意强化这个场景，正式面试时遇到同等强度的challenge，K的反应是微笑——不是轻松，而是"终于来了"的那种熟悉感。
FAQ
Mock时对方说"你回答得挺好的"，这算有效反馈吗？
不算，而且这是最常见的无效反馈形态。这句话的潜台词往往是"我不想花精力深入"或"我不知道该怎么具体说"。真正有效的反馈必须包含两个要素：具体的行为切片（"你在第12分钟提到user segment时，我作为面试官在等你的quantification，但你跳到了next step"），以及可验证的替代方案（"如果你当时说'假设这个segment是DAU的15%，那么...'，我会更清楚你的 prioritization 逻辑"）。
候选人L的经历是典型反例：他的Mock对象连续五次都说"挺好的"，他误以为稳定，直到正式面试挂掉后复盘，才发现自己的回答始终缺少"量化锚点"。建议你在Mock开始时明确约定反馈格式："请在我回答的每个决策点，标注你作为面试官的期待值和实际观察到的差距。"这不是挑剔，是对双方时间的尊重。
我应该Mock到面试前最后一刻吗？
不应该。面试前48小时的大脑状态比任何一次Mock都重要。候选人M的教训：他在Google onsite前一天晚上还在Mock新题，结果正式面试时大脑处于"搜索模式"——不是在思考当前问题，而是在检索"这个题像哪道Mock题"。真正起作用的Mock发生在面试前3-7天，那时你有时间消化、整合、让模式转入潜意识。
最后48小时应该做三件事：睡觉、轻度复习旧题（不新做）、以及准备一两个"个人故事"确保鲜活度。一个检验标准：如果你能在和朋友吃饭时，把面试要用的框架用非专业语言讲清楚，说明整合完成了；如果还需要翻笔记，说明Mock的密度过高，需要主动降温。
Mock对象没有目标公司经验，还能用吗？
能，而且有时候必须用。目标公司在职PM的局限在于：他们离流程太近，容易把"当前做法"当成"唯一正确做法"，而面试考察的往往是更底层的元能力。候选人N准备Uber面试时，Mock对象是一位Fintech背景的PM，完全没做过打车产品。但正是这位PM在Mock中追问了N从未想过的问题："你的定价模型如果用在Uber Eats上，哪个变量会最先崩？
"这个问题迫使N从"Uber打车PM"的身份抽离，看到更底层的经济学结构——而这个视角，恰恰是Uber面试官在找的"能跨场景迁移的产品思维"。判断一个非目标公司Mock对象是否值得继续的标准：他是否能在你的回答中引出"真正的 surprise"——不是纠正你的知识，而是拓展你的思维边界。如果有，继续；如果只是泛泛鼓励，果断替换。
薪资参考框架（以硅谷一线公司L4-L6 PM为例）：
- Google：Base $140K-$180K，RSU $80K-$200K/年（4年vest），Bonus 15%-20% target
- Meta：Base $130K-$170K，RSU $100K-$250K/年（4年vest），Sign-on $10K-$50K，Bonus 10%-15% target
- Amazon：Base $130K-$160K（西雅图上限，加州略高），RSU按年份递增（典型5%-15%-40%-40%），Sign-on两年总包$30K-$80K，没有传统bonus
- Netflix：Base $200K-$400K（全现金包，无RSU），无bonus，无sign-on，总包即base
- Uber：Base $140K-$180K，RSU $60K-$150K/年，Bonus 15%-20% target，Sign-on $20K-$50K
面试流程拆解（以Google PM为例，7轮，通常分两天或一天完成）：
- 第一轮（45min）：Product Sense — 考察"从0到1"的模糊问题处理能力，典型题"设计一个给老人的产品"
- 第二轮（45min）：Product Execution/Metrics — 给定产品数据，诊断问题并提出方案，考察analytical rigor
- 第三轮（45min）：Behavioral/Leadership — "tell me about a time"，考察googleyness和conflict handling
- 第四轮（45min）：System Design — 非纯技术，而是"设计一个系统的product层面"，考察technical breadth
- 第五轮（45min）：Strategy — 行业趋势、竞争分析、长期产品方向，考察strategic thinking
- 第六轮（30min）：Googliness/Culture — 轻松对话，但Bar Raiser在场，任何red flag都会被记录
- 第七轮（30-45min）：Hiring Manager — 双向匹配，HM在评估fit的同时也在sell
Meta、Amazon流程结构类似，但轮次命名和权重不同：Meta更重speed和willingness to experiment，Amazon更重leadership principles的系统性引用，Netflix的"面试"可能长达一整天且多为senior peer interview而非标准loop。
Mock时必须针对目标公司的轮次结构调整准备重心，而非一套答案走天下。
Mock的三条铁律，最终指向同一个判断：你不是在练习"答对"，而是在校准"你是谁"。水位由对象定，反馈由关系定，效用由次数定——这三者都不在你"更努力"的范围内，而在你"更清醒"的范围内。面试的本质不是淘汰赛，是匹配赛。Mock的作用，是让你在匹配发生前，先对自己诚实。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。