Embauchez des développeurs Android

Android, c’est là où se trouvent la plupart des utilisateurs de téléphones dans le monde, et là où la différence entre développeurs paraît vite. Des milliers de modèles d’appareils, une gestion agressive de la batterie et un processus de révision du Play Store avec ses propres règles font qu’une application qui roulait bien dans l’émulateur peut planter, vider les batteries ou se faire refuser une fois sur le terrain. Bien des gens peuvent construire un écran en Jetpack Compose. Beaucoup moins peuvent livrer une application qui reste rapide et stable sur les appareils que vos utilisateurs possèdent réellement. turnkey.dev sélectionne le deuxième groupe.

Ce qu’un développeur Android fait concrètement pour vous

Un bon développeur Android va :

• Construire l’application en Kotlin moderne : Jetpack Compose pour l’interface, coroutines et flows pour l’asynchrone, et une architecture que le prochain développeur peut reprendre sans visite guidée.
• Gérer les arêtes vives de la plateforme. La mort de processus, les changements de configuration, les limites d’exécution en arrière-plan et les flux de permissions, tout ce qui sépare une démo d’un produit.
• Réussir les données et le réseau : Room ou SQLDelight pour le stockage local, un comportement hors ligne sensé et des couches API qui échouent proprement sur les mauvaises connexions.
• Prendre en charge le pipeline de mise en production. Les fiches Play Store, les déploiements progressifs, la surveillance des plantages et les obstacles de révision et de politiques qui ralentissent les équipes qui le font pour la première fois.
• Brancher la plomberie de revenus et de rétention : des notifications poussées qui se rendent vraiment, Play Billing pour les abonnements et les achats, et des liens profonds qui mènent les utilisateurs là où ils s’attendent.
• Garder le tout rapide et utilisable pour tous. Le temps de démarrage, les saccades, la mémoire sur les appareils d’entrée de gamme et l’accessibilité, parce que la plupart des utilisateurs Android n’ont pas un téléphone haut de gamme.

Les parties difficiles du travail Android

Si les développeurs Android seniors coûtent ce qu’ils coûtent, c’est parce que l’essentiel de la difficulté est invisible dans une démo.

Le cycle de vie et la mort de processus. Android tue les applications en arrière-plan dès qu’il veut de la mémoire. L’application d’un développeur faible revient sur un écran vide ou un plantage; celle d’un bon développeur restaure son état si proprement que l’utilisateur ne remarque rien. La même discipline couvre la rotation, l’écran partagé et tous les autres changements de configuration. Les intervieweurs qui sautent ce sujet embauchent des gens qui l’apprendront dans votre application en production.

La fragmentation. Vos utilisateurs roulent des versions d’Android différentes, des surcouches de fabricants différentes, des formats d’écran différents et du matériel radicalement différent. Des fabricants comme Samsung et Xiaomi ajoutent leurs propres tueurs de batterie par-dessus les règles Doze et App Standby de la plateforme, ce qui casse silencieusement la synchronisation en arrière-plan et la livraison des notifications. Les développeurs expérimentés testent sur du vrai matériel d’entrée de gamme, surveillent les données terrain dans les signaux vitaux de la Play Console, et considèrent « ça marche sur un Pixel » comme le début des tests, pas la fin.

Le travail en arrière-plan. Téléversements, synchronisation, localisation, lecture de médias : tout ce qui roule pendant que l’application est fermée doit être négocié avec le système à travers WorkManager, les services au premier plan et les permissions d’alarmes exactes qui se resserrent à chaque version de l’OS. C’est là que les applications construites par des développeurs web qui font de l’Android à temps perdu ont tendance à s’effondrer.

Le Play Store lui-même. Les dates limites de SDK cible arrivent chaque année et les applications non conformes cessent de recevoir des mises à jour. Les déclarations de sécurité des données, les justifications de permissions et les revues de politiques peuvent bloquer une sortie pendant des jours. Quelqu’un dans votre équipe doit prendre en charge les déploiements progressifs, la santé des versions et les plans de retour en arrière. Un développeur Android senior a déjà fait tout ça, habituellement plus d’une fois.

La migration d’ancien code. Une grande part du vrai travail Android n’est pas du neuf. C’est une application de cinq ans en Java et en vues XML qui a besoin d’un chemin progressif vers Kotlin et Compose sans gel des fonctionnalités. Savoir faire cohabiter les deux systèmes d’interface et migrer écran par écran est une compétence en soi, et une compétence qui vaut la peine d’être sondée en entrevue.

Signaux de séniorité : distinguer une bonne recrue Android d’une faible

Des signaux à chercher, en entrevue ou dans un portfolio :

• Il parle de ce qui s’est passé après la sortie. Taux sans plantage, ANR, signaux vitaux, pourcentages de déploiement progressif, et un bogue qui n’apparaissait que sur les appareils d’un seul fabricant. Les développeurs qui n’ont construit que des applications jamais livrées ne peuvent pas simuler ça.
• Il explique la gestion d’état sous la mort de processus, pas seulement « j’utilise ViewModel ». Demandez ce qui survit à la mort de processus et ce qui n’y survit pas; la réponse trie les candidats rapidement.
• Il raisonne sur les fils d’exécution en termes de concurrence structurée : portées de coroutines, annulation, et ce qui arrive au travail en cours quand l’utilisateur quitte l’écran.
• Il a des opinions sur les frontières de modules et les temps de compilation, parce qu’il a vécu dans une base de code assez grosse pour que les deux fassent mal.
• Il lit les changements de politiques du Play Store comme les ingénieurs d’arrière-plan lisent les journaux de modifications, parce qu’une date limite de SDK cible manquée ou un formulaire de sécurité des données refusé est une panne d’affaires.

