Wise Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Wise: it is a mission company, not a "move fast and break things" one.

• They move real people's money across borders, billions a quarter, with a stated goal of eventually zero hidden fees.
• When your bug is somebody's rent not arriving, code quality and correctness stop being nice-to-haves.
• Every round is a variation on the same question: can you be trusted with money.

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

A referral jumps the queue. Wise hires through their careers page and LinkedIn, but a referral still flags you for a human.

• Ask a contact to refer you through the internal tool, not just "pass my CV along."
• The internal referral flags your application for a recruiter, so a person reads it inside days.
• The difference is a response in a week versus silence.

No referral? Make the resume do the work. Recruiters scan for three things: impact on money, scale, reliability.

• If a bullet touches none of those, it is filler. Cut it.
• Here is a bullet that lands:

Rebuilt the payment reconciliation service in Kotlin, cutting settlement mismatches by 92% and reducing nightly batch time from 40 minutes to 6, across 2.3M daily transactions.

Why that bullet works.

• The shape: what I built, in what language, with a percentage and an absolute number, at a scale that implies production.
• "Settlement mismatches" and "reconciliation" are their exact domain, so the recruiter thinks "this person already works on our kind of problem."
• It beats "worked on backend services using microservices," which says nothing about whether you can be trusted with a ledger.

ATS keywords, used inside real bullets.

• Backend: Java, Kotlin, Spring Boot, microservices, Kafka, PostgreSQL, REST, gRPC, AWS, Docker, Kubernetes, CI/CD.
• Mobile: Kotlin, Swift, Jetpack Compose, SwiftUI, MVVM.
• Do not keyword-stuff. Attach each to a result, because a human makes the shortlist call and a wall of nouns reads as desperate.

What actually gets you shortlisted.

• A clear resume with 2 to 4 strong quantified bullets per role.
• A GitHub or portfolio that shows you can ship (one finished small thing beats ten abandoned repos).
• Location match. Hubs are London, Tallinn, Budapest, Austin, Hyderabad, Singapore.
• Applying to a hub you cannot realistically work from? Say why in one line, or the recruiter assumes a visa or relocation problem and passes.

3The loop at a glance#

How the loop actually runs.

• Mid-level pipelines sometimes fold system design into the pairing round, or skip it.
• Senior and Staff always get a dedicated design round.
• The order varies by hub, but the machine-coding round is the center of gravity everywhere.
• If you only have time to prepare one thing well, prepare that one.

4The coding or technical rounds#

The DSA is medium, not Google-hard. The difficulty lives in the communication, not the algorithm.

• You will not usually get a cursed DP problem with three hidden edge cases and a trick you had to have seen.
• You will get a problem where the naive solution is obvious, and they watch you get from naive to clean and correct.
• Then you reason about complexity out loud. That narration is the real test.

Patterns they reuse:

• Hash maps and frequency counting (grouping, deduping, "find the first X").
• Two pointers and sliding window (substrings, subarrays, rate windows).
• Trees and simple graph traversal (BFS/DFS, "is this reachable").
• Intervals (merge, overlap, schedule): fits their money and transaction domain.
• Basic parsing (parse a transfer string, a currency amount, a transaction log).

Most problems are finance wording wrapped around a pattern you know.

• "Given a list of transfers, each with a currency and amount, return the net position per currency" is a hash map from currency to a running total.
• "Find the busiest window of transactions in a day" is a sliding window.
• "Merge overlapping settlement windows" is the intervals problem you already know.
• Strip the domain wording, name the pattern, and the problem shrinks.

How to actually win the round, in order:

