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，說白了，差別就在這裡。