Technický pohovor v mobilním vývoji: podstata průběhu, fáze a příprava

Co je technický pohovor v IT?

Technický pohovor — strukturovaný proces hodnocení profesionálních kompetencí vývojáře zahrnující kontrolu hard skills (technické znalosti) a soft skills (komunikace, týmová práce). Standardní cyklus pohovoru mobilního vývojáře trvá 3-5 kol o celkové délce 4-6 hodin. Procento úspěšného průchodu z počtu prvotních odpovědí činí 2-5 % u velkých technologických společností.

Proces náboru v mobilním vývoji se liší od webového vývoje: přidávají se otázky na specifika platformy — životní cyklus Activity/Fragment, ARC a správa paměti v Swiftu, threadingové modely (Main Thread, Dispatch Queue, Coroutines), práce se síťovými požadavky a ukládáním dat do mezipaměti. Android vývojář musí znát Jetpack Compose, Room, WorkManager, Dagger/Hilt. iOS vývojář — SwiftUI, Core Data, Combine, URLSession. Rozdíl v požadavcích roste s praxí: pro Senior pozice se přidává systémový návrh a architektura celé aplikace.

Struktura pohovoru závisí na úrovni. Pro Junior pozice stačí základní znalost jazyka a platformy (1-2 kola). Middle vývojář prochází 2-3 koly s blokem algoritmů. Senior pohovor zahrnuje 4-5 kol: algoritmy, architekturu mobilní aplikace, systémový návrh, behaviorální pohovor a závěrečný pohovor s VPE (Vice President of Engineering) nebo CTO.

Fáze technického pohovoru

HR screening — první fáze trvající 20-30 minut. Náborář kontroluje soulad zkušeností s požadavky pracovní pozice, diskutuje pracovní podmínky, platová očekávání a motivaci kandidáta. V této fázi je důležité jasně formulovat své zkušenosti: projekty, technologický stack, úspěchy v metrikách (zkrácení doby načítání, snížení crash rate, zrychlení kompilace). HR screening nekontroluje technické znalosti, ale vyřazuje až 40 % kandidátů kvůli nesouladu s formálními požadavky.

Po screeningu následuje algoritmický pohovor — klíčová fáze pro většinu společností. Délka — 45-90 minut. Kandidát dostane 1-2 úkoly na algoritmy a datové struktury. Řešení se píše na online tabuli (Codility, HackerRank, CoderPad) nebo na papír. Hodnotí se nejen správnost, ale také rychlost myšlení, schopnost klást upřesňující otázky a optimalizovat řešení. Podle interviewing.io (2025) 73 % kandidátů selhává právě v algoritmické fázi.

Architektonický pohovor

Architektonické kolo prověřuje schopnost navrhovat mobilní aplikace. Kandidát má za úkol navrhnout aplikaci (TODO seznam, messenger, agregátor zpráv, streamovací služba). Hodnotí se výběr architektonického vzoru (MVP, MVVM, MVI, VIPER), organizace vrstev (Presentation, Domain, Data), práce s DI (Dagger, Hilt, Swinject) a navigace. Pro Android — znalost Jetpack Navigation, pro iOS — vzor Coordinator a SwiftUI NavigationStack.

Na behaviorálním pohovoru se hodnotí soft skills: schopnost týmové práce, řešení konfliktů, argumentace rozhodnutí. Používá se metoda STAR (Situation, Task, Action, Result) — kandidát popisuje konkrétní situaci ze zkušenosti. Příklad otázky: „Povězte o nejtěžší chybě, kterou jste našli a opravili”. Závěrečné kolo s vedoucím týmu nebo VPE prověřuje strategické myšlení a kulturní soulad se společností.

Algoritmy a datové struktury na pohovoru

Algoritmické úkoly — povinná součást pohovorů ve velkých technologických společnostech (Google, Meta, Yandex, Tinkoff, Avito). Hlavním cílem je posouzení ability to solve (schopnost řešit problémy), nikoli znalost jazyka. Kandidát může použít libovolný programovací jazyk — přednost se dává Kotlin pro Android a Swift pro iOS. Typická témata: pole, hash tabulky, grafy, dynamické programování, stromy (Binary Tree, Trie, Segment Tree).

Podle LeetCode (2025) je pro jistý průchod algoritmickým pohovorem třeba vyřešit 250-400 úkolů. Klíčová témata podle četnosti výskytu: Two Pointers (12 %), Sliding Window (10 %), DFS/BFS na grafech (14 %), Binary Search (8 %), Dynamic Programming (18 %), Hash Map / Set (15 %). Big O notace — povinný prvek: kandidát musí vysvětlit časovou a prostorovou složitost svého řešení a navrhnout optimalizaci.

Příklad úkolu: Two Sum

// LeetCode 1: Two Sum — klasický HashMap problém
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Ulož complement = target - nums[i] a jeho index
    val map = mutableMapOf<Int, Int>()

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

        // Pokud je complement nalezen — dvojice nalezena
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Čas: O(n), Paměť: O(n)

Úkol Two Sum — nejoblíbenější úkol na pohovorech (podle LeetCode přes 20 milionů odeslání). Řešení v O(n) používá HashMap: pro každý prvek kontrolujeme, zda se rozdíl target - nums[i] již vyskytl. Pokud ano — vracíme indexy. Pokud ne — ukládáme aktuální prvek do HashMap. Naivní řešení v O(n²) se dvěma vnořenými cykly se pro Senior pozice považuje za nevyhovující.

