A candidate who sails through Mercury’s take-home can freeze in Brex’s system design round, and the reverse happens just as often. Both get filed under “fintech” and prepped for the same way, which is a mistake. Mercury wants to watch you do real work at an unhurried pace. Brex wants to see you reason about card authorization and money movement while the clock runs. Time spent preparing for one buys you almost nothing for the other.
Mercury builds banking for startups and runs a Haskell backend with an Elm frontend, a choice that already narrows the kind of engineer they hire. Brex sells corporate cards and spend management, moves real money at volume, and builds its loop around that.
Mercury’s craft round is the interview
The loop starts with a recruiter call about your background and why fintech, then a technical screen that splits by track. Frontend candidates get a React and TypeScript exercise. Backend and full-stack candidates usually get a SQL pull request to review, where you read a schema change against a payments-style database and leave the comments you would actually write on a teammate’s PR.
The center of gravity is the craft round, a work sample that runs about three hours. An engineer spends the first fifteen to thirty minutes walking you through the task and the constraints. You get roughly two hours to build. The last forty minutes are a code review of what you wrote, done together, the same way a real review happens after you join. Nobody is timing you on a whiteboard or waiting for you to recall an algorithm. They want to see how you structure a small system, name things, handle the edge cases, and talk through the tradeoffs you chose.
Pass that and you reach a virtual onsite built around product thinking, working with a peer, and light architecture. Mercury spreads these across days on purpose, so you are not doing five hours back to back. Candidates consistently call it one of the more humane loops they have been through, and also one of the harder ones to fake, because there is no trivia to memorize and no single trick that saves a weak sample.
The kind of prompts you should expect:
- Review this pull request that alters a transactions table and flag what you would push back on before approving
- Build a small feature against a stubbed API and defend the shape of your data model
- Design the flow for scheduling a recurring transfer, including what happens when one fails midway
You do not need to know Haskell or Elm to get an offer. The stack matters because of what it selects for: people comfortable with types and correctness tend to do well, and the craft round rewards clean data modeling over cleverness.
Brex runs a conventional loop with fintech teeth
Brex uses a more familiar five-stage shape: recruiter screen, a coding round, a technical round centered on system design, a values interview, and a recruiter wrap-up. Candidates report the whole thing averaging around three weeks from first call to offer.
The coding rounds, usually two at about sixty minutes each, lean practical. You build a small backend service from scratch, something like a credit-limit checker, a transaction parser, or a basic rate limiter, or you get handed working code with a bug and asked to find and fix it. You pick the language. The point is watching you write and reason about real code, not solving a contrived puzzle.
The system design round is where Brex shows its hand. The prompts are money problems, not generic “design Twitter” fare. Expect card authorization at scale, transaction ledger design, a fraud detection pipeline, or a rate-limited payment API. A strong answer treats correctness as the first requirement rather than an afterthought, because a ledger that double-counts is worse than one that is slow.
The values round scores you against Brex’s stated principles, with Ownership and “Complexity is the enemy” coming up the most. Treat this as a real gate and bring two stories where you cut scope or killed complexity to ship something that mattered.
Representative questions:
- Design the card authorization path, from swipe to approve-or-decline in well under a second, with a balance hold and a fraud check in the middle
- Build a service that ingests a batch of transactions and flags duplicates
- Design a double-entry ledger that stays correct under concurrent writes
- Tell me about a time you removed complexity instead of adding a feature
| What differs | Mercury (startup banking) | Brex (corporate cards and spend) |
|---|---|---|
| Overall loop | Recruiter screen, track-specific technical screen, three-hour craft round, product-focused onsite | Recruiter screen, two coding rounds, fintech system design, values interview, recruiter wrap |
| Screening round | React and TypeScript exercise, or a SQL pull-request review | Practical coding: build a small backend service or debug existing code |
| Signature round | Craft round with about two hours building and forty minutes reviewing your code together | System design on money problems, discussion-driven, around sixty minutes |
| System design flavor | Light architecture and data modeling inside product work | Card authorization, ledgers, fraud pipelines, rate-limited payment APIs |
| Backend stack | Haskell backend, Elm frontend | Elixir and Phoenix, high-throughput services |
| Culture signal scored | Craft and judgment over speed | Ownership and “Complexity is the enemy” |
| Typical timeline | Spread across several days by design | Around three weeks start to offer |
What Haskell, Elm, and Elixir tell you
Neither company quizzes you on its language, but the stack is a strong hint about what the interviewers value. Mercury’s Haskell and Elm say they care about types and provable correctness, and the craft round is where that shows up: model the data well and the rest tends to follow. Brex’s backend has leaned heavily on Elixir and Phoenix, a choice made for high-throughput, fault-tolerant money movement, which is exactly what the system design round probes. Idempotency and ledger correctness are not bonus points there; they are the whole question.
So the underlying signal differs. Mercury is asking whether you have taste and can do the actual job at a sustainable pace. Brex is asking whether you can keep money correct when the system is under load and something is actively trying to defraud it.
How to prepare for each without wasting weeks
For Mercury, skip the algorithm grind. Practice reading SQL pull requests and saying out loud what you would change and why. Sketch data models until it feels automatic. Do a timed build against a fake API and force yourself to narrate the tradeoffs as you go, because the review portion is half the score. If you are on the frontend track, get fluent in React and TypeScript instead of memorizing library APIs you can look up.
For Brex, rehearse fintech system design directly. Get comfortable with idempotency keys, double-entry ledgers, authorization latency budgets, and rate limiting, and be able to sketch each on a call without a diagram tool in front of you. Warm up with timed backend coding so sixty minutes feels short rather than frightening. Write out two values stories in advance, one about ownership and one about cutting complexity, so you are not inventing them live under pressure.
Offers and the equity question
Both are private, well-funded scaleups, and senior engineering total comp at each lands in a competitive range for the tier, with a meaningful equity component on top of base. The catch with private-company equity is that it is far harder to value than public RSUs, so a headline number can mean very different things depending on the strike price, the last valuation, and how far off any liquidity is. Before the onsite, ask the recruiter for the band for your level and the refresh policy, and cross-check what you hear against levels.fyi rather than trusting a single figure.
If you only have time to prep for one, prep for the round that scares you more. For most engineers that is Brex’s ledger question, because you cannot fake correctness under concurrency in forty minutes, while Mercury’s craft round rewards the habits you already have if you have been doing the job well.
Practice the behavioral round:
