How to find Kotlin developers in 2026: A sourcing guide

Kotlin started as "a better Java" and has become a production backend language in its own right. DoorDash migrated their entire backend from Python to Kotlin. Netflix built the DGS framework for GraphQL on Kotlin. Amazon Prime Video runs Kotlin services at scale. ING Bank processes 4.5 billion payments per year on Kotlin. These are not experiments. These companies chose Kotlin because it gave them JVM reliability with language ergonomics that Java still doesn't offer.

The challenge for recruiters is that Kotlin's developer pool is split. Of the roughly 2.5 million Kotlin developers globally, about half focus on Android. The backend Kotlin pool — approximately 1.25 million developers — is growing rapidly but still treated by many companies as a subset of Java hiring. That is a mistake. Backend Kotlin developers who write idiomatic coroutines, extension functions, and sealed class hierarchies think differently than Java developers who happen to use Kotlin syntax. We touched on Kotlin in our niche language sourcing guide, but it warrants separate treatment, especially alongside its Java and Scala JVM siblings.

This guide covers where backend Kotlin developers contribute on GitHub, what separates idiomatic Kotlin from "Java in Kotlin," why coroutine patterns matter more than syntax knowledge, and how to build a sourcing workflow that finds server-side Kotlin engineers before they start looking.

The Kotlin developer market in 2026

Kotlin ranked 15th in the 2025 Stack Overflow Developer Survey at 10.8% usage. That places it firmly in the mainstream — larger than Go, Rust, or Swift, smaller than Java or TypeScript. The raw number is approximately 2.5 million developers globally. But that headline number is misleading for backend hiring because it includes Android developers, multiplatform mobile developers, and Kotlin/JS experimenters alongside the server-side engineers you probably need.

KotlinConf 2025 reported that 50% of Kotlin developers now do backend work, up from roughly 40% two years ago. That puts the backend Kotlin pool at approximately 1.25 million developers worldwide. Two things are driving that growth: companies migrating Java backends to Kotlin for developer productivity, and Spring Boot 4 setting Kotlin 2.2 as its baseline. When the largest JVM framework treats Kotlin as a first-class language, the ecosystem follows.

The Spring ecosystem is where the Java-to-Kotlin crossover is most visible. 27% of Spring developers now use Kotlin, according to the Spring developer survey. That means roughly one in four Spring Boot applications being written today uses Kotlin rather than Java. That is mainstream adoption, not a niche experiment.

Compensation for Kotlin developers in the US averages $117,000 to $127,000, carrying a 1 to 3 percent premium over comparable Java roles. The premium is modest because most companies evaluate Kotlin candidates against the broader JVM talent pool. Senior backend Kotlin roles at companies like DoorDash, Netflix, and Square command higher salaries, particularly when the position involves coroutine-heavy architectures, GraphQL infrastructure, or distributed systems. The bigger draw for Kotlin developers is often the codebase itself. Companies using Kotlin for backend tend to make more modern tooling choices generally.

Where do backend Kotlin developers actually work? Microservices and API development, particularly with Ktor or Spring Boot. GraphQL servers, where Netflix's DGS framework has become the Kotlin-native option. Payment processing and fintech, where ING Bank and Square demonstrate Kotlin's reliability at transaction scale. DevOps tooling, where Gradle's Kotlin DSL has made Kotlin the language of build infrastructure. And data engineering, where Kotlin's coroutines work well for pipeline orchestration.

The companies that have gone all-in on backend Kotlin are mostly engineering-driven organizations: DoorDash, Amazon Prime Video, Netflix, Expedia, ING Bank, Square (Block), Atlassian (Jira cloud migration), Uber, Gradle, and R3 (Corda blockchain platform). They chose Kotlin because it solved real problems with developer productivity, null safety, and JVM interoperability that Java couldn't fix without breaking backward compatibility.

Where Kotlin developers contribute on GitHub

