I interviewed at Revolut in April 2024 first, and then again in October. The interview process is unnecessarily long at this company.

The first stage is with the recruiter, who asks technical questions without truly understanding your responses. They seem to be looking for specific buzzwords, but if you're working with Java, you can likely get it right.

Next, I recall one or two rounds of core Java interviews. Perhaps just one, as the details are hazy. It was very in-depth, focusing heavily on the internal workings of Java concurrency and multithreading libraries. This proved challenging for me with 20 years of experience. This round seemed designed more for someone fresh out of university with extensive theoretical knowledge. I consider myself more practical, and luckily, there was a pair programming exercise where I could shine. I had to write a simple money transfer class, focusing on concurrency. If you approach it with the simplest solution that comes to mind, you'll likely succeed.

The following round was a database interview. They require in-depth knowledge of indices and transaction isolation levels. If you use these concepts and understand how and when to apply them, that's only part of the challenge. You need to prepare for the "why" questions. Similar to the previous round, they emphasize theoretical knowledge over practical application. While my experience leans towards practicalities, I managed to get through this round after some learning and preparation.

And then we arrive at the system design, where I failed—twice. The reasons for failing in April and October were quite similar. Both times, I proceeded with the design after clarifying requirements and making some basic estimations for required storage. In the first interview in April, the interviewer and I agreed that the third-party API we needed to depend on was reliable and produced consistent results. This was important because it made a synchronous system solution more appealing due to its simplicity and ease of reasoning. I began designing the system and explained my approach. However, about 20 minutes before the end, and before I had finished addressing all agreed-upon requirements, the interviewer stated: "You know what, let's make that third-party API not safe and not consistent in its responses!"

This was quite unexpected. I had invested significant effort in covering all edge cases, and this change rendered the entire synchronous solution irrelevant, forcing me to restart. Magically, I managed to finish designing for all requirements, though not with the level of detail I had initially planned. You can probably guess the feedback: "The candidate spent too much time clarifying requirements and estimating capacities, thus failing to complete all requirements in time." They also mentioned that I required significant guidance to make the system asynchronous. I responded to Revolut that I don't believe five minutes is excessive for clarifying requirements, especially considering the preparation videos they provided. I also pointed out that I had completed everything, although I admitted not at the detailed level I would have preferred. This occurred because the interviewer changed the previously agreed requirements 20 minutes before the interview concluded.

Unsurprisingly, Revolut ghosted me. That is, until last October, when they sent me a message—evidently a template—stating they were impressed by my experience and performance in April and wished for me to retake the system design round. If my performance was so amazing, why wasn't I advanced to the next interview? I was quite shocked the first time. However, based on my prior experience, I believed I could succeed this time.

Oh boy, I couldn't have been more wrong. This time, I didn't spend five minutes on requirements. At the end, I asked the interviewer if he was satisfied with the features I planned to cover or if he wanted to add anything else. He was content. I then designed the entire system within the allocated time. I had to use a third-party API again. I opted for a simple yet sensible solution to avoid last-minute surprises. I covered everything and designed it all. However, I had a bad feeling about it. Despite communicating clearly and always vocalizing my actions and reasoning, the interviewer repeatedly asked for explanations for practically everything. I know that's part of their job, but he did it in a way that conveyed a sense of superiority. At least, that's how I perceived it.

He appeared to be just over half my age. I'm sure I've designed far more systems than he has, but of course, I didn't mention it. I remained very polite, even when he wasn't, and attempted to reason why I believed my approach was the one to focus on. When he made a valid point (which happened once), I incorporated it into my design. I hoped for objectivity, as I had addressed all previously agreed-upon requirements, and the design seemed sound.

Regarding the feedback: "I required significant guidance on how to design a system and focus on the most important things." I had only discussed the previously agreed-upon requirements—no more, no less. In this design, I had to implement something akin to booking a flight or cinema ticket: you select your seat, then pay. During this time, the seats are reserved, preventing other customers from booking them. This interviewer might not have experienced this before, as he seemed unfamiliar with the concept of reserving seats for a cinema or flight booking. While that wasn't my specific task, the core problem was very similar. This was another significant "mistake" on my part. I don't wish to elaborate further, as it seems everything I did and how I did it was perceived as wrong.

I believed system design interviews are open-ended questions with no right or wrong answers. However, this interviewer solely sought his own solution and was entirely unreceptive to alternative approaches. Therefore, I believe I failed the interview before it even began.

How does the HashMap work?

Write a money transfer class using a Test-Driven Development (TDD) approach.

Various Java concurrency and multithreading questions delve into the details of the Java implementation of some concepts.

Lots about database indices and transaction isolation levels.