Stripe Software Engineer Intern Interview Experience (2026) - PaymentLedger OOP & Integration Round, Offer

The gotcha is that this is not algorithmically hard. It is an OOP design check. The interviewer cares whether you pick reasonable data structures, name methods consistently, and handle the edge cases without being prompted.

My structure was a dict keyed on payment id pointing to a small Payment dataclass with amount, timestamp, and a cumulative refund field. A separate defaultdict(list) keyed on date string pointed at the payment IDs for that date, so get payments by date was an O(k) lookup for k matching records. Total revenue was maintained as a running counter updated inside add payment and add refund rather than recomputed every query.

The follow-ups came steady:

1. How do you support partial refunds? Answer: the refund method checks that `amount_refunded_total + new_refund <= original_payment_amount` and rejects the over-refund. I added a `refunded_cents` field to the Payment dataclass and updated it inline.
2. If the record set grows huge, how do you speed up `get_payments_by_date`? Answer: the existing per-date index is already O(k). For extreme scale, bucket at the month level first and scan within the bucket. If you need range queries, a sorted structure like a TreeMap on timestamps is the right tool.
3. What if the caller passes a malformed timestamp? Answer: validate on ingest with `datetime.fromisoformat` and raise a `ValueError` with a clear message. Do not store invalid data and hope the query side catches it.
4. How would you persist this to a database? Answer: two tables, one for payments and one for refunds, with a unique index on `payment_id`. The refund table has a foreign key to the payment row and a `cumulative_refund_cents` denormalized value we update transactionally.

The interviewer spent the last five minutes on error handling. I had wrapped the core path in explicit duplicate detection and the refund math in bounds checks, which he noted positively.

[[problem/10?company=13|Design Payment Ledger]]

Round 2: Integration — Clone, Read, Extend (60 min)

This is the round nobody warned me about. I was handed a link to a small Git repo with a README, a partially implemented payment sync job, and failing unit tests. The task was to make the tests pass and extend the job with webhook handling.

The setup alone took 10 minutes. I had to clone, install dependencies, read the project layout, find the entry point, and run the existing tests to see what was failing. Stripe explicitly grades on how fast you bootstrap in an unfamiliar repo. Practice cloning random GitHub repos and getting their tests green without reading the full source first.

The actual coding breaks into three tasks:

1. Call an external payments API with the provided client class to pull the day's transactions.
2. Handle webhook callbacks that arrive out of order and update transaction status accordingly.
3. Sync transaction status to a local DB, idempotently. Write unit tests for the sync path.

I worked top to bottom. The API fetch was straightforward because the client was already instantiated in conftest.py with mock credentials. The webhook handler needed a small state machine: pending can go to completed or failed , but once completed it can only go to reversed . I wrote the state machine as a dict of allowed transitions and validated every update against it.

The sync step is where idempotency mattered. The existing code was using INSERT , which would duplicate on retry. I changed it to an upsert keyed on transaction id and added a short unit test proving that running the sync job twice on the same payload produced a single DB row.

The last 10 minutes were me writing two more tests: one for an out-of-order webhook arriving after the sync had already completed the transaction, and one for the bounds check on partial refunds. The interviewer thanked me, reminded me to commit the changes, and said they were happy with the progress.

Result

Offer came back four business days after VO2. I was on a walk when the recruiter called. Took me a full minute to process what he said.

Tips

1. Practice reading unfamiliar codebases cold. Clone five random medium-sized Python projects on GitHub and force yourself to run their tests within ten minutes. The Integration round is won or lost on your bootstrap speed, not on how fancy your final code is.
2. Learn Stripe's idempotency vocabulary before the loop. Words like `idempotency_key`, `upsert`, `state machine`, and `out-of-order event` should roll off your tongue. The interviewer wants to hear them. Read Stripe's public API docs for an hour; it is the highest-ROI prep you can do for the intern loop.
3. In the OOP round, maintain running totals. Do not recompute `get_total_revenue` by summing every payment on every call. Keep the total as a field and update it in the mutators. This is the cheapest signal of systems thinking.
4. Validate inputs at the boundary, not in the core. Timestamp parsing, ID format, amount positivity: all of these should fail loudly on ingest. If your core path assumes valid data, you have pushed error handling into the wrong layer.
5. Write tests during the interview, not after. In Round 2 I wrote the upsert test before I wrote the upsert code, which made the fix faster and scored me engineering-hygiene points. Stripe interns often forget that tests are part of the grading surface.
6. Turn on commits early in Round 2. The interviewer explicitly asked me to `git commit` my changes. If you are a developer who lives on `git add` without committing until the end, retrain yourself for this round. Small, labeled commits are the easiest way to signal professional workflow.