Kotlin's open source ecosystem covers the language itself, server-side frameworks, concurrency libraries, and broader JVM infrastructure. GitHub works well for sourcing Kotlin engineers because most production frameworks and libraries are developed in the open, and contributors to these projects almost always use Kotlin professionally.

The language and compiler. JetBrains/kotlin (52,515 stars) is the core repository — the compiler, standard library, and language tooling. Contributors here work at the deepest level of the Kotlin ecosystem. Few people contribute here, but even substantial issue discussions and bug reports show a developer who understands Kotlin at the compiler level. The K2 compiler rewrite has brought fresh contributor activity, and developers involved in that effort understand both the language semantics and the JVM compilation model.

HTTP and networking. square/okhttp (46,922 stars) is the most widely used HTTP client in the JVM ecosystem, and its Kotlin adoption is extensive. While OkHttp is used from both Java and Kotlin, contributors who work on its Kotlin extensions, coroutine integration, and interceptor APIs understand both networking and idiomatic Kotlin well. Square pushed Kotlin's backend adoption harder than almost any other company.

Server-side frameworks. ktorio/ktor (14,333 stars) is JetBrains' own server-side framework, built from the ground up in Kotlin with coroutines at its core. Unlike Spring Boot (which supports Kotlin as a second language), Ktor is Kotlin-native — its entire API is designed around coroutines, extension functions, and DSL builders. Contributors to Ktor are working with server-side Kotlin in its most native form. javalin/javalin (8,226 stars) is another lightweight option popular in the Kotlin community for building REST APIs with minimal ceremony.

Coroutines and concurrency. Kotlin/kotlinx.coroutines (13,717 stars) is the coroutine library that powers async programming in Kotlin. It is probably the most important library in backend Kotlin. Coroutines are what make Kotlin's concurrency model different from Java's thread-based approach. Contributors here understand structured concurrency, flow operators, dispatchers, and cancellation. If you see real contributions to this repository, that developer knows Kotlin concurrency deeply.

Database access. JetBrains/Exposed (9,197 stars) is Kotlin's type-safe SQL framework, offering both a DSL and a DAO approach to database access. It is the Kotlin-native alternative to JPA/Hibernate, designed around Kotlin's type system and null safety. Contributors to Exposed know how to design data layers in idiomatic Kotlin. For teams using Spring, jOOQ with Kotlin extensions is another common pattern — look for developers who integrate these tools with coroutine-based transaction management.

GraphQL. Netflix's Netflix/dgs-framework is the dominant GraphQL framework in the Kotlin backend ecosystem. DGS (Domain Graph Service) is built on Spring Boot and designed for Kotlin-first development. Expedia also runs their GraphQL infrastructure on Kotlin. Contributors to DGS understand both GraphQL schema design and Kotlin's data class model, which maps naturally to GraphQL types. DGS contributions are a clear signal of backend Kotlin expertise since Android developers rarely work with it.

Build tooling. gradle/gradle has made Kotlin DSL the recommended way to write build scripts, replacing Groovy. Developers who contribute to Gradle's Kotlin DSL support or write Gradle plugins in Kotlin have infrastructure-level expertise. Build tooling contributions signal seniority because these developers understand the full JVM compilation and deployment pipeline, not just application code.

Kotlin Multiplatform. Kotlin Multiplatform (KMP) allows sharing code between JVM, iOS, JavaScript, and native targets. While still maturing, KMP contributors tend to be experienced Kotlin developers who understand the language at a platform level. Libraries like Kotlin/kotlinx.serialization and Kotlin/kotlinx.datetime are multiplatform by design. KMP contributors are worth watching even if your immediate need is server-side only, since they tend to be experienced developers who push the language forward.

Quality signals in Kotlin code

The most common mistake when evaluating Kotlin code is missing the difference between real Kotlin and "Java written in Kotlin syntax." Someone can migrate Java code to Kotlin, have it compile, and end up with something that misses everything that makes Kotlin worth using. Seniority signals on GitHub apply broadly, but Kotlin has specific markers that separate experienced backend engineers from developers who learned the syntax without internalizing the idioms.

