Entretien blanc Android Developer — pratique avec l'IA

Les entretiens Android sondent deux choses : votre aisance en Kotlin et combien vous avez réellement bataillé avec le lifecycle. Les candidats qui décrochent des offres connaissent la différence entre un configuration change et un process death, savent plaider pour ou contre Jetpack Compose avec des éléments concrets, et ne font pas semblant que la pile d'Activities est simple. Ce guide explique comment utiliser les entretiens blancs IA pour répéter le loop spécifique Android, calibré sur les rôles Kotlin-first en 2026.

Les tours d'entretien typiques pour les Android developers

Le loop Android compte 4 à 5 tours. Screening recruteur, un tour de fondamentaux Kotlin (data classes, sealed classes, scope functions, generics, bases des coroutines), un tour de coding pratique (construire une petite fonctionnalité en Compose ou en Views), un tour d'architecture (« concevez le cache offline de cette fonctionnalité »), et un tour behavioral. Les loops senior ajoutent un deep dive sur la plateforme Android (process lifecycle, limites du travail en background, distribution Play Store) et une revue d'architecture de projets passés.

Le tour d'architecture et le tour de fondamentaux Kotlin collent parfaitement au format de l'entretien blanc IA — ils reposent beaucoup sur la conversation. Le tour de coding profite d'une restitution verbale dans l'entretien blanc plus d'une vraie pratique sur Android Studio à côté. Les tours purement d'implémentation d'UI sont plus difficiles à simuler ; pour ceux-là, associez l'entretien blanc à un takehome sur un vrai appareil ou un émulateur.

Les principaux sujets techniques

Aisance en Kotlin

Le recruteur suppose Kotlin, pas Java. Soyez prêt : val vs var avec les bons défauts, data classes et quels equals/hashCode elles génèrent, sealed classes et when-expressions exhaustives pour modéliser un état, scope functions (let, run, apply, also, with) et quand utiliser laquelle, extension functions et leurs règles de dispatch, generics avec variance déclarative (in, out), inline et reified, le modèle de nullabilité de Kotlin et les platform types issus de l'interop Java. Un piège courant : expliquer pourquoi une NPE Java peut encore survenir dans une base de code Kotlin « safe ».

Coroutines et Flow

Incontournables. Soyez prêt : concurrence structurée (annulation parent-enfant), CoroutineScope vs CoroutineContext, la différence entre launch et async, supervisorScope vs coroutineScope, gestion d'exception (CoroutineExceptionHandler, try/catch autour d'await), Flow vs StateFlow vs SharedFlow, streams hot vs cold, backpressure avec les Channels et les opérateurs buffer/conflate. Une question favorite : « l'utilisateur navigue ailleurs en plein fetch — décrivez la bonne façon d'annuler et de nettoyer. » Les bonnes réponses enchaînent les lifecycle scopes (lifecycleScope, viewModelScope) et les garanties d'annulation.

Jetpack Compose

Compose a gagné pour les nouveaux projets mais Views est bien vivant dans 70 % des bases de code en production. Soyez prêt pour : le modèle de fonction @Composable et ce qui déclenche réellement une recomposition, le state hoisting et le flux de données unidirectionnel, remember vs rememberSaveable, LaunchedEffect vs DisposableEffect vs SideEffect, l'ordre des Modifier et pourquoi il importe, les listes paresseuses (clés de LazyColumn pour une identité stable), CompositionLocal pour les valeurs ambiantes, la navigation (Navigation Compose vs Navigation Component pour Views). Un énoncé de débogage courant : « la lazy list se recompose trop agressivement — trouvez pourquoi. »

Lifecycle, process et configuration changes

