How to Answer: "Why Do You Want to Work at Mercury?"

The best answer connects Mercury's product to work you have already done. Mercury builds banking for startups and small businesses, and its product includes checking and savings accounts, debit and credit cards, treasury, bill pay, invoicing, and spend management. Mercury is not a bank itself; it partners with regulated banks and builds the software on top.

A strong answer proves three things: that you understand this product, that you care about correctness because bugs here move money, and that you want to own a product area rather than a narrow task.

What the Interviewer Listens For

1. Real product knowledge. Mercury's job posts describe the goal as "lovable" products that replace expensive legacy tools, so name one part of the product and say why it matters to a founder. Spend management, for example, lets a company issue cards with limits per employee, and naming a specific part like this shows you did real research.

2. Care for correctness. Mercury's backend is written in Haskell, a language with a strict type system, which is the set of rules a compiler uses to reject wrong programs before they run. Mercury's engineers have said publicly that they chose it because customers expect more correctness from a bank. You do not need to know Haskell, but you do need to show you value software that fails before release rather than in production.

3. Product ownership. Mercury's job posts ask for "pragmatic, product-minded engineers" who self organize on small and medium projects, so interviewers want a story where you decided what to build, not only how. A side project with real users works well as proof.

4. Fit with the stated values. Mercury publishes six values: Think actively, Be super helpful, Act with humility, Appreciate quality, Focus on the outcome, and Build relentlessly. Pick one or two and tie them to a real habit of yours, because reciting all six proves nothing.

A Three Part Structure

Part 1: The product (2 to 3 sentences). Say why you want to work on banking software for businesses, and include evidence such as a product you used, built, or studied.

Part 2: Your proof (2 to 3 sentences). Describe one thing you built and owned end to end. Include a number.

Part 3: The direction (1 to 2 sentences). Say what you want to build at Mercury and in which product group.

Sample Answer

"I want to work at Mercury because business banking requires both correctness and product quality. I ran finance tooling at a small company and used Mercury's cards and spend limits myself, so I know the product from the customer side. At my current job I own the billing service end to end: the data model, the reconciliation job, and the alerts. I moved it to an append only ledger and cut billing disputes by about 60 percent in six months. That work taught me how much design goes into making money flows auditable. Mercury solves exactly those problems for its customers, in a codebase designed to catch errors before they run. I want to build in the Banking group, on the systems that move and record money."

This answer works because every claim has proof: the product interest comes from real use, the ownership claim comes with a number, and the direction names a product group.

Where the Question Appears

Expect the motivation question in the recruiter screen first, and then again in the final team conversations in a deeper form, where the second version asks for more evidence, not more enthusiasm. Keep the same core answer both times, because consistency itself is a signal. Add one new proof point in the later round, such as a detail from Mercury's public engineering interviews about Haskell. Interviewers compare notes, and a story that changes between rounds makes them doubt you.

Common Mistakes

• Generic fintech excitement. An answer that fits any payments company fails here, because Mercury serves founders and small businesses and the answer must show that.
• Treating Haskell as the reason. Curiosity about the language helps, but wanting the job only to learn Haskell signals a mismatch with a product first team.
• Hostility to the stack. Mercury's job posts ask for knowledge of Haskell or excitement to learn it, and published interview guides say the recruiter screen checks this. Dismissing it counts against you.
• No product contact. Mercury publishes product pages, help articles, and engineering posts, so arriving without reading any of them looks unserious.
• Asking for narrow scope. Mercury's job posts ask engineers to own projects and work with designers and product leaders, so wanting a small fixed scope is a poor fit.

How to Prepare

• Learn the full loop first. Read What is the Mercury interview process like so your motivation story matches the rounds.
• Extend the product knowledge. The same research applies to the Mercury system design interview, so study the product once and use it twice.
• Know the wait times. How long does it take to hear back after a Mercury interview explains when to follow up.
• Practice the delivery. Grokking Modern Behavioral Interview teaches answers based on evidence, not adjectives.