Teknisk intervju inom mobilutveckling: genomförandets essens, steg och förberedelse

Vad är en teknisk intervju inom IT?

Teknisk intervju — en strukturerad process för utvärdering av en utvecklares professionella kompetenser, inklusive kontroll av hard skills (teknisk kunskap) och soft skills (kommunikation, teamarbete). Standardintervjucykeln för en mobilutvecklare varar 3-5 rundor med en total varaktighet på 4-6 timmar. Andelen framgångsrika genomföranden av antalet primära svar är 2-5% hos stora teknikföretag.

Rekryteringsprocessen inom mobilutveckling skiljer sig från webbutveckling: frågor om plattformsspecifikationer läggs till — livscykel för Activity/Fragment, ARC och minneshantering i Swift, threadingmodeller (Main Thread, Dispatch Queue, Coroutines), arbete med nätverksförfrågningar och datacachning. Android-utvecklare måste kunna Jetpack Compose, Room, WorkManager, Dagger/Hilt. iOS-utvecklare — SwiftUI, Core Data, Combine, URLSession. Skillnaden i krav ökar med erfarenhet: för Senior-positioner läggs systemdesign och arkitektur för hela applikationen till.

Intervjuns struktur beror på nivån. För Junior-positioner räcker grundläggande kunskaper i språk och plattform (1-2 rundor). Middle-utvecklare går igenom 2-3 rundor med ett algoritmblock. Senior-intervju omfattar 4-5 rundor: algoritmer, mobilapplikationsarkitektur, systemdesign, beteendeintervju och slutintervju med VPE (Vice President of Engineering) eller CTO.

Steg i den tekniska intervjun

HR-screening — första steget som varar 20-30 minuter. Rekryteraren kontrollerar om erfarenheten matchar jobbkraven, diskuterar arbetsvillkor, löneförväntningar och kandidatens motivation. I detta steg är det viktigt att tydligt formulera sin erfarenhet: projekt, teknikstack, prestationer i mätvärden (minskning av laddningstid, minskning av crash rate, snabbare kompilering). HR-screening kontrollerar inte teknisk kunskap, men sållar bort upp till 40% av kandidaterna på grund av bristande överensstämmelse med formella krav.

Efter screening följer algoritmisk intervju — nyckelfasen för de flesta företag. Varaktighet — 45-90 minuter. Kandidaten får 1-2 uppgifter om algoritmer och datastrukturer. Lösningen skrivs på en online-tavla (Codility, HackerRank, CoderPad) eller på papper. Inte bara korrekthet bedöms, utan även tankehastighet, förmåga att ställa förtydligande frågor och optimera lösningen. Enligt interviewing.io (2025) misslyckas 73% av kandidaterna just i den algoritmiska fasen.

Arkitekturintervju

Arkitekturrunda kontrollerar förmågan att designa mobilapplikationer. Kandidaten får i uppgift att designa en applikation (TODO-lista, messenger, nyhetsaggregator, streamingtjänst). Man bedömer val av arkitekturmönster (MVP, MVVM, MVI, VIPER), organisering av lager (Presentation, Domain, Data), arbete med DI (Dagger, Hilt, Swinject) och navigation. För Android — kunskap om Jetpack Navigation, för iOS — Coordinator-mönster och SwiftUI NavigationStack.

I beteendeintervjun bedöms soft skills: förmåga att arbeta i team, lösa konflikter, argumentera beslut. STAR-metoden (Situation, Task, Action, Result) används — kandidaten beskriver en konkret situation från erfarenhet. Exempelfråga: „Berätta om den svåraste buggen du hittade och åtgärdade”. Slutrunda med teamledare eller VPE kontrollerar strategiskt tänkande och kulturell passform med företaget.

Algoritmer och datastrukturer på intervjun

Algoritmiska uppgifter — en obligatorisk komponent av intervjuer hos stora teknikföretag (Google, Meta, Yandex, Tinkoff, Avito). Huvudsyftet är att bedöma ability to solve (förmåga att lösa problem), inte språkkunskap. Kandidaten kan använda vilket programmeringsspråk som helst — företräde ges till Kotlin för Android och Swift för iOS. Typiska ämnen: arrayer, hashtabeller, grafer, dynamisk programmering, träd (Binary Tree, Trie, Segment Tree).

Enligt LeetCode (2025) krävs det för en säker genomgång av den algoritmiska intervjun att man löser 250-400 uppgifter. Nyckelämnen efter förekomstfrekvens: Two Pointers (12%), Sliding Window (10%), DFS/BFS på grafer (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). Big O-notation — obligatoriskt element: kandidaten måste förklara tids- och rumskomplexiteten för sin lösning och föreslå optimering.

Exempeluppgift: Two Sum

// LeetCode 1: Two Sum — klassiskt HashMap-problem
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Lagra complement = target - nums[i] och dess index
    val map = mutableMapOf<Int, Int>()

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

        // Om complement hittas — par hittat
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Tid: O(n), Minne: O(n)

Uppgiften Two Sum — den mest populära uppgiften på intervjuer (enligt LeetCode över 20 miljoner insändningar). Lösningen i O(n) använder HashMap: för varje element kontrollerar vi om skillnaden target - nums[i] redan har förekommit. Om ja — returnera indexen. Om nej — spara det aktuella elementet i HashMap. Den naiva lösningen i O(n²) med två nästlade loopar anses inte godkänd för Senior-positioner.

