Revolut Data Analyst Interview Experience — A Brutal Four-Question SQL Round

The recruiter call was pretty standard — they asked why I wanted to apply to Revolut, about my past experience, and then talked about how they're moving their headquarters to the UAE now, so a lot of the roles are on mainland Europe, not many in the UK. It depends on your interview results — they sponsor visas for senior and above, etc.

SQL Interview Questions

The SQL was actually pretty hard — four questions in total.

They gave three tables:

• user table: user_id, create_date (account opening date), etc.
• transaction table: transaction_id, user_id, amount (£), status (completed/declined), etc.
• activity table: product, event_type (view/click), etc.

Question 1
Find users whose completed crypto transactions within 7 days of account opening add up to more than £100.

• Use create_date as the starting point and count transactions within 7 days of account opening
• Only count crypto products
• Only count completed transactions (declined doesn't count)

Question 2
Find the product with the highest CTR.

• The activity table has product and view/click
• First aggregate by product: CTR = clicks / views
• The question asks you to return the product with the highest CTR

Question 3
An open-ended scenario question with no fixed answer: they just launched a new Ultra subscription plan — how would you define success, and write SQL using the existing tables.
This leaned more toward open discussion — the core was to first define the success metric, then translate it into SQL (using only the information in the existing tables).
The direction I discussed (as an example):

• DAU (or active user volume) related to Ultra in the 1 month after launch
• Broken down by country: what proportion of active users signed up for Ultra (penetration / adoption rate)

(The exact definition can be aligned with the interviewer, then you write the corresponding aggregation.)

Question 4
A scenario question: working with the Fincrime team to find suspicious transactions (rule-based thinking + write SQL using the table info).
Also open-ended — mainly testing whether you can turn "suspicious" into an executable rule. Common directions:

• IP address country doesn't match registration country / changes frequently
• Abnormal amounts (very large amounts, repeated large transactions in a short time, lots of small "probing" transactions, etc.)
• Abnormal product/behavior (certain products are higher risk, crossing multiple products in a short time, etc.)

Then you'd use transaction + user (+ possibly activity) to filter, group, and apply threshold checks.

Right after finishing, I immediately got an invite for the next round — a case interview.