Technisch interview in mobiele ontwikkeling: essentie van uitvoering, fasen en voorbereiding

Wat is een technisch interview in IT?

Technisch interview — een gestructureerd evaluatieproces van professionele competenties van een ontwikkelaar, inclusief controle van hard skills (technische kennis) en soft skills (communicatie, teamwerk). De standaard interviewcyclus van een mobiele ontwikkelaar duurt 3-5 rondes met een totale duur van 4-6 uur. Het percentage succesvolle doorloop van het aantal primaire reacties bedraagt 2-5% bij grote technologiebedrijven.

Het wervingsproces in mobiele ontwikkeling verschilt van webontwikkeling: er worden vragen over platformspecificiteit toegevoegd — levenscyclus van Activity/Fragment, ARC en geheugenbeheer in Swift, threading-modellen (Main Thread, Dispatch Queue, Coroutines), werken met netwerkverzoeken en gegevenscaching. Android-ontwikkelaar moet Jetpack Compose, Room, WorkManager, Dagger/Hilt kennen. iOS-ontwikkelaar — SwiftUI, Core Data, Combine, URLSession. Het verschil in vereisten neemt toe met ervaring: voor Senior-posities wordt systeemontwerp en architectuur van de hele applicatie toegevoegd.

De structuur van het interview hangt af van het niveau. Voor Junior-posities is basiskennis van de taal en het platform voldoende (1-2 rondes). Middle-ontwikkelaar doorloopt 2-3 rondes met een algoritmeblok. Senior-interview omvat 4-5 rondes: algoritmen, architectuur van mobiele applicatie, systeemontwerp, gedragsinterview en eindinterview met VPE (Vice President of Engineering) of CTO.

Fasen van het technisch interview

HR-screening — eerste fase van 20-30 minuten. De recruiter controleert of de ervaring voldoet aan de functie-eisen, bespreekt arbeidsvoorwaarden, salarisverwachtingen en motivatie van de kandidaat. In deze fase is het belangrijk om je ervaring duidelijk te formuleren: projecten, technologiestack, prestaties in metrieken (verkorting van laadtijd, vermindering van crash rate, versnelling van compilatie). HR-screening controleert geen technische kennis, maar verwijdert tot 40% van de kandidaten wegens niet-naleving van formele vereisten.

Na screening volgt algoritmisch interview — de sleutelfase voor de meeste bedrijven. Duur — 45-90 minuten. De kandidaat krijgt 1-2 taken over algoritmen en datastructuren. De oplossing wordt op een online bord (Codility, HackerRank, CoderPad) of op papier geschreven. Niet alleen correctheid wordt beoordeeld, maar ook denksnelheid, vermogen om verduidelijkende vragen te stellen en de oplossing te optimaliseren. Volgens interviewing.io (2025) faalt 73% van de kandidaten juist in de algoritmische fase.

Architectuurinterview

Architectuurronde controleert het vermogen om mobiele applicaties te ontwerpen. De kandidaat krijgt de opdracht om een applicatie te ontwerpen (TODO-lijst, messenger, nieuwsaggregator, streamingdienst). Beoordeeld worden: keuze van architectuurpatroon (MVP, MVVM, MVI, VIPER), organisatie van lagen (Presentation, Domain, Data), werken met DI (Dagger, Hilt, Swinject) en navigatie. Voor Android — kennis van Jetpack Navigation, voor iOS — Coordinator-patroon en SwiftUI NavigationStack.

In het gedragsinterview worden soft skills beoordeeld: vermogen om in team te werken, conflicten op te lossen, beslissingen te argumenteren. De STAR-methode (Situation, Task, Action, Result) wordt gebruikt — de kandidaat beschrijft een concrete situatie uit ervaring. Voorbeeldvraag: „Vertel over de moeilijkste bug die je hebt gevonden en opgelost”. Finale ronde met teamleider of VPE controleert strategisch denken en culturele fit met het bedrijf.

Algoritmen en datastructuren op het interview

Algoritmische taken — een verplicht onderdeel van interviews bij grote technologiebedrijven (Google, Meta, Yandex, Tinkoff, Avito). Het hoofddoel is het beoordelen van ability to solve (probleemoplossend vermogen), niet taalkennis. De kandidaat mag elke programmeertaal gebruiken — de voorkeur gaat uit naar Kotlin voor Android en Swift voor iOS. Typische onderwerpen: arrays, hash-tabellen, grafieken, dynamisch programmeren, bomen (Binary Tree, Trie, Segment Tree).

Volgens LeetCode (2025) is het voor een succesvolle doorloop van het algoritmisch interview nodig om 250-400 taken op te lossen. Belangrijkste onderwerpen qua frequentie: Two Pointers (12%), Sliding Window (10%), DFS/BFS op grafieken (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). Big O-notatie — verplicht element: de kandidaat moet de tijds- en ruimtecomplexiteit van zijn oplossing uitleggen en optimalisatie voorstellen.

Voorbeeldtaak: Two Sum

// LeetCode 1: Two Sum — klassiek HashMap-probleem
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Sla complement = target - nums[i] en de index op
    val map = mutableMapOf<Int, Int>()

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

        // Als complement is gevonden — paar is gevonden
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Tijd: O(n), Ruimte: O(n)

De taak Two Sum — de populairste taak op interviews (volgens LeetCode meer dan 20 miljoen inzendingen). De oplossing in O(n) gebruikt HashMap: voor elk element controleren we of het verschil target - nums[i] al is voorgekomen. Zo ja — geven we de indices terug. Zo nee — slaan we het huidige element op in HashMap. De naïeve oplossing in O(n²) met twee geneste lussen wordt als niet-slagend beschouwd voor Senior-posities.

