1. Interview with a recruiter: Some common questions are asked, plus a few simple technical ones. The recruiter sends all necessary information, including a PDF covering the steps of the hiring process.

2. 1h coding session: Here, the focus is on discussing the task, implementing it, and covering it with tests. It is important to discover all possible scenarios. The task was pretty simple, and the interviewer was a well-wishing individual.

3. 1h tech interview, which actually included 15 minutes for a coding task and all other time spent on its discussion and improvement. The coding task requires a profound understanding and experience with multithreading, concurrency, and relational database optimizations. I am still not aware of what was wrong with my implementation, as neither deadlocks, livelocks, nor race conditions could have happened there. I suspect that I simply implemented something different from what the interviewers expected, but they did not articulate it clearly.

In general, the interviewing process experience is positive.

The only thing I am still wondering is why the interviewers at the third stage were so focused on concurrency. Both interviewers at the second and third stages said they are using concurrency explicitly only in very rare cases. Then why is deep knowledge of concurrency mandatory?

ACID, concurrency, huge relational DB optimization