Coroutine design. Coroutines are the single most important quality signal for backend Kotlin developers. An experienced developer uses structured concurrency — coroutineScope, supervisorScope, proper cancellation handling, and flow operators for stream processing. A developer writing "Java in Kotlin" will use GlobalScope.launch everywhere, ignore cancellation, and mix blocking calls into coroutine contexts. The difference is obvious in production: one handles backpressure and failure gracefully, the other leaks resources under load. If you see GlobalScope scattered through a codebase, that developer has not internalized structured concurrency.

Extension functions and DSL design. Kotlin's extension functions allow adding methods to existing types without inheritance. Experienced Kotlin developers use extensions to create domain-specific APIs, often building DSLs (domain-specific languages) that read close to plain English. Ktor's entire routing API is a DSL built with extension functions and lambda receivers. A developer who designs APIs this way knows Kotlin's type system and function model better than someone still writing utility classes with static methods (the Java pattern). Look for custom DSL builders, well-designed extension function hierarchies, and lambda-with-receiver patterns in their code.

Sealed classes and exhaustive pattern matching. Sealed class hierarchies with when expressions are how experienced Kotlin developers model domain states. Instead of enums with string values or integer codes, a sealed class hierarchy makes invalid states unrepresentable at the type level. The compiler enforces exhaustive matching — if you add a new subtype, every when expression that handles the sealed class must be updated. A developer who models error states, API responses, or domain events as sealed hierarchies rather than strings or exception types is using Kotlin's type system to prevent bugs at compile time.

Null safety. Kotlin's type system distinguishes nullable (String?) from non-nullable (String) types at compile time. An experienced developer pushes null handling to the boundaries of the system: parse external input into non-nullable types early, then work with guaranteed non-null values throughout the core logic. A developer who sprinkles !! (the not-null assertion operator) throughout their code is defeating the point of Kotlin's null safety. Every !! is a potential NullPointerException — the exact bug Kotlin was designed to eliminate. If you see code full of !! instead of ?.let, ?: (Elvis operator), or requireNotNull, the developer is writing Java with Kotlin syntax.

Data classes and immutability. Kotlin's data classes provide equals, hashCode, copy, and destructuring automatically. Experienced Kotlin developers default to immutable data — val over var, immutable collections over mutable ones, copy() for modifications instead of mutation. A codebase dominated by var declarations and mutable state is a codebase written by someone thinking in Java. This signal is easy to check — scan a few files and count the ratio of val to var. In idiomatic Kotlin, val should dominate overwhelmingly.

Scope functions. Kotlin provides let, run, with, apply, and also for scoping operations on objects. Experienced developers use these functions idiomatically — apply for object configuration, let for null-safe transformations, also for side effects. But overuse is a red flag. Deeply nested scope functions that make code harder to read suggest a developer more interested in clever Kotlin than clear Kotlin. Good code uses scope functions where they cut boilerplate and skips them where they obscure intent.

Testing with coroutines. Testing coroutine-based code requires understanding runTest, test dispatchers, and turbine for flow testing. A developer who writes thorough tests for suspend functions and flows, handling timeouts, cancellation, and error propagation correctly, has both testing discipline and deep coroutine understanding. This is one of the harder parts of Kotlin development, and doing it well says a lot about seniority.

Backend Kotlin vs. Android Kotlin

This distinction matters a lot for sourcing. The language is the same, but the ecosystems and design patterns are different enough that Android experience does not automatically translate to backend competence.

Android Kotlin developers work with Jetpack Compose, the Android SDK, Activity and Fragment lifecycles, ViewModel and LiveData/StateFlow for UI state, Room for local databases, and Retrofit for HTTP calls. Their concurrency model uses coroutines, but in the context of UI threading — dispatching work off the main thread to avoid freezing the user interface. Memory management, battery optimization, and device fragmentation are constant concerns. It is real engineering, but it is different from backend systems design.

