The recruitment process involves three steps:

1. A basic technical interview with a recruiter.
2. A coding challenge.
3. A final stage that is a mix of a coding challenge and specific questions (covering topics like database isolation levels, microservices, and optimistic versus pessimistic concurrency control).

Regarding the talk with the recruiter and the first challenge, the experience was good enough. However, the third interview was far from a positive experience. An interview should ideally be a constructive discussion between engineers about the best approaches to achieve a goal or solve an issue. This was not possible with the current Revolut engineers. They seem to expect candidates to read their minds, not guiding them or asking questions clearly.

Regarding their feedback, there is only one word to describe it: useless. I have over 10 years of experience as a senior software engineer, primarily working with Java concurrency (and yes, I have read "Java Concurrency in Practice" several times). Concurrency is recognized by experts as one of the most difficult subjects to master. This means adequate thinking time is crucial during implementation to explore all possible flows and evaluate potential problems (such as the interleaving of multiple flows). During an interview, this is challenging due to the mix of emotions and stress. Revolut engineers do not seem to take this into consideration. In fact, for them, the issue is very clear, likely because they reuse the same problem for all interviews (they are really smart :)). I would genuinely love to see some code from these brilliant engineers.

Considering Glassdoor reviews, I believe this outcome was probably the best thing that could have happened. I would not enjoy working with this type of engineer or in a company that rates so low in culture and values.

Advises: You have several complaints about engineers conducting the third step. Perhaps management should address this. For interviews, you need good engineers, but they should also possess strong people skills. An alternative approach could be to use automated systems for interviews. If questions were programmed clearly, it would likely provide a better, and at least more objective, experience for candidates.

Avoid having arrogant engineers conduct interviews. Candidates should feel comfortable during the process.

Write a LoadBalancer and test it.

Here, you need to remember a few things, mostly the Strategy pattern and also related concurrent issues.