Stripe·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Apr 2026

Summary

Stripe coding screen for a software engineer role. The main problem was about reconciling payments and invoices, which sounds straightforward until you actually think through all the edge cases.

Questions Asked (1)

Given a list of payments and a list of invoices, match each payment to an invoice using the invoice_id field. Return three things: matched pairs, payments that couldn't be matched (missing or unrecognized invoice_id), and invoices that received no payment. Also discuss your choice of data structure and how you'd handle duplicate invoice_ids.

Algorithms & Data StructuresTechnical Trade-offsData Modeling

Author's notes

I went straight for a hashmap keyed on invoice_id, which felt right.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data model and edge cases (e.g., duplicate invoice_ids, missing fields, data types). Then propose a hash map-based solution: build a map from invoice_id to a list of invoices, iterate through payments to match and collect unmatched payments, and finally identify invoices with no payments. Discuss trade-offs of alternative structures and how you'd handle duplicates (e.g., FIFO matching or flagging for manual review).

Pro tip: Mention that in a real payment system like Stripe, you'd also consider idempotency and partial payments; showing awareness of domain-specific concerns beyond the algorithm sets you apart.

1. Clarify requirements and edge cases

Ask about data types, whether invoice_id can be null, how to handle duplicate invoice_ids (e.g., multiple invoices with same ID), and if payments can partially match invoices. Confirm output format.

2. Choose data structures

Propose using a hash map (dictionary) to index invoices by invoice_id, mapping to a list to handle duplicates. This allows O(1) average lookup per payment. Alternatively, consider sorting if memory is constrained.

3. Design the matching algorithm

Iterate through payments: for each, look up invoice_id in the map. If found and invoices remain, pair them (e.g., FIFO) and mark invoice as matched; else add payment to unmatched list. After processing, any invoices not marked matched are unmatched invoices.

4. Handle duplicates and edge cases

For duplicate invoice_ids, decide on a policy: match payments to invoices in order (FIFO), or if multiple invoices share an ID, treat as ambiguous and flag. Also handle missing invoice_id in payment by adding to unmatched.

5. Analyze complexity and trade-offs

State time complexity: O(P + I) with hash map, space O(I). Discuss alternatives like sorting (O(P log P + I log I)) and when they might be preferable. Mention potential need for stable matching or business rules.

Key Points to Mention

Use a hash map from invoice_id to a list of invoices to handle duplicates efficiently.
Iterate through payments once, achieving O(P + I) time complexity.
For duplicate invoice_ids, define a clear matching policy (e.g., FIFO) and document it.
Payments with missing or unrecognized invoice_id go to the unmatched payments list.
Invoices that remain unmatched after processing all payments are the unmatched invoices.
Consider real-world concerns like idempotency, partial payments, and data validation.

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