Stripe VO 很贴近实际开发：用 AI 写交易规则解析器，调试 requests 的重定向问题，再接入地图 API。中间穿插项目深挖和 Ledger 系统设计，追问会落到具体细节，比如文件流该恢复到哪个位置、热门商户并发入账怎么处理，以及项目里为什么选择某个方案。
Stripe NG Interview Process
这次 Stripe SWE VO 一共五轮，NG的话类似，但是没有System Design这轮。Coding 使用 Python，除了实现功能，还涉及现有代码调试和陌生 API 接入。项目轮会追问技术决策，系统设计则围绕商户账本展开。
- 第一面：AI Programming
使用 HackerRank 内置 AI 助手实现交易规则判断器，先处理字符串比较，再加入布尔值和 AND/OR，并测试规则顺序及引号内的关键词。 - 第二面：Experiences & Goals
深挖 Azure Policy 与虚拟网络管理项目，讨论资源枚举、通知乱序、跨区域通信，以及如何验证 AI 生成的故障排查文档。 - 第三面：Bug Squash
调试 Pythonrequests的 HTTP 307 重定向问题，定位文件流重复发送时的游标状态，并提出恢复到首次发送前位置的修复方案。 - 第四面：System Design
设计商户 Ledger，讨论流水记录、余额查询和幂等处理，再围绕写多读少、热门商户并发写入及异步余额聚合展开追问。 - 第五面：API Integration
读取 GeoJSON，调用地图 API 并保存图片，再添加起终点标记和分段配色，最后讨论配置、错误处理及重试策略。
第一面：AI Programming，交易规则解析
题目： 在 HackerRank 中使用内置 AI 助手，45 分钟实现一个交易规则判断器。输入是一笔交易和一组有顺序的规则，每条规则包含条件及 accept/block 动作。第一条命中的规则决定结果；没有命中时默认接受。后面的 block 不能覆盖前面已经命中的 accept。
解答思路： 先让 AI 复述规则，再实现逐条判断、命中即返回的主流程。第一部分处理字符串比较，测试覆盖 accept、block、空规则和完全不匹配。第二部分加入布尔值及 AND/OR，扩展后重新跑第一部分的测试。
追问很具体：商户名里如果包含 and，还能正确解析吗？引号内的 and、or 要当作字符串内容，不能直接按关键词切开。解析时先识别引号范围，再处理外面的运算符。AI 最初停在 Plan 模式，只更新了计划，切到 Agent 模式后才开始改代码。
第二面：Experiences & Goals，项目深挖
题目： 讲一个规模最大的项目，说明自己负责什么、难点在哪里、哪些决定改变了方案。这轮主要聊 Azure Policy 与 Azure Virtual Network Manager 的动态网络组项目，链路包括资源变更通知、EventHub、资源处理与规则评估。
解答思路： 先交代职责和交付阶段，再讲真正卡住实现的问题：Management Group 下的资源需要分层枚举；更新和删除通知会乱序；下游接口还有限流。回答落到对应处理上，例如查询资源当前状态、批量处理，以及带抖动的重试。
“为什么项目做了一年半？”后面紧接着是“资源数量为什么会成为问题？”和“有没有标准 API 可以直接列出来？”只报组件名不够，要解释跨订阅枚举的成本。另一个追问是 EventHub 放哪边：同步发布跨区域请求会超时，后来把 EventHub 放到发布方附近，把跨区域延迟留给异步消费。
AI 的例子是整理故障排查文档。生成内容把历史状态混成了当前状态，因此改用当前代码仓库核对，并通过 PR 审查。面试官接着问：“如果你是新人，没有这些历史上下文，怎么确认 AI 写对了？”回答要说清验证依据，以及什么时候找熟悉系统的人复核。
第三面：Bug Squash，HTTP 307 重定向
题目： 调试 Python requests 的失败测试：POST 请求的 body 是可 seek 的文件流，收到 HTTP 307 重定向后再次发送，测试超时。普通请求体可以通过，完整文件流和已读过一部分的文件流各有一个失败用例。
解答思路： 先复现测试，再沿第一次发送、重定向、第二次发送追踪 body。文件流第一次发送后已经被读走，第二次请求没有按预期重新发送内容，服务端继续等待数据。最后定位到游标恢复问题，并提出：首次发送前记录 tell()，重定向时 seek() 回该位置。
这里不能直接 seek(0)，部分读取的用例中，首次发送前文件流就已经读过一部分。要恢复到原始起点。后续验证应同时覆盖完整文件流和部分读取的文件流；这一轮的进度停在定位原因、提出修复方案。
第四面：System Design，商户 Ledger (NG没有这轮)
题目： 设计商户 Ledger，记录收到和支出的金额，并查询余额，用于后续定期结算。题目先简化为单币种；账本负责记账，实际转账由其他服务完成。
解答思路： 先用关系型数据库保存账户及流水。请求携带稳定的幂等键，通过唯一约束防止重复入账；流水写入和余额更新放在同一事务。余额可以预先汇总，避免每次查询都扫描全部记录。
面试官随后纠正了读写比例：余额只在结算时定期读取，支付产生的写入更多。接着追问“写多读少怎么调整？”“热门商户并发写怎么处理？”思路转向先追加流水，再异步聚合余额，减少同一余额行的锁竞争。补充设计时还要讲清：展示余额允许多大延迟，结算前如何确认相关流水已处理完。
第五面：API Integration，地图路线绘制
题目： 50 分钟接入一个陌生的地图 API。先读取 GeoJSON 文件，输出前十个坐标；再调用静态地图接口，把返回的二进制内容保存成 PNG；最后加入起终点标记，并让路线每十条线段在蓝色和棕色之间交替。
解答思路： 先跑通坐标读取、请求和图片保存，再加标记及路线。十条线段需要十一个点，相邻分组共享端点，否则会断开。GeoJSON 坐标是经度在前、纬度在后，传给 API 前按接口要求核对顺序。生成图片后直接打开检查。
最后问：“如果要放到生产环境，还会改什么？”回答包括把 URL、文件路径和颜色分组参数提到配置中，拆开请求体构造与网络调用，检查状态码，只对适合重试的错误做有上限的重试，并记录请求延迟。
总结
这次 Stripe VO 面经比较明显的特点是，面试不仅关注算法和系统设计思路，也很重视实际工程能力。尤其是 System Design，不能只套用 High-Level SD 模板、画出几个架构图就结束，还需要结合具体业务场景，讲清楚 API 的定义、参数设计的原因、Service Layer 的职责，以及数据库结构如何满足业务需求。准备 Stripe VO 时，建议多练习从实际需求出发拆解问题，并能够解释每个技术决策背后的原因。
如果你正在准备 Stripe 或其他大厂的 OA 或面试，除了刷题，也可以结合真实面经熟悉常见题型和考察方向。InterviewShow 整理了 Microsoft、Amazon、Google、Stripe、TikTok 等科技公司的面试资料，并提供 OA 辅助和面试辅助，可以查看服务介绍，覆盖 Coding、System Design 和 BQ。需要的话，可以直接联系我们。
FAQ
每轮都能使用 AI 吗？
这次明确允许使用内置 AI 助手的是 AI Programming；Bug Squash 要求关闭 Copilot。Integration 可以查阅 API 文档和在线资料。工具权限按每轮要求确认。
Ledger 设计需要懂复式记账吗？
这道题没有要求会计专业知识。重点是流水、余额查询、幂等写入，以及并发和异步聚合带来的取舍。
除了刷题，还需要准备什么？
练一次现有仓库调试和陌生 API 接入，做到能跑测试、跟调用链、检查实际输出。项目部分挑一个做过关键取舍的例子，练习回答“为什么这样做”和“换个约束会怎么改”。