Otázky z mobilního vývoje

Platformní otázky na pohovoru mobilního vývojáře se dělí do tří bloků: základní znalosti platformy, práce s UI a vícevláknovostí, síťové požadavky a ukládání dat. Pro Android povinné: životní cyklus Activity a Fragment, rozdíly Fragment v1 vs Fragment v2, ActivityResult API (náhrada za onActivityResult), ViewModel + StateFlow, Compose lifecycle. Pro iOS: životní cyklus UIViewController, ARC (Automatic Reference Counting), DispatchQueue a OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Příklad otázky: životní cyklus

Typická otázka: „Jaké callbacky životního cyklu Activity jsou volány při otáčení obrazovky?”. Správná odpověď: onPause → onStop → onDestroy → onCreate → onStart → onResume. Doplňující otázka: „Jak zachovat stav při otočení?” — přes SavedStateHandle ve ViewModel, onSaveInstanceState Bundle nebo rememberSaveable v Jetpack Compose. Pro iOS: „Co se děje s UIViewController při přechodu do pozadí?” — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Systémový návrh mobilní aplikace

System Design Interview pro mobilního vývojáře prověřuje schopnost navrhnout architekturu klientské aplikace a její interakci se serverem. Standardní úkoly: navrhnout zpravodajský feed (jako Instagram/TikTok), chat (jako Telegram), video přehrávač (jako YouTube), cache první úrovně (L1 — in-memory, L2 — disk). Délka — 60 minut. Hodnotí se strukturovanost myšlení, nikoli množství detailů.

Šablona odpovědi na System Design: 1) Clarify requirements — vyjasnit funkční (feed, lajky, komentáře, nahrávání fotografií) a nefunkční požadavky (offline, rychlost načítání, spotřeba baterie). 2) High-level design — nakreslit schéma vrstev: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — detailně rozpracovat klíčové komponenty, například mechanismus stránkování (Paging 3 pro Android, Offset-based vs Cursor-based pro iOS). 4) Trade-offs — diskutovat kompromisy: cache vs čerstvost dat, offline-first vs online-only.

Klíčová témata System Design pro mobil: ukládání do mezipaměti (LRU Cache, Disk Cache s limitem), práce s obrázky (Coil, Glide, SDWebImage — načítání, cache, placeholder, průběh), optimalizace provozu (protobuf místo JSON, komprese, Differ/GraphQL), offline práce (Room + Sync Adapter, Core Data + iCloud, WorkManager pro synchronizaci na pozadí). Offline-first — jedno z nejčastějších témat pro Senior pozice.

Pro iOS se přidávají otázky o App Thinning, Slicing, On-Demand Resources a optimalizaci buildu. Pro Android — o R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery a Minification. Architektonická otázka „Jak implementovat cache obrázků s omezením paměti?” prověřuje pochopení LRU Cache (LinkedHashMap s access order), Disk LRU Cache (DiskLruCache Jakea Whartona) a vrstvy paměťové cache Coil/Glide.

Strategie přípravy na pohovor

Příprava na pohovor vyžaduje systematický přístup 4-8 týdnů před plánovaným pohovorem. Základní strategie: 2 týdny na opakování teorie (jazyk, platforma, algoritmy), 2-4 týdny na řešení algoritmických úkolů (100-300 úkolů na LeetCode), 1-2 týdny na mock pohovory (Pramp, interview.io, s přáteli). Pro Senior pozice se přidává příprava System Design (2-3 týdny). Plán poskytuje 70-80% úspěšný průchod na cílové úrovni.

Pro mobilní vývojáře specifická příprava zahrnuje: čtení Android Developers Guide / iOS Developer Library, analýzu zdrojového kódu populárních knihoven (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), psaní pet-projektu s Clean Architecture a CI/CD (GitHub Actions, Fastlane). Napište ukázkovou aplikaci na GitHub s modulární architekturou, DI, testy (Unit + UI + Snapshot) — to ukáže hluboké porozumění a bude argumentem na pohovoru.

Typické chyby kandidátů

Chyba 1: tiché řešení. Kandidát píše kód mlčky, nekomentuje tok myšlenek. Tazatel nemůže posoudit proces řešení. Správně: každý krok říkat nahlas — „Vidím, že úkol se redukuje na prohledávání grafu. Navrhuji použít BFS, protože potřebujeme najít nejkratší cestu”. Taková komunikace dává tazateli možnost nasměrovat kandidáta při chybě, což je hodnoceno pozitivně.

Chyba 2: okamžité psaní kódu. Začít kódovat bez vyjasnění požadavků a diskuse přístupů — jeden z hlavních důvodů neúspěchu. Před napsáním kódu je třeba: vyjasnit vstupní/výstupní data, diskutovat okrajové případy, porovnat 2-3 přístupy s hodnocením Big O a teprve po dohodě s tazatelem napsat optimální řešení. Správný vzor: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Chyba 3: neznalost platformy. Kandidát výborně řeší algoritmy, ale neumí vysvětlit rozdíl mezi Activity a Fragment nebo mezi weak/unowned v Swiftu. U mobilních pozic jsou znalosti platformy hodnoceny stejně jako algoritmy. Prostudujte: rozdíly verzí SDK (compileSdk vs minSdk vs targetSdk), pravidla ProGuard/R8 pro populární knihovny, Swift Concurrency (async/await, actors) a MainActor. Každý třetí kandidát na iOS pozici selhává na otázkách o ARC.