Just finished the Affirm senior SWE loop. The system design round was 60 minutes with one interviewer, no co-interviewer shadow. Here's what I walked into.
The prompt was roughly: design a payment processing system that handles installment scheduling, retries on failed charges, and surfaces real-time status to a merchant dashboard. Classic fintech territory.
What they actually cared about:
Reliability and failure modes first. I started sketching the happy path and the interviewer immediately asked "okay, what happens when the charge fails?" before I had even finished drawing the queue. That set the tone. At Affirm this makes sense. BNPL lives or dies on correctly tracking payment state.
Idempotency. Came up explicitly. I said "idempotency keys on the retry job" and got visible head nods. If you haven't thought about idempotency in payment flows, stop and do that now.
Data model questions. Not just the service diagram. He asked me how I'd model installment schedule vs. disbursement vs. ledger entry. The distinction between operational data (what's scheduled) and financial data (what's settled) mattered.
Scale was secondary, not primary. I've been in loops where you estimate QPS in the first five minutes. Here they cared more about correctness than raw throughput. We got to scale eventually but only after the state machine was clean.
Level-specific note: for senior (L5 equivalent), they want you to drive the conversation, not wait for nudges. I was too passive in the first 15 minutes and the interviewer actually said "what would you do next?" to unstick me. At staff+ they probably want you to anticipate tradeoffs unprompted.
Prep that helped: designing payment systems specifically, not generic "design Twitter" problems. Think about: idempotency, at-least-once vs exactly-once delivery, saga pattern for distributed transactions, reconciliation jobs.
No leetcode in the system design round. The coding round is separate (more on that in a different post).