1. Recruiter call — short intro, they explain the role, you ask questions. Low stakes. 2. Initial call (1 hour) — this is the one to prepare hardest for. They've read your CV and want to go deep on a recent project: how it was built, what trade-offs you made, what you'd do differently. It's a conversation, not a quiz — but they will probe the technical details. Pick one project you can talk about inside out. 3. Coding exercise — your choice of take-home or live pair session. Take-home is async in your own IDE, any language, includes a README where you explain your decisions. Live pairing is 45 mins with a Monzo engineer, implementing functions against a provided interface — not leetcode, no binary trees, just practical work. Both end in a review call walking through your code. 4. Systems design (1 hour) — design a scalable system for a hypothetical problem using Excalidraw. They care about your reasoning, not your diagram. Don't namedrop buzzword tech unless you can defend why — they will push back. Know your CAP trade-offs and be able to explain your choices from first principles. 5. Behavioural (1 hour, two interviewers) — communication, how you deliver complex projects, how you work with a team. Be specific about what you did personally versus what the team did. STAR format, concrete examples.

Same interview process as mentioned on the Demystifying the Backend Engineering Interview Process blog page on their website. I, however, got rejected in the take-home review round. All of the interviewers involved were really nice and warm, and they seemed to have a good internal company culture. The take-home code review round was good in some areas but seemed vague in others, such as scaling. The interviewer was asking questions while trying not to hint at the answers, and in that process the questions turned out to be super vague with some getting lost in translation. The interviewer constantly referred to "semaphores" as workers, which is conceptually incorrect. I also want to add that referring to semaphores as "workers" confused me as to whether the discussion was about scaling in a distributed production setup or something specific to my test code. This missing distinction disrupted my thought process and I got lost thinking about what they were expecting rather than taking an analytical approach to the answer. It looks like they expect specific answers to some of those questions. This pattern is evident if you look at others' interview experiences here.