Mercury Interview Guide 2026: Startup Banking Platform, Haskell/Elm Stack, and the Craft Round

Mercury Interview Process: Complete 2026 Guide

Overview

Mercury is the startup-focused banking platform offering business checking, savings, credit cards, treasury, bill pay, and spend controls to venture-backed companies and ambitious small businesses. Founded 2017 by Immad Akhund, Jason Zhang, and Max Tagher, private with a 2024 Series C valuation of $1.6B; ~700 employees in 2026. The product is built on partner banks (Choice Financial Group and Evolve Bank & Trust) and has grown into one of the most popular banking platforms for startup founders. Headquartered in San Francisco with offices in New York and Portland plus remote hiring in the US and Canada. Mercury is distinctively known among engineers for its Haskell backend and Elm frontend — unusual choices that reflect a commitment to type-safe, maintainable code for financial infrastructure. Interviews reflect that commitment: expect thoughtful engagement with functional programming, strong typing, and the realities of banking-adjacent engineering.

Interview Structure

Recruiter screen (30 min): background, why Mercury, team preference. The engineering surface is smaller than at larger fintechs but still covers product (accounts, cards, treasury, bill pay), platform, infrastructure, and data / ML (fraud, risk, underwriting). They screen early for openness to Haskell / Elm — candidates hostile to functional languages rarely advance.

Technical phone screen (60 min): one coding problem, medium-hard. Candidates can code in any mainstream language (including Haskell or Elm if comfortable); Python, TypeScript, and Java are common. Problems tilt applied and data-modeling — design a small fraud-detection primitive, model a transfer flow, implement an idempotency layer.

Take-home (many senior / staff roles): 4–6 hours on a realistic engineering problem. Historically involves a small banking or fraud-detection system. Write-up quality and type-discipline matter substantially.

Onsite / virtual onsite (4–5 rounds):

• Coding (2 rounds): one algorithms round, one applied round. The applied round often involves fintech primitives — ledger accounting, transfer idempotency, scheduled-job processing for recurring payments.
• System design (1 round): banking-platform prompts. “Design the ACH transfer orchestration system with retry handling and partner-bank dependency.” “Design the real-time fraud detection pipeline with <50ms scoring latency." "Design the per-customer spending-control rules engine for virtual cards."
• Craft / type-system round (1 round): distinctive at Mercury. A discussion of how you think about types, invariants, and error handling. Candidates with ML / Haskell / Rust / strict-TypeScript background find this round most natural.
• Behavioral / hiring manager: past projects, comfort with regulated environments, handling long-tail failure modes, customer empathy.

Technical Focus Areas

Coding: any mainstream language, with genuine openness to Haskell / Elm but no requirement to use them in interviews. Applied correctness matters more than specific language.

Haskell (if declaring it): ADTs, monadic patterns, property-based testing with QuickCheck / Hedgehog, lens / optics for data manipulation, concurrent programming with STM or async. Not required for most roles but welcomed.

System design: partner-bank integration patterns (banking-as-a-service partners are the actual chartered banks), ACH / wire / real-time payment processing, idempotency under at-least-once delivery, ledger-style accounting with double-entry bookkeeping, reconciliation workflows.

Fraud & risk: feature engineering for real-time fraud scoring, model serving with strict latency budgets, rule engines alongside ML, adversarial-robustness considerations, model monitoring in production, edge cases in consumer-vs-business fraud patterns.

Compliance: KYC / KYB (Know Your Business), AML, Bank Secrecy Act (BSA), OFAC sanctions screening, Suspicious Activity Reports (SARs), partner-bank oversight, SOC 2 Type II controls.

Data: PostgreSQL at reasonable scale, event-sourced ledger systems, analytic workloads against operational data, data-quality tooling for financial data.

Coding Interview Details

Two coding rounds, 60 minutes each. Difficulty is medium-hard. Below Google L5 on pure algorithms; higher on applied correctness and type discipline. Interviewers care about whether you write code that’s reviewable and correct, not just working.

Typical problem shapes:

• Model a transfer lifecycle with all failure paths (pending, authorized, settled, returned, reversed)
• Implement an idempotent processor for at-least-once delivery (message queue consumer handling duplicates)
• Build a rate limiter with fairness guarantees across customers
• Parse and validate structured input (ACH NACHA files, ISO 20022 messages, Plaid-style transaction data)
• Classic algorithms (graphs, trees, DP) with fintech twists (approval chain routing, ledger reconciliation across accounts)

System Design Interview

One round, 60 minutes. Prompts focus on banking-platform reality:

• “Design the ACH orchestration system processing 100K transfers/day with partner-bank dependency.”
• “Design a real-time fraud detection pipeline with <50ms scoring latency and feedback loops."
• “Design the virtual-card issuance and spending-controls rules engine.”
• “Design the reconciliation system that matches Mercury’s internal state against partner-bank feeds nightly.”

What works: explicit engagement with partner-bank-dependency realities (the bank is the chartered entity, Mercury orchestrates), idempotency under network failure, failure-mode enumeration, compliance constraints. What doesn’t: generic microservices designs that don’t acknowledge banking-specific realities.

