How to assess · For hiring teams

How to Assess Kotlin / Android Skills When Hiring

The test formats that actually work for Kotlin / Android, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess Kotlin / Android with a task, not a conversation: fix a small broken app, build a screen from a spec, ai-scored assessment (e.g. cohesyve) or architecture conversation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

Designs for the lifecycle: state survives rotation and process death, and work is scoped to the right owner
Uses coroutines and flows with structured concurrency, correct dispatchers and cancellation
Keeps a single source of truth in a ViewModel or equivalent, and drives UI from it
Writes Kotlin idiomatically: null safety, sealed classes, data classes, extension functions with restraint

Build a Kotlin / Android assessment →Read the full article ↓

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

Android has a wider range of devices, OS versions and app lifecycles than any other mainstream platform, and that is what separates Android developers: not whether they can build a screen, but whether the screen survives rotation, backgrounding, low memory and a slow network on a five-year-old phone. Kotlin has made the language side easier; the platform side is as demanding as ever. This page covers how to assess Kotlin and Android for mobile roles: language fluency, lifecycle and state, coroutines, UI with Compose or Views, and the practical experience of shipping to Play.

Why Kotlin / Android is worth testing

Android defects are lifecycle defects. A crash on rotation, a leaked activity, a coroutine that outlives its screen, a list that jumps on update — each comes from misunderstanding how the platform manages components. Strong developers design for the lifecycle from the start; weak ones patch it after each crash report. Testing shows which you are hiring, and it matters because the fixes are expensive once the architecture is wrong.

What strong Kotlin / Android looks like

Designs for the lifecycle: state survives rotation and process death, and work is scoped to the right owner
Uses coroutines and flows with structured concurrency, correct dispatchers and cancellation
Keeps a single source of truth in a ViewModel or equivalent, and drives UI from it
Writes Kotlin idiomatically: null safety, sealed classes, data classes, extension functions with restraint
Builds UI — Compose or Views — that handles configuration changes, accessibility and different screen sizes
Manages memory: no leaked contexts, no listeners outliving their owner
Has shipped: understands Play requirements, app bundles, permissions and crash reporting

Ways to assess Kotlin / Android

Fix a small broken app

Provide a project with state lost on rotation, a coroutine launched in the wrong scope, and a leaked activity reference. Ask the candidate to find, fix and explain each.

Pros

The three most common real Android defects; concrete and scoreable.

Cons

Needs a project in the UI framework the role uses.

Best for Mid and senior Android roles.

Build a screen from a spec

Ask for a list-and-detail screen loading from an API with loading, error and empty states, surviving rotation, in a capped take-home.

Pros

Shows architecture, coroutines and UI quality together.

Cons

Take-home verification; walk through it.

Best for Any level; scale via the spec.

AI-scored assessment (e.g. Cohesyve)

Generate an Android task from the job description — a lifecycle scenario, a coroutine review, a state design — with a rubric. Each candidate receives a different variant; reasoning is scored with the code.

Pros

Asynchronous and consistent; unique per candidate; the reasoning about lifecycle and scope is what scores.

Cons

Cannot build or run; have finalists demo theirs.

Best for Screening before pairing.

Architecture conversation

Describe a feature with background sync and offline reads, and ask how they would structure it across layers.

Pros

Reveals data-flow and lifecycle thinking quickly.

Cons

Talk-based; verify hands-on.

Best for Senior and lead mobile engineers.

Cohesyve

Run a Kotlin / Android assessment on your next opening

Cohesyve generates a unique Kotlin / Android task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

Try it free →Book a 30-min demo

What to test

Lifecycle and state

Whether the app survives what the platform does to it.

Preserve state across rotation and process deathScope a network call so it is cancelled when the screen goes awayExplain what happens to a running coroutine when the user backgrounds the app

Coroutines and flows

Whether async work is structured and safe.

Choose the dispatcher for a given task and explain whyConvert a callback API to a suspend functionCollect a flow safely from the UI

Kotlin and architecture

Whether the code is idiomatic and has a shape.

Model screen state with a sealed classSeparate a repository from the ViewModelExplain when an extension function helps and when it hides things

UI and shipping

Whether the app is complete on real devices.

Handle a configuration change in Compose or ViewsSupport TalkBack on a screenExplain the release path and a common Play rejection

Sample Kotlin / Android questions

What happens to an Activity on rotation, and how do you keep the user's data?

Entry

Look for Recreated; ViewModel survives configuration change; SavedStateHandle for process death.

Which dispatcher would you use for a network call, and why not the main dispatcher?

Entry

Look for IO for blocking work; main is for UI; the library may already switch, and how to check.

A coroutine launched in a ViewModel keeps running after the screen is closed. Is that a problem?

Mid

Look for Depends on the scope; viewModelScope cancels on clear; a global scope leaks; discusses what the coroutine holds.

Model the state of a screen that loads a list and can be empty, loading, error or loaded.

Mid

Look for Sealed class or interface; single StateFlow; UI derives from it.

Design offline-first reads with background sync for a messaging feature.

Senior

Look for Local database as source of truth, WorkManager or similar for sync, conflict handling, what the UI shows while offline.

Red flags

State lives in the Activity and is lost on rotation
Launches coroutines in GlobalScope
Holds a context or view in a long-lived object
Cannot explain process death
Has not shipped to Play

Scoring rubric

Criterion	Weight	What strong looks like
Lifecycle and state	30%	State survives the platform; work is scoped correctly.
Coroutines	20%	Structured, cancellable, on the right dispatcher.
Kotlin and architecture	20%	Idiomatic; layers are separated; one source of truth.
UI quality	20%	Handles configuration changes, accessibility and sizes.
Shipping experience	10%	Knows Play requirements and the release path.

Mistakes hiring teams make

Testing Compose or Views trivia when the app uses the other
Not planting a lifecycle bug — it is the defining Android defect
Accepting a screen that loses state on rotation
Ignoring accessibility and device range
Hiring on Play credits without the fundamentals

Roles that need Kotlin / Android

Android DeveloperKotlin DeveloperMobile EngineerSenior Android EngineerMobile LeadAndroid Platform Engineer

Common questions

Should I test Compose or Views?

The framework your app uses, primarily. Lifecycle, coroutines and state transfer between them; the UI APIs do not. Test fundamentals first.

What is the best single Android screening question?

Ask what happens to a screen's state on rotation and how they keep it. The answer reveals whether they understand the lifecycle, which is most of Android.

Does Java Android experience transfer to Kotlin?

The platform knowledge transfers fully. Kotlin idioms, coroutines and null safety need to be tested, since Java-style Kotlin misses most of what the language offers.

How long should an Android assessment take?

Forty-five to sixty minutes for a fix-the-bugs exercise; two to three hours capped for a screen from a spec.

Cohesyve · Skill assessments for hiring

Test Kotlin / Android before the first interview

Generate a role-specific Kotlin / Android assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

From the blog

Related skill guides