Backend Kotlin developers work with Spring Boot or Ktor for HTTP serving, coroutines for server concurrency (handling thousands of concurrent requests, not UI thread management), Exposed or jOOQ for database access, Kafka or RabbitMQ for messaging, Docker and Kubernetes for deployment, and observability tools for monitoring distributed systems. Their concerns are throughput, latency percentiles, connection pool management, and horizontal scaling. Almost none of that overlaps with Android's problem space.

When sourcing, the repository signals are clear. A developer whose GitHub is full of Android SDK imports, Jetpack Compose layouts, and build.gradle files with Android plugins is an Android developer. A developer with Ktor routes, Spring @RestController annotations, database migrations, and Dockerfile configurations is a backend developer. Some developers do both, and those cross-platform engineers who understand the full JVM stack are particularly worth talking to. But do not assume Android expertise transfers to backend by default. The coroutine knowledge transfers. The framework knowledge does not.

The Java-to-Kotlin pipeline

Kotlin's full interoperability with Java is a major recruiting advantage. Every Java library works in Kotlin. Every Kotlin class is callable from Java. A mixed Java/Kotlin codebase is the default state at most companies that adopt Kotlin, including DoorDash, Netflix, and Atlassian. This means your candidate pool is not limited to the 1.25 million backend Kotlin developers. The 126,574 Java developers in the US alone are all potential Kotlin candidates.

But "potential" requires nuance. A Java developer can learn Kotlin syntax in a week. Writing idiomatic Kotlin (coroutines instead of threads, sealed classes instead of enums, extension functions instead of utility classes, null-safe types instead of null checks) takes months of deliberate practice. The risk is "Java in Kotlin": code that compiles and passes tests but misses every advantage that justified the language switch.

The best signal that a Java developer is ready for a Kotlin role is Kotlin side projects on GitHub. Not a single tutorial repo. Look for sustained Kotlin usage across multiple repositories, evidence of coroutine adoption, and idiomatic patterns improving over time. A Java developer who has been writing Kotlin on nights and weekends for six months and whose recent code shows sealed classes, flow operators, and DSL builders is a better hire than a developer with "2 years of Kotlin experience" who writes Java syntax with Kotlin file extensions.

Spring Boot 4 with Kotlin 2.2 baseline is accelerating this pipeline. Companies running Spring Boot in Java are evaluating Kotlin migration, and their existing Java developers are the natural candidates to lead it. If you are hiring for a team making this move, an experienced Java developer with genuine Kotlin interest is often the right profile. They already know Spring deeply and can bring Kotlin idioms into an existing codebase without rewriting everything.

How to search for Kotlin developers on GitHub

Because Kotlin is a mainstream JVM language, the sourcing approach needs to be more targeted than for niche languages. With 2.5 million developers, a raw search returns too many results. You need to filter for backend expertise, idiomatic Kotlin usage, and active contribution, not just find someone who has a Kotlin repository.

Framework-based filtering. The fastest way to separate backend from Android Kotlin developers is to search within server-side framework repositories. Contributors to ktorio/ktor, Netflix/dgs-framework, JetBrains/Exposed, and Spring Boot Kotlin extensions are definitionally backend developers. This is more reliable than language-level filtering because it captures what someone actually builds, not just what syntax they write.

Coroutine library usage. Search for code contributions that import from kotlinx.coroutines in server-side contexts. Coroutine usage in backend services, particularly Flow, Channel, and structured concurrency patterns, tells you whether someone uses Kotlin's concurrency model for server workloads or only for Android UI threading.

Build tool signals. A build.gradle.kts file with ktor-server, spring-boot-starter, or exposed dependencies is a backend project. A build.gradle.kts with com.android.application plugin is an Android project. Gradle build files are the most reliable programmatic signal for distinguishing backend from mobile Kotlin development.

Contribution recency and consistency. Kotlin moves fast (Kotlin 2.0 was a major release with the K2 compiler), so recent activity matters more than in stable languages. A developer who was active in Kotlin two years ago but has not committed since may not know current idioms, coroutine improvements, or multiplatform capabilities. Prioritize developers with consistent activity over the last 6 to 12 months.

