Square · Primly Community

Square senior / L5 system design interview, what to expect and what tripped me up

sre_sol · 4 replies

Just finished the Square onsite for a senior SWE role (what they roughly call L5, though they don't always use that label externally). Four rounds total. I want to write up the system design round specifically because it's the most different from what I prepared for.

The prompt was payment-adjacent. Not "design Twitter" or "design YouTube" -- they gave me a realistic Square-world scenario. Something like: design a system to handle dispute resolution at scale, where merchants and buyers both interact with the same record. I won't give the exact wording but it was squarely (heh) in their domain.

What they care about: Data model first. Before I got into services or APIs they asked me to define the core entities. Dispute, transaction, party, state machine. They pushed back on my initial schema -- "what happens when a dispute has multiple sub-claims?" Good question, I had to revise on the fly. State machines, not just CRUD. Disputes move through states. They wanted me to think about idempotency, retries, what happens when a webhook to the bank fails halfway through. This is fintech, these things matter. Eventual consistency tradeoffs. I leaned toward a strong consistency model (Postgres, single writer) and they probed: "at what scale does this break?" Then we discussed event sourcing as an alternative. I don't think there's a right answer, they wanted to hear me reason.

Things that didn't matter much: I barely touched load balancer config or caching layers. They didn't really care about my CDN strategy.

45 minutes, one interviewer, very conversational. Not gotcha-y at all. I came in expecting the Leetcode-adjacent system design where you draw boxes and name services. This was more of a "show me you understand payment systems" conversation.

Prep advice: read up on state machines, idempotency in financial systems, and the CAP theorem in a payments context. If you've worked on anything with distributed transactions or webhooks, bring those examples.

Total loop was two coding rounds + system design + behavioral. Decision in about 8 business days for me.

4 replies

finance_faye

The state machine focus matches what I heard from someone who went through the loop 6 months ago. Square's entire payment flow is effectively a state machine. If you know that going in and can talk about failure modes at each transition, you're ahead of most candidates.

visa_vik

For the coding rounds, did they expect you to know payment domain logic or were those more standard algorithm questions?

jordan_pm

Idempotency in payments is one of those things you either live with daily or never think about until the interview. The classic: "what happens if we retry a charge and the network response was lost but the charge went through?" Fintech interviewers love this question.

director_dee

As someone on the hiring side: the data model first approach is basically a proxy for "does this person think before building." Candidates who jump straight to drawing microservices before nailing down what data they're storing consistently get lower scores.