Hiring for Kotlin: what to know first
JetBrains created Kotlin, and it is open source. It runs on the Java Virtual Machine and on Android, with other targets as well. Google recommends it for Android, which is where most teams first meet it. Hiring a Kotlin specialist means looking for command of the language and how it behaves in production: compact code, fewer surprises and files a newcomer can follow. The value shows once your product is out and several people are changing it every week.
Which gap are you filling
Some roles are about the product, and some are about the language. A product role takes in builds, store releases and device behaviour. A language role is about how the code is written and where it runs. Choose the second when releases already have an owner, when a Kotlin service is on the roadmap, when two platforms should share logic or when a Java project is waiting for conversion. Over time many teams want both skills, and one strong person can sometimes supply them. Name the gap first, and the search gets easier.
Short code that stays readable
Kotlin offers many compact forms. Data classes cut boilerplate, sealed types list every possible outcome and extension functions add small helpers where they are used. Applied with restraint, a feature fits on one screen. Applied for show, the intent disappears. Ask a candidate for a function they made simpler, and notice which tricks they left out.
Null safety and read only data
The type system tracks which values can be missing, so a whole family of crashes disappears if the code honours it. Forcing a value with a double exclamation mark deserves a question in review. Read only data that never changes after creation also helps, particularly when several tasks run together. Good developers use these as design aids rather than hurdles to get around.
Coroutines and Flow
Coroutines let background work be written as ordinary top to bottom code, so a web request reads like any other call. Flow carries values that arrive over time, such as live search results or a setting that can change. Scope and cancellation are the hard part. Work begun on a screen must end when that screen closes, and failures need a place to land. Ask how a candidate would test such code and what happens to an unfinished request when the user leaves.
Jetpack Compose
Compose is the current toolkit for Android interfaces. You describe a screen from its state, and the framework redraws what changed. New apps use it, while older ones often keep a mix of Compose and classic views for years. A Kotlin developer should keep state tidy, avoid needless redraws and know how to embed Compose in an older screen. If you want an owner for the whole app, including releases and devices, see our Android developers.
Kotlin beyond the phone
The language is not limited to apps. Because it runs on the JVM, it reaches the huge range of Java libraries. Ktor is a JetBrains framework for servers and clients written in Kotlin, and Spring Boot, popular in larger firms, supports Kotlin too. Teams write APIs with less code than Java needs, and some reuse data models in the Android app. An experienced hire can tell you which framework suits your people and why.
Kotlin Multiplatform
Multiplatform projects keep one body of code for logic such as networking, storage and business rules, then use it from Android and iOS. Each app keeps its own screens. This removes repeated work, though it brings extra tooling and needs people who read both ecosystems. Ask whether you need it at all. When one shared set of screens is also a goal, compare it with React Native developers.
Converting Java step by step
Both languages coexist in a single module, so conversion does not have to be a big bang. A sensible order is to write all new classes in Kotlin, put tests around old ones and then convert a few at a time. Android Studio can translate a Java file, but the output is only a first draft that someone fluent should reshape into natural Kotlin. Ask candidates which classes they would pick first and why.
Tests for Kotlin projects
Teams commonly use JUnit, fakes or a mocking library, plus small helpers for coroutines and Flow. Quick feedback is the aim, so decisions live outside screens and in plain classes. A useful question is how a candidate would test code that calls a remote service, and what they do about tests that fail now and then without any code change.
Gradle and project layout
Most Kotlin builds run on Gradle, frequently scripted in Kotlin itself. A thoughtful engineer divides the code into modules with clear edges, keeps dependencies short and watches build times. It is quiet work, yet slow builds drain a team every day, and good module boundaries also make sharing between app, server and libraries far simpler.
Signs it is time to hire
- An Android app is about to start and you want the foundations right.
- Your Kotlin or Java code is hard to change and review.
- You plan to adopt coroutines and Flow, or move screens to Compose.
- A Kotlin service is planned to sit behind the app.
- Android and iOS should reuse the same logic.
When the real need is someone to own releases, device testing and the whole Android product, start with an Android developer and bring in deeper Kotlin skill later.
Reading a candidate’s code
Ask for something you can open: a shipped app, a public library or a short sample. See how names are chosen, whether errors are surfaced and if the tests would catch a real bug. Then invite the candidate to describe a choice they would now make differently. Engineers who can do this usually leave a codebase better each month.
Questions worth asking
- When would a sealed type beat an enum or a data class?
- How do you stop work that started on a screen the user has left?
- What separates a cold flow from a hot one?
- How would you convert a Java class without changing its behaviour?
- How do you make a test independent of the clock and the network?
Strong replies come with a reason and an example from a real project. Treat a perfect answer to everything, with no trade offs mentioned, as a mild warning.
A short paid trial
Set the same real task for each finalist, such as a data layer with tests, a Compose screen backed by a remote call, a small Ktor route or the cleanup of one tangled class. Pay for the hours. Then compare the results, the questions they raised and how well each person explained their choices.
Keeping the project in your hands
Decide on a style guide, a linter and a review routine before work begins. Register the repository and the store and cloud accounts to your company and give each engineer a separate login. Ask for a short note on building and testing from a clean machine. That way a change of staff costs you very little.
First weeks
Share the repository, a test copy of your server, the designs and one small starter task. A weekly call and a single task board keep progress visible. Point out awkward corners of the code early, since a specialist repays the cost fastest there.
Common slips
- Choosing on a library list without opening any of the candidate’s code.
- Starting coroutines with no clear scope or cancellation plan.
- Running a converter over all the Java and calling it finished.
- Leaving repositories or store accounts under a contractor’s name.
For more context, see our Android developers for full apps and our mobile app developers for the wider picture.