Brex · Primly Community

Brex senior / L5 system design interview, what to expect in 2026

remote_swe_42 · 4 replies

Just finished my Brex senior SWE loop in April 2026 and passed, so posting while it's fresh. The system design round was the most interesting part of their process.

They gave me a prompt around building a financial transaction processing system, basically a simplified version of what Brex actually runs. The interviewer was clearly a senior IC on their payments infra team, not a generic interviewer. That matters because they pushed hard on things specific to fintech: idempotency keys, exactly-once delivery semantics, reconciliation flows, and how you handle partial failures when money is in flight.

Format: 45 minutes total. About 5 minutes of clarifying questions, then you drive. I whiteboarded a design on their virtual canvas. They interrupted more than most companies, which I took as a good sign. The questions were thoughtful.

What they cared about most: Consistency guarantees. Do you know the difference between eventual and strong consistency? Do you know when each is appropriate for money movement? Failure modes. They asked me to walk through what happens when a downstream bank API returns a 500 mid-transaction. Scalability at a plausible scale. Not "design for a billion users", just "Brex has N card transactions per second, how does your design hold?" Observability. I mentioned distributed tracing early and got some nods.

I did not get any pure distributed systems trivia (CAP theorem pop quiz style). It was all applied. Felt more like a technical conversation with a peer than a test.

Level: targeting senior / L5 equivalent. Remote, Seattle. One panel member from SF.

Prep that helped: designing payment systems content, idempotency patterns, and honestly just knowing how credit card auth flows work end to end. If you're coming from a non-fintech background spend 3-4 hours on that last part. The interviewer will notice if you don't know what an authorization hold is.

4 replies

infra_ines

Idempotency keys coming up in a design interview is honestly a good signal about the company. Means they've had the outages that teach you why it matters. Did they ask how you'd implement them or just that they exist?

remote_swe_42

Both. They wanted an actual implementation sketch. I went with client-generated UUID stored in a Redis cache with a TTL, checked before processing. They followed up on what happens if Redis is down. That's where strong vs eventual consistency came back.

backend_bekah

Did they ask about event sourcing at all? I've heard some fintech companies are big on that pattern for audit trails.

remote_swe_42

Briefly came up when I mentioned the transaction log. I don't think it was required but it seemed to land well. The auditing angle is definitely relevant at a card company.