Entretien System Design pour Android/iOS

Réussir son entretien système design en tant que développeur mobile

Les entretiens système design évaluent votre capacité à concevoir des applications mobiles évolutives adaptées aux plateformes Android et iOS. On vous donne un brief pour concevoir un service — comme une app de messagerie, un clone de YouTube ou un flux style Twitter — et vous devez expliquer votre raisonnement en 45–60 minutes. L'accent est mis sur la méthode : clarifier les besoins, architecture globale, plongée dans les composants, et récapitulatif final. Pour les postes mobile, mettez en avant le cache local, l'optimisation UI, l'autonomie de la batterie, sans vous perdre dans le sharding de bases de données backend.

Étape 1 : Clarifier les besoins (5 minutes)

Démarrez par des questions précises pour bien cerner le problème. Notez les réponses sur un outil de tableau blanc (Miro, Draw.io, Excalidraw) pour les fixer. Obtenez l'accord de l'intervieweur avant de passer à la suite.

Questions clés pour les apps mobiles :

• Besoins fonctionnels : scénarios utilisateurs, fonctionnalités essentielles (utilisateurs, patterns d'usage, capacités indispensables).
• Périmètre : client-side uniquement, ou incluant APIs/backend ?
• Support des appareils : smartphones, tablettes, Wear OS ?
• Niveau API minimum (impacte des features comme le Scoped Storage sur Android).
• Non-fonctionnels : support hors ligne, notifications push, authentification.

Discutez des cas limites : connexion instable, batterie faible, gros volumes de données. Ça montre la réflexion pragmatique d'un dev intermédiaire à senior.

Étape 2 : Architecture globale (10 minutes)

Esquissez un diagramme en blocs des composants principaux. Sur Android, appuyez-vous sur l'architecture propre : couches Presentation, Domain et Data.

Exemple basique :

• Presentation : ViewModel, Fragment/Activity, RecyclerView.
• Domain : UseCase, Repository.
• Data : ApiDataSource (Retrofit/OkHttp), LocalDataSource (Room/SQLite).
• DI : Hilt/Dagger.

Adaptez selon les specs : ajoutez ImageLoader (Coil/Glide), PushService (Firebase), Navigation Coordinator.

Expliquez vos choix : « On utilise LocalDataSource en mode offline-first pour réduire les appels réseau et la conso data. » Parcourez les flux utilisateurs et validez le schéma avec l'intervieweur.

Étape 3 : Plongée dans les composants (20 minutes)

Démontrez chaque bloc : expliquez l'implémentation, alternatives et compromis. Priorisez l'essentiel ; zappez les bonus sauf demande.

ApiDataSource : Retrofit + OkHttp pour les APIs REST. Alternative : GraphQL avec Apollo.

Avantages REST :

• CRUD standard, sans état.
• Facile à mettre en place.

Inconvénients mobile :

• Connexions séparées par requête (mauvais pour les mises à jour fréquentes).
• Surcharge de sérialisation (JSON), Base64 pour les binaires.

Retrofit excelle pour les apps non temps réel comme la météo ou les flux sociaux sans chat.

LocalDataSource : Room sur SQLite pour le cache offline avec invalidation (TTL ou événementielle).

Repository : Source unique de vérité, orchestre Api/Local. Exemple : lecture locale d'abord, synchro API en arrière-plan.

UseCase : Logique métier (tri, filtrage). Garde le Domain isolé des Data.

Presentation : ViewModel pour l'état (StateFlow/LiveData), RecyclerView avec DiffUtil pour des mises à jour fluides comme du beurre.

DI : Hilt pour l'injection modulaire, moins de boilerplate.

Couvrez les optimisations : Coroutines/Flow pour l'asynchrone, Paging 3 pour les listes infinies, WorkManager pour les tâches en fond.

Étape 4 : Conclusion et questions (10 minutes)

Récapitulez l'architecture, soulignez les compromis, proposez des métriques (latence <200 ms, drain batterie <5%/h). Répondez aux questions de l'intervieweur. Posez les vôtres : sur leur stack actuel, leurs outils.

Points clés

• Méthode avant perfection : Montrez votre raisonnement, vos questions, les cas limites.
• Mobile first : Priorisez offline, batterie, perf UI (60 ips), pas le scaling backend.
• Architecture propre : Couches, flux de données unidirectionnel, code testable.
• Compromis : Justifiez vos choix (ex. Retrofit vs GraphQL selon le volume de données).
• Timing : 5-10-20-10 minutes, discutez comme un pair.

— Editorial Team