En entretien, un développeur Android Jetpack Compose doit montrer qu'il relie l'interface à un état. Il écrit des fonctions composables, remonte l'état vers un ViewModel qui expose un StateFlow, place les effets de bord dans LaunchedEffect ou DisposableEffect et construit la navigation avec Navigation Compose ou Navigation 3, désormais stable. La plupart des offres ajoutent Hilt, Room, Retrofit, les coroutines et un build Gradle découpé en modules.
Compose figure sur beaucoup de CV après un tutoriel ou un petit projet. L'expérience de production se voit sur d'autres sujets : un écran qui se recompose à chaque frappe, une LazyColumn qui saccade, un état perdu à la rotation ou après la mort du processus, des écrans XML qui cohabitent avec des composables. Une personne qui a compté des recompositions dans le Layout Inspector a en général dépassé le tutoriel.
La plateforme change aussi les attentes. Depuis le 31 août 2026, les mises à jour publiées sur Google Play doivent cibler Android 16 (API 36). L'affichage edge-to-edge n'a plus d'échappatoire, le retour prédictif est actif par défaut et les verrous d'orientation sont ignorés sur les écrans de 600 dp et plus. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.
Compose et la pile Jetpack autour d'un écran Android
Jetpack Compose
La boîte à outils d'interface déclarative d'Android. Chaque écran est une fonction Kotlin qui décrit l'interface pour un état donné, et Compose la réexécute quand cet état change : c'est la recomposition. Le compilateur Compose est livré avec Kotlin depuis la version 2.0 et active le strong skipping par défaut depuis Kotlin 2.0.20.
ViewModel, StateFlow et flux unidirectionnel
L'état de l'écran vit dans un ViewModel qui l'expose en StateFlow. Le composable le lit avec collectAsStateWithLifecycle et renvoie des événements. rememberSaveable et SavedStateHandle conservent ce qu'il faut après une rotation ou la mort du processus.
Listes lazy
LazyColumn, LazyRow et les grilles lazy ne composent que les éléments visibles. Des clés stables, un contentType par type de ligne et des éléments légers évitent les saccades. C'est souvent là que les problèmes de performance apparaissent en premier.
Navigation Compose et Navigation 3
Navigation Compose décrit un graphe de destinations, avec des routes typées depuis la version 2.8. Navigation 3, stable, laisse l'app gérer sa propre pile de retour, une simple liste affichée par NavDisplay. Les deux se rencontrent dans les offres, et les apps plus anciennes reposent sur Navigation Compose.
Material 3
Les composants Material Design pour Compose : thème, couleurs dynamiques, typographie, composants adaptatifs pour tablettes et pliables. Une équipe qui a son propre design system construit ses composants par-dessus ou à côté.
Hilt, Room, Retrofit et coroutines
Le socle habituel autour de l'interface : injection de dépendances avec Hilt, base locale Room, appels réseau avec Retrofit et OkHttp, coroutines et Flow pour l'asynchrone. Une partie des offres demande Koin ou Ktor à la place.
ComposeView et AndroidView
Les ponts entre les deux mondes. ComposeView place du Compose dans un écran XML ou un fragment, AndroidView fait l'inverse pour une vue existante comme une carte ou un lecteur vidéo. La migration avance écran par écran, en commençant souvent par les nouveaux.
Layout Inspector, Baseline Profiles et tests Compose
Le Layout Inspector d'Android Studio compte les recompositions. Les Baseline Profiles accélèrent le démarrage et le défilement, et Macrobenchmark mesure le gain. Les tests d'interface Compose passent par createComposeRule et l'arbre sémantique des composables.
Le poste change avec l'âge de l'app. Sur une app récente, tout est en Compose et l'entretien porte sur l'architecture, les performances et les tests. Sur une app plus ancienne, une partie reste en XML avec des fragments, View Binding ou Data Binding, et le travail consiste à migrer sans casser les versions publiées. Une app prévue pour tablette, pliable ou ChromeOS ajoute la mise en page adaptative. Compose Multiplatform étend Compose à iOS et au desktop, sans être exigé pour un poste Android. Indiquez dans l'offre la part de Compose dans le code, la version de Kotlin et la bibliothèque de navigation, car ces trois informations changent les questions à poser.
Les points techniques à noter sur un profil Compose
- Recomposition et stabilité
- Gestion d'état et state hoisting
- Effets de bord et cycle de vie
- Listes lazy et performances
- Navigation et architecture d'app
- Migration XML vers Compose
Questions d'entretien sur Compose et l'architecture Android
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un champ de recherche fait recomposer toute la liste de résultats à chaque lettre tapée. Comment le confirmez-vous, et que changez-vous ?
Une bonne réponseIl confirme avec les compteurs de recomposition du Layout Inspector. Puis il cherche un état lu trop haut dans l'arbre (le texte du champ lu par le parent de la liste), un paramètre instable comme une List classique ou une classe d'un autre module, ou une liste filtrée recalculée dans le corps du composable. Les corrections : lire l'état au plus près de l'endroit qui l'utilise, remember pour le calcul, derivedStateOf quand le résultat change moins souvent que l'entrée, des collections immuables. Il sait que le strong skipping, actif par défaut depuis Kotlin 2.0.20, compare les paramètres instables par identité.
Signal d'alerteTout envelopper dans remember sans mesurer, ou ne pas savoir expliquer ce qu'est une recomposition.
Question 2 · confirmé
Comment répartissez-vous un formulaire de trois champs entre les composables et le ViewModel ? Où vit l'état de chaque champ ?
Une bonne réponseDes composables sans état qui reçoivent une valeur et un callback (state hoisting), et un composable d'écran qui lit l'état du ViewModel, exposé en StateFlow et collecté avec collectAsStateWithLifecycle. La validation et ce qui doit survivre vont dans le ViewModel, avec SavedStateHandle pour la mort du processus. L'état purement visuel, comme une section dépliée, peut rester local avec rememberSaveable. Un profil à jour mentionne TextFieldState, utilisé par les nouveaux champs de texte.
Signal d'alerteUn mutableStateOf dans chaque petit composable, ou le ViewModel passé en paramètre jusqu'aux boutons.
Question 3 · confirmé
À l'ouverture d'un écran, il faut lancer un appel réseau et afficher un snackbar en cas d'erreur. Où placez-vous chaque morceau de code ?
Une bonne réponseLe chargement part du ViewModel, dans viewModelScope, au démarrage ou sur une action explicite, jamais dans le corps du composable qui peut s'exécuter de nombreuses fois. Le snackbar est un effet côté interface : un LaunchedEffect qui réagit à l'état d'erreur, puis prévient le ViewModel que le message a été montré. Il distingue LaunchedEffect (coroutine liée à une clé), DisposableEffect (nettoyage à la sortie de la composition) et rememberCoroutineScope (coroutine lancée depuis un clic).
Signal d'alerteUn appel réseau dans le corps du composable, ou un LaunchedEffect(Unit) qui relance le chargement à chaque retour sur l'écran sans que la personne le sache.
Question 4 · senior
Une LazyColumn de 2 000 éléments saccade au défilement, même en build release. Que regardez-vous ?
Une bonne réponseUne mesure sur un build release et un vrai téléphone, jamais en debug où Compose est bien plus lent. Puis des clés stables par élément (key) et un contentType par type de ligne, des éléments légers sans formatage ni calcul dans leur corps, des images chargées à la taille affichée, aucune liste lazy imbriquée dans un parent qui défile dans le même sens. Un Baseline Profile et un test Macrobenchmark sur le défilement pour suivre les images lentes d'une version à l'autre.
Signal d'alerteDes mesures en debug, ou une Column avec verticalScroll qui compose les 2 000 éléments d'un coup.
Question 5 · confirmé
Comment introduisez-vous Compose dans une app en XML, avec fragments et View Binding, sans geler les livraisons ?
Une bonne réponseÉcran par écran ou composant par composant : un ComposeView dans un fragment existant, avec une ViewCompositionStrategy adaptée au cycle de vie de la vue du fragment, et AndroidView pour réutiliser une vue existante dans un écran Compose. Un thème Compose aligné sur le thème XML pour ne pas avoir deux apparences, les nouveaux écrans directement en Compose, des tests d'interface sur les écrans migrés. La navigation existante reste en place au début.
Signal d'alerteUne réécriture complète avant toute nouvelle version, ou deux thèmes qui divergent d'un écran à l'autre.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Avant de publier une offre Android orientée Compose
Que vaut une expérience XML sur un poste Compose ?
Beaucoup. Le cycle de vie Android, les coroutines, Room, Hilt et la publication restent les mêmes, et une app existante contient presque toujours des écrans XML à maintenir. La différence tient à la façon de penser l'interface à partir d'un état. Un profil XML qui a déjà écrit quelques écrans Compose en production et sait expliquer une recomposition peut tenir le poste. Sans aucune pratique de Compose, prévoyez une période de montée en compétence.
Navigation 3 doit-elle figurer dans l'offre ?
Seulement si votre app l'utilise ou si la migration est décidée. Les apps plus anciennes tournent sur Navigation Compose, et un développeur qui la maîtrise comprend vite Navigation 3, dont l'idée centrale est une pile de retour gérée par l'app. Exiger Navigation 3 réduit le vivier sans gain réel. En entretien, demander au candidat de comparer les deux suffit à voir s'il suit l'évolution de Jetpack.
Exercice à la maison ou en direct pour évaluer Compose ?
Un exercice court en direct apprend davantage. Donnez un écran Compose existant avec un défaut : une liste qui recompose trop, un état perdu à la rotation, un effet mal placé. La personne corrige en partageant son écran et explique ses choix. Si vous tenez à un test technique à la maison, limitez-le à deux ou trois heures et prévoyez un échange où le candidat justifie son code.
Compose Multiplatform change-t-il le profil recherché ?
Oui, s'il fait partie du poste. Compose Multiplatform reprend les mêmes API pour iOS et le desktop, mais ajoute Kotlin Multiplatform, la frontière avec Swift et les particularités d'iOS : cycle de vie, gestes, publication. Un excellent développeur Android Compose n'a pas forcément touché à iOS. Si l'app est uniquement Android, ne le demandez pas ; si elle partage son interface entre plateformes, ajoutez des questions sur iOS.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
