Chapters

Hide chapters

Living by the Code

Second Edition ·

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Community

Section 1: 14 chapters
Show chapters Hide chapters

Getting to Work

Section 2: 17 chapters
Show chapters Hide chapters

14. An Interview with Roman Elizarov
Written by Enrique López-Mañas

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

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
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.

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.

Roman’s Recommendation

  • Algorithms + Data Structures = Programs | Niklaus Wirth
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now