The interview process was quite structured and well-organized. It began with a call from the recruiter, who explained the overall process.

The first stage was an online coding round, where you were required to write production-grade code that compiles successfully and is covered with comprehensive unit tests.

Next came another coding round, where you were asked to write a simple function and then translate it into an SQL query—this formed the first half of the round. The second half focused purely on technical questions related to databases, architectural patterns, distributed systems, microservices, deployment, observability, and more.

Following that was the system design round. You were given a vague description of a system that needed to be integrated into Revolut's existing environment. The expectation was that you would navigate through the ambiguity by asking relevant questions until the interviewer was satisfied with your solution. Unlike typical system design interviews that focus on large-scale distributed systems like YouTube or Google Drive, this round was centered on FinOps-related designs.

Next came the behavioral round, followed by the team-matching round. Before each stage, a recruiter would conduct a prep session, giving an overview of the types of questions you might be asked and providing feedback from the previous round.

One downside of the process was the lack of detailed feedback. If you failed any round, you would simply receive a generic rejection email with no explanation, leaving little opportunity to learn from any mistakes.

A notable negative aspect of interviewing at Revolut is the rigid approach to technical questioning. There is little consideration for a candidate’s thought process or experience; instead, they expect instant, precise answers. For example, if asked about CQRS, you are expected to deliver a Wikipedia-style definition in just a few sentences. Similarly, failing to recall what each letter in ACID stands for would be considered a red flag. The volume of technical questions is overwhelming, so a strong grasp of fundamentals is essential.

Overall, despite not making it to the final stage, I am still satisfied with the process. However, even if I had received an offer, I doubt I would have accepted it, given the overly mechanical nature of the interviews, Revolut’s reportedly harsh company culture, and the widely discussed lack of work-life balance.

A classic interview question involves implementing either a Load Balancer or a URL Shortener class using a Test-Driven Development (TDD) approach. This means you are expected to write test cases first and then develop the working code that ensures all tests pass.

The code must be production-ready, thread-safe (avoiding deadlocks), and should incorporate well-known design patterns such as Strategy. Additionally, you are required to implement functionality that involves probabilities (e.g., random selection) and ensure it is covered by test cases. It is also expected that you mention how probabilities can be tested using statistical methods, such as equal frequency distribution.

A typical transaction/locking-related question involves implementing a money transfer between two accounts. While you are not required to cover the code with tests at this stage, the solution must be thread-safe and should use a reliable data structure for storing monetary data.

Next, you are expected to translate your implementation into an SQL transaction, choosing between optimistic or pessimistic locking based on your preference.

Following that, there is a 30-minute Q&A session covering a wide range of topics, including:

• Data structures
• ACID principles
• Transactions
• Locks
• RDBMS
• CAP theorem
• Microservices
• TDD
• CQRS
• DDD
• Distributed systems
• Resiliency patterns
• Observability
• Deployments
• Security
• Database migrations

A challenging system design question focuses on FinOps-related topics. The design typically involves integrating with a third-party API that is initially described as reliable. However, once you build your system, the interviewer changes the requirements, revealing that the API is actually unreliable.

To handle this, the only viable solution is to introduce locking within your system and gradually transition to using transactions with ACID guarantees to ensure consistency and reliability.