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 technical 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 ChatGPT, the in-depth multithreading knowledge feels unnecessary.

I demonstrated I can solve the problem and had a high-level understanding of multithreading 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 a multithread 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.

The questions asked included different ways to implement and manage threads in Java, along with the pros and cons of each approach. The interviewer discussed why a thread pool size shouldn't be too large or too small, and different ways of distributing or batching work across threads. Other topics covered scaling with queues and databases.

You were also asked how you would implement a distributed rate limiter, with a hint to learn the rate-limiting algorithms. There were pros and cons for every question asked.