EN
DE
Fluro is a technology-led consumer lender, offering unsecured personal loans via their white-label platform.
They have lent more than £250m of loans since launching in 2014. Fluro transitioned from PHP to Kotlin due to its larger talent base and better support for concurrency. They considered Java but found Kotlin to be more productive, and with great interop with the Java ecosystem. Fluro has used Kotlin for multiple projects, including customer portals, pricing, external data integration, and payout automation.
Currently, 20% of their codebase uses Kotlin, with a goal of reaching 100%. The biggest challenge was getting PHP developers accustomed to the new language and approach to development and operations techniques needed for Kotlin compared to interpreted languages like PHP. The conversation is about hiring Kotlin developers and the challenges involved.
The company looks for candidates with strong coding skills and project ownership but has had difficulty finding enough qualified candidates. They have tried a pair programming exercise as part of their interview process, but some candidates struggle to complete it within the allotted time.
Tom Wood interviews Jason de Carvalho and explores the journey Fluro took when moving to Kotlin.
Tom:
When did you start using Kotlin?
Jason:
2021. Previously we had a PHP monolith, we wanted to pick a JVM language or a language that's got a larger talent base of people that can build distributed systems.
So PHP, you've got two types of engineer, one that builds that sort of system, but ones that just do WordPress or Drupal and that sort of stuff as well.
We felt there was a bigger market there. And also there were a few issues we'd have with using PHP in the particular framework, like in terms of concurrency or some libraries not there are some quirks in there that haven't been seen in enterprise-ready libraries in the Java ecosystem. Just sort of the types of use cases not being fought about by the people writing those libraries. So there's an aim to do that.
Tom:
In your previous company you were using JVM, weren't you?
Jason:
Yeah, it was mainly Java. Some teams were using Scala and including one of the groups in my area, around 30-40 people there.
Tom:
And then the transition from PHP to Kotlin seems to be there are at least two of the fairly similar businesses to you. Lendable is on a similar journey and Personio is as well, so it seems to be an interesting route there. And, what framework are you using?
Jason:
It's http4K. We liked its simplicity and functional style, which is a common theme to many of our tech choices. Despite focusing on developer experience and simplicity, it's also super performant despite the simplicity. And the default way of using it isn't with explicit concurrency unlike Ktor that uses coroutines, it's just threads and it's still super performant. With Project Loom coming out eventually, then this is going to be sort of a non-issue and we don't need even the complexity overhead of coroutines.
Tom:
In terms of the applications that you're using Kotlin for within your business, what is it across the whole business or what applications are you using it for?
Jason:
It's going to be across the whole business in due course. The first project we launched was a rewrite of our customer portal, Kotlin on the back end and Typescript/React on the front end. But since then we've built a new pricing service and external data integration service. We're building a service to automate payouts in the reusing Kotlin. Essentially building in Kotlin as much as we can.
Our new work is done in Kotlin, and we'll make some smaller changes to the monolith tactically, but the broader strategy is to be working in Kotlin now.
Tom:
How much of the company's code base is in Kotlin would you say?
Jason:
I think we're up to about 20% now. It's maybe a two-to-three-year goal to be near 100%. There are probably going to be some laggards, but that sort of time frame is.
Tom:
Okay, fine. And do you think there are barriers that might prevent you to get into that 100% number?
Jason:
One of the early ones was getting people from a PHP background to be able to write Kotlin code, its easier for people from a Java background. They picked it up super quick. But it's the bigger change for PHP and it's not just the language, there's the frameworks we use and there's just kind of the approach to development that's different.
Tom:
Okay, and in terms of your engineering team, what is the balance between the PHP and Kotlin now?
Jason:
It's about 50:50 in terms of people's backgrounds with a couple of React engineers.
Tom:
Did you manage to find any PHP and Kotlin people or did you just have to upskill everyone?
Jason:
I don't think we hired anyone with Kotlin experience before they joined us. This has been a non-issue with people from Java backgrounds. I imagine it'd be almost a non-issue from C# as well, but in general, we're open to literally any other background. Our main focuses are their fullstack development skills and their test-driven development skills.
Tom:
What are the three top three benefits you've experienced from adopting Kotlin?
Jason:
Part of our modernization has been rewrite the system with better quality code. And so it's not just been because of the language shift, you can build high-quality systems in PHP as well, but in general we're finding more concise code that does end up being better quality and more performant systems.
Tom:
How many people in your business are doing Kotlin?
Jason:
Our team is around 16 people, and essentially all of them can do some Kotlin now.
Tom:
And do you have any freelance or contractors or is everyone permanent within the business?
Jason:
It's all permanent.
Tom:
And specifically on the hiring side, then, what are the kind of main challenges you faced when trying to hire Kotlin engineers?
Jason:
We've been focusing on really great coding skills, which is a very narrow subset of the whole skillset. We ask for what sort of level of project ownership. Level of project ownership is more how progressed in their career are they rather than the hard criterion. Whereas for everyone, we're looking for really strong coding skills like being able to write really good code in our programming coding exercise and finding people that really double down into that coding skills has maybe been a challenge.
Tom:
How long do you expect the pair programming exercise to take?
Jason:
It's an hour of pair programming. We have 30 minutes of talking about it. But we are working on a revised edition of it where we give more of a skeleton. So that all of that time can be focused on one part of that, the most tricky high-signal part of it. If a candidate does that well, then you would have probably done the rest of it well as well. We've made sure the candidate definitely has enough time to be able to do that part of the interview or of the exercise. Whereas before they got there, they often ran out of time just because you were, ironically, putting more effort into the quality of the rest of it.
Tom:
Have you interviewed anyone since you've made the slight nuances changed?
Jason:
I'm not sure whether it was in place for the last couple of hires that we made but quite possibly it was okay.
Tom:
And what is the full process before the pair programming you have? Is there an initial call first?
Jason:
Yes, we're doing an initial call and the latest revision was try and then offer either a take-home or pair programming interview. But it might be more valuable to insist on the pair programming even though that maybe pushes some other candidates away just because we get more information about why they're making the decisions, though we don't want to take people's time up unnecessarily either. Also, lots of people say they do the take home but they're not find the time to actually do it. If you book in a pair programming then they turn up and do it.
Tom:
Yeah, I think my experience is obviously on the other side of this and you definitely get a bigger drop-off rate, there's drop-off rates on both sides right, whether it's a live pair programming or a take-home. But the take-home tests do seem to be bigger drop-off rates. Not drop-off rates always but certainly the time that they take to complete the exercise as well. It might take them a couple of weeks and typically if they're interviewing at more than one of the place, that kind of process gets pushed to the side and they focus ones where they can work through the process a little quicker. So my experience tells me that homework and exercises do slow processes down and reduce chances of success.
Do you give the candidates much context as what to expect prior to the interview? Are they kind of coming in fairly blind?
Jason:
We give them a little bit of heads up on what the exercise is but weren't giving the full brief ahead of time, like maybe 30 minutes ahead of time.
Tom:
Have you had lots of interviews with people with Kotlin experience and they've just not hit the bar?
Jason:
No, it hasn't been that, it's been availability. So, you are working in Kotlin space and giving Kotlin engineers, but the other agencies I don't think find them. Maybe there's just not very many and you need to really focus on finding them to be able to find them. A couple of the salary reports I read suggest that trying to be thinking around why this is, but they have a different line entry for Kotlin Engineer versus Java engineer with a higher salary band. And I'm not necessarily sure it's because they know Kotlin because we hire someone that doesn't and they learn it quickly and that's Java typically.
But my hypothesis at the moment is that companies that are using Kotlin are more likely to have a higher bar for recruitment and so many Java shops do have a high bar for recruitment as well. But there's probably more a higher proportion of Java development places that have a lower bar than Kotlin places that have a low bar. There's probably fewer Kotlin places with a low bar.
Tom:
Why do you think that is?
Jason:
The sort of group that thinks about how they should be writing code to the extent that they've thought about Kotlin rather than just going with a default have probably been thinking of other aspects of writing code and development. The difference between Kotlin and Java isn't giant, but there's probably a lot of other practices that come along with someone that's looked into it and thought, “ok, we're going to use Kotlin”.
Tom:
Do you find a lot of the Java engineers that you spoke to that was quite an interesting selling point and incentive for them to come and join yourselves because they would get the opportunity to work with Kotlin commercially?
Jason:
Yeah, it definitely is. There's a selection bias about who wants to put themselves forward for our roles. There's definitely people that want to learn Kotlin and haven't had the experience the opportunity before and that includes PHP engineers as well.
We're happy to have people from PHP backgrounds and being able to read our existing code is useful. We absolutely need them to be willing, or even more than willing: wanting, to learn Kotlin and be enthusiastic about it. So it's good when we see that coming through from a candidate.
Tom:
And how long do you think it takes someone, an engineer from a different background to upskill themselves and become proficient in Kotlin?
Jason:
I think it's three months to be writing good idiomatic Kotlin.
Tom:
And do you do anything practically to help them upskill? Is there any courses that you put them on or is it just kind of learning on the job and from other engineers?
Jason:
Yeah, we've got a lot better at this recently. There's a gap where I knew that we needed to come up with something a bit more structured rather than just pair programming and feedback. We've created a more curated learning path for our team, what's going to be useful for working at Fluro and then we're organizing workshops for people to learn together.
Tom:
Do you tend to hire people that have been to university and computer science backgrounds? Do you have any thoughts on that?
Jason:
Yes, in the past and in general, and this comes back to being language agnostic and stuff, I care about skills, and when it comes to the interviews, we're only going to judge someone on skills. We're not going to say, well, they seem better on skills, but they didn't have the degree. That's not what we're going to ever do. But in practice we find that people with that background are more likely to have the skills necessary. I've said before, very open to from any background as long as they have the skills because there's many ways to develop those skills and you do see it all the time. For example, I did a maths degree, but went into software engineering. More recently we've been discussing whether should we hire a grad intake this year.
Tom:
It's a tricky one, isn't it? Because it does kind of depend on your infrastructure internally and what support you can give to these people. Because it's all well and good hiring these people, but if you haven't got the resources, people available to help upskill them and give them the development and that they need, then you kind of just set them up to fail a little bit anyway.
Jason:
Yeah. We’ll learn from creating our new learning path at the moment, that we can be in a place where we can take a less experienced person and get them productive in our stack faster and that we've got a high enough skill density that they can learn from everyone. Whereas right now they'd also need to learn a few languages to be truly productive. So the more we condense our stack into very lean tech stack, the easier that will be.
Thank you for your time, Jason, it was great to chat with you and learn more about Kotlin as a programming language at Fluro.