Stripe interviews are very practical and focused on real-world payment problems.

The question was about designing a payment system that guarentees exactly-once processing even with retries and network failures. This is literally what Stripe does so they know the space deeply.

I started with idempotency keys: client generates a unique key per payment attempt, server deduplicates. Stored the idempotency key with the payment state in a transactional database.

The nuance was handling partial failures. What if the charge succeeds at the payment processor but the response times out? I discussed a reconciliation worker that periodically checks pending payments against the processor's records.

Also covered the state machine for payment lifecycle: created -> processing -> succeeded/failed -> refunded. Each transition needs to be atomic and auditable.

The interviewer was very engaged and kept pushing on edge cases. What about double refunds? What about currency conversion failures mid-transaction? Good discussion overall.

Stripe's interview process is honestly the most relevant to actual work I've experienced.