Stripe Software Engineer OA 面经｜高频 stripe oa questions 真题拆解

Stripe 一直是工程圈公认“技术标准非常正、但筛选极其严格”的公司之一。它的 Online Assessment（OA）本身就非常强调工程质量和系统稳定性，这一点在 Stripe 官方工程博客 中也有大量体现，包括风控系统、支付架构以及高并发数据处理的实践。过去一段时间，我作为 ProgramHelp 的一线面试辅导导师，完整陪跑并复盘了多位候选人的 Stripe OA。本文并不是泛泛而谈的刷题总结，而是围绕真实出现过的 stripe oa questions ，从工程视角拆解 Stripe 到底在考什么。

Stripe OA 的整体风格（基于真实 stripe oa questions 归纳）

从我们协助过的候选人反馈来看，Stripe OA 在题型与节奏上有高度一致性：

• 题目具有明确业务背景，而不是纯算法建模
• 多条规则叠加，但要求按步骤、分阶段处理
• 状态跨 transaction 维护，不能只看当前输入
• 对代码可读性与逻辑拆分要求高

这些特征在大多数 stripe oa questions 中都会反复出现，本质上是对工程成熟度的筛选。

Stripe OA 真实真题分享（高频 stripe oa questions 还原）

下面这道题，来自我们陪跑过的一位候选人的 Stripe OA 复盘，题目结构与考点均已脱敏，但规则逻辑与复杂度与真实 stripe oa questions 保持一致。

Problem Description

The fraud detection team at Stripe aims to reduce merchant fraud risk for Stripe with minimal pain to good merchants through machine learning. To provide initial data for training this machine learning model, you are tasked with developing a system to assess the fraud associated with transactions made by various merchants.

You are given:

• transactions_list: a list of transactions for a certain day
• merchants_list: a list of merchants, each with a base_score
• rules_list: a list of rules corresponding to each transaction

Each transaction represents a payment from a customer to a merchant. Your task is to assign each merchant a fraud score based on all their transactions.

Scoring Rules

1. Initialize each merchant’s current_score as their base_score.
2. For each transaction in transactions_list, update the merchant’s current_score in separate passes:
   • Transaction amount rule
     If the transaction amount is greater than the corresponding rule’s min_transaction_amount, multiply current_score by the rule’s multiplicative_factor.
   • Repeat customer rule
     If the same customer_id has made three or more transactions to the same merchant_id (including the current one), add all corresponding rules’ additive_factors cumulatively.
   • High-frequency hourly rule
     If a transaction is the third or later transaction from the same customer_id within the same hour for the same merchant_id:
     • If hour is between 12 and 17 (inclusive): add the penalty each time
     • If hour is between 9–11 or 18–21 (inclusive): subtract the penalty each time

这道题为什么典型

从导师视角来看，这道题几乎浓缩了 Stripe OA 的全部核心考点：

1. 强规则驱动，而非算法炫技

这类 stripe oa questions 不需要复杂算法，而是考你是否能：

• 准确理解规则
• 按顺序执行规则
• 保证状态在多次 transaction 中不出错

2. 状态设计是成败关键

你需要同时维护：

• merchant 级别的 current_score
• customer + merchant 维度的交易次数
• customer + merchant + hour 的频率统计

很多候选人在 stripe oa questions 中失分，并不是不会写代码，而是状态建模一开始就不合理。

3. “Separate passes” 是明显的工程信号

题目明确要求规则在 separate passes 中执行，这一点在 Stripe OA 中非常常见。

它本质是在测试：

• 你是否会为了代码清晰度而牺牲一点“写得快”
• 你是否理解可维护性比合并逻辑更重要

Stripe OA 常见失误

结合失败案例，总结 Stripe OA 最常见的几个问题：

• 把所有规则硬塞进一次循环
• 用临时变量堆逻辑，代码难以维护
• 忽略“第三次及之后”的累计规则
• 对 hour 区间判断出现边界错误

这些问题在 stripe oa questions 中非常致命，即使最终跑通部分样例，也很容易被系统或人工 review 卡掉。

关于 OA 无痕助攻的一点真实说明

说实话，Stripe 这种 OA，刷题能力只是门槛，真正决定过不过的是你会不会在规定时间内把一堆规则完整写对。很多同学翻车，不是算法不行，而是漏条件、算错累计规则、状态写乱，最后连自查时间都没有。

OA 无痕助攻解决的就是这个问题：
有人在你做题的同时，帮你盯规则、盯结构、盯容易翻车的点。

比如这种 stripe oa ：

• 规则要求分多轮 pass，你是不是一不小心写成了一轮
• “第三次及之后”的累计是不是少算了一次
• hour 区间边界有没有写反

这些点一旦漏掉，基本就是直接挂。

助攻的作用很简单：在你要写歪之前把你拉回来，让你按 Stripe 想看的方式把题完整写完，而不是考完才发现“我其实会，但刚刚没写对”。

不改系统、不动环境，代码还是你自己写，只是把本来就具备的能力稳稳落地。对 Stripe 这种规则密、容错低的 OA，说白了，差别就在这里。