一句话总结
Supabase的PM面试不是考你会多少数据库概念，而是考你能否在30分钟内，向一群写代码的人证明：你比他们更懂用户为什么需要PostgreSQL的实时订阅功能，以及为什么这个功能值每个月多收15美元。
这不是一道技术题。这是一道判断题——面试官要在你的回答里听到：你知道什么该做、什么不该做、什么时候该停。90%的候选人输在第三点。
Supabase的产品逻辑和传统SaaS有本质区别。它不是卖一个工具给你，而是卖一个开发体验的“可能性”。你的product sense必须围绕这个核心运转。所有偏离这个核心的回答——无论多么流畅、多么有结构——都会在HC讨论时被标记为“缺乏产品直觉”。
你有没有遇到过这种情况：觉得自己答得还行，但面试官突然变脸？这背后的评分逻辑，《PM面试通关手册》里拆解得很透。
适合谁看
这篇文章写给三类人。
第一类是正在准备Supabase PM面试的候选人。你可能已经通过了简历筛选，或者被recruiter直接reach out，但你不知道product sense轮到底在考什么。你在网上搜到的都是“STAR法则”、“宝洁八大问”这种通用模板，它们在Supabase的面试室里毫无用处。
第二类是面过Supabase但挂在product sense轮的人。你可能觉得自己答得还不错——有框架、有数据、有竞品分析——但最后收到的结果是“方向不对”。你不知道问题出在哪里。这篇文章会告诉你，问题不在于你答得不好，而在于你答的东西根本不是Supabase想听的。
第三类是想了解Supabase这家公司产品逻辑的人。你不一定在面试，但你好奇为什么一个开源数据库公司能估值20亿美元，以及它的PM到底在做什么样的产品决策。这篇文章会从面试题的维度，拆解Supabase的产品哲学。
如果你不属于这三类，这篇文章对你没有价值。
我当时准备PM面试的时候把这些框架都整理在一份文档里。同时面5-6家公司的时候，集中看省下了很多切换成本。
Product Sense · Metrics · Behavioral · Strategy 四大题型系统攻略
Supabase为什么考Product Sense
在Supabase的5轮面试中，product sense是第二轮，也是分水岭。前面一轮是screening，recruiter问你为什么对Supabase感兴趣、你最常用的功能是什么——这是热身。product sense轮才是真正的筛选。
这不是Supabase独有的。Stripe、Databricks、Vercel这些开发者工具公司，都把product sense放在第二轮。但Supabase的考法有它的特殊性。
特殊性在于：你的面试官大概率是写代码的。
在Supabase的PM团队里，有相当比例的人是从工程师转岗的。他们问product sense问题的时候，思维模式不是“用户想要什么”，而是“用户说的这句话背后，代码层面到底发生了什么”。这不是说他们不关心用户——恰恰相反，他们对用户的理解是通过技术细节来完成的。
这就导致了一个关键差异：如果你在回答中使用了模糊的用户洞察，比如“开发者希望工具更易用”，他们会追问你“更易用具体指什么？哪个操作步骤？之前是多少秒，现在是多少秒？”如果你答不上来，你的回答在他们眼里就是无效的。
这不是在刁难你。这是在验证你的product sense是不是建立在真实的产品理解上，还是建立在一堆假设上。
在Supabase的语境里，product sense不是“用户导向思维”这种虚词。它是：你能否准确描述一个开发者在你设计的产品上，从打开浏览器到完成他想要的操作，这中间每一步发生了什么，以及他在每一步的心理状态是什么。
这就是为什么很多有消费产品背景的候选人会挂这一轮。他们习惯了“用户痛点→解决方案→价值主张”这种宏观框架，但 Supabase的面试官要的是微观层面的产品理解。你需要知道一个开发者使用Supabase的Realtime功能时，他的心态变化曲线——从“这能解决我的问题吗”到“这真的能work吗”到“这值得我花时间迁移吗”。
这不是学得来的。这是做产品做出来的。
> 📖 延伸阅读：Supabase PMoffer negotiation指南2026
面试流程拆解：每一轮考什么、考多久
Supabase的PM面试一共5轮，总时长大约6到8小时，分两天进行。
第一轮是recruiter screen，30分钟。这轮不考product sense，但它的结果会影响你后面两轮的难度。如果recruiter觉得你对Supabase的产品理解很深，会在notes里注明，hiring manager读到你的时候会有不同的预期。如果recruiter觉得你只是“海投”，后面问的问题会偏基础，你反而更容易过。这不是公平不公平的问题——这是信息传递的现实。
第二轮是product sense，45分钟到1小时。这是核心轮。面试官通常是senior PM或者product director。他们会给你一个具体的产品场景，让你做判断。场景可能是Supabase已有的功能，比如Realtime、Auth、Edge Functions；也可能是他们正在考虑但还没做的功能，比如新的定价层级、新的集成。关键不在于你给出什么答案，而在于你给出答案的过程。
第三轮是technical depth，45分钟。这轮不是让你写代码，而是让你解释技术决策。面试官会问你：如果让你设计Supabase的数据库连接池，你会怎么做？为什么要用PgBouncer而不是自己写？这些问题考察的是你能不能和工程师进行有效沟通。在Supabase，PM如果不能理解PostgreSQL的架构，连daily standup都参加不了。
第四轮是cross-functional collaboration，45分钟。这轮会模拟一个跨部门冲突场景。比如：工程师说某个功能做不了，sales team已经答应客户两周后上线，你作为PM怎么办？或者：marketing要做一场发布会，需要新功能支持，但engineering说至少需要6周，你怎么协调？这一轮考察的是你的谈判能力和优先级判断能力。
第五轮是hiring manager wrap-up，30分钟到45分钟。这轮通常是收尾的behavioral interview，但hiring manager会在这轮给你一个“反向提问”的机会——让你问他一个问题，他来评估你问问题的质量。很多候选人在这轮放松警惕，结果踩坑。hiring manager会通过你问的问题，判断你对产品的理解深度和未来潜力。
每一轮都有明确的考察重点。product sense轮的核心是：你能多准确地描述一个产品决策的因果链条，以及你能否在信息不完整的情况下做出合理假设并验证。
核心题型深度解析：定价与商业化
在Supabase的product sense轮里，定价问题是出现频率最高的题型之一。这不是偶然的。Supabase的商业模式是开源核心+付费增值，定价策略直接决定了它的增长模型和用户分层。PM如果不懂定价，就无法参与公司最核心的战略讨论。
一道典型的定价题是这样的：Supabase现在有三个付费层级——Free、Pro、Enterprise。Pro是每月25美元，Enterprise是每月599美元。面试官会问你：如果让你增加一个Tier，你建议放在什么价格区间？这个新层级应该包含哪些功能？
这不是一道数学题。它是一道产品判断题。
错误的回答方式是：先做竞品对比，列出AWS DynamoDB、Firebase、PlanetScale的定价，然后说“我们应该比Firebase便宜10%，所以定价在每月35美元左右”。这种回答在HC讨论时会被标记为“缺乏独立判断”。
正确的回答方式需要分三层。
第一层是用户分层。你要先回答一个更根本的问题：谁会买这个新层级？是初创公司的小团队？是中型公司的开发团队？还是大企业的某个部门？不同用户群体的付费意愿和付费能力完全不同。如果你无法清晰地说出这个新层级是为哪一类用户设计的，后面的定价讨论就没有意义。
第二层是功能边界。新层级应该包含哪些功能，不是由“你觉得什么功能值多少钱”决定的，而是由“用户在使用过程中，哪个环节的摩擦最大”决定的。你需要描述一个具体的用户场景：一个开发者在使用Supabase时，遇到了什么具体问题，这个问题在当前层级无法解决，他必须升级到更高层级才能解决。这个场景必须具体到操作步骤。
第三层才是定价。定价不是成本加成，不是竞品对标，而是用户价值感知。你需要回答：用户愿意为解决这个问题支付多少钱？这个数字不是猜的——你需要给出推理过程，比如你之前在类似产品上的经验，或者你通过用户访谈获得的数据。
在HC讨论中，定价题的淘汰率很高。常见的原因是：候选人给出了定价，但没有给出定价背后的用户场景。面试官会认为这是“价格导向”而不是“价值导向”的产品思维，不符合Supabase的PM画像。
> 📖 延伸阅读：Supabase PMday in life指南2026
核心题型深度解析：竞争分析与差异化
竞争分析是另一类高频题型。但Supabase问竞争分析的方式，和大多数公司不同。
大多数公司问竞争分析，期望的答案是：我们的竞品是谁，他们做什么，我们和他们相比有什么优势。这种回答是静态的——它描述的是一个时间点的状态。
Supabase期望的答案是动态的：在一个具体的时间窗口内，竞争格局会如何变化，以及我们应该如何应对这个变化。
比如一道典型的竞争分析题：Google最近发布了Cloud Firestore的重大更新，增强了它的离线数据同步能力。Supabase的Realtime功能面临直接竞争。你认为Supabase应该如何回应？
错误的回答方式是：列出Firestore的新功能，对比Supabase的现有功能，然后说“我们应该尽快在Realtime里加入类似的离线同步能力”。这种回答在面试官眼里是“被动反应”——你在跟着竞品的节奏走。
正确的回答方式需要先回答一个更根本的问题：Firestore的这个更新，会影响Supabase的哪一类用户？
如果你分析的是使用Realtime做聊天应用的开发者，他们的痛点是消息的可靠性和顺序性，离线同步不是核心需求——他们更关心的是消息不丢、不乱序。在这种情况下，Firestore的更新对Supabase的影响很小，Supabase不需要做直接的功能对标。
但如果你分析的是使用Realtime做协作编辑的开发者，比如Figma、Notion这种实时协同工具，离线同步就是核心需求。在这类场景下，Firestore的更新确实构成了威胁。
关键在于：你能否准确识别出Firestore的更新到底影响了Supabase的哪一部分用户，以及这一部分用户在Supabase整体用户池里占多大比例。如果占比很小，你的时间应该花在更重要的地方。
这就是Supabase的竞争分析逻辑：不是看竞品做了什么，而是看竞品的动作会影响我们的哪一类用户，以及影响程度有多大。
在HC讨论中，竞争分析题的淘汰原因通常是：候选人做了全面的竞品分析，但没有给出优先级判断。面试官会认为这是“信息堆砌”而不是“产品判断”。
核心题型深度解析：产品决策与优先级
产品决策题是Supabase product sense轮的核心题型。它考察的不是你能不能找到一个正确答案，而是你能不能在信息不完整的情况下，做出一个合理的决策，并清晰地解释你的推理过程。
一道典型的问题是：Supabase的Edge Functions现在支持Deno和Bun两个运行时。Engineering团队资源有限，只能投入一个方向的优化。你建议优先优化哪个运行时？
这个问题没有标准答案。面试官想看到的是你的决策框架。
错误的回答方式是：先查一下Deno和Bun的市场份额，然后说“应该优化Deno因为它的市场份额更大”。这种回答是数据驱动的，但不是产品驱动的。市场份额是结果，不是原因。
正确的回答方式需要回到用户场景。你需要回答：什么样的开发者会使用Edge Functions？他们在什么场景下会关心运行时的性能？他们选择运行时的时候，最看重的因素是什么？
如果你分析的是使用Edge Functions做API网关的开发者，他们最关心的是冷启动时间。在这种情况下，Deno和Bun的性能差异不是关键——关键是Supabase的边缘基础设施能不能把冷启动时间控制在500毫秒以内。
如果你分析的是使用Edge Functions做SSR的开发者，他们最关心的是运行时对Node.js API的兼容性。Bun在这方面的兼容性好于Deno，所以应该优化Bun。
关键在于：你能否把你的决策锚定在一个具体的用户场景上，而不是锚定在抽象的市场数据上。
在Supabase的HC讨论里，产品决策题的淘汰原因通常是：候选人的决策框架太抽象，没有落地到具体用户。面试官会反复追问“具体是哪种开发者？”“在什么场景下？”“他的替代方案是什么？”如果你的回答里没有这些具体的用户画像，你的决策在他们眼里就是空中楼阁。
常见错误
在Supabase的product sense轮里，有三类错误出现频率最高，每一类都对应一个典型的面试场景。
第一类错误是“框架过载”。
BAD版本：面试官问你，你建议Supabase增加哪个新功能来提升用户留存？你开始回答：首先我要做用户调研，然后做竞品分析，然后做SWOT分析，然后做优先级矩阵，最后做A/B测试。面试官打断你：这些我都同意。但你现在必须告诉我一个具体的功能建议，以及为什么是这个功能而不是别的。
GOOD版本：面试官问同样的问题。你先说：我认为Supabase应该增加一个功能，让开发者可以在一周内看到他的数据库查询性能趋势。然后你解释为什么是这个功能：你的推理是，Supabase的用户主要是后端开发者，他们最关心的不是功能多不多，而是数据库稳不稳。查询性能可视化是一个低开发成本、高用户价值的功能，它能直接提升用户的“掌控感”，而掌控感是开发者工具留存的关键。
区别在于：好的回答是先给答案，再给推理。框架是隐性的，不是显性的。面试官想看到的是你的产品判断，不是你的方法论储备。
第二类错误是“技术逃避”。
BAD版本：面试官问你，如果你要让Supabase支持实时协作编辑，你会怎么设计产品功能？你回答：这个需要和engineering讨论技术可行性，我现在没有足够的技术背景来回答这个问题。面试官追问：你不需要知道技术实现细节，你只需要告诉我用户在使用这个功能时的体验是什么样的。你继续回答：我认为用户体验应该是……但你描述的是Google Docs的体验，和Supabase的数据库产品完全不对应。
GOOD版本：面试官问同样的问题。你先说：我先假设Supabase的实时协作编辑是面向什么用户场景。我认为有两类场景——一类是团队内部的数据标注协作，一类是面向end-user的协作应用。如果是第一类场景，核心体验是多人同时编辑同一条记录时的冲突解决；如果是第二类场景，核心体验是终端用户感知不到延迟的实时同步。这两类场景的产品设计完全不同。然后你选了其中一个场景，深入展开。
区别在于：好的回答是先做假设，再做推演。技术细节可以承认不知道，但用户场景不能承认想象不到。在Supabase，PM可以不会写SQL，但不能不会描述一个开发者的使用场景。
第三类错误是“价值错配”。
BAD版本：面试官问你，Supabase的Pro层级定价是每月25美元，你认为这个价格是高了还是低了？你回答：我认为低了，应该提高到每月35美元，因为我们的成本在增加，我们需要更高的毛利率来支持研发投入。面试官追问：用户会因为你成本增加而付更多钱吗？你回答不出来。
GOOD版本：面试官问同样的问题。你回答：我认为25美元这个价格对于当前的Pro层级功能来说是合理的。让我解释我的判断：Pro层级的核心功能是500MB的数据库存储和每月的API调用限额。对于一个早期创业团队来说，500MB存储大约可以支持他们3到6个月的用户增长需求。在这个时间窗口内，25美元是一个不需要做太多决策就能接受的价位。如果我们要提价，必须同时扩大存储空间或者增加新功能，让用户感知到“同样价格，更多价值”。单纯提价会降低升级转化率。
区别在于：好的回答是站在用户价值角度定价，错误回答是站在公司成本角度定价。在Supabase的HC讨论里，价值错配是product sense轮最常见的淘汰原因，因为它直接暴露了候选人缺乏最基本的产品思维。
准备清单
如果你要参加Supabase的PM面试，以下是你需要在product sense轮之前完成的准备。
第一，系统性拆解Supabase的产品架构。Supabase的核心产品不是数据库，而是“数据库+一系列围绕数据库的开发工具”。你需要理解Realtime、Auth、Edge Functions、Storage这四个主要功能之间的关系，以及它们分别解决什么问题。PM面试手册里有完整的Supabase产品线实战复盘可以参考。
第二，准备三个具体的用户场景。你需要能够详细描述：Supabase的典型用户是谁、他在什么场景下使用Supabase、他使用Supabase时的核心痛点是什么、他在使用过程中有没有流失、流失的原因是什么。这三个场景必须是你通过实际使用或者用户访谈获得的，不是从官网抄的。
第三，理解PostgreSQL的基础概念。你不需要会写复杂的SQL查询，但你需要知道：什么是主键、什么是索引、什么是事务、什么是VACUUM。这些概念在technical depth轮会用到，也在product sense轮会间接用到。如果你在product sense轮里说“我不太懂数据库”，面试官会质疑你能不能胜任Supabase的PM。
第四，练习“假设-验证”的思考方式。Supabase的product sense题通常信息不完整，你需要做假设。好的假设是基于用户场景的假设，坏的假设是基于直觉的假设。你需要练习在30秒内构建一个用户场景假设，然后在2分钟内验证这个假设。
第五，准备一个你自己的产品失败案例。Supabase的PM面试一定会问“你做过最失败的产品决策是什么”。你需要准备一个真实的案例，以及你从中学到了什么。这个案例不一定要在Supabase的领域内，但必须体现你的产品判断能力。
第六，了解Supabase的融资历史和竞争格局。你需要知道Supabase目前的估值、它的主要投资者、它的主要竞品以及它和竞品的差异化定位。这些信息在hiring manager轮会用到，也能在product sense轮帮你建立上下文。
第七，准备一个针对Supabase的产品建议。这个建议不一定要是对的——面试官知道你是外部人，信息不完整。但你需要展示你能发现问题、分析问题、提出解决方案的能力。这个建议会在cross-functional collaboration轮被追问，你需要能回答“如果工程师说做不了，你会怎么办”这种问题。
FAQ
Supabase的product sense轮会问到哪些具体的功能？
在product sense轮里，出现频率最高的功能是Realtime、Auth和Edge Functions。Realtime是Supabase最核心的差异化功能，也是它和Firebase竞争的主要战场。面试官经常会问：如果让你给Realtime增加一个功能，你会加什么？或者：Realtime的定价应该怎么设计？Auth是Supabase的第二大功能，它解决的是开发者不想自己写用户认证系统的需求。Edge Functions是Supabase最近在推的功能，它对标的是Cloudflare Workers和Vercel Edge Functions。面试官经常会问：Edge Functions的未来发展方向是什么？你需要对这些功能有足够深的理解，才能回答这类问题。
如果我不是开发者背景，是不是在Supabase的PM面试中完全没有优势？
不是完全没有优势，但你的准备成本会更高。Supabase的PM面试确实对技术理解有要求，但这要求不是“会写代码”，而是“能理解开发者的思维方式”。如果你没有技术背景，你需要花更多时间了解开发者到底关心什么。最有效的方式不是去学SQL，而是去和开发者聊天——了解他们在日常工作中最大的痛点是什么，他们在选择工具时的决策逻辑是什么，他们在使用Supabase时有没有遇到过让他们想放弃的瞬间。这些信息比技术知识更重要。
Supabase的PM薪资范围是多少？
Supabase的PM薪资在硅谷属于中上水平。L3级别的PM，base salary大约在$130,000到$160,000之间，RSU四年总计大约$80,000到$120,000，bonus大约在10%到15%之间。L4级别的PM，base salary大约在$160,000到$200,000之间，RSU四年总计大约$150,000到$250,000，bonus大约在15%到20%之间。L5级别的PM，base salary大约在$200,000到$250,000之间，RSU四年总计大约$300,000到$500,000，bonus大约在20%到25%之间。具体数字取决于你的经验层级和面试表现。需要注意的是，Supabase的RSU是四年 vesting，第一年 cliff，具体的package会在offer阶段由recruiter详细解释。