Mise à jour 2026
Quelques choses ont changé en France en 2026. L'AI Act encadre le recrutement par IA depuis le 2 août, 31 % des candidats utilisent déjà l'IA pour se 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
La barre sur laquelle on vous note- Posséder une surface ou un sous-module d'app de bout en bout : architecture, budget de perf, cadence de release
- Mener techniquement 2 à 4 ingénieurs Android : relire les designs, écrire les conventions que les autres suivent
- Piloter les décisions transverses sur les modules partagés (réseau, chargement d'images, analytics) et la structure Gradle
- Fixer la barre de qualité Android en production : objectif de taux sans-crash, budget de taux d'ANR, budget de temps de démarrage
- Mentorer les ingénieurs Android mid-level ; participer régulièrement aux loops d'entretien Android comme intervieweur
- Travailler d'égal à égal avec le back-end, le design et le produit sur des features pluri-trimestrielles ; influencer le design d'API en amont
Process d'entretien, round par round
6 rounds · 4 à 6 semainesLa plupart des entreprises suivent une trame similaire pour les entretiens Senior Android. Délai calendaire total : 4 à 6 semaines du pré-screen recruteur jusqu'à l'offre.
Récit de carrière, calibration de niveau, surface possédée, attentes de rémunération
Problème plus dur qu'au L4, le plus souvent une composition de coroutines / Flow ou un petit sous-système (cache d'images, graphe de dépendances). Du Kotlin de niveau production est attendu
Design à l'échelle d'un sous-module ou d'une app entière : feature modularisée avec sa structure Gradle, pipeline d'images / vidéo à grande échelle, personnalisation on-device, push sur plus de 100M d'appareils. On creuse le build, l'impact sur la taille de l'app, les baseline profiles
Choisissez une feature que vous avez architecturée et déroulez chaque décision. La barre : des staff Android engineers qui creusent autant les choix qui tiennent debout que ceux qui sentent le cargo-culting
Opérer avec des partenaires senior, conflit sur le design d'API ou la stratégie de rollout, priorisation sous pression de livraison
Décisions d'architecture revues, incidents de production que vous avez pilotés, mentorat, leadership Android au niveau de l'équipe
Senior Android tourne sur 6 rounds. Pour voir où se situe chaque rôle, ouvrez le rapport entretiens tech 2026.
Questions types à anticiper
14 questions qui décidentReprésentatives de ce que les entreprises demandent à ce niveau. Chaque question ici se travaille à voix haute, c'est le moyen le plus rapide de savoir si votre réponse tient face aux relances. Calibrd ajoute l'entraînement vocal avec un retour sur chaque réponse, et une simulation d'entretien complète : un tour en direct avec un intervieweur IA qui a lu le poste et votre CV, puis un débrief honnête.
- 01« Vous devez paralléliser un traitement par lots où chaque tâche dépend du résultat de la précédente dans son groupe, mais où les groupes sont indépendants. Construisez ça avec les coroutines et la concurrence structurée : quel scope, quel dispatcher, et qu'arrive-t-il aux tâches en cours si l'une d'elles échoue ? »La travailler →
- 02« Vous exposez un Flow qui combine plusieurs sources (cache local, réseau, événements utilisateur) et qui alimente un écran Compose. Détaillez comment vous gérez le backpressure, le partage à plusieurs collecteurs (shareIn / stateIn), et ce qui s'annule quand l'écran passe en arrière-plan. »La travailler →
- 03« Déroulez précisément ce qui survit à la mort du process dans une feature à état complexe : un formulaire à plusieurs étapes avec une requête réseau en cours. Différenciez SavedStateHandle, le state hissé dans le ViewModel et la persistance Room, et dites ce que vous restaurez où, et pourquoi. »La travailler →
- 04« Vous découpez un monolithe Android en multi-module pour qu'une équipe de 50 ingénieurs puisse builder en parallèle. Détaillez les frontières de modules, la navigation inter-modules sans couplage, et comment vous mesurez l'impact sur le temps de build. »La travailler →
- 05« Une liste Compose lourde se recompose trop pendant le scroll et le démarrage à froid a dérivé de 200 ms sur la dernière release. Déroulez comment vous diagnostiquez les deux : quels outils (Layout Inspector, recomposition counts, baseline profiles, traces), dans quel ordre, et ce que vous regardez en premier. »La travailler →
- 06« Une app voit sa mémoire grimper release après release sans crasher. Comment déterminez-vous si c'est une fuite (Activity retenue, context capturé dans un singleton, listener non désabonné) ou une croissance de cache légitime ? Quels outils, dans quel ordre, et où placez-vous la frontière ? »La travailler →
- 07« Designez l'architecture d'un codebase Android de 200 ingénieurs qui veulent livrer leurs features indépendamment par équipe. Couvrez la modularisation Gradle, l'impact sur le temps de build, et comment vous gérez la navigation inter-modules. »La travailler →
- 08« Designez une feature offline-first dans une app à 100M de MAU (par ex. la messagerie d'un Leboncoin ou d'un BlaBlaCar) : sync bidirectionnelle, résolution de conflits, schéma Room, et ce qui se passe si une sync est interrompue par la mort du process ou un changement de réseau. »La travailler →
- 09« Designez le feed d'une app sociale ou de revente à fort trafic (style Vinted) : pagination, préchargement, décodage d'images hors main thread, recyclage des items, et comment vous tenez le budget de perf au scroll rapide sur du milieu de gamme Android. »La travailler →
- 10« Designez un système de feature flags et de remote config pour notre app à 100M de MAU : il doit gérer l'offline, supporter un rollout progressif via le Play Store, et ne jamais bloquer le démarrage. Déroulez le stockage, la stratégie de fetch et le chemin de fallback. »La travailler →
- 11« Parlez-moi d'une décision d'architecture que vous avez portée et que vous reviendriez défaire 18 mois plus tard. Quel signal vous a dit qu'il fallait la revisiter ? »La travailler →
- 12« Décrivez un incident Android en production dont vous avez piloté la réponse : pic d'ANR, régression de crash, rejet du Play Store. Déroulez la détection, la mitigation et le postmortem. »La travailler →
- 13« Racontez une fois où vous avez tenu tête au back-end sur un design d'API. Comment avez-vous opéré ? »La travailler →
- 14« Parlez-moi d'une fois où vous avez remonté la barre de qualité Android de votre équipe : budgets de perf, règles de lint, baseline profiles, quelque chose de systémique. »La travailler →
Ce sont les questions générales. Collez une vraie offre et Calibrd prédit celles que cette entreprise pose pour ce poste précis, puis vous interroge dessus.
Prédire mes questions →Benchmark de salaire
Médiane · base, equity, bonusRémunération médiane pour Senior Android, chiffres principaux tels que le marché de référence les affiche. Quand le repère est le marché tech américain, comptez 30 à 50 % de moins en base à Paris, Berlin ou Singapour. Les ratios d'equity varient selon le stade de l'entreprise.
Pour repère, le total comp d'un Android L5 en FAANG tourne autour de 400–550 k$ au 50e percentile, et suit de près la bande Senior SWE. Google paie la même grille au niveau L5 Android ; chez Meta, un E5 Android équivaut à un E5 back-end. À Paris, la base d'un Senior Android se situe plutôt autour de 65–90 k€ selon l'employeur : scale-ups produit (Doctolib, BlaBlaCar, Leboncoin, Back Market, Lydia, Sorare, Aircall), grands comptes, ou filiales tech américaines. Berlin / Stockholm autour de 70–95 k€. Gardez le chiffre US comme benchmark, pas comme attente locale.
Comment se préparer
6 conseils tactiquesOuvrez vos réponses comportementales avec la méthode STAR : Situation, Tâche, Action, Résultat. Les conseils ci-dessous s'appuient sur cette structure pour ce rôle précis.
- 01Choisissez 1 ou 2 surfaces Android que vous avez architecturées et répétez le deep-dive à froid : chaque choix de design, chaque trade-off, ce que vous feriez différemment aujourd'hui
- 02Maîtrisez 3 ou 4 problèmes canoniques de system design Android à l'échelle : modularisation, personnalisation on-device, feature flags, pipeline d'images / vidéo. Pattern-matchez le reste
- 03Préparez 6 à 8 récits STAR étiquetés sur les signaux senior : décision d'architecture revue, incident de production, conflit cross-fonctionnel, mentorat, travail de perf
- 04Rattrapez les 18 derniers mois de Now in Android : Compose, baseline profiles, améliorations du build, Predictive Back
- 05Drillez la concurrence Kotlin avancée : composition de Flow, partage d'état (shareIn / stateIn), annulation et exceptions en concurrence structurée. C'est l'écart le plus visible entre un L4 et un L5 au coding round
- 06Lisez les posts du blog ingénierie de la boîte que vous visez : chaque loop Android senior a au moins un round qui gagne à nommer les patterns que l'équipe a déjà shipés
Les pièges fréquents au niveau Senior Android
À repérer en simulationQuelques erreurs fréquentes qui font recaler les candidats Senior Android même quand ils sont par ailleurs solides. Mieux vaut les repérer en simulation avant qu'elles n'apparaissent en vrai.
Dérouler son travail Android passé en « j'ai construit X » sans nommer les décisions d'architecture qui comptaient.
Pourquoi ça rate
Les entretiens Senior Android calibrent contre l'ownership d'architecture, pas le nombre de features. « J'ai construit le nouveau feed » est une histoire mid-level. « J'ai défendu une librairie de paging plutôt qu'une pagination maison parce qu'on avait besoin des snapshots Compose pour sauter proprement la recomposition, et cette décision a débloqué l'adoption de LazyColumn par l'équipe » est une histoire senior. Le signal senior, c'est le choix, pas la construction.
Comment rattraper
Pour chaque histoire d'architecture, poussez au-delà du « ce que j'ai construit » vers « le choix que j'ai fait et pourquoi ». Si vous ne savez pas nommer un trade-off précis (perf vs ergonomie de dev, temps de build vs runtime, MVVM vs MVI), c'était du travail d'implémentation, pas d'architecture. Prenez une autre histoire.
Défendre un pattern d'architecture (MVVM, MVI, Clean Architecture) en disant « c'est ce que l'équipe utilise » au lieu de donner le raisonnement de trade-off.
Pourquoi ça rate
Les entretiens Senior Android cherchent à savoir si vous avez réfléchi à pourquoi le pattern de votre équipe marche pour votre équipe. Le pattern en lui-même est rarement le sujet : le signal senior, c'est de comprendre ses trade-offs face aux alternatives, et d'oser pousser pour en changer si ces trade-offs évoluaient. Faire du MVI par cargo-culting parce qu'une conf en parlait vous fait descendre d'un niveau.
Comment rattraper
Préparez une défense de 60 secondes de votre architecture : ce qu'elle optimise (testabilité, vitesse de build, scalabilité de l'équipe), ce qu'elle sacrifie (boilerplate, courbe d'apprentissage, coût de recomposition), et ce qui vous ferait reconsidérer. Même si l'intervieweur préfère un autre pattern, le raisonnement donne l'image d'une réflexion de niveau senior.
Faire un system design Android sans jamais mentionner la taille de l'app, le temps de démarrage, le taux d'ANR ou les contraintes de rollout Play Store.
Pourquoi ça rate
Le system design Android au L5 note sur les contraintes de production, pas seulement l'architecture abstraite. Un design qui n'évoque ni la taille de l'APK / AAB, ni le budget de démarrage à froid, ni le risque d'ANR, ni le scénario de rollout progressif et de kill-switch donne l'image de « quelqu'un qui pense comme un architecte back-end et qui design pour Android par accident ». Le pattern senior, c'est de poser ces contraintes comme des citoyens de première classe.
Comment rattraper
Dans tout system design Android à la barre senior, nommez les contraintes de production d'entrée : impact sur la taille de l'app, budget de démarrage à froid, risque d'ANR, surface de rollout Play (pourcentage progressif, contrôles de régression Play Console), et le chemin kill-switch / remote config. Même 60 secondes là-dessus gagnent le signal senior.
Ressources recommandées
Sans lien d'affiliationLivres, cours et outils qui reviennent le plus dans la préparation Senior Android.
- 01Android Developers, guide d'architecture →
Le guide d'architecture officiel de Google. Relisez les sections Modularisation et Architecture avant tout round d'architecture Android senior.
- 02Kotlin Coroutines (guide officiel) →
Le guide canonique sur les coroutines, les scopes et Flow. Au niveau senior, creusez la concurrence structurée, l'annulation et la composition de Flow : c'est ce qui tombe au coding round.
- 03Jetpack Compose (doc officielle) →
La doc de référence sur l'état, la recomposition et les side-effects. Relisez les sections perf et stabilité avant un round qui touche à la perf Compose.
- 04Now in Android (app d'exemple Google) →
L'app de référence de Google pour les patterns d'architecture Android actuels à l'échelle. Les décisions d'architecture documentées dans le repo sont les plus rentables.
- 05Android Interview Questions (GitHub) →
Repo communautaire de questions d'entretien classées par thème. À parcourir pour pattern-matcher les questions Kotlin avancé, cycle de vie et architecture qui tombent vraiment.
- 06Documentation Android vitals →
La référence canonique des budgets crash-free et ANR que ce guide invoque sans arrêt, y compris les seuils à partir desquels le Play Store pénalise la visibilité de l'app.
Scénarios courants
Situations qui reviennent souventJe suis Android mid-level (4-5 ans) dans une boîte produit française (Doctolib, BlaBlaCar, Leboncoin). Je suis solide sur la feature mais on me dit que mon scope n'est pas encore « senior ». Comment je passe la barre L5 ?
L'écart n'est pas technique, c'est l'ownership. Un L4 livre des features bien ; un L5 fait les choix d'architecture sur lesquels les autres s'appuient ensuite. Le test rapide : sur les 12 derniers mois, combien de décisions avez-vous portées dont dépend maintenant le code des autres ? Un module partagé que vous avez designé, une convention que l'équipe suit, une migration Views vers Compose que vous avez pilotée sur plusieurs écrans. Si vos décisions s'arrêtent à votre propre feature, vous êtes encore L4. Pour le loop, le round qui décide tout est le deep-dive d'architecture : choisissez 1 ou 2 surfaces que vous avez vraiment possédées et répétez-les à froid, chaque choix, chaque trade-off, chaque contre-factuel. Si vous ne savez nommer aucun trade-off précis sur une feature, c'était de l'implémentation, pas de l'architecture, prenez-en une autre. Et au coding round, ne vous reposez pas sur un Kotlin « qui marche » : la concurrence avancée (composition de Flow, scopes, annulation) est ce qui sépare visiblement un L4 d'un L5.
Mon app est encore très Java + Views sur les écrans critiques, et je migre vers Kotlin + Compose au fil de l'eau. Est-ce que ça me dessert pour un loop Senior Android chez Lydia, Qonto ou Sorare ?
Non, au contraire, à condition de cadrer la migration comme un travail d'architecture senior. La réalité des grosses apps françaises (Doctolib, Leboncoin, BlaBlaCar) c'est exactement ça : du Java + Views historique sur les écrans critiques, du Kotlin + Compose sur le neuf, et beaucoup d'interop entre les deux. Les intervieweurs senior le savent et le valorisent : piloter une migration Views vers Compose sans casser la prod, c'est une histoire d'architecture de premier ordre. Préparez-vous à dérouler comment vous avez séquencé la migration (quels écrans d'abord et pourquoi), comment vous avez géré l'interop (ComposeView, état partagé entre les deux mondes), et où vous gardez encore des Views en connaissance de cause (listes très lourdes, vues custom existantes). Le piège, c'est de présenter la migration comme une corvée subie plutôt que comme une décision que vous avez portée. Mais Kotlin n'est pas optionnel au coding round senior : drillez les coroutines, Flow et la concurrence structurée à fond, c'est là qu'on attend de la fluidité.
Je suis Senior iOS et je veux passer Senior Android (ou l'inverse). Mes contraintes mobiles transposent-elles au niveau senior, ou je repars de zéro côté Kotlin ?
Vos contraintes mobiles transposent presque entièrement, et c'est la moitié de la barre senior : ownership d'une surface sur plusieurs releases, perf à l'échelle, gestion mémoire, sync offline, postmortems d'incidents. Ce qui ne transpose pas, c'est l'idiome Kotlin et les frontières propres à Android. Au coding round, le piège classique d'un profil venu d'iOS, c'est d'écrire du Kotlin comme du Swift : drillez la concurrence structurée (coroutines, scopes, annulation, composition de Flow) et la gestion d'état Compose, parce que c'est précisément là qu'on vous repère. Côté system design et deep-dive d'architecture, votre intuition sur l'offline, le cache et la perf de liste se transpose directement, apprenez juste les noms Android (Room vs Core Data, WorkManager vs background tasks, la mort du process et SavedStateHandle vs la restauration d'état iOS). Comptez 6 à 8 semaines de remise à niveau Kotlin sérieuse plus la dernière année de Now in Android. En behavioral, assumez la transition franchement : passer d'une plateforme mobile à l'autre en senior est une histoire d'apprentissage rapide qui plaît, pas un handicap.
Je suis Android tech lead dans une scale-up parisienne mais sur une app relativement petite. Mon scope va-t-il « tenir » dans un loop Senior Android d'une filiale FAANG à Paris ou d'une boîte à 100M+ d'utilisateurs ?
Attendez-vous à de la friction sur la calibration. « Tech lead Android » dans une petite app veut souvent dire « l'Android le plus senior, qui fait de la feature plus un peu d'architecture », ce qui peut se situer au L4 haut chez une boîte à très grande échelle plutôt qu'au L5 plein. Au L5 dans une grosse boîte, on attend de l'architecture multi-module qui tient pour plusieurs équipes, des budgets de perf défendus contre des contraintes de prod réelles (taux d'ANR, démarrage à froid, taille d'app), et du mentorat structuré. Ne négociez pas le niveau au pré-screen : passez le loop au niveau proposé, performez, et laissez le deep-dive d'architecture signaler où vous vous situez vraiment. Le travail le plus rentable avant le loop, c'est de transposer votre expérience à l'échelle de l'intervieweur : même sur une petite app, vous avez fait des choix de modularisation, géré la mort du process, optimisé un démarrage. Cadrez-les en termes de production (chiffres d'ANR, taux sans-crash, métrique de perf qui a bougé) et la conversation monte d'un cran.
Questions fréquentes
Je suis actuellement Android Engineer (L4 / IC3). Dois-je lire ce guide ou celui de Android Engineer en premier ?
Lisez d'abord le guide Android Engineer. Les entreprises calibrent les candidats L5 / IC4 contre la barre L4 / IC3, en ciblant clairement l'écart de scope, elles veulent voir où vous êtes aujourd'hui, puis creuser le gap jusqu'au L5 / IC4. Lisez ce guide APRÈS avoir compris la baseline L4 / IC3, comme ça vous saurez exactement quels signaux démontrer pour le step-up.
Combien de temps prévoir avant un onsite Senior Android ?
Le process prend 4 à 6 semaines. Ajoutez 6 à 8 semaines de prep, le deep-dive d'architecture est le round à plus fort levier. Choisissez 1 ou 2 surfaces que vous avez possédées et répétez-les à froid : chaque choix, chaque trade-off, chaque contre-factuel. Ne sautez pas le rattrapage de Now in Android.
Quelle est l'erreur la plus fréquente des candidats au niveau Senior Android ?
Décrire du travail d'implémentation comme du travail d'architecture. Les entretiens Senior Android calibrent contre les choix que vous avez faits, pas les features que vous avez shipées. De solides histoires L4 « j'ai construit X à l'échelle » vous feront descendre d'un niveau si vous ne savez pas articuler le trade-off d'architecture derrière X.
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 L5 / IC4. 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.
Passez à votre vraie offre
Collez n'importe quelle offre Senior Android, 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. Ensuite, répétez le tour à voix haute avec un retour honnête jusqu'à être prêt.
Gratuit pour commencer · Sans carte bancaire · Votre CV reste sur votre appareil