Stripe 高频面经总结：从 Shipping Cost 到 Dataset 验证

在准备 Stripe SDE 的过程中，我先后面试了两个不同的组，发现他们在技术面中都使用了一个非常相似的高频题，涉及数据验证逻辑和实际业务规则模拟的实现。尤其是一个在地里几乎没有见过的 dataset 验证题，在短时间内重复出现。另外还有一道经典的 Shipping Cost 题目，通过多个层级递进，考察candidate对规则建模、边界处理以及代码组织能力的综合判断。这篇文章将结合我的实际面试经历，复盘两个题型的结构与考点，帮助未来准备 Stripe 面试的朋友提前规划和避坑。

Dataset 验证规则：结构化输入下的细节控制

这个题目在两个不同的组中均出现过，形式为验证一个 CSV 格式的字符串输入。输入数据类似于：

col1,col2,col3,col4,col5,col6

a,b,c,d,e,f

1,2,3,,5,6

我们需要按顺序判断每一行数据是否符合“VERIFIED”标准，或者给出 “NOT VERIFIED” 的具体原因，输出结果必须保持行序。判断依据并不只是格式化校验那么简单，而是包含了多层嵌套的业务规则：首先，任意一列为空都会导致该行被标记为 NOT VERIFIED。其次，col5 的长度需在 5 到 31 之间。接着是对 col2 中的内容进行关键词过滤：我们需识别是否包含如 COMPANY、FIRM 等敏感词（不区分大小写）。最后一道门槛是匹配度逻辑：将 col2 分词后，需至少有 50% 的词能在 col4 或 col5 中出现，且 LLC 与 Inc 这两个词不计入匹配范围。第二次面试中还加入了对验证失败原因的解释要求。这意味着，除了判断逻辑，我们还需对每一条失败的记录输出具体原因，比如：“2 is not verified because col4 is empty”。这一步骤对语言组织与判断顺序提出了更高要求。整个题目的核心在于：对输入格式的解耦、对每项规则的模块化实现、以及在输出中保持业务视角清晰，能够解释为什么。

Shipping Cost：经典题目的三层递进

另一道经典面试题是关于 Shipping Cost 的计算，整个题目分为三个阶段，第一阶段是固定成本的计算。每种产品在不同国家有单价，题目会提供一个订单对象，我们需要遍历订单中每个产品的数量与国家对应的单价，并乘积求和，逻辑较为直白。第二阶段引入了基于数量的“分段递减价格”。比如前两台笔电为 $1000/台，之后每台 $900。这一阶段考察的是区间判断能力：是否能正确分配数量到不同价格区间，并进行逐段累加，而不是用最大数量直接乘以最低单价。第三阶段最复杂，加入了两种 pricing type：incremental（按数量计算）和 fixed（只要落在区间内就收一次费用）。比如，一个 0-2 台的 fixed 价格是 $1000，不论用户买 1 还是 2 台，只需收一次 $1000。剩下数量再进入下一个 incremental 区间，如每台 $900。此处需要识别先处理 fixed 区间，再用 incremental 补充剩余部分。

这个问题难点在于对“每种价格机制”的理解差异清晰，以及对 quantity 的分段管理细致到位。我的建议是，尽量将每种 cost 逻辑封装成函数或 handler，这样逻辑更清晰、也更易调试。

面试体验与建议

我的两次 Stripe 电面经历节奏都非常紧凑，面试官几乎直接进入题目。虽然都使用了 Hackerrank 环境，但问题描述通常是口头给出，我们需要边理解边提问，尤其在规则含糊或 edge case 需要澄清时主动沟通显得非常关键。