If you have ever interviewed at a regular fintech and walked out feeling like you mostly answered LeetCode questions about transaction tables, an interview at Mercury will feel like a different sport. The company is one of the most distinctive engineering organizations in the entire fintech space — built on Haskell on the backend and Elm on the frontend, run by founders who care visibly about types and invariants, and shaped by the operational reality that every line of code in their system touches real money belonging to real venture-backed startups.
That technical character runs straight through the interview process. Mercury's loop is more rigorous than most B2B SaaS companies and noticeably less stressful than the median FAANG loop. The bar is high, but the rounds are calibrated to real working signal — not to artificial trick questions. This guide walks you through every round, what the interviewers are actually testing, and how to prep efficiently.
Quick Context: Why Mercury's Loop Is Different
Mercury was founded in 2017 by Immad Akhund, Jason Zhang, and Max Tagher to build banking infrastructure for startups. The company has grown to roughly 1,500 employees, with a $1.6B+ valuation and 200,000+ business customers. The product surface is large: checking and savings, a credit card, working-capital products, treasury, bill pay, spend controls, and a growing developer platform.
What makes the interview loop unusual is that Mercury's leadership has made an explicit bet on type-driven design. The backend is Haskell. The frontend is Elm. Internal libraries lean on advanced type-system patterns. The interview process therefore screens for two things at once: (1) you can ship production-grade software in a regulated domain, and (2) you have enough type-system intuition to grow into the stack within 2-3 months of joining.
The Mercury Interview Loop: All Six Rounds
The full process for a senior software engineering role has six discrete stages. Elapsed time is usually 3-5 weeks from first recruiter conversation to final offer.
Recruiter Screen
30 minA standard get-to-know-you call. Your recruiter walks through your background, your interest in Mercury specifically, the team you're being considered for, comp expectations, and timeline. This is also your first chance to ask substantive questions about the role.
How to prep: Have a clean two-minute version of your story. Know one specific thing about Mercury beyond "you do banking for startups" — mentioning their type system, their product velocity in 2024-25, or the founder's prior company (Heyzap) is a green flag. Ask one question that signals you've thought about the job, not just the brand.
SQL / Code Review Screen
60 minThe first technical round is distinctive: it's a SQL exercise paired with a code review. You'll be asked to write or modify SQL queries against a realistic schema (think: business accounts, transactions, partner-bank relationships) and to walk through a code change — either reviewing a pull request the interviewer shares or making a small one yourself.
What they're testing:
- Can you write correct, idiomatic SQL against an unfamiliar but realistic schema?
- Do you ask the right clarifying questions about the data model?
- When reviewing code, do you catch correctness issues — not just style?
- Do you reason about edge cases (NULLs, partial failures, duplicates) before the interviewer brings them up?
How to prep: Practice window functions, CTEs, and aggregation against realistic business data (transactions, ledgers, account hierarchies). For the code review portion, treat any PR you read in the next two weeks as practice — write down what you'd comment on before reading actual review comments.
The 3-Hour Take-Home
3 hours synchronousThis is the longest single component of the loop. A Mercury engineer briefs you on a problem and parameters for 15-30 minutes. You then code for ~2 hours. The final 30-40 minutes are spent walking through your code with the interviewer, who asks about decisions you made, edge cases you handled, and how you'd extend the design. The exercise is synchronous — you do it live, not on your own time.
What they're testing:
- Can you write a small but realistic backend service from scratch under time pressure?
- Do you decompose the problem before diving in?
- Are your data structures and error-handling deliberate, or accidental?
- When the interviewer pushes on a design choice, do you defend it or update it appropriately?
How to prep: Practice in the language you're strongest in. Time yourself building a small service end-to-end (e.g., a simple ledger API or a rate-limiter) in 90-120 minutes. Treat tests, edge cases, and clean structure as part of the deliverable — not extras. Be ready to explain trade-offs you didn't make as well as the ones you did.
System Design (Banking-Flavored)
60 minMercury's system design round leans hard into the actual problem domain. Don't expect "design Twitter" prompts. Expect prompts that revolve around money movement, idempotency, audit trails, partner-bank failure modes, fraud detection, and regulatory reporting.
Common problem spaces:
- Design the ACH transfer orchestration system with retry handling and partner-bank dependency
- Design the ledger that records every money movement (with reconciliation and audit requirements)
- Design the fraud signal pipeline (real-time scoring with offline backtesting)
- Design a card authorization system with stand-in processing for partner-bank outages
- Design the BSA/AML monitoring queue, including alert generation and analyst workflow
What they're testing: Specifically, your reasoning under correctness-critical constraints. There is a right answer to "what happens if the partner bank is down for 4 hours" in a way there isn't for a typical "design Twitter feed" question. They want to see you reach for idempotency keys, ledger-style state, and reconciliation processes without prompting.
How to prep: Read the canonical references on idempotent APIs and event-sourcing patterns. Stripe's engineering blog (their Idempotency Keys posts in particular) is required reading — the concepts translate directly. Practice with prompts from our Stripe interview guide too, since the patterns overlap heavily.
The Craft / Type-System Round
60 minThis is the round Mercury is known for — sometimes called the "Craft round" internally — and it's the most distinctive part of the loop. It's a conversational round about how you think about types, invariants, and code design. You'll either review a code snippet the interviewer shares or sketch an API or data model in response to a prompt. The language you use is yours to choose.
What they're testing:
- Do you reach for type-level constructs (sum types, refined types, parse-don't-validate) to model state explicitly?
- Can you articulate why making illegal states unrepresentable matters — in a financial system in particular?
- When asked about error handling, do you reason in terms of total functions and exhaustive cases, or in terms of exceptions and catch-alls?
- Are you allergic to ambiguity in data shape, or comfortable with it?
The interviewers are not looking for Haskell-specific knowledge. They're looking for the underlying intuition. A senior engineer who has read Alexis King's "Parse, Don't Validate" essay or Rich Hickey's design talks will recognize this round immediately — the question is whether you can apply that intuition to a fresh problem.
transferMoney(fromAccount: String, toAccount: String, amount: Number). What states can this function be called in that you'd want to prevent? How would you change the signature to make those states unrepresentable? Now: what does the return type look like, and how does it handle the case where the partner bank says 'maybe'?"
How to prep: Read Parse, Don't Validate by Alexis King. Skim a beginner Haskell tutorial just to absorb the vocabulary (Maybe, Either, sum types). Then practice rewriting messy functions from your own codebase using stricter types — not just adding TypeScript annotations, but actually making the type system express the invariants of the domain. The goal is intuition, not language fluency.
Hiring Manager / Behavioral
45-60 minThe final round is with the hiring manager (or founding team for senior+ roles). It covers your past projects, your comfort with regulated and correctness-critical work, how you collaborate, and how you handle long-tail failure modes — situations where the right answer requires patience and rigor rather than speed.
Common topics:
- Walk me through a project where the most important work was the part nobody saw (e.g., careful migration, dead-code removal, observability buildout)
- Tell me about a time you found a bug that no one else would have caught
- How do you think about working in a regulated environment? Have you done that before?
- How do you decide what level of robustness is enough?
- What's an opinion you hold about software engineering that most of your peers disagree with?
How to prep: Have 3-4 stories ready, calibrated to senior-IC scope. Mercury cares deeply about candidates who take craft seriously — if you have a story about catching a subtle correctness bug, improving system observability, or pushing back on a "ship it" instinct in favor of doing it right, that's gold. Avoid stories that frame you as the hero in a way that erases the team.
What Mercury Looks For (and What's a Red Flag)
Green flags
- You think out loud and update your design when given new information — without ego.
- You reach for explicit data modeling before you reach for logic.
- You have read at least one engineering blog post that took types seriously.
- You can articulate why correctness matters in financial systems specifically — not in the abstract.
- You've thought about how the engineering culture you want to work in relates to the product you're building.
Red flags
- You treat the Craft round like a vocabulary check. The interviewer doesn't care if you say "monad." They care if you reason like one.
- You're dismissive of strongly-typed approaches because "TypeScript already does that."
- Your system designs jump to scaling concerns before establishing correctness invariants.
- You frame past failures purely as someone else's problem.
- You haven't done basic homework on the product. A 60-second look at Mercury's culture profile would catch that.
Compensation Context
Mercury is one of the better-paying fintechs but does not chase frontier-lab numbers. Senior engineer total compensation is typically in the $230–$320K range, with strong equity grants given the company's growth trajectory and $1.6B+ valuation. Comp is geo-adjusted — SF and NYC sit at the top of the bands, with remote roles adjusted moderately. For a fuller comparison with other fintechs, see our 2026 tech hiring market analysis.
See open Mercury roles — with culture context
Live Mercury openings across engineering, product, and operations — alongside roles from Stripe, Plaid, Ramp, and 113+ other companies.
View Mercury Jobs → See Mercury Culture Profile →One Last Note on the Mercury Style
The single most useful thing to internalize before walking into a Mercury interview is that the company genuinely values how you reason, not how quickly you arrive at an answer. Engineers who slow down, ask clarifying questions, sketch out the data model before coding, and explicitly state assumptions tend to do well across every round.
Engineers who pattern-match aggressively (any "this is just like X at my last job" instinct) tend to miss the part of the problem that Mercury actually cares about — the part where small correctness choices compound into systems that move billions of dollars without losing track of a cent. If that framing excites you, you're already 80% of the way there.