The Revolut problem-solving interview

Last verified: August 2026

What the round actually is

You get a problem with deliberately incomplete information. The interviewer is not looking for the answer — they're looking at whether your thinking is structured, whether you notice what information is missing, and whether you can be corrected without losing the thread.

How it's scored

A repeatable structure

1. 1
   Clarify the objective and the constraint. What are we optimising, and what can't we touch?
2. 2
   Restate the problem back. This catches misunderstandings while they're still cheap.
3. 3
   Break it into 3–4 drivers that don't overlap. Say them out loud before going deep.
4. 4
   State a hypothesis. "My instinct is it's X — let me test that." This is what separates senior candidates.
5. 5
   Go depth-first on the branch that matters most, not left-to-right through everything.
6. 6
   Name what would change your mind, then recommend anyway.

The most common failure isn't a wrong answer. It's a candidate who explores every branch evenly, runs out of time, and never commits to a recommendation.

A case, worked end to end

This is a case I was given, worked through the way I'd approach it now. I've reconstructed the figures from memory rather than from a transcript — the shape of the data is right, the exact numbers are illustrative. What matters here isn't the arithmetic, it's the sequence: what I asked, in what order, and how each answer changed where I looked next.

The interviewer had data — but only released it if I asked a question specific enough to deserve it. Vague questions got "I don't have data for that." That constraint is the whole test. You're not being scored on knowing the answer; you're being scored on whether your questions are aimed at anything.

Step 1 — Clarify before structuring

Two problems were handed to me as if they were separate. My first questions were aimed at whether they actually were:

• Which of the two matters more, if I can only move one?
• Is "time to hire" measured from job opening, or from first candidate contact?
• Is there a target, or is this "make it better"?

The answers: both matter, measured from first contact, no fixed target. That last one is useful — no fixed target means I need to find where the loss is concentrated rather than chase a number.

Step 2 — Restate

"So: we're losing backend candidates somewhere between first contact and signature, and the process is slower than we want. I want to find where the time goes and where the people go, and check whether those are the same place."

Cheap to say, and it caught something — the interviewer reacted to "whether those are the same place." That turned out to be the case.

Step 3 — Three buckets

I split the problem three ways:

• 1
  System — the tooling and the process itself
• 2
  Internal — interviewers, scheduling, approvals
• 3
  External — competitors, compensation, market supply

An honest note on this: these overlap more than I'd like. Scheduling sits in Internal but is also a process problem; compensation sits in External but the bands are an internal decision. A cleaner cut would have been by funnel stage, with each stage carrying both a duration and a pass rate. It worked, but I'd structure it differently now — and being able to say that is worth more in the room than pretending the first cut was perfect.

Step 4 — The questions, and what came back

"What does the funnel look like, stage by stage — volumes, conversion, and days spent in each stage?"

This was the question that unlocked the case. Asking for days and conversion in the same breath is what made the rest work.

Two numbers are outliers, and neither is in the middle of the funnel: 12 days waiting for a technical screen, and a 50% offer-accept rate against a healthy 70–90%.

"What tools are we using, and is anything broken?"

Nothing was broken. That mattered — it moved the 12 days out of the System bucket and into Internal. It's a capacity problem, not a tooling one.

"Do we have feedback from candidates who dropped out at the bottom of the funnel?"

"What are competitors offering — are we short?"

Roughly 12–15% below the competitor set on total compensation for equivalent seniority.

Step 5 — The branch that mattered

Here's what the data gives you, and it's the whole case: the two problems aren't separate.

Two of the seven declines had already accepted elsewhere. That isn't a compensation loss — that's a 43-day cycle losing a race. Speed isn't just the first problem, it's a cause of the second one.

So the hypothesis I committed to: time-to-hire is the dominant driver, because it damages both metrics, and the 12-day scheduling gap is the single largest recoverable block of it. I went depth-first there instead of touring the other branches.

Step 6 — Recommendation, and the risk in it

Priority 1 — interviewer capacity and scheduling. Six engineers, manually coordinated, creates the 12-day gap. Widening the pool and moving to self-serve booking attacks 12 of 43 days and recovers roughly 2 of 7 declines. It's the cheapest intervention and the only one that moves both metrics.

Priority 2 — compensation band review. Being 12–15% short explains 4 of 7 declines. It recovers more offers than Priority 1, but costs materially more and moves only one metric.

Everything else is noise at this stage. A 20% application-to-screen rate looks low, but with 1,000 applications the top of the funnel isn't where the constraint is.

The risk in my own recommendation: widening the interviewer pool to cut the wait is exactly how you dilute a hiring bar. The 43% technical-screen pass rate is the guardrail — if it starts climbing after the pool expands, that's not improvement, that's the bar slipping. I'd want it tracked from day one.

What I'd do differently

I spent too long on the System bucket before asking for the funnel. The funnel question is the one that opens the case, and I should have led with it — the tooling questions only became meaningful after I knew where the days were going.

Mistakes that cost the offer

• Jumping into solutions before establishing what success means.
• Using a memorised framework that doesn't fit the problem — interviewers notice immediately.
• Going silent to think. They can't score what they can't hear.
• Treating a correction as a failure rather than new information.
• Running out of time because every branch got equal attention.
• Ending on "it depends" instead of a recommendation with a named risk.

Frequently asked questions

← The full Revolut interview process, round by round

Revolut interview questions, by round →

More on PM interview problem-solving →