Signaux faibles : un portfolio d’applications en forme de tutoriel, des captures d’écran d’interface sans aucune discussion d’architecture, et toute affirmation que tester sur l’émulateur suffit.

Android natif ou multiplateforme : le compromis honnête

Nous plaçons aussi des développeurs React Native et Flutter, alors nous n’avons aucun intérêt à vous pousser d’un côté ou de l’autre.

Choisissez l’Android natif (Kotlin) quand Android est votre plateforme principale ou votre plateforme de revenus, quand l’application s’appuie sur la profondeur de la plateforme (traitement en arrière-plan, Bluetooth et autre matériel, pipelines caméra et médias, widgets, Wear OS), ou quand la performance sur les appareils d’entrée de gamme qui dominent bien des marchés décide si les utilisateurs restent. Le natif vieillit mieux aussi : vous n’attendez jamais qu’un cadriciel enveloppe une nouvelle API de la plateforme.

Choisissez le multiplateforme quand vous avez besoin d’iOS et d’Android avec une seule petite équipe, que l’application est surtout des écrans par-dessus une API, et que le temps avant d’arriver sur les deux magasins compte plus que de tirer le maximum de la plateforme. Flutter et React Native sont vraiment bons pour cette classe d’applications.

La réponse mixte est courante. Bien des équipes roulent une application multiplateforme avec des modules Kotlin natifs pour les parties difficiles, ou commencent en multiplateforme et passent au natif quand une plateforme porte clairement les affaires. Si vous pesez ce choix, mettez-le dans le formulaire de demande et nous en discuterons avant de jumeler qui que ce soit.

Quand embaucher un développeur Android

Les déclencheurs habituels : vous construisez une application Android native à partir de zéro, votre application existante a vieilli en Java et en vues d’ancienne génération et a besoin d’un chemin vers Kotlin et Compose, votre produit web ou iOS a besoin d’un pendant Android, ou les taux de plantage et les évaluations une étoile grimpent et personne dans l’équipe ne s’occupe de la plateforme. Si vous voulez un seul code pour les deux plateformes plutôt que la profondeur native, les pôles React Native et Flutter ci-dessous sont le meilleur point de départ.

Comment fonctionne la vérification turnkey.dev

Chaque développeur passe une évaluation des fondamentaux (Kotlin, le cycle de vie Android, la concurrence et l’architecture d’application), un exercice pratique bâti autour d’une fonctionnalité réaliste avec gestion d’état, navigation et gestion d’erreurs, et une revue des applications livrées, y compris l’échelle, l’historique de plantages et ce qu’il ferait autrement. Les applications publiées sont examinées, pas seulement mentionnées. Nous refusons beaucoup plus de candidats que nous en acceptons.

La séniorité, et à quoi sert chaque niveau

La plupart des entreprises qui viennent nous voir ont besoin d’un développeur senior capable de prendre l’application Android en charge au complet, avec un lead appelé brièvement pour les grandes décisions comme une migration vers Compose ou un choix entre réécriture et remaniement.

Les modèles d’engagement

• Temps plein. Un développeur, votre équipe, vos mêlées quotidiennes. Le choix par défaut pour une nouvelle construction, une réécriture majeure ou toute application qui livre chaque semaine. Comptez sur ce modèle pour au moins les premiers mois d’un projet neuf.
• Mandat à temps partiel. Un bloc hebdomadaire fixe, souvent 10 à 20 heures, pour une application stable qui a besoin de mises à jour d’OS, de hausses de SDK cible, de mises à niveau de dépendances et d’une cadence de livraison régulière. C’est la façon la plus économique de garder une application terminée en santé, et c’est là que bien des engagements à temps plein finissent par se poser une fois la grosse construction faite.
• Par projet. Un morceau de travail délimité avec une fin claire : une migration Compose, une intégration Play Billing, une passe de performance sur le démarrage et les saccades, ou faire passer la revue du Play Store à une application bloquée. Ça marche mieux quand le livrable tient dans un paragraphe.

Vous pouvez passer d’un modèle à l’autre au fil de la vie de l’application; la plupart des clients le font.

Combien ça coûte et à quelle vitesse

Les développeurs Android vérifiés facturent généralement entre 70 $ et 130 $ de l’heure. Traitez ça comme une fourchette de marché, pas comme un prix de menu : la position d’un développeur bouge avec la séniorité, la région et la portée du mandat. Les leads qui prennent en charge l’architecture et les mises en production sont dans le haut; les développeurs intermédiaires qui travaillent sous revue sont vers le bas; le même bagage se facture différemment selon le fuseau horaire. Même dans le haut de la fourchette, le total revient habituellement bien en dessous du coût total d’une embauche à temps plein une fois comptés le temps de recrutement, les avantages sociaux et l’équipement. Le tarif de chaque développeur est indiqué avant tout engagement, et demander une liste restreinte est gratuit. Comptez 2 à 5 jours pour recevoir une liste restreinte.

Commencez par une demande, pas par un contrat

Dites-nous ce que vous construisez, l’état du code actuel s’il y en a un, et votre échéancier. Nous revenons avec une courte liste de développeurs vérifiés qui correspondent, avec tarif et disponibilité. Vous passez les entrevues, faites un essai payé si vous le souhaitez, et décidez seulement ensuite. Si le jumelage ne convient pas dans les deux premières semaines, nous vous jumelons à quelqu’un d’autre sans frais.