Revolut Interview Guide (2026)

1Snapshot, read this first#

The one thing to internalize about Revolut: it moves fast and expects you to own things end to end.

• They are not hiring a ticket-closer who waits for a Jira card.
• The culture runs on a KPI tree: almost every team and most individual engineers carry a number they are accountable for moving.
• They want someone who sees a gap, builds the thing, ships it to production, measures whether it worked, and does not wait for a sign-off to start.
• If "no owner, so I left it" is how you think, this is the wrong company.

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

Revolut hires in volume and genuinely reads applications, but it also moves fast, so a weak resume gets a no in seconds.

Referrals help, but less than at some places.

• The internal referral culture is active and they pay referral bonuses, so employees do submit people.
• A referral mostly buys a faster look and a recruiter who opens your CV instead of letting it sit. It is not a guaranteed screen. The bar is still the bar.
• If you know someone there, ask them to message the recruiter or hiring manager directly with one line on why you fit the team, not just click the portal button.
• A named intro from an engineer on the actual team is worth far more than a generic portal referral.

Make your bullets measurable. Revolut is a metrics-obsessed company whose internal culture runs on numbers and weekly KPI reviews, so speak that language on the resume.

• Weak: "Worked on payments backend service and improved performance."
• Strong: "Rebuilt the card-authorization path in Kotlin, cut p99 latency from 180ms to 42ms, handling 3k auth/sec during peak."

The strong version reads like someone who already thinks the way Revolut thinks: a specific system, the real tech, a before-and-after number, and the load it ran under. A recruiter skimming 200 CVs stops on that one.

ATS keywords that actually matter here.

• Backend: Kotlin, Spring, PostgreSQL, Kafka, gRPC, microservices, Kubernetes.
• Android: Kotlin, Jetpack Compose, Coroutines, MVVM.
• Frontend: React, TypeScript, Redux.
• Put the real stack you used, and do not keyword-stuff things you cannot defend, because they hand you that exact stack and watch you use it live.
• If your CV says Kafka and you cannot explain consumer groups and offset commits in the concepts round, that gap sinks you faster than never listing it.

How people actually get shortlisted:

• A clean one-page resume.
• A stack that matches the team you applied to.
• At least one project where you clearly owned the outcome from idea to production.
• Recruiters here skim for ownership signals fast. "Led," "built," "shipped," "owned," each followed by a number, beats "contributed to" every time.

3The loop at a glance#

Reading the table:

• Order varies by team and region. Mobile and backend loops differ in the technical rounds but share the shape.
• On the recruiter screen, give a comp number if they ask. Revolut recruiters are direct and will tell you if your expectation is out of band, which saves everyone three weeks.

4The coding or technical rounds#

Two very different coding experiences. Do not confuse them, because prep for one does almost nothing for the other.

The DSA screen is a filter, not the main event.

• A timed online test on CodeSignal or HackerRank, medium difficulty, occasionally one harder question, often 3 to 4 problems in 60 to 90 minutes.
• Topics: arrays, hashmaps, strings, two pointers, sliding window, basic graphs and trees, a bit of dynamic programming. Nothing exotic.
• What trips people: the time pressure and the auto-scored format. No partial credit for a nice approach, only passing test cases count.
• You need clean, correct, and fast enough to finish. Practice until medium LeetCode feels boring and you write the common patterns from memory, not re-deriving them.

The patterns they reuse:

• Sliding window on strings, interval merging, graph BFS and DFS, prefix sums, and a classic DP like coin change or a longest-increasing-subsequence variant.
• Hash-based counting shows up constantly, because it maps straight to real fintech problems: deduplicating transactions, counting events for rate limiting, grouping by account.
• If you can recognize "this is a frequency-count problem" or "this is a sliding window with a running sum" in the first 30 seconds, you pass the screen on time.

The machine-coding round is where Revolut is different, and where people lose the offer.

• A live session, usually 60 to 90 minutes, where you build a small working program from a spec.
• Typical prompts: a simplified transaction ledger, a currency converter with a rate table, an in-memory key-value store with expiry, a simple order or payment matcher, or a parser.
• It is real code, in a real editor, in your real language, and the interviewer watches you work.

Here is what they are actually grading, and most candidates never figure this out:

1. Do you write code that a teammate could maintain? Clear names, small single-purpose functions, obvious structure. Not clever one-liners. Ask yourself: if a new hire opened this file on day one, could they read it top to bottom and understand it?
2. Did you handle the obvious edge cases? Null inputs, empty collections, concurrent access, invalid currency, negative amounts, an account that does not exist. In fintech, the edge case IS the job. A transfer of a negative amount is a theft bug, not a nitpick.
3. Did you make it testable? The strongest candidates write a few quick tests or at least structure the code so tests are trivial to add. That single move signals seniority louder than anything else in the round, because it says you think about correctness before someone tells you to.
4. Can you take a follow-up change calmly? They will add a requirement near the end on purpose. "Now support multiple currencies." "Now make deposits and withdrawals thread-safe." If your design was clean, this is a 10-minute change. If you hard-coded a single currency and used global state, you unravel.

