24 - Simulations d'entretiens

Objectifs pédagogiques

À la fin de ce chapitre, vous serez capable de :

1. Répondre à 30 questions comportementales avec la méthode STAR
2. Répondre à 30 questions techniques (Android, iOS, cross-platform, architecture, system design)
3. Structurer vos réponses et éviter les pièges classiques
4. Défendre vos choix techniques et vos décisions d'architecture

Plan du chapitre

Fichiers du chapitre

Temps estimé

• Préparation par écrit : 10 h
• Simulations à l'oral : 6 h (3 sessions de 2 h)

Méthode STAR (réponses comportementales)

• Situation : contexte précis (projet, équipe, échéance).
• Tâche : votre responsabilité exacte.
• Action : les étapes que vous avez menées (avec le « je », pas le « nous »).
• Résultat : chiffres, impact mesurable, leçon retenue.

---

PARTIE 1 — 30 questions comportementales

Section 1 — Général (Q1 à Q10)

Q1. Parlez-moi de vous.

Objectif : vérifier la cohérence du parcours, la motivation et la communication.

Structure de réponse (2 min) :

1. Situation actuelle : formation, dernière expérience (30 s).
2. Compétences clés : stack maîtrisée, projets marquants (1 min).
3. Objectif : pourquoi ce poste, ce que vous apportez (30 s).

Piège : raconter sa vie depuis l'enfance ou réciter son CV. Restez orienté mobile et résultats.

Q2. Qu'est-ce qui vous a poussé vers le développement mobile ?

Objectif : juger la motivation authentique.

Réponse type : parlez d'un projet réel (app publiée, projet fil rouge, problème résolu), de l'attrait pour l'expérience utilisateur, et de l'évolution rapide du secteur.

Q3. Quels sont vos points forts ?

Objectif : l'auto-évaluation et l'honnêteté.