Craft / Type-System Round

Distinctive to Mercury. A conversation about how you model problems and use type systems. Sample topics:

• How do you represent states that can’t coexist? (make illegal states unrepresentable)
• When do you reach for a sum type vs a field-with-null?
• How do you handle errors — exceptions, Result / Either, or something else?
• Show me a time you caught a bug through the type system.
• When is a type system overkill?

Strong answers: concrete examples from past work, thoughtful engagement with trade-offs, awareness that types are a design tool rather than a correctness guarantee. Weak answers: generic “types are good for documentation” or pure ideological stances in either direction.

Behavioral Interview

Key themes:

• Craft: “Tell me about a time you pushed back on shipping because the design wasn’t right yet.”
• Customer empathy: “Describe a moment where you understood a user / customer need deeply.”
• Ownership: “Tell me about a production incident you owned end-to-end.”
• Regulated-environment comfort: “Have you worked under compliance / regulatory constraints?”

Preparation Strategy

Weeks 3-6 out: LeetCode medium/medium-hard in your chosen language. If you want to engage Mercury’s stack seriously, spend time with Haskell — Learn You a Haskell (free online) or Haskell Programming from First Principles (Allen & Moronuki) are standard entry points.

Weeks 2-4 out: read about banking-as-a-service, partner-bank architecture, and ACH mechanics. Stripe’s engineering blog for idempotency patterns. Mercury’s own engineering blog has occasional posts about Haskell in production. Understand KYB, KYC, and BSA at a conceptual level.

Weeks 1-2 out: open a Mercury account if you’re eligible — understand the product as a user. Prepare 2–3 craft-round stories about type-system engagement and a bug caught through careful modeling. Mock system design with banking prompts.

Day before: review your type-system stories; prepare 3–4 behavioral stories; form an opinion about Mercury’s product direction.

Difficulty: 7.5/10

Solidly hard. Coding bar is comparable to mid-tier FAANG; the craft / type-system round is distinctive and rewards candidates who think about code quality explicitly. Candidates with functional-programming background or strong type-discipline track record have an edge. Strong backend generalists pass with focused prep.

Compensation (2025 data, US engineering roles)

• Software Engineer: $175k–$220k base, $150k–$270k equity (4 years), modest bonus. Total: ~$280k–$420k / year.
• Senior Software Engineer: $225k–$285k base, $280k–$520k equity. Total: ~$380k–$580k / year.
• Staff Engineer: $290k–$355k base, $550k–$1M equity. Total: ~$520k–$830k / year.

Private-company equity valued at recent Series C marks. 4-year vest with 1-year cliff. The company is profitable with strong growth; treat equity as mid-upside with illiquidity risk. Cash comp is competitive with mid-tier fintech. Remote US and Canada hiring is common; comp varies by location within transparent bands.

Culture & Work Environment

Craft-focused, intentionally selective, and engineering-driven. Immad Akhund (CEO) has a visible engineering background and communicates directly about product and engineering decisions. The Haskell / Elm stack choice reflects a broader bet on maintainability over initial velocity — and the team takes this seriously in hiring, reviews, and day-to-day work. Remote-friendly; hubs in SF, NYC, and Portland. Pace is deliberate — neither frantic startup nor public-company slow. The profitability gives engineering room to invest in craft rather than chase quarterly ship metrics.

Things That Surprise People

• Haskell actually works at Mercury. It’s not a vanity choice; the team ships production features in it daily.
• The hiring bar is higher than the 700-person company size suggests.
• The craft round is decisive for many candidates — technical strength alone isn’t enough.
• Customer empathy is real; engineers frequently hear directly from founders using the product.

Red Flags to Watch

• Dismissing Haskell / Elm as “niche” or “hipster.” Mercury chose them carefully; dismissiveness lands badly.
• Weak opinions about type systems. “Types are good” without specifics signals shallow thinking.
• Ignoring partner-bank dependency realities in system design.
• Not having authentic customer empathy. Business banking is serious — founders’ companies depend on it.

Tips for Success

• Engage with the stack. You don’t need to be fluent in Haskell, but know enough to discuss its trade-offs.
• Prepare type-system stories. “I modeled this state machine so that invalid transitions couldn’t compile” — specifics win.
• Know partner-bank banking. The distinction between Mercury and its partner banks is real; understand it before interviewing.
• Use the product. If you can’t open an account, read the Mercury blog and understand the product deeply from the outside.
• Read Immad’s writing. His public posts on engineering culture and product direction are signals of fit.

Resources That Help

• Mercury engineering blog (posts on Haskell in production, infrastructure, architecture)
• Learn You a Haskell for Great Good (free online) or Haskell Programming from First Principles (Allen & Moronuki)
• Stripe engineering blog for idempotency and payment-processing patterns
• Designing Data-Intensive Applications (Kleppmann)
• The NACHA operating rules (ACH primer) for fintech domain
• Immad Akhund’s essays and podcast appearances

Frequently Asked Questions

See also: Brex Interview Guide • Plaid Interview Guide • Chime Interview Guide