Building Signposts for C# Engineers Racing to Kotlin

A while back, leadership came to me with an unusual staffing proposal. They had a pool of experienced C# developers they wanted to place, and I had open Kotlin positions that required deeper experience than flashy UI and a server API — the kind of skillset that’s genuinely hard to find on the open market. Could we bring these developers up to speed on Kotlin and fold them into the mobile team?

The developers already knew the company. In this organization, most teams didn’t have any real trouble pulling in a developer from outside their vertical. They would need to learn new tooling, maybe a few new libraries, but not a new programming language and hardware stack. But Kotlin is not C#. We needed to bridge that gap efficiently to solve our staffing problem.


Lost in Too Much Familiar Territory

The easy answer? Tell these developers to go read a book, watch YouTube tutorials, or enroll in a Kotlin bootcamp. But the problem becomes obvious pretty quickly.

Most Kotlin learning material is written for a general audience. It starts at the beginning. Data types. Variable declarations. How to return a value. All perfectly reasonable if your reader has never programmed before. But a developer with years of C# experience doesn’t need that level of pedantry. They start skimming, and skipping, and somewhere around page 127, buried in a chapter they half-read, is the explanation of scope functions that would have saved them three hours of confusion next Tuesday.

And self-study has its own trap. Sure, they’ll eventually need to stop writing endless else if chains — but who’s going to tell them to look up when? Who will they trust to explain the difference between let, apply, also, and run? It’s not always obvious where to start, or even that there’s something worth looking for.

We needed something that would show them all the tripping hazards and shortcuts, not teach them how to walk all over again.


Planting the Signposts

Once we identified the current skillset of our audience, we could target the training to their experience level. The skill gap for an experienced C# developer learning Kotlin isn’t the basics. It’s the subtle differences and valuable tools that Kotlin uses to make a developer’s life easier.

I started with a one-page summary of data types — not the ints and Strings they knew by heart, but the core concept of mutability (consider a var List vs a val MutableList) and nullability (why the perfectly obvious !! can cause your app to crash). Once that was established, we could move on to the things that have no real C# equivalent: scope functions, when expressions, data classes, sealed classes. Each one got its own focused one-pager rather than a footnote buried in a chapter about something else.

I wrote a whole series of focused one-pagers, each covering one concept, each with exercises. I wanted our incoming developers, who already understood the basics of programming, to work through the whole thing in about a week. They would come out with a mental map of how Kotlin thinks, and enough confidence to navigate the unfamiliar territory on their own.


Learning to Run

Our first volunteer had spent years working in a low-level language and was genuinely excited to be working in something higher-level again. He went through the entire guide in a single day. Then he started building small apps to prove to himself — and to me — that he’d understood the principles well enough to keep going independently. The guide showed him the terrain. He did the running himself.

It’s easy to assume that training needs to be thorough — start from the beginning and walk forward methodically so nothing gets missed. But experienced developers don’t need a comprehensive guide to get themselves started. They need a few pages of guidance on what’s different, signposts for where to take the next steps, and trust that they can take it from there.

There are plenty of Kotlin textbooks out there if you really want one. But you might save yourself some time by minding the gap.