Frågor om mobilutveckling

Plattformsfrågor på mobilutvecklarintervjun delas in i tre block: grundläggande plattformskunskap, arbete med UI och flertrådning, nätverksförfrågningar och datalagring. För Android obligatoriskt: livscykel för Activity och Fragment, skillnader Fragment v1 vs Fragment v2, ActivityResult API (ersättare för onActivityResult), ViewModel + StateFlow, Compose lifecycle. För iOS: livscykel för UIViewController, ARC (Automatic Reference Counting), DispatchQueue och OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Exempelfråga: livscykel

Typisk fråga: „Vilka callbacks i Activitys livscykel anropas vid skärmrotation?”. Rätt svar: onPause → onStop → onDestroy → onCreate → onStart → onResume. Följdfråga: „Hur bevarar man tillstånd vid rotation?” — via SavedStateHandle i ViewModel, onSaveInstanceState Bundle eller rememberSaveable i Jetpack Compose. För iOS: „Vad händer med UIViewController vid övergång till bakgrunden?” — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Systemdesign av mobilapplikation

System Design Interview för mobilutvecklare kontrollerar förmågan att designa arkitekturen för en klientapplikation och dess interaktion med servern. Standarduppgifter: designa en nyhetsfeed (som Instagram/TikTok), chat (som Telegram), videospelare (som YouTube), cache på första nivån (L1 — in-memory, L2 — disk). Varaktighet — 60 minuter. Strukturerat tänkande bedöms, inte mängden detaljer.

Svarsmall för System Design: 1) Clarify requirements — förtydliga funktionella (feed, gillamarkeringar, kommentarer, fotouppladdning) och icke-funktionella krav (offline, laddningshastighet, batteriförbrukning). 2) High-level design — rita lagerschema: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — detaljera nyckelkomponenter, till exempel paginering-mekanism (Paging 3 för Android, Offset-based vs Cursor-based för iOS). 4) Trade-offs — diskutera kompromisser: cache vs datans färskhet, offline-first vs online-only.

Nyckelämnen för System Design inom mobil: cachning (LRU Cache, Disk Cache med begränsning), arbete med bilder (Coil, Glide, SDWebImage — laddning, cache, placeholder, förlopp), trafikoptimering (protobuf istället för JSON, komprimering, Differ/GraphQL), offlinearbete (Room + Sync Adapter, Core Data + iCloud, WorkManager för bakgrundssynkronisering). Offline-first — ett av de vanligaste ämnena för Senior-positioner.

För iOS läggs frågor till om App Thinning, Slicing, On-Demand Resources och build-optimering. För Android — om R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery och Minification. Arkitekturfrågan „Hur implementerar man en bildcache med minnesbegränsning?” kontrollerar förståelsen av LRU Cache (LinkedHashMap med access order), Disk LRU Cache (Jake Whartons DiskLruCache) och Coil/Glide minnescachelager.

Förberedelsestrategi för intervjun

Förberedelse inför intervjun kräver ett systematiskt tillvägagångssätt 4-8 veckor före den planerade intervjun. Grundstrategi: 2 veckor för repetition av teori (språk, plattform, algoritmer), 2-4 veckor för att lösa algoritmiska uppgifter (100-300 uppgifter på LeetCode), 1-2 veckor för mock-intervjuer (Pramp, interview.io, med vänner). För Senior-positioner läggs System Design-förberedelse till (2-3 veckor). Planen ger 70-80% framgångsrikt genomförande på målnivån.

För mobilutvecklare omfattar specifik förberedelse: läsning av Android Developers Guide / iOS Developer Library, analys av källkod för populära bibliotek (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), skrivning av ett pet-projekt med Clean Architecture och CI/CD (GitHub Actions, Fastlane). Skriv en exempelapplikation på GitHub med modulär arkitektur, DI, tester (Unit + UI + Snapshot) — detta visar djup förståelse och blir ett argument på intervjun.

Typiska misstag hos kandidater

Misstag 1: tyst lösning. Kandidaten skriver kod tyst, kommenterar inte tankegången. Intervjuaren kan inte bedöma lösningsprocessen. Rätt: uttala varje steg högt — „Jag ser att uppgiten handlar om sökning i en graf. Jag föreslår att använda BFS eftersom vi behöver hitta den kortaste vägen”. Sådan kommunikation ger intervjuaren möjlighet att vägleda kandidaten vid fel, vilket bedöms positivt.

Misstag 2: omedelbar kodskrivning. Att börja koda utan att förtydliga krav och diskutera tillvägagångssätt — en av huvudorsakerna till misslyckande. Innan kod skrivs måste man: förtydliga in-/utdata, diskutera kantfall, jämföra 2-3 tillvägagångssätt med Big O-bedömning och först efter överenskommelse med intervjuaren skriva den optimala lösningen. Rätt mönster: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Misstag 3: okunskap om plattformen. Kandidaten löser algoritmer utmärkt men kan inte förklara skillnaden mellan Activity och Fragment eller mellan weak/unowned i Swift. För mobilpositioner bedöms plattformskunskap lika mycket som algoritmer. Studera: skillnader i SDK-versioner (compileSdk vs minSdk vs targetSdk), ProGuard/R8-regler för populära bibliotek, Swift Concurrency (async/await, actors) och MainActor. Var tredje kandidat för iOS-position misslyckas på frågor om ARC.