Meet the MongoDB Sharding Team’s New Barcelona Division

I sat down with Kaloian Manassiev (Kal), Lead Engineer on MongoDB’s Barcelona-based Sharding team, to better understand what the team does and how they plan to grow. The Sharding team started in our New York City headquarters and expanded to Barcelona in the summer of 2019. Here, we explore who they are recruiting in the growing Spanish market and why someone would be excited to join their team.

Ashley Perez: First, can you give a quick overview of what the Sharding team does?

Kal Manassiev: The Sharding team builds frameworks and tools that abstract away difficult distributed systems problems for database users. This frees developers to focus on working with the data itself and not have to worry about where it resides, whether there is some network problem, or if a data center catches fire. As a result of this, the projects delivered by the Sharding team are highly visible and are predominantly flagship features for each major MongoDB release.

AP: Let’s dive in a little more. What projects has your team taken on?

KM: In the past, we’ve delivered projects such as Distributed Transactions and Retryable Writes. Retryable Writes, for example, makes it much easier to implement scenarios so that if your browser crashes when you click the Pay button, it will not charge you two times when you try again.

Just recently, we completed a project to assign vector or scalar clocks to all the distributed objects we manage, so that our system is easier to reason about and can be proven correct via theoretical proof models and correctness checkers such as TLA+. This project also makes it easier to add more distributed systems features and be confident in their correctness.

AP: Very interesting! What are some projects on the horizon?

KM: The biggest upcoming effort is to make sharding even more transparent (invisible) to developers so they can focus on working with data. Behind the scenes, we will analyze their workload patterns and apply balancing techniques to relocate data in order to squeeze the maximum performance out of the hardware and offer the best possible throughput and latency to users.

There are a myriad of technical challenges we will need to solve. For example: how to decide the best placement for workloads that might change dynamically, how to ensure consistency while we are reshuffling in the background, and how to minimize the impact on the customers’ workloads so they are not aware of what is going on behind the scenes.

AP: I’m sure our customers will be excited when you roll this out. Now, let’s talk a little bit about you. Why did you join MongoDB?

KM: Before joining MongoDB, I worked in Seattle at Microsoft SQL Server and at AWS, where I was thrown in the deep end, working on a service running on thousands of nodes across the globe. One day, while I was on vacation, a recruiter from MongoDB randomly reached out to me. After learning about the new Document Model and how MongoDB is essentially taking the best things from the good old relational databases and making them more scalable and available, I was convinced that this was “the future.” So, I made the jump and moved to New York City.

I have been at MongoDB for more than seven years because I still believe the direction we are going is the future. In addition, I love the company culture with respect to giving responsibility to engineers to provide input into the roadmap of their teams, and also with tasking them with doing features of critical importance to the business.

AP: You went from Seattle to New York City, and now Spain. Can you tell me more about your move and how that sparked a new Sharding team in Barcelona?

KM: After living in the United States for roughly 15 years, I decided to move to Europe. It had always been my dream to live in Barcelona because of the Mediterranean climate and lifestyle, which are very well paired with a good education and technology environment. For example, Universitat Politècnica de Catalunya is a well-known school here that hosts the Barcelona Supercomputing Centre and the Mare Nostrum supercomputer. They conduct research very closely related to what my team does, and a good portion of my team had some tenure there at some point in their careers.

Because I was very familiar with the company culture and could mentor this team on our technological base, company values, and processes, MongoDB gave me the opportunity to build a small team in Barcelona to see how things would work out. Initially, we started with just two people. After the first eight months (which included the COVID-19 lockdown), it was obvious the team was very strong and that there is very good talent in Barcelona. Therefore, we decided to scale it up and now we have eight people.

AP: I hear you’re planning to hire a few more to the Sharding team in Barcelona. What are the career opportunities for your team?

KM: That’s correct. Our team is growing.

Since sharding is at the forefront of the company’s products, there are many interesting projects to choose from that solve difficult distributed systems problems.

With respect to career growth in general, it’s not much different from our North American teams. Our career growth guidelines are universal. Currently, there are two career paths; individual contributor (IC) and manager. On the Barcelona Sharding team, we have career growth opportunities mostly on the IC path. However, we have discovered that it is best to promote leads from within the team, because they already have established rapport with the team members and can work well with them. So while we are growing initially and we definitely lean on the IC path more, there are lead opportunities too.

AP: How do you mentor individual contributors so they can move up on the team?

KM: It’s a cliche, but the best way to build skills for new engineers is to “throw them in the deep end” and let them figure out how to swim. When people join, we generally let them ease into the team’s processes for a few weeks and train them on how to use MongoDB as a customer. Then, they spend the next month or so fixing small bugs, investigating failures, and so on. After that, they typically join an ongoing project, and little by little will become responsible for some aspect of the project.

Mentorship comes as a byproduct of working together with engineers who have been on the team a long time already, and consists of providing feedback and explaining internals of the system and why things work the way they work historically. I also encourage people to read papers, see what other products are doing, and so forth.

AP: What’s your proudest moment leading this team?

KM: Realizing about five to six months after the first two engineers started and after we hired our third engineer that we have become a proper team and not that little group of people working out of Europe. Our team members were participating in discussions with the bigger team in New York, defending their ideas and proposing new ones. I believe this helped MongoDB see the value in our team and why we’re able to continue to add more hires in Barcelona.