Revolut Data Engineer Interview Guide

We've seen Revolut care less about flashy theory and more about whether candidates can stay precise when the schema gets messy. Across experiences, the recurring pattern is a heavy emphasis on joins, aggregations, and window functions, but always with edge cases attached: users with no transactions, duplicate records, null prices, tie-breaking logic, and cancelled orders. One candidate described the interview as “70% SQL patterns, 30% analytical thinking,” and that feels accurate from the reports we’ve reviewed. The strongest candidates weren’t just fast; they narrated why they chose ROW_NUMBER() versus RANK(), or how they’d handle a running total without breaking partition logic.

A second theme is that Revolut seems to test how you structure data work, not just whether you can write the query. Multiple candidates reported being pushed on rewriting solutions with CTEs, explaining pipeline components in Python and SQL, and describing how Airflow, dbt, and documentation fit into the broader workflow. Even the more conversational rounds had a technical edge, with questions about governance and pipeline design that required real operational familiarity. We also see a clear bias toward realistic, production-like scenarios: large tables, multi-table joins, fraud or login-pattern detection, and performance follow-ups when the data volume is assumed to be huge. In practice, the make-or-break factor here is often whether you can keep your reasoning organized under pressure and adapt your solution when the interviewer adds one more constraint.