OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导，已帮助多位候选人斩获 Senior 级别 Offer。
在帮助客户准备 Stripe SDE 的过程中，我们先后试水了多次VO面试，发现他们在技术面中都使用了一个非常相似的高频题，涉及数据验证逻辑和实际业务规则模拟的实现。尤其是一个在地里几乎没有见过的 dataset 验证题，在短时间内重复出现。另外还有一道经典的 Shipping Cost 题目，通过多个层级递进，考察candidate对规则建模、边界处理以及代码组织能力的综合判断。这篇文章将结合我们的实际面试经历，复盘两个题型的结构与考点，帮助未来准备 Stripe 面试的朋友提前规划和避坑。
这个题目在两个不同的组中均出现过，形式为验证一个 CSV 格式的字符串输入。输入数据类似于：
col1,col2,col3,col4,col5,col6
我们需要按顺序判断每一行数据是否符合“VERIFIED”标准，或者给出 “NOT VERIFIED” 的具体原因，输出结果必须保持行序。判断依据并不只是格式化校验那么简单，而是包含了多层嵌套的业务规则：首先，任意一列为空都会导致该行被标记为 NOT VERIFIED。其次，col5 的长度需在 5 到 31 之间。接着是对 col2 中的内容进行关键词过滤：我们需识别是否包含如 COMPANY、FIRM 等敏感词（不区分大小写）。最后一道门槛是匹配度逻辑：将 col2 分词后，需至少有 50% 的词能在 col4 或 col5 中出现，且 LLC 与 Inc 这两个词不计入匹配范围。第二个part还加入了对验证失败原因的解释要求。这意味着，除了判断逻辑，我们还需对每一条失败的记录输出具体原因，比如：“2 is not verified because col4 is empty”。这一步骤对语言组织与判断顺序提出了更高要求。整个题目的核心在于：对输入格式的解耦、对每项规则的模块化实现、以及在输出中保持业务视角清晰，能够解释为什么。
另一道经典面试题是关于 Shipping Cost 的计算，整个题目分为三个阶段，第一阶段是固定成本的计算。每种产品在不同国家有单价，题目会提供一个订单对象，我们需要遍历订单中每个产品的数量与国家对应的单价，并乘积求和，逻辑较为直白。第二阶段引入了基于数量的分段递减价格。比如前两台笔电为 $1000/台，之后每台 $900。这一阶段考察的是区间判断能力：是否能正确分配数量到不同价格区间，并进行逐段累加，而不是用最大数量直接乘以最低单价。第三阶段最复杂，加入了两种 pricing type：incremental（按数量计算）和 fixed（只要落在区间内就收一次费用）。比如，一个 0-2 台的 fixed 价格是 $1000，不论用户买 1 还是 2 台，只需收一次 $1000。剩下数量再进入下一个 incremental 区间，如每台 $900。此处需要识别先处理 fixed 区间，再用 incremental 补充剩余部分。