L4 / IC3 · 3 à 5 ans
Préparation entretien Android Engineer, ce qui vous attend
Si vous préparez un process Android Engineer, la trame est reconnaissable dans la plupart des boîtes tech : un pré-screen recruteur, un round de coding Kotlin, un round de system design à la sauce mobile, souvent un deep-dive sur un projet de votre CV, et un comportemental avec le hiring manager. La barre, c'est l'aisance en Kotlin, le confort avec le cycle de vie Android (y compris la mort du process et les changements de configuration), et la capacité à raisonner sur le travail en background sans vous réfugier derrière un « de toute façon WorkManager s'en occupe ».
Le point clé à comprendre : on évalue si vous écrivez du Kotlin comme un ingénieur Android de production (coroutines, scopes liés au cycle de vie, gestion d'état Compose, survie à la mort du process), pas seulement la justesse algorithmique. Ce guide reflète la barre Android large, des équipes mobiles des grands produits français comme des filiales tech américaines. Le candidat L4 / IC3 est calibré sur le fait de porter une feature ou un écran de bout en bout : design, implémentation, A/B test, rollout progressif sur le Play Store.
Version personnalisée
Ce guide couvre la barre générale pour Android Engineer. L'extension Chrome applique la même préparation à chaque offre que vous ouvrez, questions prédites pour cette entreprise précise, entraînement vocal avec votre coach IA sur chaque réponse, benchmark de salaire, analyse des écarts, plus brouillons de lettre de motivation et d'auto-présentation. Premier rapport gratuit ; plans payants à partir de 3,99 $. Ou lancez un scan unique sur une offre, sans installer.
Mise à jour 2026
Ce guide couvre la barre générale pour Android Engineer. Quelques choses ont changé en France en 2026, l'AI Act encadre le recrutement IA à partir du 2 août, 31 % des candidats utilisent déjà l'IA pour préparer (APEC), les mises en situation remplacent les tests classiques, et le cycle de recrutement reste à 12 semaines. Lire ce qui a changé en 2026 →
Ce qui sera attendu de vous
- Porter une feature ou un écran de bout en bout : spec, implémentation, A/B test, rollout progressif sur le Play Store
- Écrire du Kotlin de production : coroutines, Flow, concurrence structurée, composants conscients du cycle de vie
- Construire l'UI en Jetpack Compose (ou maintenir le code Views si l'équipe est en pleine migration) ; raisonner sur la recomposition
- Cadrer les contrats d'API avec le back-end ; gérer explicitement les chemins offline, la mort du process et les changements de configuration
- Participer à l'astreinte sur l'app ; débugger les ANR, les crashs et les régressions de perf en production
- Optimiser la taille de l'app, le temps de démarrage à froid et la batterie ; produire les baseline profiles quand c'est utile
Process d'entretien typique
La plupart des entreprises suivent une trame similaire pour les entretiens Android Engineer. Délai calendaire total : 3 à 5 semaines du pré-screen recruteur jusqu'à l'offre.
Questions types à anticiper
Représentatives de ce que les entreprises demandent à ce niveau, pas une liste exhaustive. Lancez le scan gratuit ci-dessus pour des questions prédites liées à une offre d'emploi précise. L'extension Chrome ajoute l'entraînement vocal avec coaching IA sur chaque réponse (technique, design système, comportemental, motivation).
- “Implémentez une classe qui télécharge des images depuis une liste d'URLs en concurrence, les met en cache par URL, et ne dépasse jamais 4 téléchargements simultanés. Utilisez les coroutines et la concurrence structurée.”
- “Déroulez ce qui arrive à un ViewModel pendant la mort du process. Comment survivriez-vous à une requête réseau en cours déclenchée par une saisie utilisateur ? Détaillez le rôle de SavedStateHandle.”
- “Expliquez la différence entre viewModelScope, lifecycleScope et un scope que vous créeriez vous-même. Vous lancez une coroutine qui met à jour l'UI depuis un callback réseau, lequel choisissez-vous et pourquoi, et qu'est-ce qui s'annule quand l'écran disparaît ?”
- “Vous avez une liste Compose qui se recompose trop souvent pendant le scroll. Déroulez comment vous diagnostiquez ça : quels outils, qu'est-ce que vous regardez en premier, et que faites-vous de la stabilité des paramètres et des clés de liste ?”
- “Comment gérez-vous l'état dans Compose ? Différenciez remember, rememberSaveable et l'état hissé dans le ViewModel, et dites lequel survit à un changement de configuration, lequel survit à la mort du process, et lequel ne survit à rien.”
- “Une app Android voit sa mémoire grimper régulièrement pendant un scroll, sans crasher, juste en montant. Comment déterminez-vous si c'est une fuite (une Activity retenue, un context capturé) ou une croissance de cache ? Quels outils, dans quel ordre ?”
- “Designez une app de to-do offline-first qui se synchronise au back-end quand l'appareil revient en ligne. Couvrez la résolution de conflits, le schéma Room, et ce qui se passe si une sync est interrompue par la mort du process.”
- “Designez une librairie de chargement d'images type Coil ou Glide. Couvrez cache mémoire vs disque (Room ou DiskLruCache), l'annulation liée au cycle de vie du Composable, et la gestion d'une image de 10 Mo qui arrive sur un item de LazyColumn.”
- “Designez le feed d'images d'une app sociale (style le feed Vinted ou Leboncoin) : préchargement, recyclage / réutilisation des items, décodage hors main thread, et pagination quand on scrolle vite.”
- “Designez un handler de notifications push qui doit mettre à jour des données locales et afficher une UI personnalisée avant que l'utilisateur n'ouvre l'app. Couvrez le mode Doze, les règles de foreground service, et le chemin du data push silencieux.”
- “Parlez-moi d'une feature que vous avez shipée et qui a cassé en production. Comment l'avez-vous découvert, et qu'avez-vous changé dans les pratiques de l'équipe ?”
- “Racontez une fois où vous avez tenu tête à un designer ou un PM sur une feature que vous pensiez infaisable proprement sur Android (contraintes mémoire, cycle de vie, fragmentation des appareils).”
- “Décrivez une optimisation de démarrage d'app ou de mémoire que vous avez faite. Quelle métrique, et qu'avez-vous mesuré pour prouver que ça marchait ?”
Benchmark de salaire
Salaire médian pour Android Engineer dans les grandes boîtes tech US, chiffres principaux en USD. Paris / Berlin / Singapour paient typiquement 30 à 50 % de moins en base ; les ratios d'equity varient selon le stade de l'entreprise.
Pour repère, un Android L4 en FAANG tourne autour de 260–340 k$ de TC au 50e percentile, et suit la grille L4 SWE chez Google / Meta / Stripe / Snap. À Paris, un Android Engineer mid se situe plutôt autour de 50–70 k€ de base selon l'employeur (scale-up produit, grand compte, ou filiale tech américaine). Google paie la même bande au niveau L4 Android ; chez Meta, un E4 Android équivaut à un E4 back-end.
Comment se préparer, cinq conseils tactiques
Ouvrez vos réponses comportementales avec la méthode STAR, Situation, Tâche, Action, Résultat. Les conseils tactiques ci-dessous s'appuient sur cette structure pour ce rôle précis.
- Drillez Kotlin à froid : coroutines, Flow, concurrence structurée, generics, sealed classes, data classes. Le round de coding suppose une aisance que la pratique en take-home ne peut pas simuler
- Maîtrisez Jetpack Compose en profondeur : état, recomposition, side-effects, navigation. Si l'équipe est encore sur Views, connaissez ce cycle de vie aussi (LiveData, fragments, transactions)
- Préparez-vous à dérouler une feature que vous avez shipée : choix liés au cycle de vie, gestion de la mort du process, travail de perf. Le deep-dive attend du concret
- Regardez les épisodes Now in Android de la dernière année pour ce qui est d'actualité : Compose a beaucoup bougé sur les releases récentes
- Entraînez-vous sur 2 ou 3 system designs mobiles à froid : offline-first avec Room, cache d'images, handler de push avec travail en background. Vous pattern-matcherez le reste
- Ne négligez pas le round d'algos : même léger, c'est lui qui élimine les profils mobiles qui n'ont jamais fait de LeetCode. Comptez 40 à 60 mediums sur tableaux, strings, hashmaps
Les pièges fréquents au niveau Android Engineer
Quelques erreurs fréquentes qui font recaler les candidats Android Engineer même quand ils sont par ailleurs solides. Mieux vaut les repérer en mock interview avant qu'elles n'apparaissent en vrai.
Résoudre le problème de coding de façon optimale mais ignorer les parties spécifiques à Android : aucune conscience du cycle de vie, aucune réflexion sur la mort du process, aucune mention de l'endroit où se place la frontière du ViewModel.
Pourquoi ça rate
Au L4 la barre n'est pas « savez-vous coder ». C'est « écrivez-vous du Kotlin comme quelqu'un qui a shipé en prod ». Une solution juste qui ne pense pas aux changements de configuration, ou qui retient une référence de context dans un objet à longue durée de vie, donne l'image d'un « ingénieur générique qui a appris Kotlin récemment ». L'intervieweur attend le commentaire sur la couche Android, pas l'algorithme.
Comment rattraper
Après chaque solution, narrez la couche Android à voix haute : où ça vit à travers le cycle de vie, ce qui se passe pendant la mort du process et un changement de configuration, si le type devrait retenir un context (et si oui, application ou activity), et où vous prendriez un scope de coroutine, lié à quel propriétaire de cycle de vie.
Designer une feature Android comme si c'était une feature web : connectivité parfaite, pas de mort du process, l'app toujours au premier plan.
Pourquoi ça rate
Le system design mobile n'a pas les mêmes contraintes que le back-end. L'offline, le réseau capricieux, la mort du process, le mode Doze, les règles de travail en background : rien de tout ça n'est optionnel. Un design qui les ignore donne l'image de « quelqu'un qui pense back-end et qui écrit du Kotlin par accident ». L'intervieweur attend la question de clarification sur le cycle de vie, pas que vous fonciez sur un design serveur-d'abord.
Comment rattraper
Dans les cinq premières minutes de tout system design Android, posez les questions de cycle de vie : que se passe-t-il pendant la mort du process, qu'est-ce qui tourne en background, quelle est la règle pour le mode Doze, quelles données survivent à un changement de configuration. Ensuite construisez le design autour des réponses.
Décrire son travail Android passé en termes de features construites : pas de DAU, pas de taux sans-crash, pas de récit de rollout Play Store, pas de chiffres d'ANR.
Pourquoi ça rate
Les intervieweurs Android calibrent contre l'expérience de mise en prod. « J'ai construit le nouveau feed » ne leur dit rien. « J'ai construit le feed utilisé par 1,2 M de DAU, fait passer le taux scroll-vers-engagement de 41 % à 48 % via les correctifs de recomposition Compose, et le rollout progressif sur le Play a remonté un ANR au démarrage sur Android 11 qu'on a patché en deux jours » leur permet de vous situer. Les chiffres de prod séparent les candidats L4 des L3 plus encore que la profondeur technique.
Comment rattraper
Pour vos 3 ou 4 meilleures histoires, attachez trois chiffres chacune : échelle (DAU ou installs), impact (la métrique qui a bougé), et un détail opérationnel (taux sans-crash, taux d'ANR, rollout Play Store). Des chiffres approximatifs valent mieux que pas de chiffres.
Ressources recommandées
Livres, cours et outils qui reviennent le plus dans la préparation Android Engineer. Sans lien d'affiliation.
- 01Android Developers, doc officielle →La référence canonique. Relisez les sections Lifecycle, Background Work et l'état Compose avant tout loop chargé en Android.
- 02Kotlin Coroutines (guide officiel) →Le guide canonique sur les coroutines, les scopes et Flow. Les questions sur la concurrence structurée tombent à chaque round de coding récent.
- 03Jetpack Compose (doc officielle) →La doc de référence sur l'état, la recomposition et les side-effects. À relire avant tout round qui touche à l'UI Compose.
- 04Now in Android (app d'exemple Google) →L'app de référence de Google qui montre les bonnes pratiques actuelles. Lisez les décisions d'architecture dans le README, elles reflètent ce sur quoi les équipes des grands produits convergent.
- 05Android Interview Questions (GitHub) →Repo communautaire de questions d'entretien Android classées par thème. À parcourir pour pattern-matcher les questions Kotlin et cycle de vie qui tombent vraiment.
Scénarios courants
Je suis dev Android en agence / ESN (ou en freelance) depuis 4 ans, j'ai livré une dizaine d'apps clients. Comment je transitionne vers une boîte produit française (Doctolib, BlaBlaCar, Leboncoin, Back Market) où le code reste plusieurs années ?
Le piège du parcours agence / ESN, c'est que vous avez livré beaucoup d'apps mais jamais vécu une seule sur la durée : pas de taux sans-crash suivi sur 12 mois, pas d'A/B test, pas de dette technique que vous avez dû payer vous-même. Les boîtes produit recrutent exactement pour ça. Avant le loop, ressortez 2 ou 3 apps et ré-écrivez-les côté décisions et pas côté livrables : « j'ai choisi telle archi pour telle raison, voici le cas limite qui m'a mordu, voici ce que je referais ». Sur le coding round, votre Kotlin sera probablement solide mais centré sur la livraison rapide ; le system design mobile est le vrai écart, drillez sync offline-first avec Room, cache d'images et handler de push à froid. Attention au round d'algos : en agence on fait rarement du LeetCode, comptez 40 à 60 mediums minimum. Et ne sous-vendez pas l'expé clients (livrer sous contrainte de délai, jongler les specs qui changent) ; reformatez-la en « livré sous contrainte » plutôt qu'en prestation.
Je code en Java + Views depuis des années et je n'ai presque pas touché Kotlin ni Compose. Les offres parlent toutes de Kotlin et Compose maintenant. Est-ce que je dois tout réapprendre avant de passer des entretiens chez Lydia, Qonto ou Sorare ?
Non, et c'est une erreur fréquente de croire qu'il faut être 100 % Kotlin + Compose avant de candidater. La réalité des grosses apps françaises (Doctolib, Leboncoin, BlaBlaCar) c'est un codebase mixte : du Java + Views historique sur les écrans critiques, du Kotlin + Compose sur les nouvelles features, et beaucoup d'interop entre les deux (Compose dans une Activity Views, ComposeView, interopérabilité Kotlin / Java). Les intervieweurs le savent. Ce qu'ils testent, ce n'est pas « connaissez-vous tout Compose », c'est « comprenez-vous le modèle déclaratif et savez-vous quand l'un bat l'autre ». Préparez-vous à expliquer la différence de cycle de vie (onCreate / findViewById vs état hissé et recomposition), à parler de la gestion d'état en Compose (remember, rememberSaveable, état dans le ViewModel), et à dire honnêtement où vous mettriez encore des Views (perf sur des listes très lourdes, vues custom existantes). Mais Kotlin n'est pas optionnel : c'est lui qu'on attend au coding round, donc drillez les coroutines, Flow et les sealed classes en priorité. Construisez une petite app Compose avec un appel réseau et un peu d'état partagé sur 2 ou 3 week-ends, ça suffit pour le niveau de la discussion. Le piège, c'est de bluffer une maîtrise Compose que vous n'avez pas, l'intervieweur le voit en deux questions.
Je suis dev iOS (ou cross-platform Flutter / React Native) et je veux passer sur du natif Android. Comment je prépare un loop Android quand mon Kotlin est encore frais ?
L'avantage : vous comprenez déjà les contraintes mobiles (cycle de vie, offline, perf de liste, mémoire), et ça, c'est la moitié de la barre Android. L'écart, c'est l'idiome Kotlin et l'écosystème Android. Sur le coding round, ne vous contentez pas d'un Kotlin « qui marche » : drillez les coroutines et la concurrence structurée, les scopes liés au cycle de vie (viewModelScope, lifecycleScope), et la gestion d'état Compose, parce que c'est précisément là qu'un profil venu d'iOS se fait repérer (on écrit du Kotlin comme du Swift). Côté system design, votre intuition iOS sur la sync offline et le cache se transpose presque directement, apprenez juste les noms Android (Room vs Core Data, WorkManager vs background tasks, le data push silencieux, la mort du process et SavedStateHandle). Pour Flutter / React Native, l'écart est plus grand : vous avez probablement délégué le natif au framework, donc le cycle de vie Android, la mort du process et la mémoire sont à reconstruire. Comptez 6 à 8 semaines : Kotlin à fond, une vraie app native sans framework cross-platform, et la dernière année de Now in Android. En behavioral, assumez la transition franchement, les boîtes produit voient d'un bon œil quelqu'un qui choisit le natif en connaissance de cause.
Je suis dev Android autodidacte, très à l'aise pour construire des apps complètes, mais le round d'algos me terrifie. À quel point c'est éliminatoire dans un loop Android en France ?
C'est moins lourd que pour un poste back-end, mais ce n'est pas décoratif : le round d'algos est précisément l'endroit où les profils mobiles autodidactes ou venus de l'agence se font sortir. La plupart des loops Android gardent un seul round d'algos (souvent un medium en 40 minutes) plutôt que deux ou trois comme pour un SWE. Les filiales tech américaines à Paris et les scale-ups exigeantes (Qonto, Sorare, Back Market) maintiennent une vraie barre dessus ; certaines boîtes plus petites le remplacent par un exercice plus appliqué. Le plan : 40 à 60 LeetCode mediums sur tableaux, strings, hashmaps et arbres, pas besoin d'aller jusqu'aux graphes avancés ou à la programmation dynamique pointue. Entraînez-vous à parler de votre approche avant de coder et à donner la complexité, parce que sur un round Android l'intervieweur pardonne plus volontiers une solution non optimale si le raisonnement est propre. Ne sacrifiez pas pour autant la prep Kotlin et system design : l'algo vous fait passer le filtre, mais c'est la couche Android (coroutines, cycle de vie, état Compose, mort du process) qui décide du niveau et de l'offre.
Questions fréquentes
Ce guide est-il utile si je suis dev back-end / web et que je passe sur Android ?
Oui, la barre L4 / IC3 décrite ici s'applique que vous veniez du web, du back-end, ou directement de l'Android. Les transitions SWE-vers-Android ont en général la base algorithmique mais doivent driller les patterns spécifiques Android (cycle de vie, mort du process, scopes de coroutines, recomposition Compose). Le plus gros écart, c'est le round de coding qui attend des idiomes Kotlin fluides, pas seulement du code juste. Préparez ce gap en premier.
Combien de temps prévoir avant un onsite Android Engineer ?
Le process prend 3 à 5 semaines. Ajoutez 4 à 6 semaines de prep si vous êtes rouillé sur le Compose / Kotlin actuel ; 2 à 3 semaines si vous shipez de l'Android tous les jours. Rattraper la dernière année de Now in Android est le geste à plus fort levier à ce niveau.
Quelle est l'erreur la plus fréquente des candidats au niveau Android Engineer ?
Traiter le round de coding Android comme un test d'algos. L'intervieweur note si vous écrivez du Kotlin comme un ingénieur Android de production : scopes liés au cycle de vie, gestion d'état Compose, survie à la mort du process. La justesse algorithmique sans cette couche donne l'image d'un dev back-end qui joue à l'Android.
Et si mon process d'entretien diffère de celui décrit ici ?
L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.
Comment ce guide se compare-t-il au scan gratuit ?
Ce guide couvre la barre générale au niveau L4 / IC3. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.
Prêt à préparer un vrai poste ?
Collez n'importe quelle offre Android Engineer, découvrez votre coach en moins de 30 secondes.
Déposez une URL LinkedIn, Greenhouse, Lever ou Levels.fyi, ou collez le texte de l'offre. Votre coach prédit les questions pour cette entreprise, fait ressortir vos écarts d'expérience, et calibre un benchmark de salaire pour le poste et la localisation. PDF par e-mail. L'entraînement vocal avec retour IA sur chaque réponse vit dans l'extension Chrome.
Installation libre · Aperçu sur chaque offre · Plans payants à partir de 3,99 $