Stripe Data Engineer Interview Experience — A Two-Part CSV Transaction Fee Coding Problem

The screening interview started with the interviewer giving a very brief self-introduction, and then we went straight into the coding section.

Part 1 was: given a CSV string of transactions, parse out each person's fee. Questions I asked the interviewer:

1. What are the specific fee calculation rules for different transaction types and payment providers? For example, do payment transactions with card providers have a different fee structure? Are there different rates for different currencies or buyer countries?
2. Does the fee calculation only apply to transactions in a specific status, or should we calculate fees for all transactions regardless of status? For example, should we calculate fees for unpaid transactions or transactions with a pending refund?
3. How should fees be calculated for refunds and disputes — are they based on the original transaction amount, or do they have their own fee structure? (The answer was: none, because there's no refund fee.)

I also asked: does the result need to be a valid CSV string?

Part 2 was to further calculate fees based on the exchange rate between different countries, for transactions with a completed status.

My approach: I'd use a dictionary to build a lookup table mapping the combination of payment provider and buyer country to the corresponding variable fee percentage. For payment_completed transactions, I'd extract the payment_provider and buyer_country fields, look up the corresponding rate from the table, then apply the formula — amount times the variable rate, plus a fixed 30-cent fee.

For cases where multiple countries share the same credit card rate — for example, Germany, France, and Austria all have a 2.3% credit card rate — I'd still store them as separate entries in the lookup table, to keep the logic simple and avoid complex conditional checks.

All other transaction statuses — including dispute_lost, dispute_won, payment_failed, payment_pending, and refund_completed — would continue to use the exact same fee calculation logic as part 1, so the change is minimal and limited only to the payment_completed case.