I was approached by a recruiter on LinkedIn for a Senior Software Engineer position at Revolut. With around 10 years of experience across multiple business domains and tech stacks, I was excited to explore the fintech sector.

The initial interaction was with a recruiter who scheduled a call with a technical recruiter. The call felt more like a superficial checklist rather than an in-depth evaluation. The questions were general, basic, and didn’t dive into any real technical expertise.

I started the interview process in mid-September. The first round was a coding interview with one engineer. I was tasked with building a load balancer for a maximum of 10 services, and the interview consisted of multiple tasks. I managed to solve all four tasks, including TDD and concurrency. My advice here: keep it simple. They asked for things like ensuring services were unique, which might lead you to think a Set or Map would be appropriate. However, they seemed to prefer an ArrayList and manual validation logic. It felt like they were more focused on following a rigid checklist rather than evaluating real-world problem-solving skills.

The first interview was uncomfortable, largely because the interviewer was extremely rude and unengaged. To my surprise, I passed that round.

The second technical interview took place two weeks later. The experience was worse. The interviewer arrived 7 minutes late, didn’t introduce himself, nor did he ask me to introduce myself. To make matters worse, he wasn’t prepared with the question and asked me to talk while he searched for it. I humorously tested if he was paying attention by saying random things—he wasn’t.

Once we got to the task, I had to implement a money transfer operation using an Account class. I built the Account class, maintaining thread safety with a ReentrantLock and applying all the necessary logical validations. The task required finding the correct type for the transfer amount, and I initially used double and proceeded with the implementation. The rest of the interview involved SQL, where I answered around 15 questions, including writing an optimistic locking query, which I completed correctly.

Toward the end, we moved to theory questions covering topics like deployment, production, rollbacks, and monitoring—about 40 questions in total. After all that, the interviewer said, "I wish you had solved the coding question!" Surprised, I asked why. He responded, "You used double for the transfer amount, which is incorrect." Although I immediately acknowledged that BigDecimal would have been more appropriate (recalling an issue with fractions from years ago), he bluntly stated that since I didn’t use it from the start, he couldn’t mark it as solved.

It became clear that the interviewer was following a strict checklist rather than truly evaluating my overall solution and technical knowledge. He seemed more focused on ticking boxes than understanding my thought process or experience.

Having been through countless interviews, including at companies like Amazon and Google (where I work), this was one of the most frustrating and disorganized experiences I’ve encountered. The rigid, outdated approach made me question whether I’d even want to continue the process. Before receiving any feedback, I had already decided that I didn’t want to work at a company where the interviewers demonstrated such narrow-mindedness and a lack of professionalism.

Technical Recruiter Round:

Topics covered:

• SOLID
• CQRS
• Concurrency challenges
• Threads
• SQL and NoSQL
• Data Structures (Very basic)

Problem 1: Build a Load Balancer

You will build a load balancer for at most 10 unique services. You will be asked to use the Random algorithm to fetch a service, and then implement Round Robin. Concurrency is the last task for this problem.

Problem 2: Account Transfers

You will be provided with code for an Account class (empty) and a class with a transferMoney operation that you will need to write. The signature of transferMoney is (Account a, Account b, ???? amount).

Problem 3: SQL Transactions and Concurrency

You will face numerous questions about SQL transactions, isolation levels, and consistency. You will be asked to write SQL queries within comments and implement locking using them (both optimistic and pessimistic).

Theoretical Questions:

You will be asked many theory questions on topics such as:

• Production environment
• Stability patterns (at least 3)
• Rollback strategies
• Deployment strategies
• SOLID principles
• Monitoring code
• And others.