这次 Stripe VO（Virtual Onsite）共经历 5 轮，分别是 Coding、Hiring Manager、API Integration、Debug 和 System Design。整体来看，面试内容覆盖算法实现、项目经历、API 调用、代码调试和服务设计，既考察基础编程能力，也关注候选人处理实际开发任务的思路。
其中，Coding 环节围绕 Account Balance 展开，API Integration 要求基于给定的 repository 调用指定 API 并保存返回结果，Debug 环节涉及文件路径检查和 AST 节点访问问题。System Design 则以 Ledger Service 为主题，更关注 API 定义、service layer 划分和数据库结构设计。对于准备 Stripe VO 的候选人来说，除了熟悉常见的 Coding 题型，还需要重视代码边界情况、需求澄清和具体实现细节。
Stripe VO 第 1 轮：Coding -- Account Balance
这一轮是一道与账户余额平衡有关的 Coding 题，思路类似 LeetCode 中通过交易调整账户余额的问题。不过，原题不要求直接给出交易次数最少的最优解，只需要设计一种可行的交易方案，使所有账户的余额达到预期值即可。
题目的基础部分只有一个 part，整体难度不算高。解题时需要先理解每个账户的当前余额与目标余额之间的差额，再根据差额安排交易，让所有账户最终达到指定状态。
Follow-up 1：如何减少交易次数？
面试官进一步询问，能否在满足余额要求的前提下，减少完成平衡所需的交易次数。
这部分可以结合经典的最少交易次数问题进行讨论。与基础版本不同，优化目标不仅是完成余额调整，还要尽可能减少交易数量。候选人可以先说明当前方案为什么能够完成平衡，再讨论如何通过重新匹配欠款方和收款方来减少交易次数。
回答时需要注意，可行解与最优解是两个不同的目标。如果基础题只要求完成余额平衡，就没有必要一开始便引入复杂的最优化逻辑；只有在 Follow-up 中明确提出交易次数最少的要求时，才需要进一步讨论相应的算法。
Follow-up 2：如何进行 Audit？
第二个 Follow-up 关注交易审计（Audit）。面试官希望了解，如何验证交易流程执行后，系统中的实际记录是否符合预期。
面经中的回答思路是先对交易流程进行 dry run，模拟每笔交易执行后的账户余额变化，再将模拟结果与数据库中的实际记录进行对比，检查是否存在差异。
这个问题不只是验证最终余额是否正确，还涉及交易记录的一致性。实际实现中，还可以进一步讨论交易金额、交易方向、交易状态和记录完整性等检查维度。如果模拟结果与数据库记录不一致，就需要定位差异发生在哪一步，并判断问题来自交易逻辑还是数据记录过程。
这一轮的核心考点： 账户余额计算、交易逻辑、可行解与最优解的区别，以及交易记录的审计思路。
Stripe VO 第 2 轮：Hiring Manager
第二轮是 Hiring Manager（HM）面试，主要围绕简历、项目经历和过往工作展开，没有特别复杂的技术题目，整体交流氛围比较轻松。
面试官会根据候选人的简历进一步追问项目背景、负责的工作和实际参与程度。相比于单纯介绍项目做了什么，这一轮更需要讲清楚自己在项目中的具体职责、遇到的问题，以及最终如何推进和解决问题。
此外，面试官也会关注候选人的表达方式，以及过往经验与团队工作内容是否匹配。回答项目问题时，建议围绕具体场景展开，明确说明自己的决策和贡献，避免只介绍团队整体完成的工作。
这一轮的准备重点： 梳理简历中的核心项目，准备能够体现个人贡献的案例，并确保项目中的技术选择、实现过程和结果经得起追问。
Stripe VO 第 3 轮：API Integration
这一轮是 API Integration 面试，面试官提供一个现有的 repository，要求候选人在其中调用指定的 API，并将返回的 response 保存下来。
从面经反馈来看，任务本身没有特别高的算法难度，重点在于能否按照要求理解现有代码、跑通调用流程，并正确处理 API 的返回结果。
面对这类题目，不建议拿到任务后就急着编写大量代码。可以先查看 repository 的目录结构、入口文件和现有实现，确认项目使用的技术栈以及需要修改的位置，再根据题目要求完成 API 调用和数据存储。
实现过程中，需要关注几个基本问题：
-
API 调用： 是否使用正确的 endpoint、请求参数和必要的请求头。
-
Response 处理： 是否正确读取和解析 API 返回的数据。
-
数据存储： 是否按照要求保存返回结果，并确认保存的数据符合预期。
-
异常处理： 如何处理请求失败、异常响应或无效数据。
-
运行验证： 是否实际执行代码，确认整个流程能够正常工作。
这些内容不一定都会作为独立问题出现，但它们能够帮助候选人更完整地处理实际开发任务。如果题目只要求完成指定功能，就应优先保证主流程正确，再根据剩余时间处理异常情况和边界条件。
这一轮的核心考点： 阅读现有代码、理解项目结构、调用 API、处理 response，以及完成端到端的功能验证。
Stripe VO 第 4 轮：Debug（Mako）
第四轮是 Debug 面试，使用 Mako 完成调试任务。根据这次面经，题目涉及两个具体问题。
Bug 1：没有检查 File Path 是否为目录
第一个 bug 与文件路径处理有关。代码没有检查传入的 file path 是否指向一个目录，导致程序可能在不符合预期的路径上继续执行。
排查时，需要先确认该路径在程序中的用途，再检查相关文件操作是否假设路径一定是目录。如果调用方传入的是普通文件路径，或者路径本身不存在，程序就可能出现错误行为。
修复时，应根据具体需求补充相应的路径校验，并明确路径无效时应该如何处理。除了修复当前报错，也需要考虑目录不存在、路径指向普通文件等边界情况。
Bug 2：缺少特定 AST 节点的访问函数
第二个 bug 与 AST（Abstract Syntax Tree，抽象语法树）有关。代码遗漏了一个特定 AST 节点对应的访问函数，导致程序运行时报错。
在基于 AST 的程序中，访问函数通常负责处理特定类型的语法节点。如果代码需要遍历或处理某种节点，却没有实现对应的访问逻辑，就可能在运行过程中出现异常，或者无法正确完成节点处理。
调试时，可以先根据报错信息定位出错位置，再检查相关 AST 节点类型是否有对应的访问函数，以及现有的节点遍历逻辑是否覆盖了题目要求的情况。
这一轮整体思路并不复杂，但需要注意边界情况。Debug 的关键不是看到报错后立即修改代码，而是理解程序原本的执行逻辑，找到问题的实际原因，再通过测试验证修复是否有效。
这一轮的核心考点： 阅读和理解现有代码、定位运行时错误、处理文件路径校验，以及检查 AST 节点访问逻辑的完整性。
Stripe VO 第 5 轮：System Design -- Ledger Service
最后一轮是 System Design，题目围绕 Ledger Service（账本服务）展开。
与侧重高并发、缓存、消息队列和整体架构的传统系统设计题相比，这道题更偏向 API 设计和具体业务逻辑。候选人需要结合使用场景，明确服务提供哪些功能、API 应该如何定义，以及 service layer 和数据库结构应该如何组织。
1. 先明确业务需求
开始设计之前，建议先确认 Ledger Service 的使用场景和核心需求。例如，系统需要支持哪些账本操作，调用方需要提交什么数据，以及服务需要返回哪些信息。
涉及交易或账本记录时，还应进一步确认数据的正确性要求，以及是否需要支持交易查询、状态追踪或历史记录核对。具体功能应以题目给出的需求为准，不要在尚未明确业务规则时直接假设系统需要一整套复杂架构。
2. 设计清晰的 API
API 是这一轮的重要考察点。候选人需要说明每个 endpoint 的职责、请求参数、返回结构，以及不同参数为什么采用这样的设计。
例如，在讨论创建账本记录的 API 时，可以进一步明确请求中需要哪些字段、哪些字段由服务端生成，以及遇到无效请求时如何返回错误信息。
如果场景涉及交易创建，还可以主动确认重复请求应该如何处理，以及如何避免同一笔业务操作被重复记录。是否需要幂等机制，应结合题目要求和业务场景解释，而不是机械地套用固定设计。
3. 划分 Service Layer
在明确 API 之后，需要考虑各层的职责划分。API 层负责接收请求和返回响应，service layer 负责执行核心业务规则，数据访问层则负责与数据库交互。
例如，余额或账本相关的业务校验不应全部堆积在 API handler 中。将业务逻辑放在合适的 service layer 中，有助于保持代码结构清晰，也便于单独测试和维护。
设计时，需要解释为什么采用这样的划分，以及不同模块之间如何协作，而不是只列出几个组件名称。
4. 设计数据库结构
数据库设计需要与 API 和业务规则保持一致。候选人应说明需要保存哪些实体、各字段的用途，以及不同记录之间的关联关系。
如果题目涉及账本或交易记录，可以进一步讨论如何保存交易金额、账户标识、交易状态和创建时间等信息。若业务要求保留可审计的历史记录，还需要考虑如何避免历史记录被不恰当地覆盖，以及如何核对记录与业务状态之间的一致性。
具体字段和表结构仍然需要根据题目要求确定，不宜在需求尚未明确时直接引入过多不必要的表或复杂组件。
5. 解释设计取舍
这一轮尤其需要说明设计背后的理由。例如，为什么选择某种 API 参数形式，为什么将某项业务校验放在 service layer，以及为什么需要特定的数据库约束。
如果面试官提出新的使用场景或约束，候选人也需要能够解释原有设计是否仍然适用，以及需要调整哪些部分。
这一轮的核心考点： 需求澄清、API contract、service layer 职责、数据库结构和具体设计取舍。
Stripe VO 备考建议
结合这次五轮面经，准备 Stripe VO 时，可以重点关注以下几个方面。
第一，Coding 不要只准备最优算法。 需要先确保能够写出正确、可验证的基础方案，再根据 Follow-up 讨论性能优化、最少交易次数等更深入的问题。遇到交易类题目时，也要留意状态变化和数据一致性。
第二，熟悉真实代码库中的开发任务。 API Integration 和 Debug 都不是单纯的算法题。阅读项目结构、理解现有实现、运行代码、定位报错，以及通过测试验证修改结果，都是值得提前练习的能力。
第三，准备好项目经历。 HM 面试可能围绕简历中的细节持续追问。候选人需要明确自己做了什么、为什么这么做，以及遇到了哪些实际问题。
第四，System Design 要从具体需求出发。 不要一开始就画出包含缓存、消息队列、负载均衡等组件的通用架构图。先把 API、参数、业务规则和数据结构讲清楚，再根据题目要求逐步讨论扩展性、可靠性和一致性。
Stripe VO 的准备重点不只是能否给出一个答案，还包括能否解释实现过程中的具体选择，并在新约束出现时调整方案。尤其是 API Integration、Debug 和 Ledger Service 这几轮，理解代码与业务细节，比机械套用固定模板更重要。