14 An Interview with Roman Elizarov

Roman works at JetBrains as Team Lead for the Kotlin Libraries team, where he is focused on development and maintenance of multi-platform foundational libraries for Kotlin programming language. His main contribution in this role is design of Kotlin coroutines and development of the Kotlin coroutines library. In 2000, Roman graduated from St. Petersburg ITMO and started his career as a professional software developer. During his undergraduate study, he participated in International Collegiate Programming Contests (ICPC). Since 1997 and, until now, Roman has served as a Chief Judge of Northern Eurasia Region of ICPC. He also maintains his academic ties and now teaches a course on concurrent and distributed programming at ITMO. Roman worked for most of his career at Devexperts, where he designed and developed high-performance trading software for leading brokerage firms and market data delivery services that routinely handle millions of events per second. He is an expert in Java and JVM, particularly in concurrency, real-time data processing, algorithms, and performance optimizations for modern languages.

Roman Elizarov

Connect with Roman

Twitter: @relizarov

“If you’re hiring a person to do some specific assignments using a specific framework for a library, then you might just test a person’s knowledge of this specific practical task. But if you’re hiring a person for advanced status to do something that wasn’t done before, you’ll want someone with the key fundamental knowledge.”

Interview

You have a very strong algorithmic background. There has been a large controversy in terms of interviews for software engineering jobs — some people are in favor of having algorithm content in those interviews, whereas some other people prefer to focus on more practical issues. There will be some white-boarding. There is homework to implement at home. There is bare coding. What is your opinion about this? What is the method you have found that works best in your career?

This is torturous because there is no one simple answer, especially when you are hiring a person. What kind of skills, experience, and knowledge are you looking for in a person you are hiring? So consider algorithms as an example, especially in terms of global content. I worked all my life with all the high-performance, high-level, low-level stuff, and we were developing software in which these aspects were critical. But now I’m working on core foundational content libraries. Millions of people will be using them and, with all the different use cases, every small detail will matter in these libraries.

So, for hiring, we are looking for people who understand all those low-level details, and these aren’t just about algorithms. It’s actually quite an extensive body of knowledge that we’re looking for a person to have—that includes some parts of algorithm design and implementation. But it’s not the only skill we’re looking at. The difference I think, and why many people are asking about algorithms, is that, unlike different technologies, they don’t just come and go.

Once your library percolates, in five, 10 years, there are different levels of framework, and this changes every time. In our careers, you always learn new things, but there is certain fundamental knowledge that’s algorithmic in design; it’s one of those things that never changes. It does progress, but it progresses in a more specialized areas—it’s not like the fundamentals, which do not change.

Algorithms have been there for 50 years. And it’s the kind of knowledge you’re supposed to acquire early in your career. It’s supposed to stay with you for the rest of your career.

If you’re hiring a person to do some specific assignments using a specific framework for a library, then you might just test a person’s knowledge of this specific practical task. But if you’re hiring a person for advanced status to do something that wasn’t done before, you’ll want someone with the key fundamental knowledge.

There’s a current trend of placing a job candidate on the team for a few days and paying them as freelancers or contractors for their time. What do you think of this approach?

When I’m hiring a developer, I want them to write code. So, whatever the strategy, by the end of the interview, I should be familiar with or what kind of code they are writing. But you also want to know how they fit with your team and how comfortable you feel with them. But there’s a lot of approaches. Eventually, there’s some moment just to stop and make a decision. I don’t think one strategy is superior than the other; it’s just whatever companies feel they like doing.

You’re also involved in functional programming, which isn’t as well-known in our field, especially with enterprise software. How would you explain functional programming to people who have no experience with it?

Functional programming is one of the things a software engineer must know. It’s something that they should have been learned when the person was learning how to program. It’s really pitiful that it’s not a universal knowledge still nowadays. And the reason for that? When you teach people programming, it’s typical that you teach people imperative programming first and, in some sense, that’s essentially whether it’s fundamentally easier to accept.

I haven’t seen any research into this, but it seems the educational courses today—like any computer science 101, or any introduction to programming course—are structured to start with imperative programming. We teach loops. So this is how we, as an industry, are teaching people to code: imperative comes first and then, somewhere later in education, people learn functional programming. And, so, some people just never get to learn functional programming, which is understandable.

But project programming is when it’s repetitive; you end up writing the same things over and over again. You need to filter objects, and you go write this loop that does filtering—and you do it again and again and again. It’s very predictive; it’s time consuming. So functional programming helps avoid this repetition; instead of repeating the same thing over and over again, you extract it through a function. This was known before as a kind of procedural programming.

The key difference between procedural programming and functional programming is that, in procedural programming, we would usually extract some operation to a processor, and then we use it to repeat. In functional programming, we go a step further. We make higher-order functions. So we don’t just extract a function to filter this particularly, under this particular criteria, because this particular operation is unlikely to be repeated in the future. But we are extracting a high-order function or filter that takes another function as a parameter that configures exactly you want to filter.

So it’s not just introducing new function procedures. It is basic imperative programming 101. It’s about a program with higher-order functions that we use to avoid this repeating boilerplate. We use algorithms that you read just once. Then it goes on from there, and you can then increase those levels of abstraction further. But from a practical standpoint, you’re just reaching higher in terms of code reuse.

Your work with functional programming has made you one of the direct contributors to the success of Kotlin. What would you say to a person interested in adopting this language?

There are many reasons I’d advocate for adopting it. Something interesting is that every person is different, and every person has at least 10 reasons why they’d do what they do. I think that’s the key to Kotlin’s success. Kotlin has dozens of things that it does better than other languages. It’s better on so many aspects overall that I see no reason not to adopt Kotlin.