How to win it, in order:

• Restate the spec in your own words and ask two or three sharp clarifying questions: "Can amounts be negative?" "Do I need to support concurrent access?" "Is this single-currency or multi?"
• Sketch the data model out loud before writing a line: "I am going to model a Transaction with an amount stored as a long in minor units, cents or pence, so I never touch floating point for money."
• That one sentence makes an interviewer lean in, because storing money as a float or double is the classic junior mistake and you just showed you will not make it.
• Narrate as you build. When you run a quick loop to validate inputs, say out loud what you are checking and why. Silence is the single biggest killer in this round.
• Leave 10 minutes at the end to write a test or two and run them in front of the interviewer.

Here is the kind of modeling that wins it, in Kotlin:

// Money as minor units. No floats near a balance, ever.
data class Money(val minorUnits: Long, val currency: String)

class Ledger {
    private val balances = HashMap<String, Long>()

    fun deposit(account: String, amount: Money) {
        require(amount.minorUnits > 0) { "amount must be positive" }
        balances.merge(account, amount.minorUnits, Long::plus)
    }

    fun transfer(from: String, to: String, amount: Money) {
        require(amount.minorUnits > 0) { "amount must be positive" }
        val bal = balances[from] ?: error("unknown account")
        require(bal >= amount.minorUnits) { "insufficient funds" }
        balances[from] = bal - amount.minorUnits
        balances.merge(to, amount.minorUnits, Long::plus)
    }
}

That snippet does three things an interviewer is scoring:

• Money as a long in minor units, so floating point never touches a balance.
• Input guards on every mutation, so a negative amount or a missing account fails loudly.
• Clear naming, so the shape reads top to bottom.
• When they say "now make it thread-safe," you reach for a lock or atomic structures and you are done, because the shape is already right.

For the concepts round: know your language cold.

• Kotlin: coroutines, null safety, data classes, structured concurrency. What a suspend function actually does, how a coroutine scope cancels, why you would use a Flow.
• Java: the JVM memory model, garbage collection, and concurrency primitives like synchronized versus a ReentrantLock versus an atomic.
• Databases: indexes and when they do not help, transactions, isolation levels, what a deadlock is and how two transactions cause one.
• Your resume: they will dig into a listed project, so be ready to defend every claim with real detail, including a tradeoff you made and a thing that broke.

5System design (for senior) and machine-coding design sense#

For mid-level, "design" shows up mostly as the design quality of your machine-coding solution plus a few concept questions. For senior and above, there is a dedicated system design round, and the fintech angle is not decoration, it is the test.

A framework that works here:

1. Clarify scope and scale. Reads vs writes, latency needs, consistency needs, expected throughput. For a payments company, ask early: does this need strong consistency? Money almost always does.
2. Define the API and data model. Concrete endpoints, concrete tables, concrete fields. Vague boxes labeled "service" lose points.
3. Draw the high-level components. Services, queues, databases, caches. Show the request path.
4. Go deep where it matters. Pick the hard part, the part that would actually page you at 3am, and solve it properly.
5. Talk tradeoffs and failure modes. What happens when the queue backs up, when a write half-commits, when a downstream call times out. This is where senior candidates separate themselves from people who only memorized a reference diagram.

Classic prompts they ask:

• Design a payment processing system. Expect deep questions on idempotency, exactly-once semantics, retries, and reconciliation. Know what an idempotency key is and why every payment endpoint needs one: the client sends the same key on a retry, the server recognizes it, and returns the original result instead of charging twice.
• Design a real-time fraud detection or transaction-limit system.
• Design a currency exchange or FX rate service.
• Design a notification system that fans out to millions.
• Design a rate limiter or a distributed counter.

The fintech flavor is the whole point.

• If you design a payment system and never mention consistency, idempotency, or the double-spend problem, you will not pass, full stop. Say the words out loud.
• Explain why a transfer must be atomic: both the debit and the credit land, or neither does.
• Say what you do on a partial failure: you do not leave money vanished, you reconcile from the ledger.
• Treat the ledger as the single source of truth and everything else as a cache or a view you can rebuild.
• An interviewer who hears "the ledger is append-only and the balance is derived from it" knows they are talking to someone who has thought about money.

6Behavioral and culture fit#

Revolut's values are real and they interview against them hard.

The values that matter, and what each one is scoring:

• Get it done: ownership, bias to action, no excuses, ship it.
• Deliver wow: quality and customer obsession, not "good enough."
• Dream team: hire and work with strong people, raise everyone around you.
• Never settle: keep raising the bar on yourself.
• A strong data-driven streak runs through all of it, which is why every answer needs a number.
• They are proud of being intense and high-output and they say so openly. Do not pretend you want a slow, comfy nine-to-five; that reads as a mismatch they will remember.

Prepare four to six STAR stories.

• At least two should show pure ownership: you saw a problem nobody owned and you fixed it without being asked.
• At least one should show working under real pressure, a deadline or an incident.
• Bring numbers to every single one. This company lives on metrics and a story without a result sounds invented.
• If the result was "it felt better," find the number: latency, error rate, revenue, hours saved, tickets dropped.

