Stripe VO 分好幾輪，整個過程緊張但收穫頗豐。這篇複盤整理出我們團隊帶學員走完的四輪流程、各輪感受與準備心得，給準備衝擊 Stripe 或類似頂級科技公司的同學一個參考。我對接了 oavoservice 團隊協助完成關鍵技術輪，下面逐輪還原真題。
一、四輪概覽
| 輪次 | 形式 | 重點 |
|---|---|---|
| Round 1 Coding | 共享線上編輯器 / 白板 | 邊想邊講，寫出可運行或邏輯清晰的程式碼 |
| Round 2 System Design | 開放性設計題 | 業務建模 + 與面試官互動討論 |
| Round 3 BQ | 情景題深挖 | 溝通、協作、衝突解決、領導力、文化契合 |
| Round 4 Product/Cross-functional | 開放討論 | 業務 / 產品理解 + 跨職能協作 |
Coding 輪題型覆蓋很廣：鏈表 / 樹 / 圖等基本資料結構的操作與應用、動態規劃與貪心、字串與陣列處理，甚至可能涉及並發與鎖的理解。
二、Round 1 Coding：命令流模擬商戶與支付系統
題目
你會收到一系列命令，用於模擬一個基本的商戶與支付系統。每條命令是一個空格分隔的字串，包含關鍵字和參數。你需要維護商戶與餘額的映射，以及支付記錄。
每條命令是以下兩種之一：
INIT merchant_id balance：初始化一個商戶並設定其初始餘額。CREATE payment_id merchant_id amount：為某個商戶創建一筆支付；支付成功處理後，金額加到該商戶餘額上。
支付狀態和流程是隱式的：一旦支付成功處理，金額就加到商戶餘額中。
輸入：一個字串列表，每個字串代表一條命令。 輸出：執行完所有命令後，每個商戶最終的餘額狀態。
# 示例
commands = [
"INIT m1 1000",
"CREATE p1 m1 200",
"CREATE p2 m1 300",
]
# 輸出: {"m1": 1500}
解法：命令分發 + 狀態機思維
這題表面是模擬，重點在把命令解析與狀態變更解耦，並為後續 followup（新增命令類型、顯式支付狀態）留好擴展口。我用一個 dispatch 表把每種命令映射到處理函式：
from typing import List, Dict
class PaymentSystem:
def __init__(self):
self.balances: Dict[str, int] = {}
self.payments: Dict[str, dict] = {} # 為後續 followup 保留支付記錄
def init_merchant(self, merchant_id: str, balance: str):
self.balances[merchant_id] = int(balance)
def create_payment(self, payment_id: str, merchant_id: str, amount: str):
amt = int(amount)
self.payments[payment_id] = {"merchant": merchant_id, "amount": amt}
# 隱式成功：直接入帳
self.balances[merchant_id] = self.balances.get(merchant_id, 0) + amt
def run(self, commands: List[str]) -> Dict[str, int]:
dispatch = {
"INIT": self.init_merchant,
"CREATE": self.create_payment,
}
for line in commands:
op, *args = line.split()
handler = dispatch.get(op)
if handler is None:
raise ValueError(f"unknown command: {op}")
handler(*args) # 參數順序與命令格式一致
return self.balances
面試官的典型 followup：
- 如果支付有顯式狀態（pending / completed / failed）怎麼辦？ → 在
payments裡存 status，只有轉到completed才入帳，把「隱式成功」改成顯式狀態機。 - 如果同一個 payment_id 重複 CREATE？ → 加冪等判斷，已存在則忽略或報錯（貼合 Stripe 真實的冪等語義）。
- 如何支持退款 / 轉帳？ → dispatch 表再加一種 handler 即可，主迴圈不動。
dispatch + 狀態機的結構讓這些 followup 都變成「加一個 handler / 加一個狀態」，而不是重寫主迴圈——這正是 Stripe 想看到的擴展性。
三、Round 2 System Design：多國運費矩陣聚合訂單成本
題目
每個國家 / 產品組合有對應的運輸成本，費用以最小貨幣單位儲存。給定一張運費矩陣和一個訂單，算出訂單總運費。
shipping_cost_matrix = {
"US": [
{"product": "mouse", "cost": 550},
{"product": "laptop", "cost": 1000},
],
"CA": [
{"product": "mouse", "cost": 750},
{"product": "laptop", "cost": 1100},
],
}
order = {
"country": "US", # CA 表示加拿大訂單
"items": [
{"product": "mouse", "quantity": 20},
{"product": "laptop", "quantity": 5},
],
}
解法：先把矩陣轉成 O(1) 查找結構
原始矩陣是「國家 → 列表」，每次查 product 要線性掃。先預處理成 (country, product) -> cost 的巢狀字典，訂單聚合就是一次遍歷：
def build_index(matrix: dict) -> dict:
"""把 country -> [ {product, cost} ] 轉成 country -> {product: cost}"""
return {
country: {row["product"]: row["cost"] for row in rows}
for country, rows in matrix.items()
}
def order_shipping_cost(matrix: dict, order: dict) -> int:
index = build_index(matrix)
country = order["country"]
if country not in index:
raise ValueError(f"unsupported country: {country}")
country_costs = index[country]
total = 0
for item in order["items"]:
product = item["product"]
if product not in country_costs:
raise ValueError(f"no shipping cost for {product} in {country}")
total += country_costs[product] * item["quantity"]
return total
# US: 550*20 + 1000*5 = 11000 + 5000 = 16000
討論延伸（面試官最看重的部分）：
- 成本以最小貨幣單位存整數，避免浮點誤差——這是支付系統的硬規矩。
- 缺失組合怎麼處理：拋錯 / 回退預設 / 標記為不可發貨，要和面試官 clarify 業務期望。
- 規模化：矩陣很大時如何快取索引、如何按國家分片、如何支持運費隨時間 / 重量 / 區域階梯變化。
- 可擴展：把「固定單價」抽象成
cost_fn(product, quantity, context)，未來接階梯計價或促銷不改主流程。
四、Round 3 BQ：深挖經歷細節
基於過去經歷的情景題，面試官會深挖細節。重點考察溝通、協作、衝突解決、領導力，以及面對挑戰和失敗的態度，是否與 Stripe 的文化價值觀契合。Stripe 非常重視團隊合作和正直。建議用 STAR 框架，並準備「失敗 / 衝突 / 推動改變」三類故事，每個都能講到具體決策與可量化結果。
五、Round 4 Product/Cross-functional：跨職能討論
開放性問題，會結合 Stripe 的具體產品或業務場景。考察你理解業務和產品需求的能力，從用戶 / 產品 / 技術 / 商業多個角度思考問題，以及在跨職能團隊中有效溝通協作的能力。回答時先框定用戶與目標，再談技術取捨，最後落到商業指標，邏輯會很清晰。
六、總結
Stripe VO 四輪各有側重：Coding 偏真實系統模擬（命令流 + 狀態機思維）、System Design 重業務建模與最小貨幣單位等支付細節、BQ 深挖文化契合、Product 輪考多視角與跨職能溝通。把 Coding 題練到「dispatch + 狀態機隨時可擴展」，把設計題練到「先建 O(1) 索引再聊規模化」，整輪會穩很多。
FAQ
Q1：Stripe VO 一共幾輪、考什麼？
四輪：Coding（命令流模擬商戶支付系統）、System Design（多國運費矩陣聚合）、BQ（文化契合深挖）、Product/Cross-functional（多視角業務討論）。
Q2：商戶支付模擬題怎麼拿高分？
用 dispatch 表把命令解析與狀態變更解耦，支付用狀態機而非「隱式成功」，並主動加冪等判斷。這樣面試官的 followup（顯式狀態 / 退款 / 重複提交）都能輕鬆接住。
Q3：運費矩陣題的關鍵是什麼？
先把「國家 → 列表」預處理成 (country, product) -> cost 做 O(1) 查找；堅持用最小貨幣單位整數；並和面試官 clarify 缺失組合、階梯計價、規模化等業務邊界。
Q4：怎麼準備 Stripe VO？
Coding 練擴展性結構，Design 練「索引 + 規模化」推演，BQ 備好 STAR 故事，Product 輪練多視角框架。如需這幾道真題的限時陪練，或 VO代面 / VO輔助 的即時對接，可以發崗位 JD 先做題型預測再排練習計劃。
正在準備 Stripe 面試？
Stripe VO 考真實系統模擬 + 支付細節 + 文化契合 + 跨職能溝通。oavoservice 提供 Stripe 全流程陪練：商戶支付模擬、運費矩陣聚合、System Design 推演、BQ 與 Product 輪演練，也支持 VO代面 / VO輔助 的即時對接。教練含前大廠資深工程師，熟悉 Stripe「願意 merge 的程式碼品質 + 業務貼合」評分風格。
立即添加微信 Coding0201，獲取 Stripe 真題與陪練。
聯絡方式
- 微信：Coding0201
- Email：[email protected]
- Telegram：@OAVOProxy