Le sobes dans le développement mobile : déroulement des étapes et préparation

Qu'est-ce qu'un «sobes» en IT ?

L'entretien technique («sobes») — processus structuré d'évaluation des compétences professionnelles d'un développeur, comprenant la vérification des hard skills (connaissances techniques) et des soft skills (communication, travail en équipe). Le cycle d'entretien standard d'un développeur mobile comprend 3 à 5 tours d'une durée totale de 4 à 6 heures. Le taux de réussite par rapport au nombre de candidatures initiales est de 2 à 5 % dans les grandes entreprises technologiques.

Le processus de recrutement dans le développement mobile diffère du développement web : s'ajoutent des questions sur les spécificités de la plateforme — cycle de vie d'Activity/Fragment, ARC et gestion de la mémoire en Swift, modèles de threading (Main Thread, Dispatch Queue, Coroutines), gestion des requêtes réseau et de la mise en cache des données. Un développeur Android doit connaître Jetpack Compose, Room, WorkManager, Dagger/Hilt. Un développeur iOS — SwiftUI, Core Data, Combine, URLSession. La différence d'exigences augmente avec l'expérience : pour les postes Senior, s'ajoutent la conception système et l'architecture de l'ensemble de l'application.

La structure de l'entretien dépend du grade. Pour les postes Junior, une connaissance de base du langage et de la plateforme suffit (1-2 tours). Un développeur Middle passe 2-3 tours avec un bloc d'algorithmes. L'entretien Senior comprend 4-5 tours : algorithmes, architecture d'application mobile, conception système, entretien comportemental et entretien final avec le VPE (Vice President of Engineering) ou le CTO.

Étapes de l'entretien technique

Le screening RH — première étape d'une durée de 20 à 30 minutes. Le recruteur vérifie la correspondance de l'expérience avec les exigences du poste, discute des conditions de travail, des attentes salariales et de la motivation du candidat. À cette étape, il est important de formuler clairement son expérience : projets, stack technologique, réalisations mesurables (réduction du temps de chargement, diminution du taux de crash, accélération de la compilation). Le screening RH ne vérifie pas les connaissances techniques, mais élimine jusqu'à 40 % des candidats qui ne correspondent pas aux exigences formelles.

Après le screening suit l'entretien algorithmique — étape clé pour la plupart des entreprises. Durée : 45-90 minutes. Le candidat reçoit 1-2 problèmes d'algorithmes et structures de données. La solution s'écrit sur un tableau en ligne (Codility, HackerRank, CoderPad) ou sur papier. Sont évalués non seulement la justesse, mais aussi la vitesse de réflexion, la capacité à poser des questions de clarification et à optimiser la solution. D'après interviewing.io (2025), 73 % des candidats échouent précisément à l'étape algorithmique.

Entretien d'architecture

Le tour d'architecture vérifie la capacité à concevoir des applications mobiles. On propose au candidat de concevoir une application (liste de tâches, messagerie, agrégateur d'actualités, service de streaming). Sont évalués le choix du patron d'architecture (MVP, MVVM, MVI, VIPER), l'organisation des couches (Presentation, Domain, Data), la gestion de l'injection de dépendances (Dagger, Hilt, Swinject) et la navigation. Pour Android — connaissance de Jetpack Navigation, pour iOS — patron Coordinator et SwiftUI NavigationStack.

Lors de l'entretien comportemental, on évalue les soft skills : capacité à travailler en équipe, à résoudre les conflits, à argumenter les décisions. On utilise la méthode STAR (Situation, Task, Action, Result) — le candidat décrit une situation concrète de son expérience. Exemple de question : « Parlez-moi du bug le plus complexe que vous avez trouvé et corrigé ». Le tour final avec le lead technique ou le VPE vérifie la pensée stratégique et l'adéquation culturelle à l'entreprise.

Algorithmes et structures de données à l'entretien

Les problèmes algorithmiques — composante obligatoire des entretiens dans les grandes entreprises technologiques (Google, Meta, Yandex, Tinkoff, Avito). L'objectif principal est d'évaluer l'ability to solve (capacité à résoudre des problèmes), et non la connaissance du langage. Le candidat peut utiliser n'importe quel langage de programmation — la préférence est donnée à Kotlin pour Android et à Swift pour iOS. Thèmes typiques : tableaux, tables de hachage, graphes, programmation dynamique, arbres (Binary Tree, Trie, Segment Tree).

D'après LeetCode (2025), pour réussir sereinement l'entretien algorithmique, il faut résoudre 250 à 400 problèmes. Thèmes clés par fréquence d'apparition : Two Pointers (12 %), Sliding Window (10 %), DFS/BFS sur les graphes (14 %), Binary Search (8 %), Dynamic Programming (18 %), Hash Map / Set (15 %). La notation Big O — élément obligatoire : le candidat doit expliquer la complexité temporelle et spatiale de sa solution et proposer une optimisation.

Exemple de problème : Two Sum

// LeetCode 1 : Two Sum — problème classique de HashMap
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Stocke le complément = target - nums[i] et son index
    val map = mutableMapOf<Int, Int>()

    for (i in nums.indices) {
        val complement = target - nums[i]

        // Si le complément est trouvé — la paire est trouvée
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Temps : O(n), Espace : O(n)

Le problème Two Sum — le problème le plus populaire des entretiens (d'après LeetCode, plus de 20 millions d'envois). La solution en O(n) utilise une HashMap : pour chaque élément, on vérifie si la différence target - nums[i] a déjà été rencontrée. Si oui — on renvoie les indices. Sinon — on enregistre l'élément courant dans la HashMap. La solution naïve en O(n²) avec deux boucles imbriquées est considérée comme insuffisante pour les postes Senior.

Questions sur le développement mobile

Les questions de plateforme à l'entretien d'un développeur mobile se divisent en trois blocs : connaissances fondamentales de la plateforme, travail avec l'UI et le multithreading, requêtes réseau et stockage des données. Pour Android, obligatoires : le cycle de vie d'Activity et de Fragment, les différences Fragment v1 vs Fragment v2, l'ActivityResult API (remplacement d'onActivityResult), ViewModel + StateFlow, le cycle de vie Compose. Pour iOS : le cycle de vie de UIViewController, l'ARC (Automatic Reference Counting), DispatchQueue et OperationQueue, le cycle de vie SwiftUI (View — @State — @Binding — @ObservedObject).