Réponse type : choisissez 3 forces liées au poste (rigueur sur les tests, soin de l'UX, autonomie), chacune illustrée par un exemple concret et si possible un chiffre.

Q4. Quels sont vos points faibles ?

Objectif : lucidité et capacité de progrès.

Réponse type : choisissez un vrai défaut non rédhibitoire (ex. impatience à vouloir tout tester soi-même, tendance à sur-architecturer) et le plan d'amélioration déjà en place (revue par les pairs, ADR, mentorat).

Q5. Pourquoi voulez-vous travailler chez nous ?

Objectif : la préparation et l'adéquation produit.

Réponse type : montrez que vous connaissez le produit, la stack (vérifiée dans les offres et GitHub), la culture, et reliez vos compétences aux enjeux de l'entreprise.

Q6. Où vous voyez-vous dans 5 ans ?

Objectif : ambition réaliste et alignement.

Réponse type : trajectoire crédible (senior → lead/architecte), en restant dans le mobile, avec une évolution que l'entreprise peut accompagner.

Q7. Quel salaire visez-vous ?

Objectif : cohérence marché.

Réponse type : donnez une fourchette basée sur le marché (benchmark Glassdoor/Levels.fyi), en la reliant à l'expérience et en restant négociable. Évitez la première position trop basse.

Q8. Avez-vous des questions pour nous ?

Objectif : votre intérêt et votre sens critique.

Préparez : 3 questions sur la stack, le processus (review, CI), les objectifs d'équipe, le produit. Exemples : « Quelle est votre politique de dette technique ? », « Comment mesurez-vous la qualité ? ».

Q9. Comment apprenez-vous une nouvelle technologie ?

Objectif : la capacité d'apprentissage autonome.

Réponse type : docs officielles → projet scratch → codelab → contribution/veille. Citez un exemple récent (SwiftUI, KMP, etc.) avec le résultat.

Q10. Travaillez-vous mieux seul ou en équipe ?

Objectif : honnêteté et adaptabilité.

Réponse type : les deux, avec des conditions (autonomie sur les tâches définies, collaboration sur l'architecture et les reviews). Illustrez avec deux exemples.

Section 2 — Équipe & produit (Q11 à Q20)

Q11. Décrivez un conflit avec un collègue et comment vous l'avez résolu.

STAR attendue : désaccord technique (ex. choix d'architecture) → argumentation par les faits (mesures, ADR) → décision d'équipe → résultat positif et relation préservée.

Q12. Comment gérez-vous une critique de votre code ?

Réponse type : la critique est sur le code, pas la personne ; on demande les raisons, on argumente si nécessaire, on accepte les meilleures solutions, on remercie. Exemple concret de revue qui a amélioré votre code.

Q13. Comment priorisez-vous votre travail ?

Réponse type : impact × urgence, alignement sur les objectifs produit, feedback court, et gestion des interruptions. Donnez un exemple où vous avez dit « non » à juste titre.

Q14. Que faites-vous quand vous ne comprenez pas une spécification ?

Réponse type : reformuler, demander des clarifications au PO, proposer des options avec compromis, documenter la décision. Ne jamais coder dans le vague.

Q15. Comment réagissez-vous face à un délai irréaliste ?

Réponse type : quantifier l'écart, proposer des découpages (MVP), des compromis (qualité/scope), remonter tôt les risques. STAR avec un exemple de négociation de périmètre.

Q16. Comment partagez-vous votre savoir avec l'équipe ?

Réponse type : documentations courtes (ADRs), sessions de partage, revues de code pédagogiques, mentoring de juniors. Un exemple de talk ou de doc qui a aidé l'équipe.

Q17. Quelle est votre expérience de la revue de code ?

Réponse type : relecteur régulier (checklists, bienveillance, questions plutôt qu'injonctions), auteur qui répond aux commentaires et apprend. Mentionnez les critères : lisibilité, tests, sécurité, performance.

Q18. Comment travaillez-vous avec un designer ?

Réponse type : traduire les maquettes en implémentation fidèle, discuter des contraintes techniques (perf, accessibilité), prototyper rapidement, boucler sur l'expérience utilisateur.

Q19. Comment gérez-vous les demandes urgentes du client en pleine itération ?

Réponse type : qualification de l'urgence (vrai incident ?), priorisation avec le PO, communication transparente, gestion de la dette (fix + analyse des causes).

Q20. Quelle méthode agile utilisez-vous et qu'en pensez-vous ?

Réponse type : Scrum/Kanban selon le contexte ; l'essentiel est la boucle de feedback et la transparence, pas le rituel. Donnez un exemple d'amélioration de process apportée.

Section 3 — Échec & leadership (Q21 à Q30)

Q21. Racontez un échec professionnel.

STAR attendue : un échec réel mais non catastrophique (bug en prod, estimation ratée, fonctionnalité abandonnée), l'analyse des causes, les actions correctives, ce que vous avez changé depuis.

Q22. Avez-vous déjà introduit un bug en production ?

Réponse type : oui, honnêtement. Description : cause (manque de test, hypothèse fausse), détection (crash reporting), correction rapide, et surtout prévention : test ajouté, check de release, revue du process.

Q23. Comment décidez-vous entre vitesse et qualité ?

Réponse type : le contexte décide ; on ne sacrifie jamais la sécurité et l'intégrité des données ; on documente la dette technique et on la rembourse. Exemple de compromis assumé.

Q24. Quelle est votre plus grande réalisation technique ?

STAR attendue : une réalisation avec impact mesurable (app publiée avec X utilisateurs, performance divisée par 2, architecture adoptée par l'équipe). Chiffres à l'appui.

Q25. Comment donnez-vous un retour négatif à un collègue ?

Réponse type : privé, factuel, orienté solutions, basé sur des faits observables, sans jugement personnel. Exemple concret.

Q26. Comment gérez-vous une surcharge de travail ?

Réponse type : tri (important/urgent), délégation si possible, communication des limites, techniques de focus (pomodoro), et prévention (estimation plus réaliste).

Q27. Qu'avez-vous appris lors de votre dernier projet ?

Réponse type : une compétence technique ET une leçon de processus. L'objectif est de montrer la capacité de rétrospective continue.

Q28. Que pensez-vous du télétravail ?

Réponse type : honnête et équilibré (avantages de focus, vigilance sur la communication asynchrone et la collaboration), adapté à votre mode de fonctionnement.

Q29. Pourquoi avez-vous quitté votre dernier poste ?

Réponse type : toujours positif, orienté opportunité (nouvelle stack, plus de responsabilités), jamais dénigrant.

Q30. Comment voyez-vous l'évolution de votre rôle en 2 ans ?

Réponse type : progression vers senior/lead avec des responsabilités croissantes en architecture et en mentoring, tout en restant impliqué dans le code.

---

PARTIE 2 — 30 questions techniques

Section 4 — Android (Q1 à Q6)

Q1. Expliquez le cycle de vie d'une Activity.

Attendu : onCreate (initialisation unique), onStart (visible), onResume (interactive), onPause (partiellement masquée), onStop (masquée), onDestroy (fin). Rotation = destruction + recréation. On parle aussi de l'« app startup » et de onSaveInstanceState.

Q2. Quelle est la différence entre une Activity et un Fragment ?

Attendu : l'Activity est l'unité d'écran/tâche, le Fragment est une portion d'UI réutilisable avec son propre cycle de vie, géré par le FragmentManager. Avec Compose, la navigation se fait par destinations, mais les concepts restent.

Q3. Comment fonctionne la mémoire en Android ?

Attendu : chaque app a un heap, l'OS gère la mémoire (low memory killer), les Activity sont des références fortes → fuites possibles (listeners, ViewModels trop larges). Outils : Profiler, LeakCanary, onTrimMemory.

Q4. Qu'est-ce qu'un ContentProvider ?

Attendu : une interface d'échange de données entre apps (contacts, médias), sécurisée par permissions. On le confond souvent avec les bases internes : ce n'est pas un besoin systématique.

Q5. Comment gérer les threads sur Android ?

Attendu : le main thread (UI) ne doit jamais être bloqué ; les tâches lourdes vont sur Dispatchers.IO/Default ; communication par Main + coroutines/Flow, ou runOnUiThread en legacy. ANR : > 5 s sans réponse.

Q6. Qu'est-ce que l'inversion de contrôle ? Donnez un exemple Android.

Attendu : le framework appelle votre code (callbacks de cycle de vie), pas l'inverse. Exemples : onCreate, onClick, lifecycle callbacks. À distinguer de l'injection de dépendances (DI) : fournir les dépendances de l'extérieur (Hilt).

Section 5 — iOS (Q7 à Q12)

Q7. Expliquez le « Automatic Reference Counting » (ARC).

Attendu : compteur de références incrémenté/décrémenté ; libération à zéro. Pièges : cycles forts (class → class) → weak/unowned ; [weak self] dans les closures. Les struct sont copiées, pas comptées.

Q8. Quelle est la différence entre weak et unowned ?

Attendu : weak → optionnelle, devient nil quand l'objet est libéré (safe) ; unowned → référence non optionnelle supposée toujours vivante (crash si libérée). On préfère weak pour la sûreté.

Q9. Comment fonctionne SwiftUI par rapport à UIKit ?

Attendu : SwiftUI est déclaratif (l'état pilote l'UI, pas de mise à jour manuelle), UIKit est impératif. SwiftUI moderne (iOS 16+) gère NavigationStack, @Observable ; UIKit reste pour les apps legacy ou les besoins très spécifiques.

Q10. Expliquez @escaping dans une closure.

Attendu : une closure qui survit après le retour de la fonction (ex. complétion async) doit être @escaping. Attention aux fuites (capture de self → [weak self]).

Q11. Comment protéger l'accès à une ressource partagée en Swift moderne ?

Attendu : les actor (isolation de l'état mutable), @MainActor pour l'UI, ou des mécanismes type semaphores pour les cas legacy. Swift 6 rend l'isolation stricte au niveau du compilateur.

Q12. Qu'est-ce que le « Main Thread Checker » ?

Attendu : un outil de Xcode qui détecte les accès UI hors du main thread (crash possible). Connexe : les UI updates doivent être sur MainActor.

Section 6 — Cross-platform (Q13 à Q18)

Q13. React Native vs Flutter : quel choix et pourquoi ?

Attendu : RN utilise des composants natifs (bridge/JSI) et JavaScript ; Flutter dessine tout via son moteur (Skia/Impeller) avec Dart. RN : communauté JS, intégration native fine. Flutter : rendu cohérent, performance prévisible, hot reload. Le choix dépend de l'équipe et du produit.

Q14. Comment React Native gère-t-il le thread principal ?

Attendu : trois threads : UI (natif), JS (logique), Native (modules). Le bridge/JSI les relie. Les animations doivent rester sur le thread UI (native driver) pour éviter le jank.

Q15. Qu'est-ce qu'un « stateful widget » Flutter et quand l'utiliser ?

Attendu : widget avec State mutable (setState). À utiliser quand l'UI dépend d'un état local ; au-delà, monter en gamme (Provider/Riverpod/Bloc). Un composant pur = StatelessWidget.

Q16. Comment partager du code entre RN et Flutter ?

Attendu : chacun a ses plateformes (iOS/Android/web/desktop). Pour le code métier partagé entre les deux écosystèmes, on ne partage généralement que la logique (TypeScript vs Dart) via des librairies dédiées ou une architecture BFF. (KMP est l'option « Kotlin ».)

Q17. Qu'est-ce que le « New Architecture » React Native ?

Attendu : JSI (accès natif synchrone), TurboModules (chargement paresseux), Fabric (renderer partagé), et le « codegen » typé. Objectif : performances et interopérabilité améliorées par rapport au bridge legacy.

Q18. Comment gérer les assets et le thème en Flutter ?

Attendu : ThemeData global (MaterialApp), MediaQuery/LayoutBuilder pour l'adaptation, packages flutter_launcher_icons, assets déclarés dans pubspec.yaml.

Section 7 — Architecture (Q19 à Q24)

Q19. Comparez MVC, MVP, MVVM et MVI.

Attendu : MVC (Controller pilote tout, couplé à la View), MVP (Presenter, UI passive), MVVM (ViewModel + bindings, l'UI observe), MVI (flux unidirectionnel : Intention → État → Vue). MVVM/MVI sont les modernes ; MVI apporte la traçabilité et le déterministe.

Q20. Quand choisir MVVM ou MVI ?

Attendu : MVVM est plus simple et suffisant pour la majorité des écrans ; MVI est plus rigoureux (état unique, effets explicites) pour les écrans complexes, les flows à états multiples (paiement, onboarding) et les équipes qui valorisent le test de l'état.

Q21. Qu'est-ce que Clean Architecture et pourquoi l'utiliser ?

Attendu : séparation en couches (domain/data/presentation), dépendances vers l'intérieur, indépendance des frameworks. Bénéfices : testabilité, maintenabilité, évolutivité. Coût : plus de boilerplate — à appliquer quand la complexité le justifie.

Q22. Comment concevoir la couche de données (repository) ?

Attendu : interface dans le domaine, implémentation data qui combine sources (remote/local), stratégie de cache (read-through, TTL), gestion d'erreurs (Resource/Résultat), tests par fakes.

Q23. Qu'est-ce qu'un ADR et comment le rédiger ?

Attendu : Architecture Decision Record : Contexte → Décision → Conséquences. Court (une page), versionné avec le code, discuté en équipe. Exemple : « choisir StateFlow plutôt que LiveData ».

Q24. Comment éviter les fuites de ViewModel et de mémoire ?

Attendu : ViewModel doit rester léger (ne pas capturer l'Activity), utiliser viewModelScope/MainActor, retirer les listeners, utiliser des objets partagés (repository) et weak/cleanup pour les Observers. LeakCanary/Instruments pour valider.

Section 8 — System design mobile (Q25 à Q30)

Q25. Concevez une application de chat (type WhatsApp).

Attendu : architecture (client mobile + backend), temps réel (WebSocket/SSE pour messages, MQTT pour présence), persistance locale (file de messages hors-ligne), synchronisation (conflicts), sécurité (E2E chiffrement), scaling (chat sharding), notifications push. Établissez les exigences puis les décisions clés.

Q26. Concevez un système de notification push.

Attendu : FCM (Android) / APNs (iOS) côté fournisseur, device tokens, backends d'envoi (server → push provider → device), registre des tokens, gestion des doublons, deep links, notifications locales vs distantes, e2e latency et retries.

Q27. Comment concevoir le stockage hors-ligne d'une app de commandes ?

Attendu : file locale (Room/CoreData) + file d'opérations en attente, réconciliation au retour du réseau, conflits par version/timestamp, indicateurs UI, chiffrement des données sensibles, taille et purge (LRU, TTL).

Q28. Concevez une app de streaming vidéo (architecture client).

Attendu : lecture progressive (HLS/DASH), qualité adaptative (bandwidth detection), cache segmenté, DRM, téléchargement hors-ligne (licences), considérations mémoire/GPU, métriques de lecture (startup time, buffering), background audio/video.

Q29. Concevez le « cold start » d'une app de banque.

Attendu : objectif < 1,5 s : démarrage minimal (splash léger), chargement paresseux des modules, préfetch des données critiques, cache local, fallback offline, sécurité (Keystore, biometrics, session), analytics de démarrage.

Q30. Comment architecturer la géolocalisation et le suivi en temps réel ?

Attendu : permissions et vie privée (à la volée vs arrière-plan), fusion de sources (GPS, WiFi, cell), batching des envois, batteries (mise en veille, smart frequency), serveur de position (WebSocket), ant-réplique, et conformité (RGPD, opt-in).

---

Règles d'or pour l'entretien

Plan de préparation (2 semaines)

Pour aller plus loin

1. Rédigez vos 30 réponses STAR par écrit : la clarté à l'écrit se transmet à l'oral.
2. Réalisez une simulation avec un pair et demandez un retour structuré.
3. Préparez 3 études de cas system design avec schémas (chat, offline, push).