7 Steps to Hire an Android Kotlin Developer in Singapore, the Screening Order I Had Backwards for a Year

We hired an Android engineer who interviewed beautifully. Clean Kotlin, sensible architecture opinions, a thoughtful answer on coroutines. Six weeks in, a Play Console policy change landed and we discovered that nobody on the team, including the new hire, had ever managed a staged rollout or reverted a bad release. The interview had tested the language. The job was about shipping.

Why Android hiring goes wrong in a specific way

Backend hiring processes have converged on something reasonable over the last decade. Android hiring, in most companies I see, has not. It tends to test the same things a backend interview tests (language fluency, data structures, architectural vocabulary) and then discovers the actual failure modes in production.

Those failure modes are specific to the platform. You do not control the runtime. The operating system may kill your process, the user may be on a four-year-old device with 3GB of RAM, the manufacturer may have implemented aggressive background restrictions, and the store may change a policy that makes your current release non-compliant. None of that appears in a coding exercise about reversing a tree.

Singapore adds a second layer. The mobile talent pool here is deep but narrow: strong engineers, concentrated in a relatively small number of companies, most of whom are not actively looking. Combined with the pass and notice-period timelines, that makes the cost of a mis-hire higher than the market average, because the replacement search will not be quick.

Step 1: Decide native or cross-platform before opening the role

This is a scoping decision that people postpone into a hiring decision, and it is expensive to reverse. Answer it from constraints rather than preference.

Cross-platform is the reasonable default when your app is largely screens over an API, your team is small, and parity between iOS and Android matters more than platform-specific polish. Native Android is the better answer when you depend on background execution, tight hardware integration such as Bluetooth or camera pipelines, sophisticated offline behaviour, or performance you need to control precisely.

The pattern that costs the most is choosing cross-platform for delivery speed and then hiring a native specialist eighteen months later to fix everything the abstraction could not reach, at which point you are permanently maintaining both skill sets on a team that was too small for one. Write the decision down with its reasons, so the next person who questions it is arguing with a rationale rather than with a habit.

Step 2: Write the requisition around constraints, not frameworks

Most Android job descriptions are a list: Kotlin, Coroutines, Flow, Hilt, Compose, Room, Retrofit. Every competent candidate has used all of them, so the list discriminates on nothing and reads as though nobody thought about the role.

Replace it with your three hardest constraints. “The app must work for two hours with no connectivity and reconcile cleanly on reconnect.” “We support devices back to Android 9 because a third of our users are on them.” “Background sync has to survive aggressive OEM battery management.”

Strong engineers self-select on problems. A constraint-led description reliably produces fewer applications and a better shortlist, which is the trade you want in a market where screening time is your scarcest resource.

Step 3: Source where Android engineers are actually visible

Mobile engineers leave unusually good public evidence, and most sourcing ignores it. A shipped app is a portfolio you can install.

Look at the apps you admire in the local market and find who built them. Search open-source contributions to Android libraries your stack already depends on. Check who has spoken at regional Android and Kotlin community events. Then write to the artefact, not to the person: a message referencing a specific decision in something they built gets a reply rate that no template approaches.

This matters more here than in larger markets. The strongest Android engineers in Singapore are largely not on the open market, so your realistic pipeline is built from people who were not looking when you contacted them. Generic outreach fails against that population by design.

Step 4: Screen on the release cycle, not the language

This is the step I had in the wrong place, and moving it to the front changed our outcomes more than anything else on this list.

In the first conversation, ask how they ship:

• Walk me through your last release. Staged rollout? What percentage, and what were you watching?
• Tell me about a release you had to roll back. How did you find out, and how long did it take?
• How do you triage a crash cluster that only appears on one manufacturer’s devices?
• How did you choose your minimum SDK version, and who did that decision exclude?
• What is in your pre-release checklist that is not in the automated pipeline?

These questions are almost impossible to answer convincingly without having done the work, which makes them unusually resistant to interview preparation. They also surface the difference between an engineer who has contributed features to someone else’s app and one who has owned a release. Both are valuable; only one can be your first mobile hire.

Step 5: Use a work sample drawn from your own domain

Generic exercises produce generic signal. Take a problem your team actually solved in the last quarter, strip it to its core, and time-box it hard: ninety minutes to three hours, never a weekend.

Tell candidates explicitly what you are assessing (structure, state management, error handling, testing approach) and explicitly that feature completeness is not on the list. Then review it as a code review, with the candidate present, and ask what they would do with another day. The answer to that question is frequently more informative than the submission.

If the exercise needs to be longer than three hours, pay for it. Senior Android engineers in this market routinely have several processes running at once and decline unpaid multi-day work, which means an over-long take-home filters out your strongest candidates first, the precise opposite of its purpose.

Step 6: Interview for store policy and device fragmentation

Nobody interviews for this, and it causes more production incidents on mobile teams than architecture ever does.

Ask about a Play Store policy change they had to absorb: what it was, how much notice they had, what it cost. Ask how they handle permissions that have become more restrictive with successive platform versions. Ask what they do about a device family where their app misbehaves and they cannot reproduce it locally.

An engineer who has lived through a compliance deadline talks about it in concrete, slightly weary detail. One who has not will give you a general answer about following guidelines. The difference is audible within a minute, and it predicts a category of risk that no other part of your loop is testing.

Step 7: Plan the offer around pass and notice-period reality

The offer is not the finish line, and treating it as one is the most common planning error I see on Singapore mobile teams.

For a foreign hire, an Employment Pass application goes through the Ministry of Manpower, and under the Fair Consideration Framework most roles must be advertised on MyCareersFuture before an EP application is submitted. Build both the advertising requirement and the processing time into your plan rather than discovering them after a verbal acceptance.

For a local hire or an existing pass holder, the binding constraint is usually the notice period, commonly one to three months for mid and senior roles. A candidate who signs in September may well start in December.

Work backwards from the date you need code shipping. If that date is inside eight weeks and the role requires a new pass, the honest answer may be that you need contract or agency capacity for the gap and a permanent hire behind it. That is a better conversation to have in week one than in week nine.

What the process costs

Roughly a day of engineering time to build the constraint-led requisition and the domain work sample, both of which are reusable for every subsequent mobile hire. After that, about four hours of interviewer time per serious candidate. Against a mis-hire on a small mobile team, which typically costs a quarter of degraded release velocity plus the replacement search in a narrow market, it repays itself on the first bad hire it prevents.

If the underlying need is a full mobile capability rather than one engineer, the sequencing question comes before the hiring question. Our notes on building a fintech app in Singapore and on e-commerce platforms both start from the architecture, because the architecture determines whether you need one senior engineer or three mid-level ones. The same release-ownership screen travels well across markets, our Dubai mobile practice runs an almost identical first-stage conversation, for the same reason: shipping judgement is the part you cannot teach in a quarter.

Frequently asked questions