Loop Revolut Analytical

Revolut PM Analytical Interview: Metrics, SQL, and Case Questions

TL;DR

The Revolut PM analytical interview tests whether you can define success, write functional SQL, and reason through product trade-offs under ambiguity — not whether you memorize frameworks. Candidates fail by treating metrics questions like exams and overcomplicating case structures. The real filter is judgment: can you isolate signal from noise in a fast-moving fintech environment?

Who This Is For

This guide targets mid-level product managers (2–5 years experience) preparing for Revolut’s analytical interview loop, typically the second or third round after initial screening. You’ve passed early behavioral rounds and now face live whiteboarding on metrics, 20-minute SQL coding on HackerRank or CoderPad, and open-ended business cases tied to Revolut’s core verticals: payments, savings, lending, and stock trading. You need precision, not polish.

What does the Revolut PM analytical interview actually test?

It tests execution clarity under pressure, not theoretical knowledge. In a Q3 debrief last year, a candidate correctly calculated LTV but missed the hiring committee’s concern: they hadn’t questioned whether the cohort was seasonally skewed. The HC approved the candidate anyway — but only because they acknowledged the gap when challenged. Judgment matters more than correctness.

Revolut operates at high velocity. A PM who debates metric definitions for 30 minutes will stall launches. They want people who pick a defensible path quickly, then adapt. Your analytical skills are a proxy for decision hygiene.

Not perfection, but prioritization.
Not completeness, but calibration.
Not accuracy in isolation, but awareness of downstream impact.

One hiring manager told me: “If you take more than 90 seconds to define success for ‘improving card approval rates,’ you’re already too slow.” The expected move is to state the business goal (increase approved applications), identify drop-off points (e.g., credit check failure), and propose a single leading metric (like yield rate post-KYC) — then move on.

They’re not testing whether you know every SQL window function. They’re testing whether you can write a query that answers a real business question — like “What percentage of users who opened a spending account in Q2 made a transaction within 7 days?” — in under 12 minutes, with clean syntax and correct edge-case handling (e.g., NULLs, duplicates).

The case portion isn’t about delivering a 10-slide deck in 20 minutes. It’s about narrowing scope fast. When asked to “improve savings feature engagement,” the strong candidates immediately ask: Which segment? What’s the current retention curve? What’s the North Star? The weak ones dive into gamification ideas without context.

How are metrics questions structured, and what do evaluators listen for?

Metrics questions follow a predictable shape: “How would you measure the success of X?” or “We saw a 15% drop in Y — what do you investigate?” The interviewer watches your first 60 seconds more than the next 14 minutes. That’s when you signal judgment.

In a recent debrief for the “savings feature engagement” question, two candidates took different paths. Candidate A said: “I’d look at DAU, session duration, and feature conversion rate.” Textbook. But the hiring manager stopped them at 90 seconds and said, “Why those three?” Candidate A fumbled.

Candidate B started with: “Are we trying to increase retention, AUM, or cross-sell investment products? Because the metric changes based on that.” That single question got them through. Not because it was insightful — but because it showed they knew metrics serve strategy, not the other way around.

The evaluation rubric is silent on exact answers. It asks:

Did the candidate clarify the goal before proposing metrics?
Did they distinguish between leading and lagging indicators?
Did they consider countermetrics to avoid perverse incentives?

For example, if you suggest “increase % of users setting up auto-save rules” as a success metric, you must also warn that it could lead to users setting trivial amounts (e.g., £0.01) just to dismiss the prompt.

Not output, but intent.
Not breadth, but alignment.
Not speed, but coherence.

One HC member said: “We rejected a Meta PM because they proposed seven metrics for a referral program but never asked who the target user was.” Revolut’s product teams move faster than FAANG on experiment cycles. They can’t afford PMs who generate analysis debt.

What level of SQL is expected, and how is it evaluated?