Vragen over mobiele ontwikkeling

Platformvragen op het interview van een mobiele ontwikkelaar worden verdeeld in drie blokken: fundamentele platformkennis, werken met UI en multithreading, netwerkverzoeken en gegevensopslag. Voor Android verplicht: levenscyclus van Activity en Fragment, verschillen Fragment v1 vs Fragment v2, ActivityResult API (vervanger van onActivityResult), ViewModel + StateFlow, Compose lifecycle. Voor iOS: levenscyclus van UIViewController, ARC (Automatic Reference Counting), DispatchQueue en OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Voorbeeldvraag: levenscyclus

Typische vraag: „Welke callbacks van de Activity-levenscyclus worden aangeroepen bij rotatie van het scherm?”. Juiste antwoord: onPause → onStop → onDestroy → onCreate → onStart → onResume. Aanvullende vraag: „Hoe bewaar je de toestand bij rotatie?” — via SavedStateHandle in ViewModel, onSaveInstanceState Bundle of rememberSaveable in Jetpack Compose. Voor iOS: „Wat gebeurt er met UIViewController bij het naar de achtergrond gaan?” — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Systeemontwerp van mobiele applicatie

System Design Interview voor een mobiele ontwikkelaar controleert het vermogen om de architectuur van een clientapplicatie en de interactie met de server te ontwerpen. Standaardtaken: ontwerpen van een nieuwsfeed (zoals Instagram/TikTok), chat (zoals Telegram), videospeler (zoals YouTube), cache van eerste niveau (L1 — in-memory, L2 — schijf). Duur — 60 minuten. Gestructureerd denken wordt beoordeeld, niet het aantal details.

Antwoordsjabloon voor System Design: 1) Clarify requirements — verduidelijken van functionele (feed, likes, reacties, foto-upload) en niet-functionele vereisten (offline, laadsnelheid, batterijverbruik). 2) High-level design — tekenen van het lagenmodel: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — detailleren van de belangrijkste componenten, bijvoorbeeld het paginering-mechanisme (Paging 3 voor Android, Offset-based vs Cursor-based voor iOS). 4) Trade-offs — bespreken van compromissen: cache vs versheid van gegevens, offline-first vs online-only.

Belangrijkste System Design-onderwerpen voor mobiel: caching (LRU Cache, Disk Cache met limiet), werken met afbeeldingen (Coil, Glide, SDWebImage — laden, cache, placeholder, voortgang), verkeersoptimalisatie (protobuf in plaats van JSON, compressie, Differ/GraphQL), offline werken (Room + Sync Adapter, Core Data + iCloud, WorkManager voor achtergrondsynchronisatie). Offline-first — een van de meest voorkomende onderwerpen voor Senior-posities.

Voor iOS worden vragen over App Thinning, Slicing, On-Demand Resources en build-optimalisatie toegevoegd. Voor Android — over R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery en Minification. De architectuurvraag „Hoe implementeer je een afbeeldingencache met geheugenlimiet?” controleert het begrip van LRU Cache (LinkedHashMap met access order), Disk LRU Cache (Jake Whartons DiskLruCache) en de Coil/Glide geheugencache-laag.

Voorbereidingsstrategie voor het interview

Voorbereiding op het interview vereist een systematische aanpak 4-8 weken voor het geplande interview. Basissstrategie: 2 weken voor herhaling van theorie (taal, platform, algoritmen), 2-4 weken voor het oplossen van algoritmische taken (100-300 taken op LeetCode), 1-2 weken voor mock-interviews (Pramp, interview.io, met vrienden). Voor Senior-posities wordt System Design-voorbereiding toegevoegd (2-3 weken). Het plan geeft 70-80% succesvolle doorloop op het doelniveau.

Voor mobiele ontwikkelaars omvat specifieke voorbereiding: lezen van Android Developers Guide / iOS Developer Library, analyse van broncode van populaire bibliotheken (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), schrijven van een pet-project met Clean Architecture en CI/CD (GitHub Actions, Fastlane). Schrijf een voorbeeldapplicatie op GitHub met modulaire architectuur, DI, tests (Unit + UI + Snapshot) — dit toont diepgaand begrip en wordt een argument op het interview.

Typische fouten van kandidaten

Fout 1: stil oplossen. De kandidaat schrijft code in stilte, zonder de gedachtegang te becommentariëren. De interviewer kan het oplossingsproces niet beoordelen. Juist: elke stap hardop uitspreken — „Ik zie dat de taak neerkomt op het zoeken in een grafiek. Ik stel voor om BFS te gebruiken omdat we het kortste pad moeten vinden”. Dergelijke communicatie geeft de interviewer de mogelijkheid om de kandidaat bij fouten te sturen, wat positief wordt beoordeeld.

Fout 2: meteen code schrijven. Beginnnen met coderen zonder verduidelijking van vereisten en bespreking van benaderingen — een van de belangrijkste oorzaken van falen. Voor het schrijven van code moet men: invoer/uitvoergegevens verduidelijken, randgevallen bespreken, 2-3 benaderingen vergelijken met Big O-beoordeling en pas na overleg met de interviewer de optimale oplossing schrijven. Juiste patroon: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Fout 3: onbekendheid met het platform. De kandidaat lost algoritmen uitstekend op, maar kan het verschil tussen Activity en Fragment of tussen weak/unowned in Swift niet uitleggen. Voor mobiele functies wordt platformkennis even belangrijk beoordeeld als algoritmen. Bestudeer: verschillen in SDK-versies (compileSdk vs minSdk vs targetSdk), ProGuard/R8-regels voor populaire bibliotheken, Swift Concurrency (async/await, actors) en MainActor. Elke derde kandidaat voor een iOS-functie faalt op vragen over ARC.