Interviul tehnic în dezvoltarea mobilă: esența desfășurării, etape și pregătire

Ce este interviul tehnic în IT?

Interviul tehnic — un proces structurat de evaluare a competențelor profesionale ale dezvoltatorului, incluzând verificarea hard skills (cunoștințe tehnice) și soft skills (comunicare, lucru în echipă). Ciclul standard de interviu al unui dezvoltator mobil durează 3-5 runde cu o durată totală de 4-6 ore. Procentul de promovare din numărul de răspunsuri primare este de 2-5% în companiile mari de tehnologie.

Procesul de angajare în dezvoltarea mobilă diferă de dezvoltarea web: se adaugă întrebări legate de specificul platformei — ciclul de viață Activity/Fragment, ARC și gestionarea memoriei în Swift, modelele de threading (Main Thread, Dispatch Queue, Coroutines), lucrul cu solicitări de rețea și stocarea în cache a datelor. Dezvoltatorul Android trebuie să cunoască Jetpack Compose, Room, WorkManager, Dagger/Hilt. Dezvoltatorul iOS — SwiftUI, Core Data, Combine, URLSession. Diferența în cerințe crește cu experiența: pentru pozițiile Senior se adaugă designul de sistem și arhitectura întregii aplicații.

Structura interviului depinde de nivel. Pentru pozițiile Junior sunt suficiente cunoștințele de bază ale limbajului și platformei (1-2 runde). Dezvoltatorul Middle trece prin 2-3 runde cu un bloc de algoritmi. Interviul Senior include 4-5 runde: algoritmi, arhitectura aplicației mobile, design de sistem, interviu comportamental și interviul final cu VPE (Vice President of Engineering) sau CTO.

Etapele interviului tehnic

Screening HR — prima etapă cu durata de 20-30 de minute. Recrutorul verifică conformitatea experienței cu cerințele postului, discută condițiile de muncă, așteptările salariale și motivația candidatului. În această etapă este important să vă formulați clar experiența: proiecte, stiva de tehnologii, realizări în metrici (reducerea timpului de încărcare, scăderea ratei de crash, accelerarea compilării). Screening-ul HR nu verifică cunoștințele tehnice, dar elimină până la 40% dintre candidați din cauza neconformității cu cerințele formale.

După screening urmează interviul algoritmic — etapa cheie pentru majoritatea companiilor. Durata — 45-90 de minute. Candidatul primește 1-2 sarcini de algoritmi și structuri de date. Soluția se scrie pe o tablă online (Codility, HackerRank, CoderPad) sau pe hârtie. Se evaluează nu doar corectitudinea, ci și viteza de gândire, abilitatea de a pune întrebări clarificatoare și de a optimiza soluția. Conform interviewing.io (2025), 73% dintre candidați eșuează tocmai la etapa algoritmică.

Interviul arhitectural

Runda arhitecturală verifică abilitatea de a proiecta aplicații mobile. Candidatului i se propune să proiecteze o aplicație (listă TODO, mesager, agregator de știri, serviciu de streaming). Se evaluează alegerea modelului arhitectural (MVP, MVVM, MVI, VIPER), organizarea straturilor (Presentation, Domain, Data), lucrul cu DI (Dagger, Hilt, Swinject) și navigația. Pentru Android — cunoașterea Jetpack Navigation, pentru iOS — modelul Coordinator și SwiftUI NavigationStack.

La interviul comportamental se evaluează soft skills: abilitatea de a lucra în echipă, de a rezolva conflicte, de a argumenta deciziile. Se folosește metoda STAR (Situation, Task, Action, Result) — candidatul descrie o situație concretă din experiență. Exemplu de întrebare: „Povestește despre cea mai dificilă eroare pe care ai găsit-o și ai reparat-o”. Runda finală cu liderul echipei sau VPE verifică gândirea strategică și potrivirea culturală cu compania.

Algoritmi și structuri de date la interviu

Sarcinile algoritmice — o componentă obligatorie a interviurilor în companiile mari de tehnologie (Google, Meta, Yandex, Tinkoff, Avito). Scopul principal este evaluarea ability to solve (capacitatea de a rezolva probleme), nu cunoașterea limbajului. Candidatul poate folosi orice limbaj de programare — preferința se acordă Kotlin pentru Android și Swift pentru iOS. Temele tipice: array-uri, tabele hash, grafuri, programare dinamică, arbori (Binary Tree, Trie, Segment Tree).

Conform datelor LeetCode (2025), pentru o promovare sigură a interviului algoritmic este necesar să se rezolve 250-400 de sarcini. Temele cheie după frecvența apariției: Two Pointers (12%), Sliding Window (10%), DFS/BFS pe grafuri (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). Notația Big O — element obligatoriu: candidatul trebuie să explice complexitatea temporală și spațială a soluției sale și să propună optimizarea.

Sarcină exemplu: Two Sum

// LeetCode 1: Two Sum — problema HashMap clasică
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Stochează complement = target - nums[i] și indexul său
    val map = mutableMapOf<Int, Int>()

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

        // Dacă complementul este găsit — perechea este găsită
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Timp: O(n), Spațiu: O(n)

Sarcina Two Sum — cea mai populară sarcină la interviuri (conform LeetCode, peste 20 de milioane de trimiteri). Soluția în O(n) folosește HashMap: pentru fiecare element verificăm dacă diferența target - nums[i] a mai apărut. Dacă da — returnăm indicii. Dacă nu — salvăm elementul curent în HashMap. Soluția naivă în O(n²) cu două bucle imbricate este considerată nepromovabilă pentru pozițiile Senior.

Întrebări de dezvoltare mobilă

