The interview process consisted of three interviews.

The first interview was with a tech recruiter. They asked questions regarding my past experiences and also some technical questions, such as algorithms used by database indexes, Big O related questions, and ACID properties.

The second interview was with a software engineer and was a live coding interview. The engineer arrived 10 minutes late, blaming their calendar. The coding exercise was a simple problem: design and implement a very simple Load balancer. In this task, they were evaluating my coding skills related to writing clean code, following SOLID principles, and primarily if the code was well-covered with unit tests. No complex algorithms needed to be implemented. First, the engineer presented a problem and then asked me to extend the solution by adding some more features.

The third interview was with two senior engineers, although only one asked questions. They called it a "Technical Conversation Interview," which was not entirely accurate. The interview was divided into two parts: a coding part and a Q&A part. In the coding part, I was given a task to develop a method to handle money transfers from one account to another. The engineer primarily wanted me to use locks on both account objects. I struggled to understand what they were looking for in an answer, specifically regarding double synchronized blocks, which one would hardly implement in production code. The second part was mainly database-related questions, including query optimization, indexes, concurrency control (optimistic, pessimistic), isolation levels, and partitions. The interviewer asked vague questions but expected in-depth answers. There were so many database questions that it seemed like the team experienced significant issues with databases in their system. They also asked me questions about scaling databases, then moved the subject to streams, event sourcing, CQRS, how to scale, fault tolerance, and other related topics.

As a result, I was rejected with feedback stating that my answers were too vague and lacked in-depth knowledge, even though the interviewer seemed satisfied with my responses during the interview. They also mentioned that I struggled to solve the double coding exercise, noting that the double object lock likely posed a challenge.

Be aware of the following:

• The interviewers were not friendly and lacked basic social skills, not attempting to make me comfortable during the interviews. This may be a cultural difference, possibly from Eastern Europe.
• The interviewer offered tips at a few moments, which seemed to have affected my evaluation.
• They asked vague questions but required in-depth responses.

How can you identify issues in a database query?

How to interpret the query execution plan? How can you tell if it is using indexes or not? What algorithms do database indexes use?

In addition to B-trees, what other algorithms are used by database indexes?

What is the difference between hash-based indexes and B-trees? When should you use them? What are the trade-offs?

If, even after solving issues with indexes, how can you improve the performance of the database?

How would you solve concurrency issues with database transactions? How to use pessimistic locks?

What are the isolation levels? What would be the best isolation level to solve the issue with the money transfer coding exercise?

What exactly are the isolation levels repeatable read, serializable, read committed, and other questions related to the same topic?

How would you create partitions in a database? Which approach would you use?

What are the trade-offs of database partitions (sharding)?

If, even after sharding, you still have problems with performance, what would you do?

Some questions about event sourcing, that I don't recall anymore.

What is CQRS? How to implement it?

There were also some questions about availability, like if a write database is down, what would be the impacts if it is down for a long period of time? (Guess what the answer was? Because of locks in their upstream systems….)

So, it seems they prefer pessimistic concurrency control and synchronized blocks.