← Stripe Interview Insights

Stripe·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jul 2026

Summary

Stripe SWE interview with a payments-flavored coding problem. Pretty domain-specific which was a nice change from generic leetcode, but the complexity discussion at the end caught me slightly off guard.

Questions Asked (1)

Q1

You're building a payment processor. Given a fee table that maps (payment_type, payment_status) pairs to rates in basis points, and a list of transactions each with an id, type, status, and amount in cents, compute the processing fee for each transaction using floor(amount * rate / 10000), return 0 for unmatched rules, and return both the per-transaction fees in input order and the total. Discuss time and space complexity.

Algorithms & Data StructuresAPI & IntegrationsTechnical Trade-offs
Author's notes

The core logic clicked pretty fast, just build a dict from the fee table and do a lookup per transaction.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem and edge cases, then propose a solution using a hash map for O(1) rule lookups and a single pass over transactions. Emphasize integer arithmetic to avoid floating-point errors and discuss time/space complexity.

Pro tip: Mention that using integer arithmetic (floor division) is crucial in payment systems to avoid floating-point precision issues, and that you would validate inputs and handle edge cases like negative amounts or missing rules.

1. Clarify requirements and edge cases

Ask about input constraints, data types, and expected behavior for unmatched rules, zero amounts, or negative amounts. Confirm that fees are floored and that the total is the sum of per-transaction fees.

2. Design the algorithm

Propose using a hash map to store the fee table for O(1) lookups. Iterate through transactions, compute fee as floor(amount * rate / 10000), defaulting to 0 if no rule matches, and accumulate the total.

3. Implement with integer arithmetic

Use integer division to compute the fee, ensuring no floating-point errors. For example, fee = (amount * rate) // 10000. Handle potential overflow by considering larger integer types if needed.

4. Analyze complexity

Time complexity is O(n + m) where n is number of transactions and m is number of rules (to build the map). Space complexity is O(m + n) for the map and output list, or O(m) if we can stream results.

5. Test and validate

Walk through examples, including unmatched rules and edge cases like zero amount. Verify that the output order matches input order and that the total is correct.

Key Points to Mention

  • Use a hash map for O(1) rule lookups, keyed by (payment_type, payment_status).
  • Compute fees using integer arithmetic: floor(amount * rate / 10000) to avoid floating-point errors.
  • Default to 0 for unmatched rules and maintain input order in the output.
  • Time complexity: O(n + m) where n is transactions and m is rules; space complexity: O(m + n) or O(m) if streaming.
  • Consider edge cases: zero amounts, negative amounts (if allowed), and large amounts causing overflow.
  • Discuss potential optimizations like precomputing rates or using a trie if rules are hierarchical.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.