Întrebările de platformă la interviul dezvoltatorului mobil se împart în trei blocuri: cunoștințe fundamentale ale platformei, lucrul cu UI și multi-threading, solicitări de rețea și stocare a datelor. Pentru Android obligatorii: ciclul de viață Activity și Fragment, diferențele Fragment v1 vs Fragment v2, ActivityResult API (înlocuitor pentru onActivityResult), ViewModel + StateFlow, Compose lifecycle. Pentru iOS: ciclul de viață UIViewController, ARC (Automatic Reference Counting), DispatchQueue și OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Întrebare exemplu: ciclul de viață

Întrebarea tipică: „Ce callback-uri ale ciclului de viață Activity sunt apelate la rotirea ecranului?”. Răspunsul corect: onPause → onStop → onDestroy → onCreate → onStart → onResume. Întrebarea suplimentară: „Cum se salvează starea la rotire?” — prin SavedStateHandle în ViewModel, onSaveInstanceState Bundle sau rememberSaveable în Jetpack Compose. Pentru iOS: „Ce se întâmplă cu UIViewController la trecerea în fundal?” — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Design de sistem al aplicației mobile

System Design Interview pentru dezvoltatorul mobil verifică abilitatea de a proiecta arhitectura aplicației client și interacțiunea acesteia cu serverul. Sarcini standard: proiectarea unui flux de știri (ca Instagram/TikTok), chat (ca Telegram), player video (ca YouTube), cache de prim nivel (L1 — in-memory, L2 — disc). Durata — 60 de minute. Se evaluează structurarea gândirii, nu cantitatea de detalii.

Șablonul de răspuns pentru System Design: 1) Clarify requirements — clarificarea cerințelor funcționale (flux, like-uri, comentarii, încărcare foto) și nefuncționale (offline, viteza de încărcare, consumul bateriei). 2) High-level design — desenarea schemei straturilor: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — detalierea componentelor cheie, de exemplu mecanismul de paginare (Paging 3 pentru Android, Offset-based vs Cursor-based pentru iOS). 4) Trade-offs — discutarea compromisurilor: cache vs prospețimea datelor, offline-first vs online-only.

Temele cheie ale System Design pentru mobil: stocarea în cache (LRU Cache, Disk Cache cu limită), lucrul cu imagini (Coil, Glide, SDWebImage — încărcare, cache, placeholder, progres), optimizarea traficului (protobuf în loc de JSON, compresie, Differ/GraphQL), lucrul offline (Room + Sync Adapter, Core Data + iCloud, WorkManager pentru sincronizare în fundal). Offline-first — una dintre cele mai frecvente teme pentru pozițiile Senior.

Pentru iOS se adaugă întrebări despre App Thinning, Slicing, On-Demand Resources și optimizarea build-ului. Pentru Android — despre R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery și Minification. Întrebarea arhitecturală „Cum se implementează un cache de imagini cu limită de memorie?” verifică înțelegerea LRU Cache (LinkedHashMap cu access order), Disk LRU Cache (DiskLruCache a lui Jake Wharton) și stratul de cache de memorie Coil/Glide.

Strategia de pregătire pentru interviu

Pregătirea pentru interviu necesită o abordare sistematică cu 4-8 săptămâni înainte de interviul planificat. Strategia de bază: 2 săptămâni pentru recapitularea teoriei (limbaj, platformă, algoritmi), 2-4 săptămâni pentru rezolvarea sarcinilor algoritmice (100-300 de sarcini pe LeetCode), 1-2 săptămâni pentru interviuri simulate (Pramp, interview.io, cu prieteni). Pentru pozițiile Senior se adaugă pregătirea System Design (2-3 săptămâni). Planul oferă 70-80% promovare cu succes la nivelul țintă.

Pentru dezvoltatorii mobili, pregătirea specifică include: citirea Android Developers Guide / iOS Developer Library, analiza codului sursă al bibliotecilor populare (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), scrierea unui proiect personal cu Clean Architecture și CI/CD (GitHub Actions, Fastlane). Scrieți o aplicație exemplu pe GitHub cu arhitectură modulară, DI, teste (Unit + UI + Snapshot) — aceasta va demonstra o înțelegere profundă și va fi un argument la interviu.

Greșeli tipice ale candidaților

Greșeala 1: rezolvarea tăcută. Candidatul scrie codul în tăcere, fără a comenta firul gândirii. Intervievatorul nu poate evalua procesul de rezolvare. Corect: rostiți fiecare pas cu voce tare — „Văd că sarcina se reduce la căutarea într-un graf. Propun să folosesc BFS pentru că trebuie să găsim cel mai scurt drum”. O astfel de comunicare îi oferă intervievatorului posibilitatea de a direcționa candidatul în caz de eroare, ceea ce este evaluat pozitiv.

Greșeala 2: scrierea imediată a codului. Începerea codării fără clarificarea cerințelor și discutarea abordărilor — una dintre principalele cauze de eșec. Înainte de a scrie codul, trebuie: clarificate datele de intrare/ieșire, discutate cazurile limită, comparate 2-3 abordări cu evaluarea Big O și abia după acordul cu intervievatorul scrisă soluția optimă. Modelul corect: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Greșeala 3: necunoașterea platformei. Candidatul rezolvă excelent algoritmii, dar nu poate explica diferența dintre Activity și Fragment sau dintre weak/unowned în Swift. Pentru posturile mobile, cunoștințele de platformă sunt evaluate la fel ca algoritmii. Studiați: diferențele versiunilor SDK (compileSdk vs minSdk vs targetSdk), regulile ProGuard/R8 pentru bibliotecile populare, Swift Concurrency (async/await, actors) și MainActor. Fiecare al treilea candidat la poziția iOS eșuează la întrebările despre ARC.