C'est la douleur typiquement Android. Soyez prêt : le lifecycle d'Activity (et pourquoi onSaveInstanceState existe), les Fragments et le double lifecycle, configuration changes vs process death (et pourquoi votre state en mémoire disparaît dans le second cas), le rôle du ViewModel et ce qu'il survit ou non, les composants lifecycle-aware, la différence entre ViewModels scopés à l'Activity et au Fragment. Un piège favori : « l'utilisateur fait pivoter l'appareil trois fois pendant un appel réseau — que doit-il se passer ? »

Architecture et modularisation

MVVM avec un pattern Repository est la réponse canonique ; la question est ce qui vient ensuite. Soyez prêt : MVI pour les fonctionnalités lourdes en machines à états, Clean Architecture pour séparer le domaine du framework, modularisation (feature modules vs layer modules, dynamic feature delivery), injection de dépendances avec Hilt ou Koin, à quoi ressemble une architecture « single activity, multiple fragments » et quand enfreindre cette règle. Soyez prêt à défendre un choix dans une vraie base de code.

Travail en background et contraintes de la plateforme

Les loops senior creusent : WorkManager (et les couches JobScheduler/AlarmManager en dessous), le mode Doze et App Standby, les changements des limites d'exécution en background depuis O, les foreground services et les notifications requises, les push notifications via Firebase Cloud Messaging, la distinction message data-only vs notification, et comment gérer un kill de process en plein sync. Connaître cela sépare un senior d'un mid.

Questions de scénario courantes

• « Concevez la synchronisation offline d'une app de notes. Room vs SQLite brut, résolution de conflits, planification WorkManager. »
• « Votre LazyColumn se recompose trop souvent. Déroulez-moi le diagnostic. » (Clés stables, état immuable, capture de lambda.)
• « L'app crashe sur Samsung mais pas sur Pixel. Comment enquêtez-vous ? » (Modifications OEM, permissions du manifest, killers de background propres aux constructeurs.)
• « Implémentez des téléchargements d'images parallèles avec une limite de concurrence en utilisant les coroutines. »
• « L'équipe veut migrer de Views vers Compose. Feuille de route ? » (ComposeView dans le XML, ViewModels partagés, déploiement par écran, tests de régression.)

Axes behavioral — ce que les recruteurs recherchent

Les recruteurs Android recherchent trois traits. D'abord, le réalisme OEM — le monde Android n'est pas un unique happy path en forme de Pixel. Les bons candidats ont livré sur Samsung, Xiaomi, Huawei et ont des histoires sur des bugs propres aux constructeurs. Ensuite, la discipline Play Store — vous avez géré un refus, un faux positif de Play Protect, une régression en staged-rollout. Enfin, la vigilance sur la taille de l'app et la batterie — les utilisateurs Android sont plus sensibles au prix que ceux d'iOS, et une app de 100 Mo ou un drain de 4 % de batterie en background vous coûte des installs. Attendez-vous à des énoncés qui touchent l'un de ces points.

Comment utiliser l'entraînement IA pour ce poste

Réglez le type d'entretien sur « Tech Screening » et choisissez Android comme plateforme. L'IA pondère les questions vers Kotlin, les coroutines, Compose et le lifecycle. Collez la fiche de poste quand vous en avez une — les rôles Jetpack Compose-only posent des questions très différentes des bases de code qui utilisent encore Views.

Pour la pratique d'architecture, lancez des sessions « System Design » avec des énoncés spécifiques Android : app offline-first avec synchronisation WorkManager, chat temps réel avec Firebase, flux de paiement avec authentification biométrique, architecture de service multi-process. L'IA poussera sur les pièges de lifecycle qui n'existent pas sur le web.

Un exercice qui paie : choisissez une fonctionnalité Compose que vous avez livrée et faites mener à l'IA un entretien sur la recomposition. « Qu'est-ce qui déclenche une recomposition ici ? Et si je change ce state ? Pourquoi cette capture de lambda cause-t-elle une recomposition ? » L'entretien blanc trouvera les lacunes de votre modèle mental de Compose, qui sont généralement exactement celles que trouvent les recruteurs.

Questions fréquentes