Adjacent JVM signals. The Java developer pool is the primary adjacent talent source for Kotlin. Java developers with Kotlin repositories — even small ones — demonstrate intentional interest in the language. Scala developers are another good adjacent pool. They already think in functional JVM patterns, understand immutability and type safety, and sometimes transition to Kotlin when they want a more pragmatic language with better tooling. Search for developers whose primary language is Java or Scala but who have Kotlin repositories showing progressive adoption.

A practical Kotlin sourcing workflow

Here is what works, from discovery to first outreach.

Step 1: Define the technical profile. "Kotlin developer" will flood your pipeline with Android engineers. Be specific about the backend domain. Are you hiring for microservices (Ktor, Spring Boot)? GraphQL APIs (DGS framework)? Data pipelines (coroutines, Kafka integration)? Build infrastructure (Gradle plugins, Kotlin DSL)? Payment processing (transaction safety, financial domain modeling)? Each maps to different GitHub repositories, different framework expertise, and different contributor communities. Someone contributing to Netflix DGS has a different skill set than someone writing Gradle plugins, even though both write backend Kotlin.

Step 2: Identify target repositories. Based on the technical profile, list the GitHub repositories where your ideal candidate would contribute. For HTTP services: ktorio/ktor, javalin/javalin. For Spring Kotlin: spring-projects/spring-boot (Kotlin extensions). For GraphQL: Netflix/dgs-framework. For databases: JetBrains/Exposed. For concurrency infrastructure: Kotlin/kotlinx.coroutines. For serialization: Kotlin/kotlinx.serialization. For build tooling: gradle/gradle. Map the role to the repos. That is your search surface.

Step 3: Extract and filter contributors. Use GitHub's contributor graphs or tools like riem.ai that index GitHub event data at scale. The important part is filtering: exclude repositories with Android SDK dependencies, focus on server-side framework contributions, and prioritize developers whose recent commits touch coroutines, database layers, or API routing. With 2.5 million Kotlin developers total, filtering matters more here than for niche languages where most of the pool is potentially relevant.

Step 4: Evaluate for idiomatic Kotlin. Review each candidate's code for the quality signals described above. Coroutine design is the top-priority signal for backend roles. Extension functions and DSL patterns show language fluency. Sealed class usage shows type-system thinking. Null safety discipline (absence of !!) tells you whether someone understands why Kotlin exists, not just how to write it. Seniority signals like code review participation and architectural decisions apply here as they do for any language.

Step 5: Expand to the Java pipeline. Do not limit sourcing to pure Kotlin developers. Experienced Java developers with Kotlin side projects are strong candidates, especially for teams running mixed codebases or planning a migration. Full interop means a Java developer can start contributing from day one while ramping on Kotlin idioms. Look for Java developers whose recent GitHub activity shows increasing Kotlin usage. They are already making the transition on their own time.

Step 6: Craft personalized outreach. Generic "I found your profile on GitHub" messages get ignored. Outreach that works references specific contributions: "I saw your coroutine-based connection pool implementation in your Ktor service — we're building a similar pattern for our payment processing pipeline and your approach to structured concurrency matches exactly what we need." Kotlin backend developers get fewer targeted messages than React or Python developers because most recruiter outreach lumps them in with Android developers. Mentioning Ktor, DGS, coroutines, or Exposed rather than Jetpack Compose immediately sets your message apart.

Step 7: Scale with tooling. The manual workflow above works but takes time, especially when the biggest challenge is separating backend from Android developers across thousands of profiles. Tools like riem.ai automate discovery and evaluation by analyzing 30 million-plus GitHub events per month and surfacing Kotlin developers based on actual contribution patterns. Instead of manually reviewing build.gradle.kts files to tell backend from mobile projects apart, you describe the technical profile in natural language ("Kotlin developers who contribute to server-side frameworks like Ktor or Spring Boot with coroutine experience") and get a ranked list with contribution summaries and quality scores.

