Interview with Personio .

The interview is about Personio's use of Kotlin in their microservices architecture. They started using Kotlin around 2021 when they moved to a more microservices architecture, initially dabbling with it before fully committing. They transitioned from PHP Laravel monolith and are now predominantly using Kotlin for microservices communicating across their stack. They chose Kotlin as an industry standard, with support from big players such as Jetbrains, Google, Facebook, and Netflix.

The main challenges they faced were upskilling engineering teams and ensuring good infrastructure support for running the stack on JVM through Kubernetes and Docker. They primarily use SpringBoot framework but also have other services that don't require it depending on the use case.

Ben speaks to Luke Curtis, Engineering Manager in the Personio Team. 

Ben:
What language did you transition from? 

Luke:
We transitioned from PHP to Kotlin. 

Ben:
Why did you decide to start working with Kotlin?

Luke:
I think there was a good alignment there in terms of its verbosity compared to Java as well. We looked at Java for obvious reasons, but Kotlin kind of made more sense for us as it moves into the more mainstream and gives us more of an opportunity to write a bit more flexible code, shall I say.

Ben:
Is there any particular challenges that you have faced going from a non-JVM language to Kotlin? Obviously, the more typical route is moving from Java to Kotlin rather than PHP, although we are seeing sort of other languages pop up more and more. In terms of transition, are there any particular challenges that you feel you have faced outside of that because you haven't transitioned from Java? 

Luke:
I think the main challenges we've kind of faced really are from an operational perspective. 

I'd say from a technical perspective, there have been no real roadblocks per se. I think the only thing that may have been like less what's the word I'm looking for, maybe more of a challenge, is just around that infrastructure side of things. 

Ben:
And you said you looked at Java. Were there any other languages that you also considered when you were looking to make that change? 

Luke:
Not so much. I think were pretty happy with the JVM world, to be honest. But we still use Golang in Personio, so it's just kind of whoever feels which language facilitates their use case best. 

Ben:
What framework do you use with Kotlin? 

Luke:
We're currently using Spring Boot, currently moving all of our services to Spring Boot 3.

Ben:
It's definitely the most popular, although there are of course, others which seem to be growing in popularity, like Http 4K, for example, seem to be picking up as well. 

Ben:
So, in percentage terms, roughly how much do you say of the code base across Personi is written in Kotlin?

Luke:
I'd say probably right now, today it's about 40% in Kotlin, maybe 10% in Golang, and the rest is still currently in our PHP monolith. But that number goes down every down the PHP side as we move to Kotlin. 

Ben:
Yeah, makes sense. And in terms of the future state, where do you see that percentage eventually landing? What's the goal? 

Luke:
I think in general, obviously the goal right now is to just remove PHP entirely from one stack. Whether or not it's in Kotlin in the future, I don't know for sure. But that's not to say we're married to Kotlin in any sense of the word, we're just enjoying what it's doing for us right now and we'll probably keep with it. 

Ben:
What would you say are the top three benefits that you've experienced from using Kotlin? 

Luke:
I think as an engineering manager you want to make sure there's a good pool of talent out there to hire. That's first and foremost the main reason why I believe it to be a good choice for us. Second of all, I think that piece around the clear and very wide-reaching documentation and support online is fantastic. 

I'm looking for some of the more fiddly bits of Java with regards to things like the null patterns and things like that. So it kind of allows us to move quite quickly, but with a very tried and tested underlying foundation of software in the Jvm world. So it helps me quite quickly with a lot of safety. We're now in good hands, as it were. 

Ben:
You mentioned sort of the verbosity of Java earlier as well. Are you finding that you have to write less code than you would with Java and any sort of numbers around that? 

Luke:
Perhaps 100%? Yeah, definitely. Having to write less code. I couldn't give you explicit numbers, but in terms of a like-for-like representation of some of our code in Java versus what would be the Kotlin equivalent, you could easily suggest in terms of actual raw line count, I mean, it goes down, 30% probably just because of the safety involved and all that kind of fun games. In general, it's been totally fine. We're happy with the verbosity of our Kotlin services. 

Ben:
Do you know roughly how many Kotlin developers work at Personio? 

Luke:
I would say around the 300 mark.

Ben:
And, do you know roughly how that would be split between freelancers contractors, and permanent members of staff? 

Luke:
Let's see, we did have a lot of freelancers last year, but we've since started to move more into the permanent employee world. So I think right now I don't know the exact numbers, but there are not many freelancers. 

Ben:
And what are the primary locations for the talent? 

Luke:
Yes, so predominantly our engineers are based in Munich and Dublin. We have offices in Amsterdam where we are also getting engineers at as well. There are three main places for engineering.

Ben:
Now, one of the main reasons that you said you've used the language is because of the accessibility of talent. But are there any particular challenges that you found in trying to hire? 

Luke:
Yeah, I think from my side, this is kind of more of a personal opinion, but from what I've experienced so far when having to hire Kotlin engineers it's not so much about the language, it's more about applying the patterns, and the frameworks that we use within Personio to facilitate that. We do a lot of event logging, event sourcing, event-driven development, etc.

For me, it's more around ensuring that the talent that we're bringing into the fold actually has a solid understanding of what the technical horizons look like for the actual way to build a distributed system, rather than what the languages in particular. I'd say the other piece of the puzzle is obviously Java to Kotlin is a transition, right? That's not a pick-up-and-play type situation. You still need to kind of put a bit of graft in. 

Ben:
And our final question is, would you consider hiring someone with no commercial experience?

Luke:
I think as long as the developer that's being interviewed has an awareness of maybe just the basics of Kotlin before they go into the coding challenge, then that's okay. It's just about ensuring that they can kind of get to grips a little bit with that Kotlin world, but using their hopefully already well-versed approach to software development in general. 

Thanks for your insight into the use of Kotlin at Personio, Luke.