You need to write executable SQL, not explain concepts. Expect one medium-difficulty query in 15–20 minutes, usually on a schema with 2–3 tables (e.g., users, transactions, accounts). Joins, filtering, aggregation, and basic date functions are required. Window functions (e.g., ROW_NUMBER, LAG) appear occasionally but aren’t mandatory.

In a live interview last month, the prompt was: “Find the first transaction date for each user in the spending account table.” The optimal solution uses MIN(transaction_date) GROUP BY user_id. A few candidates used window functions — not wrong, but slower to write and debug under pressure. One candidate forgot to GROUP BY and couldn’t fix it in time. They were rejected, not for the mistake, but because they spent 8 minutes debating whether to use a CTE.

Execution time matters. Revolut’s internal tooling runs queries on large datasets. They care about efficient logic. A query that works on 1,000 rows but would fail on 10M gets flagged.

The evaluation criteria:

Correctness (does it return the right result?)
Clarity (are aliases meaningful? Is the logic readable?)
Edge-case handling (NULLs, duplicates, time zones)

One candidate used “WHERE transaction_date >= '2024-01-01'” without specifying time zone. The interviewer noted it as a risk — Revolut serves 25+ countries. The candidate passed, but with a “needs SQL refinement” flag.

Not theory, but practicality.
Not elegance, but reliability.
Not syntax memorization, but structural discipline.

Work through a structured preparation system (the PM Interview Playbook covers Revolut-specific SQL patterns with real debrief examples from ex-Revolut interviewers).

You won’t be asked to optimize query plans or write stored procedures. But you will be expected to translate a business question — “What’s the 7-day retention rate for users who onboarded after adding a card?” — into a single, correct query.

How should you approach case questions about new features or growth?

Start by scoping, not ideating. When asked “How would you improve Revolut’s stock trading feature?”, the strong candidates pause and say: “For which user segment? What’s the current friction point?” The weak ones launch into “Add fractional shares, social feeds, and alerts.”

In a Q2 HC meeting, a candidate proposed a “trading leaderboard” to boost engagement. The hiring manager asked: “What if it increases risky behavior among inexperienced users?” The candidate hadn’t considered it. They were rejected — not because the idea was bad, but because they didn’t weigh trade-offs.

Revolut’s PMs operate under regulatory and compliance constraints that US tech PMs often ignore. A feature that increases AUM might also increase AML risk. Your case response must acknowledge that tension.

Structure matters less than insight density. You don’t need a MECE breakdown. You need one or two sharp insights grounded in data. For example:

“Trading volume is concentrated in users aged 25–34, but retention drops after 60 days. Maybe they’re testing the platform, not building habits.”
“Revolut Exchange has higher fees than competitors for certain currency pairs. That could be a friction point for active traders.”

The case isn’t a creativity test. It’s a prioritization test. When a candidate said, “I’d survey users before building anything,” the interviewer responded: “We have survey data — 40% say they want lower fees, 30% say they want better research tools. How do you decide?” That’s the real question.

Not ideas, but filters.
Not brainstorming, but triage.
Not vision, but validation.

One candidate succeeded by proposing a small A/B test: reduce fees for a high-intent cohort (users who checked exchange rates 5+ times in a week) and measure trading conversion. That showed they understood Revolut’s data-driven culture.

How is performance scored, and what do debriefs actually look like?

Each interviewer submits a written assessment using a 4-point scale: Strong No Hire, Leaning No Hire, Leaning Hire, Strong Hire. The hiring committee — usually 3 senior PMs or directors — meets within 48 hours. They don’t re-read your resume. They read the interview notes and decide.

In a recent debrief for a London-based PM role, one interviewer wrote: “Candidate correctly wrote the SQL query but didn’t validate assumptions about user_id uniqueness.” Another noted: “They asked whether ‘active user’ meant login or transaction — that’s the rigor we want.” The committee voted Leaning Hire, pending bar raiser review.