A full worked STAR example:

Situation: Our checkout service was silently dropping about 2% of payments during traffic spikes, and no alert caught it. Support was eating the complaints one by one.

Task: I wasn't assigned to it, but I owned payments reliability in practice, so I took it.

Action: I added distributed tracing across the payment path and found connection-pool exhaustion under load: requests were queuing until they timed out. I made the retry logic idempotent using a payment key so retries couldn't double-charge, tuned the pool size and timeouts against the real peak, and added a dashboard with alerting on the drop rate so we'd see it before customers did.

Result: Dropped-payment rate went from 2% to under 0.05%. We caught the next spike before any customer noticed. I wrote a runbook so the next on-call engineer wouldn't need me at 2am.

Why that story lands:

• Ownership: "I took it unassigned."
• A fintech-specific technical move: idempotency on retries so a retry cannot double-charge.
• A hard before-and-after number: 2% down to under 0.05%.
• The Dream team angle: the runbook, so you scaled yourself out.
• It is "I," not "the team." That distinction is scored.

7Your prep plan#

4-week plan:

• Week 1: 40 to 50 medium LeetCode problems across the core patterns. Rebuild them clean, not just "accepted," and re-solve the ones you flubbed without looking.
• Week 2: Machine-coding drills. Build a ledger, a rate limiter, a key-value store with TTL, from scratch, timed at 60 minutes, in your real language. Write tests every time. Then add a surprise requirement to each and see if your design survives.
• Week 3: System design. Study payments, idempotency, consistency, isolation levels, queues, reconciliation. Do 5 full mock designs out loud, including a payment system and a rate limiter.
• Week 4: Write and rehearse STAR stories with numbers. Two timed full mock interviews. Rest the day before.

2-week plan:

• Days 1 to 5: 30 medium DSA problems, focus on hashmaps, sliding window, graphs, DP.
• Days 6 to 9: Two machine-coding builds per day, timed, with tests and a follow-up change.
• Days 10 to 12: System design fundamentals plus 3 mocks.
• Days 13 to 14: STAR stories and one full mock loop.

2-day crash plan:

• Day 1 morning: 10 medium DSA, the exact patterns above. Afternoon: one timed machine-coding build end to end with tests, then force yourself to add one new requirement.
• Day 2 morning: Read up on idempotency, strong consistency, and one full payment-system design. Afternoon: write 4 STAR stories with numbers, say them out loud once.

8Why people get rejected at Revolut#

1. Coding in silence during machine-coding. The interviewer cannot grade your thinking if you do not share it, and they are grading your thinking more than your final code. This is the top reason good coders fail here.
2. Over-engineering the small task. You pull in design patterns, factories, and abstract base classes for a 90-minute build. Revolut wants pragmatic and shipped, not an architecture astronaut building for a scale that will never come.
3. Ignoring edge cases in a fintech context. Floating-point money, negative amounts, no null handling, no "insufficient funds" check. Any one of these is an instant red flag because it is the actual job.
4. Vague behavioral answers. No numbers, no clear ownership. The story sounds like "the team did X" and you cannot say what you personally did or what moved.
5. Pretending you want a calm pace. Revolut is intense and honest about it. Low energy or "I'm looking for work-life balance" as your headline reads as a bad fit here specifically.
6. Can't defend your own resume. You claimed Kafka experience and fold on the first real question about consumer groups, offsets, or what happens on a rebalance. The CV writes a check the concepts round cashes.

9The offer, comp and negotiation#

How the package is shaped:

• Base plus meaningful equity (stock options).
• Equity is a real part of the package here, not a rounding error.
• Revolut's valuation has climbed hard over recent rounds, so the options conversation genuinely matters to the total.

Realistic ranges in 2026:

• US: base ~$150k to $210k for mid to senior, plus equity. Staff higher.
• UK (London): base ~£70k to £110k for mid to senior, plus options.
• India: total ~₹30L to ₹60L+ for mid to senior, with options on top; strong relative to local market.
• EU hubs (Portugal, Poland, Spain, Lithuania): local market rate plus equity; lower cash than US and UK but competitive locally.

Treat these as directional, not a promise. Level and team shift them a lot, and the same title pays differently across these regions.

Negotiation tips:

• Push on equity, not just base. Revolut cares a lot about its options story and there is often more give there than on cash. Ask the specifics: strike price, vesting schedule, cliff, and how they handle liquidity or buybacks, since these are options in a private company, not public RSUs you can sell tomorrow.
• Use a competing offer honestly if you have one. This company respects a candidate who has options on the table. A real competing number with a company name moves things far more than a vague "I was hoping for more."
• Negotiate level, not just dollars. If you are borderline senior, getting bumped a level is worth more than a 5% base bump, and it compounds every year after. Make the case with concrete scope: what you owned, how many people or systems depended on it, the size of the number you moved.

10FAQ#

If you want, map this into a dated, week-by-week plan around your real interview date so nothing gets skipped.