Exemple de question : cycle de vie

Question typique : « Quels callbacks du cycle de vie d'Activity sont appelés lors d'une rotation de l'écran ? ». La bonne réponse : onPause → onStop → onDestroy → onCreate → onStart → onResume. Question supplémentaire : « Comment conserver l'état lors d'une rotation ? » — via SavedStateHandle dans le ViewModel, onSaveInstanceState Bundle ou rememberSaveable dans Jetpack Compose. Pour iOS : « Que se passe-t-il avec UIViewController lors du passage en arrière-plan ? » — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Conception système d'une application mobile

L'entretien System Design pour un développeur mobile vérifie la capacité à concevoir l'architecture d'une application cliente et son interaction avec le serveur. Problèmes standards : concevoir un fil d'actualités (comme Instagram/TikTok), un chat (comme Telegram), un lecteur vidéo (comme YouTube), un cache de premier niveau (L1 — en mémoire, L2 — disque). Durée : 60 minutes. Est évaluée la structuration de la pensée, et non la quantité de détails.

Modèle de réponse au System Design : 1) Clarify requirements — clarifier les exigences fonctionnelles (fil, likes, commentaires, téléchargement de photos) et non fonctionnelles (offline, vitesse de chargement, consommation de batterie). 2) High-level design — dessiner le schéma des couches : UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — détailler les composants clés, par exemple le mécanisme de pagination (Paging 3 pour Android, Offset-based vs Cursor-based pour iOS). 4) Trade-offs — discuter des compromis : cache vs fraîcheur des données, offline-first vs online-only.

Thèmes clés du System Design pour mobile : mise en cache (LRU Cache, Disk Cache avec limite), travail avec les images (Coil, Glide, SDWebImage — chargement, cache, placeholder, progression), optimisation du trafic (protobuf au lieu de JSON, compression, Differ/GraphQL), travail hors ligne (Room + Sync Adapter, Core Data + iCloud, WorkManager pour la synchronisation en arrière-plan). Offline-first — l'un des sujets les plus fréquents pour les postes Senior.

Pour iOS s'ajoutent des questions sur App Thinning, Slicing, On-Demand Resources et l'optimisation du build. Pour Android — sur R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery et la minification. La question d'architecture « Comment implémenter un cache d'images avec une limite de mémoire ? » vérifie la compréhension du LRU Cache (LinkedHashMap avec access order), du Disk LRU Cache (DiskLruCache de Jake Wharton) et de la couche de cache mémoire de Coil/Glide.

Stratégie de préparation à l'entretien

La préparation à l'entretien exige une approche systématique 4 à 8 semaines avant l'entretien prévu. Stratégie de base : 2 semaines de révision de la théorie (langage, plateforme, algorithmes), 2-4 semaines de résolution de problèmes algorithmiques (100-300 problèmes sur LeetCode), 1-2 semaines d'entretiens blancs (Pramp, interview.io, avec des amis). Pour les postes Senior, s'ajoute la préparation au System Design (2-3 semaines). Le plan donne 70-80 % de chances de réussir le niveau visé.

Pour les développeurs mobiles, la préparation spécifique comprend : la lecture d'Android Developers Guide / iOS Developer Library, l'analyse du code source des bibliothèques populaires (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), l'écriture d'un projet personnel avec Clean Architecture et CI/CD (GitHub Actions, Fastlane). Écrivez une application d'exemple sur GitHub avec une architecture modulaire, l'injection de dépendances, des tests (Unit + UI + Snapshot) — cela montrera une compréhension approfondie et servira d'argument à l'entretien.

Erreurs typiques des candidats

Erreur 1 : résoudre en silence. Le candidat écrit du code en silence, sans commenter son raisonnement. L'intervieweur ne peut pas évaluer le processus de résolution. Correct : verbaliser chaque étape — « Je vois que le problème se réduit à une recherche dans un graphe. Je propose d'utiliser BFS, car il faut trouver le chemin le plus court ». Cette communication donne à l'intervieweur la possibilité de guider le candidat en cas d'erreur, ce qui est évalué positivement.

Erreur 2 : écrire directement le code. Commencer à coder sans clarifier les exigences ni discuter des approches — l'une des principales causes d'échec. Avant d'écrire le code, il faut : clarifier les données d'entrée/sortie, discuter des cas limites, comparer 2-3 approches avec une estimation du Big O et seulement après accord avec l'intervieweur écrire la solution optimale. Patron correct : Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Erreur 3 : ne pas connaître la plateforme. Le candidat résout parfaitement les algorithmes, mais ne peut pas expliquer la différence entre Activity et Fragment ou entre weak/unowned en Swift. Pour les postes mobiles, les connaissances de plateforme sont évaluées au même titre que les algorithmes. Étudiez : les différences de versions du SDK (compileSdk vs minSdk vs targetSdk), les règles ProGuard/R8 pour les bibliothèques populaires, Swift Concurrency (async/await, actors) et MainActor. Un candidat sur trois à un poste iOS échoue sur les questions d'ARC.