Brex Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Brex: it's a fintech that moves fast and cares a lot about correctness, because it moves real money.

• A bug in a normal app shows a wrong number on a dashboard.
• A bug here double-charges a corporate card or mis-states a company's spend ledger.
• Then someone's month-end close breaks, auditors ask questions, and the account manager gets an angry call.

So the bar is a specific blend.

• They want engineers who ship quickly AND sweat the edge cases.
• Speed without care gets you rejected. So does care without speed.
• Interviewers are trained to feel for both in the same session.
• The debrief form has separate lines for "velocity" and "correctness." You need a green mark on both.

2Getting the call (the part most guides skip)#

Brex gets a flood of applications. A cold apply works, but a referral changes your odds hard.

• Referral beats cold, every time. A referred resume gets read in full. A cold one gets six seconds and a keyword scan.
• No contacts? Make one. Find Brex engineers on LinkedIn, read something they built or posted, send a short honest note (two or three sentences: what you liked, one line on why you'd fit).
• The point of the referral: it gets a human to open your resume instead of trusting the filter.

Your resume needs numbers. Recruiters and the ATS both scan for impact and stacked keywords. Compare these two:

• Weak: "worked on payments backend." That's a to-do item, not an accomplishment.
• Strong, see the shape below.

Rebuilt the transaction reconciliation job in Go, cut nightly processing from 40 min to 6 min and eliminated ~0.3% duplicate-charge errors across 2M daily transactions.

Every bullet should have that shape: what you built, what tech, how big, what measurably changed. If a bullet has no number, the fix is almost always one of three you already know:

• A latency or throughput figure.
• A percent reduction in errors or cost.
• The scale you operated at (requests per second, rows, dollars, users).

Keywords that help for Brex SWE roles:

• The languages they use heavily: a lot of Kotlin and TypeScript, plus Go and React.
• Plus: distributed systems, event-driven, Postgres, Kafka, gRPC, payments, ledger, API design.
• Don't keyword-stuff. Put the real ones you've touched in the top third of page one, because that's the part a recruiter actually reads before deciding to keep going.
• A strong keyword buried in bullet four of job two never gets seen by a tired recruiter.

How people actually get shortlisted:

• A referral.
• A resume showing you built and owned something real end to end (not "contributed to").
• A signal you care about fintech or hard backend problems.

3The loop at a glance#

The order and count shift by team and level.

• Senior candidates get more design. New grads get more pure DSA.
• The machine-coding round is the one constant, and it's the one every interviewer talks about in the debrief.
• The debrief is where your fate is decided: each interviewer gives a hire or no-hire with evidence.
• A single strong "no" on the machine-coding round is very hard to override, even if the rest of the loop went well.

4The coding rounds#

The phone screen is a single medium problem. LeetCode-flavored, but not tricky for tricky's sake.

• Expect: hash maps, two pointers, intervals, string parsing, graph/BFS/DFS, a bit of dynamic programming.
• Difficulty sits in the medium to medium-hard band. You rarely get a nasty hard-DP problem.
• The problem is often a stand-in for something real: merging overlapping transaction windows (intervals), deduping events by key (hash set), parsing a statement into records (string parsing plus a small state machine).
• What matters is HOW you work, not whether you spot a trick.

What I'm actually scoring while you code:

• Do you clarify the input before you jump in?
• When I run a loop in my head against your solution, do your edge cases hold: empty input, one element, duplicates, negatives, overflow?
• Do you say the complexity out loud without me asking?
• Do you test your own code after writing it, or declare victory and lean back?

That last one matters more than people think.

• A candidate who finds and fixes their own bug scores higher than one who wrote clean code but never checked it.
• Self-correction is the single clearest signal that you'll catch your own money-moving bug before it ships.

Practice this way.

• Pick 60 to 80 mediums across the patterns above.
• Talk out loud the whole time, even alone.
• State the brute force, state the optimal, give Big-O for both, then code.
• End every problem by dry-running one example and one edge case.
• The goal isn't to memorize problems. It's to make "clarify, plan out loud, code, test" your default so the clock and the stranger watching you can't knock you off it.

Four habits that win the round:

• Clarify. Ask about input size, types, nulls, sorted-or-not before writing a line. Thirty seconds here saves you from solving the wrong problem, and I count every clarifying question as a plus.
• Communicate. Narrate your plan before you type. Silence reads as "stuck," and I start wondering if you're lost. A rough plan said out loud beats perfect code typed in silence.
• Complexity. Say time and space, and whether you could do better. Volunteer it. "This is O(n log n) for the sort, O(n) space, and I don't think we can beat n log n because we need the ordering" is exactly the sentence I want.
• Test. Walk a real input through your code at the end, line by line. Catch your own bug before I do. I'll always catch it, and it looks better if you got there first.

5The machine-coding / low-level-design round#

This is the round that defines Brex, and it's where strong LeetCoders often fall apart.

• You get a spec for a small system: a rate limiter, an in-memory key-value store with expiry, a simple ledger that tracks balances across accounts, a parking lot, a card-authorization simulator, a job scheduler.
• You have 60 to 90 minutes to build something that actually runs and does what the spec says.
• There is no hidden trick. The point is to see you write software the way you'd write it at work.

This is a "can you write real software" test, not an algorithm puzzle. I'm looking at:

• Clean class and function design. Good names. Sensible separation between the thing that stores state and the thing that decides policy. If your rate limiter and your storage are the same class, that's a mark against you.
• Core behavior first, edge cases second, in that order. Get one real operation working end to end before you touch anything fancy.
• Extensibility. If I ask mid-round to add a feature (say a sliding-window limit on top of a fixed-window one), does your design bend or break? This is the single biggest signal, and I almost always ask.
• Working code. It compiles, it runs, it produces right answers on the examples I throw at it.

How to win it:

• Start by restating the requirements and writing down 4 or 5 concrete scenarios you'll support.
• Sketch your interfaces first (the classes, the methods, the data they hold) before a line of logic.
• Build the simplest correct version end to end, get it running, THEN add the fancy parts.
• Don't gold-plate.

A framework I'd use in the room:

1. Clarify the spec and list the operations you must support. Write them down where I can see them.
2. Name your core entities and their relationships (this is the LLD part). For a ledger: Account, Entry, Transaction, and the rule that debits equal credits.
3. Define the public interface before the internals. Method signatures first, bodies later.
4. Implement the happy path, run it against one example out loud.
5. Layer in edge cases: concurrency, expiry, invalid input, overflow, double submission.
6. Leave 5 minutes to test and talk through what you'd extend next if you had another hour.

Here's the shape of a clean starting point for a ledger, so you can see what "interfaces first" looks like:

class Account:
    def __init__(self, account_id):
        self.account_id = account_id
        self.balance = 0

class Ledger:
    def __init__(self):
        self.accounts = {}
        self.applied = set()  # idempotency keys

    def open(self, account_id):
        self.accounts[account_id] = Account(account_id)

    def transfer(self, key, src, dst, amount):
        if key in self.applied:
            return  # already applied, safe to retry
        if self.accounts[src].balance < amount:
            raise ValueError("insufficient funds")
        self.accounts[src].balance -= amount
        self.accounts[dst].balance += amount
        self.applied.add(key)

Read what that code is saying:

• The idempotency key is baked in from the start. That one detail tells a Brex interviewer you understand the domain.
• What's missing is missing on purpose: no amount validation (reject zero and negatives), no check that src and dst exist, no concurrency guard.
• Those are the exact edge cases I'd ask you to add next.
• If your structure is this clean, each is a two-line change instead of a rewrite.

For E4 and above there's usually a true system design round too.

• Classic prompts: the card transaction authorization flow, a ledger service that stays consistent, a rate limiter at scale, a notification/alerts system, an API for expense submission.
• Because it's fintech, they care hard about consistency, idempotency (what if the same payment request arrives twice), audit trails, and failure handling.
• Use a simple frame: requirements and scale first, then API, then data model, then the core flow, then scaling and failure modes.
• Always name a consistency model, and always say how you'd make an operation safe to retry.

Say these three things and you sound like you already work there:

• An idempotency key on every write.
• An append-only ledger, so you never mutate a posted entry.
• A reconciliation job that compares your ledger against the source of truth and alerts on drift.

6Behavioral and culture fit#

Brex's values center on being an owner, moving with urgency, and raising the bar. In practice they probe four things:

• Do you take real ownership?
• Do you push for impact without waiting to be told?
• Can you work with people when you disagree?
• How do you behave when things go wrong?

Fintech means "things going wrong" is costly, so the mess question is not a throwaway here.

• Expect at least one question that's really asking: "when you broke something that touched money, what did you do in the first hour, and what did you change so it couldn't happen again?"

Prepare 6 to 8 STAR stories (Situation, Task, Action, Result) covering:

• A hard technical problem you drove.
• A conflict with a teammate.
• A time you shipped under pressure.
• A failure you owned.
• A time you pushed back on a bad decision.

How to tell them:

• Every result ends in a number or a clear outcome. Vague endings ("and it went well") read as fiction. Specific endings read as memory.
• Keep each story to about 90 seconds spoken.
• Heavy on the Action part (that's the "I" part they score), light on Situation setup.

Here's one worked example:

Situation: Our payment-sync job silently dropped ~2% of transactions during a provider outage, and finance caught it a day later. Task: I owned the sync pipeline, so I had to stop the bleeding and make sure it couldn't happen quietly again. Action: I added idempotency keys and a dead-letter queue for failed records, then built a reconciliation check that alerted if sync counts drifted more than 0.1% from the source. I wrote the postmortem and walked the team through it, no blame, just fixes. Result: Zero silent drops in the following 9 months, and the drift alert caught two real provider issues before finance ever noticed. The reconciliation pattern got adopted by two other teams.

Why that story lands:

• It shows ownership, urgency, and raising the bar in one shot.
• It shows the instinct Brex screens hardest for: you didn't just fix the one bug, you made the whole class of bug visible and impossible to ship quietly again.

Ask of every story: did I fix the instance, or did I kill the category? The category answer wins.

7Your prep plan#

4-week plan

• Week 1: 20 mediums across hash maps, two pointers, intervals, BFS/DFS. Talk out loud every time.
• Week 2: 20 more mediums plus 3 machine-coding builds (rate limiter, KV store with expiry, simple ledger). Make them run.
• Week 3: System design fundamentals, 5 full designs, focus on idempotency and consistency. Write 6 STAR stories.
• Week 4: Mock interviews, 2 timed machine-coding builds, polish stories, research Brex's product deeply.

2-week plan

• Week 1: 25 mediums with narration, 3 machine-coding builds, 4 STAR stories.
• Week 2: 3 system designs, 2 timed machine-coding runs, 2 mocks, read about Brex and fintech basics.

2-day crash plan

• Day 1: 10 mediums covering the top patterns, 2 machine-coding builds end to end, write 4 STAR stories with numbers.
• Day 2: 1 system design walk-through, 1 timed machine-coding build, re-run your weakest patterns, prep 3 questions to ask them.

The one non-negotiable across all three plans: a timed machine-coding build the day before.

• It's the round that decides the loop, and it rewards reps more than reading.
• Set a real 60-minute timer, pick a prompt you haven't seen, force yourself to get it running with one clean extension point before the bell.
• Doing that once under the clock teaches you more than reading five guides.

8Why people get rejected at Brex#

1. Treated machine-coding like LeetCode. Wrote one giant function instead of clean, extensible classes. The code worked but couldn't absorb a single new requirement, so the mid-round "add this feature" ask turned into a panic rewrite.
2. Coded in silence. If I can't follow your thinking, I can't give you credit for it. A correct answer with no narration scores lower than a near-miss with clear reasoning.
3. Code didn't run. In a build round, non-working code is close to fatal. Get something running early.
4. Ignored fintech edge cases: duplicate requests, partial failures, concurrency. These are the bugs that cost money, so skipping them reads as "doesn't belong near a ledger."
5. Behavioral answers with no ownership ("the team decided") or no measurable result. Say "I," and end on a number.
6. Zero curiosity about the product. Candidates who can't say why Brex is interesting read as "just need a job," and that lands flat with a hiring manager choosing between two strong resumes.

9The offer, comp and negotiation#

Rough 2026 ranges. These move with level, team, and market.

• US, E3 (new grad): ~$150k-$170k base, ~$210k-$260k total comp with equity.
• US, E4 (mid): ~$185k-$210k base, ~$280k-$360k total.
• US, E5 (senior): ~$210k-$240k base, ~$360k-$450k total.
• Canada (Vancouver): typically 70-80% of the US figure in CAD terms.
• Brex is US and Canada heavy for SWE. They do not run a large India engineering hiring pipeline, so treat any India numbers you see with suspicion.

Equity is a real part of the package here, and it's where numbers swing most.

• As a private company, equity is the lever with the most give and the most uncertainty.
• Understand what you're actually holding before you compare offers on the total-comp headline alone.
• Ask three plain questions: how many shares, what strike price, what preferred price was the last round done at.
• The gap between strike and preferred is roughly today's paper value per share. Until you know it, "total comp" collapses to base plus a guess.

Negotiation tips:

• Get a competing offer if you can. It's the single strongest lever and Brex recruiters expect it. One real competing number moves the package more than any amount of asking.
• Negotiate equity and sign-on, not just base. There's often more give there, because base is constrained by level bands while equity and sign-on bonuses are more flexible.
• Be specific and calm: "Based on my level and competing offers, I'm targeting X total comp." A specific ask is something a recruiter can take to the team. A vague one just stalls.

If you want, map these rounds onto your own calendar with dated milestones so you walk in on interview day knowing you did the work.