1. Clarify before you type. Ask about input size, edge cases, empty input, duplicates, negative amounts. At a money company, "can the amount be negative or zero, and is a refund modeled as a negative transfer?" signals you ship to production, not that you pattern-match to LeetCode.
2. Say your plan out loud before coding. "I'll use a map from currency to running total, single pass, O(n) time and O(k) space where k is distinct currencies." Now they know you are not flailing, and a wrong plan gets steered before you waste ten minutes typing it.
3. Write code a human can read. Real variable names (netByCurrency, not m). Small functions. If the interviewer cannot skim your solution and understand it in ten seconds, that is a mark against you even when it is correct, because correct-but-unreadable is a bug waiting to happen in their codebase.
4. Test it yourself. Walk one normal case and one edge case by hand before you say "done." Catching your own bug by tracing input [USD 10, USD -4] out loud beats never having one, because it shows you do not trust code you have not checked.
5. State complexity without being asked. Time and space, then one tradeoff: "I could sort first for readability, but that is O(n log n); the map keeps it linear at O(n)."

Practice set.

• Do 60 to 80 LeetCode mediums across the patterns above.
• Skip the 2-hour hards. They are not representative and they burn your runway.
• Then run the drill most people skip: solve a medium, then rewrite it as if a teammate has to maintain it. Naming, functions, one test.
• That second pass is the exact skill this round scores.

5The machine-coding / pairing round (the one that decides it)#

This is the round people underprepare, and it matters most. You build a small but real feature, often extending a starter repo, sometimes from scratch.

• Think: an in-memory account ledger, a currency converter with a rate table, a transfer-fee calculator, a rate limiter, a parser for a transaction file.
• You get 60 to 90 minutes and an interviewer who is sometimes pairing, sometimes watching.
• They are watching how you design, not whether you finish everything.
• A clean half-finished thing with a clear next step beats a complete tangle.

A framework that works:

1. Model the domain first. Before any logic, define your core types. For a ledger: Account, Transaction, Money (amount plus currency, never a raw double for money; use a fixed-point value or a minor-units integer like pence or cents). Getting Money right as its own type, so USD 10 can never be added to GBP 10 by accident, is the single strongest green flag that you understand the domain. Do this in the first five minutes.
2. Start with the simplest correct version. Make one happy path work end to end: deposit, then transfer, then read a balance. Do not build abstractions before you have something running. A working deposit at minute 15 buys trust for the rest of the hour.
3. Then handle the real cases. Insufficient balance (reject, do not go negative). Unknown currency. Concurrent transfers (even mentioning thread safety and where you would put a lock scores points). Rounding: bankers' rounding versus half-up genuinely changes the cent when it is money, so say which you chose and why.
4. Write tests as you go. At least a couple. A candidate who writes one test unprompted stands out more than one who writes perfect code with none. Wise is testing-first, so a test proving "transfer of 10 fails when balance is 4 and the balance is unchanged" is pure signal.
5. Leave it extensible. When they say "now add a fee based on destination currency," your design should absorb it without a rewrite. A giant if/else bites you here. A rate source behind an interface lets you plug in a fee rule and smile.

Classic prompts, in some form:

• An in-memory bank with deposit, withdraw, transfer.
• A currency converter that handles cross-rates (USD to GBP via EUR when there is no direct pair).
• A fee engine with tiered rules.
• A simple event log with replay, so you can rebuild state from the events.

6Behavioral and culture fit#

Wise's values are real and used in the room, scored on a rubric, not waved through. The current set centers on:

• Customers love us (customer obsession; the mission is cheaper, fairer money transfer).
• Think like a founder / take ownership.
• Done, better than perfect (ship, iterate, do not gold-plate).
• Mission before ego.

The culture round is not a formality, and it has rejected strong coders.

• An interviewer pushes on whether you actually care about the mission (no hidden fees, moving money fairly) or just want a fintech job.
• Have a real reason. "I hate that banks quietly take 5% on an FX transfer and dress it up as 'zero commission'" beats "I like fintech," because the first shows you understand the exact problem Wise exists to kill.

Prepare 5 or 6 STAR stories:

• A conflict, a failure, a time you took ownership outside your lane, a time you pushed back on a decision, a time you shipped something imperfect on purpose to learn faster.
• Each one needs a number in the result, because "it went well" is not evidence.

One worked example:

