Revolut Data Analyst Interview Experience — Recruiter Call, Then a Four-Question SQL Screen

The recruiter call was pretty standard — they asked why I wanted to apply to Revolut, my past experience, then talked about how they're now moving headquarters to the UAE, a lot of the roles are for continental Europe rather than the UK, it depends on how the interview goes, and they sponsor visas for senior and above, etc.

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

They gave 3 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 cumulative completed crypto transactions within 7 days exceed £100.

• Use create_date (account-opening date) as the starting point, and count transactions within 7 days of account opening
• Only count the crypto product
• 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 asked to return the product with the highest CTR

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

• DAU (or active-user scale) related to Ultra in the 1 month after launch
• Broken down by country: what percentage 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 Fincrime to find suspicious transactions (rule-based thinking, plus write SQL using the table information).
Also open-ended — mainly testing whether you can turn "suspicious" into executable rules. Common directions:

• IP address country vs. registration country mismatch, or frequent changes
• Abnormal amounts (extremely large amounts, consecutive large amounts in a short window, many small probing amounts, etc.)
• Abnormal product/behavior (certain products being higher risk, crossing multiple products in a short time, etc.)

Then you'd use transaction + user (+ possibly activity) for filtering, grouping, and threshold checks.

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