The biggest debate wasn’t about skill gaps — it was about pace. One senior PM argued: “They took too long to pivot when I introduced a new constraint.” Another countered: “But they didn’t panic. They re-scoped cleanly.” They approved, but with a note: “Needs to move faster in ambiguity.”

Your fate is decided in 20 minutes of discussion. No second chances. The notes must contain evidence of judgment, not just competence. Phrases like “asked clarifying questions” or “identified a key trade-off” are positive signals. “Followed a framework” is neutral. “Didn’t challenge assumptions” is negative.

Not effort, but impact.
Not process, but pattern recognition.
Not confidence, but humility under pressure.

Compensation for PMs at Revolut ranges from £70K–£95K base (L5–L6), with 10–20% cash bonus and equity in the form of stock options. Offers are made within 5–7 days of the final interview.

Preparation Checklist

Define 10 core metrics (DAU, WAU, retention, conversion rate, LTV, CAC, AUM, yield, NPS, fee revenue) and practice linking each to business goals.
Write 15 SQL queries from real Revolut-like prompts (e.g., cohort retention, first transaction time, user funnel drop-off). Time yourself — max 12 minutes per query.
Drill one-pagers on Revolut’s product lines: banking, cards, savings, investments, insurance, crypto. Know the revenue model for each.
Practice scoping questions: “Before building X, what would you want to know?” Answer in under 30 seconds.
Work through a structured preparation system (the PM Interview Playbook covers Revolut-specific case patterns with real debrief examples from ex-Revolut interviewers).
Simulate live interviews with a timer and no notes — use a whiteboard or shared Google Doc.
Review GDPR and financial compliance basics — not to recite, but to show awareness when discussing data or feature changes.

Mistakes to Avoid

BAD: Starting a metrics question with a list of KPIs without clarifying the goal.
One candidate said: “I’d track DAU, session length, and NPS.” The interviewer replied: “None of those matter if the goal is reducing fraud losses.” The candidate never recovered.

GOOD: Pausing to define the objective first. “Are we trying to increase engagement or reduce churn? Because for engagement, I’d look at feature usage frequency; for churn, I’d analyze drop-off points in the onboarding flow.” This shows purposeful thinking.

BAD: Writing a SQL query without stating assumptions.
A candidate joined tables on user_id without confirming it was the primary key. When the interviewer asked, “What if a user has multiple accounts?” they hesitated. The feedback: “Lacks defensive coding mindset.”

GOOD: Explicitly stating assumptions: “I’m assuming user_id is unique in the users table and that each transaction has a non-null user_id. If not, I’d need to deduplicate or handle NULLs.” This signals operational rigor.

BAD: Proposing a new feature without addressing trade-offs.
“I’d add a savings goal progress bar to increase motivation.” No mention of potential downsides — e.g., cluttering the UI for users who don’t care.

GOOD: “A progress bar could help, but it might annoy inactive users. I’d test it with a segment of goal-setters first and measure both engagement and opt-out rates.” This shows balanced reasoning.

FAQ

What if I’ve never worked in fintech?
Your lack of domain experience isn’t a blocker — but you must show you’ve learned the basics. If you can’t explain how Revolut makes money from cards (interchange, FX, cashback funding) or what AUM means, you’ll fail. Study their app, their blog, and recent regulatory filings. Not familiarity, but fluency.

Is the SQL interview on paper, whiteboard, or live coding?
It’s usually live on CoderPad or HackerRank with a real schema. You write and run code. Syntax errors matter. You get 15–20 minutes. Practice with a timer and real datasets. Not conceptual understanding, but execution under conditions.

How detailed should metric trees be?
Not at all. Revolut doesn’t want a 10-box diagram. They want one clear metric tied to a goal, plus one countermetric. For example: “Primary: % of users completing first transaction in 24h. Counter: % of those who churn in 7 days.” Depth beats breadth every time.

Want to systematically prepare for PM interviews?

Read the full playbook on Amazon →

Need the companion prep toolkit? The PM Interview Prep System includes frameworks, mock interview trackers, and a 30-day preparation plan.