Situation: Our checkout service was timing out for about 3% of users during traffic spikes, and we kept blaming the database. Task: I owned reliability that quarter, so this was mine to fix even though I didn't write the original code. Action: I added tracing and found the real cause was a synchronous call to a fraud-check service with no timeout. I made it async with a circuit breaker and a sensible fallback, then wrote load tests to prove it under 3x traffic. Result: Timeout rate dropped from 3% to under 0.2%, and we handled Black Friday with zero incidents. I wrote up the tracing approach so two other teams reused it.

Why that story lands.

• Ownership: not my code, still my problem.
• Customer impact with a real before-and-after number.
• Sharing the win instead of hoarding it.
• It quietly shows "done better than perfect": a circuit breaker and fallback, not a six-month rearchitecture.

7Your prep plan#

4-week plan

• Week 1: 20 LeetCode mediums across hash maps, two pointers, intervals. Write every solution clean enough to hand a teammate.
• Week 2: 20 more mediums (trees, graphs, parsing). Start timing yourself to 25 minutes per problem so pressure feels normal.
• Week 3: Machine-coding. Build 3 small projects from scratch (ledger, currency converter, rate limiter) with tests. Refactor each once, then add a feature to prove it was extensible.
• Week 4: System design (if senior) plus write out all 6 STAR stories with numbers. Do 2 mocks where someone forces you to talk the whole time.

2-week plan

• Days 1 to 5: 25 mediums, focus on clean code and talking out loud, not just the green checkmark.
• Days 6 to 9: Two machine-coding projects with tests, practice narrating every decision.
• Days 10 to 12: STAR stories plus 2 design prompts if senior.
• Days 13 to 14: Two full mocks, then fix your single weakest round.

2-day crash plan

• Day 1: 10 mediums (hash map, sliding window, intervals, trees). Build one tiny ledger with a Money type and 2 tests. Say everything out loud, even alone.
• Day 2: Write 4 STAR stories with numbers. Read Wise's values page twice and tie one story to each value. Do one timed machine-coding problem. Sleep, do not cram.

8Why people get rejected at Wise#

1. Unreadable code. They solved it, but the interviewer could not follow it. Fatal here, because maintainable beats clever on a money codebase.
2. No tests, no mention of testing. In a testing-first culture, this reads as not production-ready.
3. Silent coding. Great solution, zero narration. The interviewer had nothing to assess except the final artifact, and the job is not the artifact, it is the thinking.
4. Used a raw float or double for money. Instant "this person has not thought about financial correctness." 0.1 + 0.2 not equalling 0.3 is a real bug in a real ledger.
5. Hand-wavy mission answer. "I just want to work in fintech" with no real conviction about the customer. Borderlines a strong coder fast.
6. Over-engineering the machine-coding task. Five abstraction layers, a plugin system, a config loader, and never a working transfer. Done beats perfect, and they wrote that value down for a reason.

9The offer, comp and negotiation#

Rough 2026 total comp, varies by hub and level:

How the pay is structured.

• A mix of base, cash bonus, and RSUs.
• Wise is publicly listed, so the equity is real and liquid: you can actually sell it, unlike a private startup's paper.
• It is competitive for the market but usually not the absolute top of band like a FAANG offer.
• Decide early whether mission plus liquid equity plus a sane culture is worth the gap. For a lot of people it is.

Negotiation tips:

• Anchor on total comp, not base. Ask for the RSU and bonus breakdown explicitly, as numbers, then negotiate the whole package. A low base with a strong RSU grant can beat a higher base elsewhere.
• Use level, not just salary. If you are borderline Senior, pushing for the higher level often beats squeezing a few thousand at the lower one. Level sets the band for every future refresh, so it compounds for years.
• Be collaborative, not adversarial. It is a mission company, and the recruiter talks to your future team. "I'm genuinely excited, here's a competing offer at X, can we close the gap" works far better than hardball. Bring a real number if you have one. Do not bluff one you do not; these recruiters know the bands cold.

Want this turned into a dated, day-by-day plan around your actual interview date? Map your rounds to the calendar and work backward from the pairing round; it is the one that decides everything.