The first call is easy - basic questions: HashMap and pessimistic time complexity when it degrades, data structures used to implement efficient indexes in Databases (name them, without explanation), ACID (just what it means, without deep explanation), etc. The first call is to determine if you have any knowledge to proceed with the process. The second call is live coding and here is where Revolut has troubles in their interview process. You are asked to write a Load Balancer. If you are an experienced Software Engineer, you'll know that this can be a whole project on its own. There are entire books and research fields about Load Balancers. But ok, you are trying to play their game, so you have a ton of questions to clarify requirements and sketch at least a raw MVP for that topic: - Does he want you to implement Level 4 or Level 7 LB? - Is there any specific LB strategy he wants you to implement? - Are there any restrictions regarding the hardware you'll operate on? - What is the domain the LB will be working in? - And a lot more. Then you'll realize that the interviewer is annoyed by your questions and he wants you to write the damn thing. In real-life work, you will get yourself in a lot of trouble trying to write the code without clarifying your doubts first, but here you are expected to show bad practices to get the job. When you figure out that he's not helpful with your questions and he wants you to just write the code, you start to understand that he wants you to simply wrap HashMap and expose "meaningful" methods, not to write a Load Balancer. Unfortunately, at this point, you wasted time being a professional Software Engineer and doing your craft, so you don't have much time left and the interviewer is rushing through topics he wanted to cover but he already decided about your future in this company - you are not delivering "quick and precise" implementation, so you are not a good fit. Of course, you'll get the email with the rejection and the feedback which unfortunately is not precise at all. For example, we had a discussion about strategies for dealing with methods that can fail. I responded that we should aim for using exceptions for such cases and not return codes - I wanted to show that I know what a Clean Code is and that I read a lot of Uncle Bob books. In the feedback I've got "We should always use exceptions and not return codes" - yes, that's exactly what I said, I even mentioned that this is one of the clean code rules. We all know that the next time their recruitment team will be going through the list of potential candidates, they will reject a candidate which tried to use return codes instead of exceptions - which I didn't, but imprecise feedback suggests that I did. There were more cases like this, but this is already too long. To sum up, I feel like the Revolut process is not well thought through, their interviewers are probably regular developers which are trying to help the company, but are not very well trained in interviewing. The more experienced you are the weirder questions like "Write a Load Balancer" are. Like.. do they even know what are they asking for? And if they say that they didn't REALLY expect the candidate to write LB, then they need to be more precise with your questions.