“Kotlin is pragmatic. We solve. We’re not into any kind of pure theoretical computer science. We’re not here to do any religious wars. We’re not here to promote our vision. We are here to solve problems developers face day to day.”

Tell us about the Kotlin team.

Right now, we have a team of more than 60 people working on the language—just a core team. We have a really great community of contributors who help us with things like feedback and code. And I think that’s important to success. Nowadays, you can’t succeed in a project like a programming language without a community, without being open and not just open source, but open and working with this community.

Regardless of how big a team you have, you can’t know everything. You can’t foresee everything. You can’t take every use case. You can’t know every use case by heart.

Kotlin is pragmatic. We solve. We’re not into any kind of pure theoretical computer science. We’re not here to do any religious wars. We’re not here to promote our vision. We are here to solve problems developers face day to day, and to make their life in Kotlin simple. That’s our mission. That’s all it is about. There’s no hidden thinking about that. There’s no hidden agenda.

Do you think most languages are working toward a specific goal and long-term vision, or are they responding to what the community needs at that time?

If you look at modern languages designed 10, 15 years ago, you see lots of common trends, and this is kind of converged with the old. I see that the times change, how people write code changes. There’s no surprise that this drives the change in programming languages, because programming as a field is evolving quickly. Twenty years ago, we were writing desktop applications and there were microservices. Nowadays, we are writing mobile applications. And there are way more people programming right now. Projects are becoming way bigger than they used to be—20 years ago, big projects were the exception. It’s no surprise that programming languages need to change to meet these new challenges, and no surprise different languages come to similar conclusions, to how these challenges have to be met.

One of the problems we seem to have is that a student starts in the university, and then will begin their professional career in five, six years. What can you recommend to these students to focus on in order to have a successful career?

Balance your education. Remember that the fundamentals are important because they stay with you forever. While you’re studying at university or in school for that matter, that’s where you should really focus on fundamentals because, as you grow older, it’s hard to pick up fundamentals you missed. So those fundamentals not only stay forever with you, they also form how you think about different problems and that’s important for the rest of your life. But, since when you graduate to get an excellent job, it’s important that you also get yourself familiar with whatever programming languages are out there.

While in university, you should not miss things like summer internships and practice time because they explore the actual technologies that are important right now. Software developers are so much in demand right now and there’s software all around the world in every conceivable niche. So lots of people find development easy—especially bright people who have a knack for it.

They find it so easy to find a good job early in their career that they might think, “Okay, I’m fine. I don’t need the rest of it. I’ll just do this. I have a job now, I’ll do it.” But then the problem is that technologies will change over time. They will in five years, in 10 years. The old ones will wither, the new ones come, but the fundamentals are there forever. So, again, while in university, you should not forget that you should learn—that’s your chance to get your fundamentals straight. And then if you get them straight, you’ll be able to find a good job for the rest of your life.

Are there any books that you could recommend to a fellow software developer that had a lasting impact on your career?

One book I really loved as a kid was Algorithms + Data Structures = Programs by Niklaus Wirth. This is a classic book. It’s quite out of date right now. I wouldn’t recommend starting with it right now because algorithms that are explained there are out of date. But that was my go-to book that basically taught me the basics of algorithmic design and how to think about writing code and even structuring code.

Do you think there is a concept that most software developers don’t pay enough attention to when they’re trying to grow their careers?

Something I think people miss when they get into industrial programming is depth of knowledge. When they get a job, they just start doing new things and are under pressure to do them quickly. So they usually make a mistake of growing their knowledge upwards as they learn how to use these technologies. They learn tips and tricks, and this is great, but what lots of people miss is the fact that they have also to study in-depth. The question they should be always asking is how it works, what it does inside, and what’s inside of that?

We develop in abstractions. There is a good post by Joel Spolsky titled, “The Law of Leaky Abstractions,” which I would again recommend anyone to read because it explains the importance for a good software developer to always question everything they use and to always learn how it works inside, what it does, why it works this way. And that’s universal advice for any kind of things.

The software development career moves very fast regardless of the fundamentals. There are new libraries, languages, and we need to understand the fundamentals. We need to master them. However, we need to use current tools because it’s part of our day-to-day work.

Being in this fast-paced environment, how do you keep yourself updated in our industry? Do you have any particular system like mailing list, attending conferences, reading, etc.?

I don’t have any single advice. There are many resources. You can use social networks. You can just talk with people. You can read books. There are so many resources out there that tell you what’s new, what’s in conferences, etc. I can’t give universal ways that work for everybody, but I would urge every developer first to learn what’s up, what’s new and what’s going on.

What’s something you wish someone had told you when you were getting started that you had to learn the hard way?

Nobody taught me formally, for example, concurrency. At the time I was studying, this was not something people talked about a lot. So, at first, I’d stumble upon problems with concurrency in practice, and then I had to go back and relearn all the fundamentals, read papers, read books about it and then discover this whole world. So, concurrency, for me, even though I am now an expert in this field, it’s not something I was formally taught. I practiced and then I went back and learned all the theory out there. It is important when you stumble into something in practice, don’t always look for a rule because, when you know the basic principles, that saves you from having to know specifics.

What is the most undervalued skill among software engineers that you would like to see more?

People are so different. Some people lack knowledge, others lack compassion. Other people lack teamwork. I don’t have any universal advice. People are so different.

Roman’s Recommendation

• Algorithms + Data Structures = Programs | Niklaus Wirth