During the interview, though, it felt like the discussion revolved around a very specific, personal interpretation of the pattern. The interviewer seemed fixed on a single flavor of the approach and didn’t really acknowledge or engage with the broader, well-established variants that exist across the industry. Some of the critiques suggested that the design wasn’t fully understood, rather than that the design itself was inherently weak.
Similar issues came up in the architectural follow-ups: several assumptions made during the conversation didn’t match the scenarios I actually described. It felt less like an open technical evaluation and more like checking alignment with one preconceived design style.
He hinted that “NoSQL scales better than relational databases” as if that was some universal, unquestionable truth. No nuance, no context, nothing. Has he even heard of NewSQL or distributed SQL systems that give you horizontal scalability and proper transactions? Or the fact that a lot of scaling problems can be solved with sharding, partitioning, and good schema design on relational databases, instead of just throwing everything into a document store and calling it a day? I know Monzo uses Cassandra but that's not the best way and that doesn't come with some compromise.
Interview questions [1]
Question 1
Questions about previous experience and architectural decisions that were made.
The first round was a deep dive into past projects. For the second part, I could choose either a take-home exercise or a live coding exercise. I chose the take-home exercise, and I was asked to implement the web-crawler.
The third call was a follow up techical discussion on the exercise. It heavily focused on different ways multithreading could be used, the reasons behind every specific choice you made, trade-offs between different solutions, and different multithreading libraries. It eventually turned into a discussion about how the solution could scale across multiple machines, how you'd utilise queues, distributed locks and how you would implement a distributed rate limiter.
Considering that I recently switched from a front-end role to a backend role, I didn't meet their expectations around the in-depth multithreading and concurrency knowledge that they require. I think in this day and age, when anyone can be a full-stack developer using Claude Code and Chat-GPT, the in-depth multi-threading knowledge feels unnecessary. I demonstrated I can solve the problem and had high level understanding of multi-threading and scaling, and I think I demonstrated I can learn new skills. I have an in-depth knowledge of front-end development, which was highlighted on my CV. I felt like they wasted my time on this interview. If they want and muti-thread expert, they could have said it upfront. Don't try to hire front-end-oriented full-stack engineers.
Overall I regret spending time on this.
Interview questions [1]
Question 1
Different ways to implement and manage threads in Java? Pros and cons of each approach. Why a thread pool size shouldn't be too large or too small? Different way of distributing/batching work across threads. Scaling with queues and databases. How would you implement a distributed rate limiter? (Hint: learn the rate-limiting algorithms). Pros and cons for every question asked.
I applied through other source. I interviewed at Monzo Bank
Interview
Recruiter call followed by technical interview with one of the developers at the company. Was really quick to hear back - the whole process only took about 1 week. Everyone was friendly, but seemingly are looking for very specific answers I did not know.
Interview questions [1]
Question 1
Explain one technical challenge, and then one piece of project work.
