Stripe Software Engineer Interview Questions
Software engineering at a payments company covers more than the charge itself: subscriptions that change mid-month, invoices that must never change once sent, cards that expire, and money in one currency paid out in another. Prepare to explain rules exactly, because a business builds its own books on what your code produces. Expect questions about writing things down and about the developer who reads your errors. What to show here: exact rules, written down, that businesses can build their books on. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Stripe hires, in its own words, and its questions for every job →
1. Tell me about a design document you wrote where review changed your mind. What did the reviewers see that you had missed?
- Describe the problem and your first proposal.
- Share the objection that mattered.
- Explain how you changed the design.
- Say what you do differently when writing now.
“I proposed storing a customer's subscription status as a single field that a nightly job updated. It was simple and I was confident. A reviewer asked what a support agent would see at noon if the customer cancelled at nine, and what happened if the job failed. I had designed for the normal path only. I changed to storing each change as an event with its time, and computing the status from the events, so the nightly job became unnecessary. The document's list of failure cases became the longest part. The outcome was your result.”
Weak answers describe a review where nothing changed, or treat the objection as a fight they lost.
2. Describe a time you improved an error message or a piece of documentation, and it reduced the questions developers asked you.
- Describe the confusing message or page.
- Explain how you noticed the confusion.
- Share the rewrite and the rule behind it.
- Give the result.
“Our API returned invalid request for many different mistakes, and the same three questions kept arriving in our support channel. I went through a month of questions and matched each to the cause. Then I changed the errors to name the field, say what was wrong with it, and link to the exact section of the documentation. For the most common mistake, a missing currency, the message now showed a correct example. I also added that example to the quick start guide. Over the following weeks the repeat questions fell. The result was your result.”
Weak answers think documentation is someone else's job, or never checked whether the change helped.
3. A customer on a monthly subscription upgrades to a bigger plan halfway through the month. How would you compute what they owe, and what must be recorded so the invoice can be explained later?
- Define the billing period and the exact moment of change.
- Credit the unused part of the old plan and charge the used part of the new plan.
- Decide rounding once and apply it at the end.
- Store the inputs and the rule version with the invoice.
“I would take the billing period and the exact time of the upgrade. The customer gets a credit for the part of the old plan they will not use, and a charge for the part of the new plan they will use, both in proportion to the remaining time. I would compute in the smallest currency unit and round only once at the end of each line, and write down which way we round. Whether the difference is charged now or added to the next invoice is a setting for the business. On the invoice I store the period, the time of change, both plans and the rule version.”
Weak answers charge the full new price at once, or round each intermediate step and get totals that do not add up.
4. A subscription charge fails because the card was declined. When and how many times would you retry, and what would you tell the business and the customer?
- Separate hard declines from temporary ones.
- Retry temporary failures a few times, spaced over days.
- Never retry an expired or closed card without new details.
- Notify the customer and let the business set the rules.
“The decline reason matters. A card that is expired or closed will never succeed, so retrying is pointless and I would ask the customer for new details straight away. A temporary reason, such as insufficient funds, may succeed later, often once money arrives in the account, so I would retry a few times spaced over days, not minutes. After the last attempt, the business decides what happens: pause the subscription or cancel it. The customer gets a clear email at the first failure with a link to update their card. All of this should be settings the business can change, with sensible defaults.”
Weak answers retry every hour for ever, or treat all declines the same.
5. Design invoice generation for businesses: line items, tax, a number sequence without gaps, and a rule that a sent invoice can never change.
- Keep a draft state where items can change.
- On finalising, assign the next number inside a transaction and freeze the content.
- Store the rendered totals, not just the inputs.
- Correct mistakes with a credit note, never an edit.
“An invoice starts as a draft, where the business can add line items and where tax is computed from the customer's location and the item type. Finalising is the important step. Inside one transaction I take the next number from a per-business counter and write the invoice as finalised with all its totals stored, so a later change in tax rules or prices cannot alter it. A counter row locked in the transaction avoids gaps and duplicates. After that, the record is read-only in code and in the database. A mistake is fixed by issuing a credit note and a new invoice, which keeps the sequence honest.”
Weak answers recompute totals when displaying an old invoice, or allow edits after sending.
6. A business sells in one currency and receives its money in another. When would you convert, how would you round, and what would you show the business so their totals reconcile?
- Fix the rate at the moment of the charge and store it on the payment.
- Round each converted amount once and record it.
- Keep the original amount and currency alongside.
- Report both currencies with the rate used.
“The rate should be fixed at the moment of the charge and stored on that payment, so the business is not exposed to changes between charge and payout. Each payment is converted and rounded separately, and the rounded value is stored, because summing exact values and rounding once would give a different total from the sum of what each customer saw. I keep the original amount and currency next to the converted one. Reports show both, with the rate, so the business can match each customer payment to its share of the payout. Refunds use the original rate, not the current one.”
Weak answers convert at payout time with that day's rate, or cannot explain why rounded totals differ.
7. A business says the total of today's payout does not match the sum of yesterday's payments in their report. They are worried money is missing. How do you work through it?
- Define exactly what each number includes.
- List the usual causes: fees, refunds, disputes, timing of settlement.
- Produce a line-by-line bridge from one number to the other.
- Fix any real gap and improve the report.
“First I would find out exactly what each number includes. A payout is usually payments minus fees, minus refunds and disputes, and it may cover a different set of days than a calendar day report, because settlement takes time and some payment methods settle later. I would build a bridge from the payments total to the payout: subtract fees, subtract refunds, adjust for payments not yet settled. If the bridge closes, I send it to the business with each line explained. If it does not, we have a real problem and I would treat it as an incident. Either way, the report should show this bridge itself.”
Weak answers tell the business the numbers are correct without showing how they connect.
8. Why do you want to be an engineer at Stripe, where a rounding rule you write ends up in thousands of businesses' accounts?
- Say what attracts you about this kind of engineering.
- Link it to your own work.
- Name what you want to learn.
- Keep it about the work.
“I enjoy work where being exactly right matters more than being clever. A subscription rule or a rounding choice sounds small, but a business will build its accounts on it, and a wrong answer is a wrong number in someone's books months later. In your project I learned to write rules down before writing code, and to keep the inputs so I could explain any result. I want to do that where the rules are money, learn from people who have handled the strange cases for years, and write APIs that other engineers trust without reading the source.”
Weak answers mention the company's reputation and never mention exactness, businesses or APIs.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.