Frequently asked questions

How many Kotlin developers are there?

Approximately 2.5 million Kotlin developers globally as of 2026, based on JetBrains and Stack Overflow estimates. Kotlin ranked 15th in the 2025 Stack Overflow Developer Survey at 10.8% usage. While the total pool is large, roughly half of Kotlin developers focus primarily on Android. About 1.25 million developers use Kotlin for backend or server-side work, according to KotlinConf 2025 data showing 50% backend adoption. The backend Kotlin pool is growing rapidly as Spring Boot 4 sets Kotlin 2.2 as a baseline and companies like DoorDash, Netflix, and Amazon Prime Video migrate server-side code to Kotlin.

What salary should I expect to pay Kotlin developers?

In the US, Kotlin developers average between $117,000 and $127,000 per year, carrying a 1 to 3 percent premium over comparable Java roles. Senior backend Kotlin developers at companies like DoorDash, Netflix, and Square earn more, particularly when the role involves coroutine-heavy architectures, distributed systems, or GraphQL infrastructure. The premium is modest because Kotlin developers are typically evaluated against the broader JVM talent pool. Companies that specifically need Kotlin expertise, not just general JVM skills, may need to offer above-market rates to attract candidates who have moved beyond Java entirely.

Should I hire Kotlin developers or Java developers who can learn Kotlin?

Java developers can learn Kotlin syntax in weeks, but writing idiomatic Kotlin takes months. The risk with Java-to-Kotlin transitions is "Java in Kotlin": code that compiles but does not use coroutines, extension functions, sealed classes, or null safety properly. For greenfield Kotlin projects, hire developers who already write idiomatic Kotlin. For mixed Java/Kotlin codebases, experienced Java developers work well, especially if they have Kotlin side projects on GitHub showing real engagement with the language's idioms. Full interoperability between Java and Kotlin makes gradual migration practical, so a team can ramp without stopping work.

What is the difference between Android Kotlin and backend Kotlin developers?

The language is the same, but the ecosystems are different. Android Kotlin developers work with Jetpack Compose, Android SDK, Activity/Fragment lifecycles, and mobile-specific constraints like battery and memory. Backend Kotlin developers work with Spring Boot or Ktor, coroutines for server concurrency, database access via Exposed or jOOQ, and deployment to JVM servers or containers. An Android developer can learn backend Kotlin, but they need to learn server-side frameworks, concurrency patterns, and infrastructure concerns. When sourcing, check GitHub repositories for server-side frameworks (Ktor, Spring) rather than Android SDK usage to distinguish backend from mobile developers.

What Kotlin projects and frameworks should I look for on GitHub?

For the language itself: JetBrains/kotlin (52,515 stars). For HTTP clients and networking: square/okhttp (46,922 stars). For server-side frameworks: ktorio/ktor (14,333 stars). For concurrency: Kotlin/kotlinx.coroutines (13,717 stars). For database access: JetBrains/Exposed (9,197 stars). For lightweight web frameworks: javalin/javalin (8,226 stars). For GraphQL: Netflix/dgs-framework. For build tools: gradle/gradle (Kotlin DSL). These repositories power production Kotlin systems, so their contributors tend to be strong candidates. Also look for contributions to Spring Boot with Kotlin, as 27% of Spring developers now use Kotlin.

How long does it take to hire a backend Kotlin developer?

Typical time-to-fill for backend Kotlin roles ranges from 30 to 60 days, faster than niche languages like Elixir or Rust but slower than general Java hiring. The main challenge is filtering: most Kotlin developers are Android-focused, so sourcing for backend expertise requires deliberate filtering on server-side frameworks and coroutine patterns. Including experienced Java developers with Kotlin interest can shorten the timeline, given the 126,574 Java developers in the US alone and full interoperability between the two languages. GitHub contribution data is useful here because it lets you identify backend Kotlin developers based on what they actually build.