Il sobes nello sviluppo mobile: come si svolge, le fasi e la preparazione

Cos'è il sobes in IT?

Il colloquio tecnico (sobes) — processo strutturato di valutazione delle competenze professionali di uno sviluppatore, che comprende la verifica delle hard skills (conoscenze tecniche) e delle soft skills (comunicazione, lavoro di squadra). Il ciclo standard di colloquio di uno sviluppatore mobile dura 3-5 round per un totale di 4-6 ore. La percentuale di superamento rispetto al numero di risposte iniziali è del 2-5% nelle grandi aziende tecnologiche.

Il processo di assunzione nello sviluppo mobile differisce dallo sviluppo web: si aggiungono domande sulle specificità della piattaforma — ciclo di vita di Activity/Fragment, ARC e gestione della memoria in Swift, modelli di threading (Main Thread, Dispatch Queue, Coroutines), gestione delle richieste di rete e della cache dei dati. Uno sviluppatore Android deve conoscere Jetpack Compose, Room, WorkManager, Dagger/Hilt. Uno sviluppatore iOS — SwiftUI, Core Data, Combine, URLSession. La differenza nei requisiti cresce con l'esperienza: per le posizioni Senior si aggiungono il system design e l'architettura dell'intera applicazione.

La struttura del colloquio dipende dal livello. Per le posizioni Junior basta la conoscenza di base del linguaggio e della piattaforma (1-2 round). Uno sviluppatore Middle affronta 2-3 round con un blocco di algoritmi. Il sobes Senior comprende 4-5 round: algoritmi, architettura dell'applicazione mobile, system design, colloquio comportamentale e colloquio finale con il VPE (Vice President of Engineering) o il CTO.

Fasi del colloquio tecnico

Lo screening HR — prima fase della durata di 20-30 minuti. Il recruiter verifica la corrispondenza dell'esperienza ai requisiti della posizione, discute le condizioni di lavoro, le aspettative salariali e la motivazione del candidato. In questa fase è importante formulare chiaramente la propria esperienza: progetti, stack tecnologico, risultati misurabili (riduzione del tempo di caricamento, diminuzione del crash rate, accelerazione della build). Lo screening HR non verifica le conoscenze tecniche, ma elimina fino al 40% dei candidati che non corrispondono ai requisiti formali.

Dopo lo screening segue il colloquio algoritmico — fase chiave per la maggior parte delle aziende. Durata: 45-90 minuti. Al candidato vengono assegnati 1-2 problemi su algoritmi e strutture dati. La soluzione si scrive su una lavagna online (Codility, HackerRank, CoderPad) o su carta. Si valuta non solo la correttezza, ma anche la velocità di pensiero, la capacità di porre domande di chiarimento e di ottimizzare la soluzione. Secondo interviewing.io (2025), il 73% dei candidati fallisce proprio nella fase algoritmica.

Colloquio di architettura

Il round architetturale verifica la capacità di progettare applicazioni mobile. Al candidato viene proposto di progettare un'applicazione (lista TODO, messenger, aggregatore di notizie, servizio di streaming). Si valuta la scelta del pattern architetturale (MVP, MVVM, MVI, VIPER), l'organizzazione dei layer (Presentation, Domain, Data), la gestione della DI (Dagger, Hilt, Swinject) e la navigazione. Per Android — conoscenza di Jetpack Navigation, per iOS — pattern Coordinator e SwiftUI NavigationStack.

Al colloquio comportamentale si valutano le soft skills: capacità di lavorare in team, risolvere conflitti, argomentare le decisioni. Si usa il metodo STAR (Situation, Task, Action, Result) — il candidato descrive una situazione concreta della propria esperienza. Esempio di domanda: «Racconti del bug più complesso che ha trovato e corretto». Il round finale con il team lead o il VPE verifica il pensiero strategico e l'adattamento culturale all'azienda.

Algoritmi e strutture dati al colloquio

I problemi algoritmici — componente obbligatoria dei colloqui nelle grandi aziende tecnologiche (Google, Meta, Yandex, Tinkoff, Avito). L'obiettivo principale è valutare l'ability to solve (capacità di risolvere problemi), non la conoscenza del linguaggio. Al candidato è consentito usare qualsiasi linguaggio di programmazione — la preferenza va a Kotlin per Android e Swift per iOS. Temi tipici: array, tabelle hash, grafi, programmazione dinamica, alberi (Binary Tree, Trie, Segment Tree).

Secondo LeetCode (2025), per superare con sicurezza il colloquio algoritmico è necessario risolvere 250-400 problemi. Temi chiave per frequenza: Two Pointers (12%), Sliding Window (10%), DFS/BFS sui grafi (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). La notazione Big O — elemento obbligatorio: il candidato deve spiegare la complessità temporale e spaziale della propria soluzione e proporre un'ottimizzazione.

Esempio di problema: Two Sum

// LeetCode 1: Two Sum — classico problema con HashMap
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Salva il complemento = target - nums[i] e il suo indice
    val map = mutableMapOf<Int, Int>()

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

        // Se il complemento viene trovato — coppia trovata
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Tempo: O(n), Spazio: O(n)

Il problema Two Sum — il problema più popolare ai colloqui (secondo LeetCode, oltre 20 milioni di invii). La soluzione in O(n) usa una HashMap: per ogni elemento verifichiamo se la differenza target - nums[i] è già stata incontrata. Se sì — restituiamo gli indici. Se no — salviamo l'elemento corrente nella HashMap. La soluzione ingenua in O(n²) con due cicli annidati è considerata insufficiente per le posizioni Senior.

Domande sullo sviluppo mobile

Le domande di piattaforma al colloquio di uno sviluppatore mobile si dividono in tre blocchi: conoscenze fondamentali della piattaforma, lavoro con la UI e il multithreading, richieste di rete e archiviazione dei dati. Per Android, obbligatori: ciclo di vita di Activity e Fragment, differenze Fragment v1 vs Fragment v2, ActivityResult API (sostituto di onActivityResult), ViewModel + StateFlow, ciclo di vita di Compose. Per iOS: ciclo di vita di UIViewController, ARC (Automatic Reference Counting), DispatchQueue e OperationQueue, ciclo di vita di SwiftUI (View — @State — @Binding — @ObservedObject).

Esempio di domanda: ciclo di vita

Domanda tipica: «Quali callback del ciclo di vita di Activity vengono chiamati alla rotazione dello schermo?». Risposta corretta: onPause → onStop → onDestroy → onCreate → onStart → onResume. Domanda supplementare: «Come salvare lo stato alla rotazione?» — tramite SavedStateHandle nel ViewModel, onSaveInstanceState Bundle o rememberSaveable in Jetpack Compose. Per iOS: «Cosa succede a UIViewController quando l'app va in background?» — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

System design di un'applicazione mobile

L'intervista System Design per uno sviluppatore mobile verifica la capacità di progettare l'architettura di un'applicazione client e la sua interazione con il server. Problemi standard: progettare un feed di notizie (come Instagram/TikTok), una chat (come Telegram), un video player (come YouTube), una cache di primo livello (L1 — in-memory, L2 — disco). Durata: 60 minuti. Si valuta la strutturazione del pensiero, non la quantità di dettagli.

Modello di risposta al System Design: 1) Clarify requirements — chiarire i requisiti funzionali (feed, like, commenti, caricamento di foto) e non funzionali (offline, velocità di caricamento, consumo della batteria). 2) High-level design — disegnare lo schema dei layer: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — dettagliare i componenti chiave, ad esempio il meccanismo di paginazione (Paging 3 per Android, Offset-based vs Cursor-based per iOS). 4) Trade-offs — discutere i compromessi: cache vs freschezza dei dati, offline-first vs online-only.

Temi chiave del System Design per mobile: caching (LRU Cache, Disk Cache con limite), lavoro con le immagini (Coil, Glide, SDWebImage — caricamento, cache, placeholder, progresso), ottimizzazione del traffico (protobuf invece di JSON, compressione, Differ/GraphQL), lavoro offline (Room + Sync Adapter, Core Data + iCloud, WorkManager per la sincronizzazione in background). Offline-first — uno dei temi più frequenti per le posizioni Senior.

Per iOS si aggiungono domande su App Thinning, Slicing, On-Demand Resources e ottimizzazione della build. Per Android — su R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery e Minification. La domanda architetturale «Come implementare una cache di immagini con limite di memoria?» verifica la comprensione della LRU Cache (LinkedHashMap con access order), della Disk LRU Cache (DiskLruCache di Jake Wharton) e del layer di cache in memoria di Coil/Glide.

Strategia di preparazione al colloquio

La preparazione al colloquio richiede un approccio sistematico 4-8 settimane prima del colloquio previsto. Strategia di base: 2 settimane per ripassare la teoria (linguaggio, piattaforma, algoritmi), 2-4 settimane per risolvere problemi algoritmici (100-300 problemi su LeetCode), 1-2 settimane per i colloqui simulati (Pramp, interview.io, con amici). Per le posizioni Senior si aggiunge la preparazione al System Design (2-3 settimane). Il piano dà il 70-80% di probabilità di superare il livello target.

Per gli sviluppatori mobile la preparazione specifica comprende: la lettura di Android Developers Guide / iOS Developer Library, l'analisi del codice sorgente delle librerie popolari (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), la scrittura di un progetto personale con Clean Architecture e CI/CD (GitHub Actions, Fastlane). Scrivete un'applicazione di esempio su GitHub con architettura modulare, DI, test (Unit + UI + Snapshot) — questo mostrerà una comprensione profonda e servirà da argomento al colloquio.

Errori tipici dei candidati

Errore 1: risolvere in silenzio. Il candidato scrive il codice in silenzio, senza commentare il proprio ragionamento. L'intervistatore non può valutare il processo di risoluzione. Corretto: verbalizzare ogni passo — «Vedo che il problema si riduce a una ricerca su un grafo. Propongo di usare BFS, perché bisogna trovare il percorso più breve». Questa comunicazione dà all'intervistatore la possibilità di guidare il candidato in caso di errore, il che viene valutato positivamente.

Errore 2: scrivere subito il codice. Iniziare a codificare senza chiarire i requisiti e discutere gli approcci — una delle principali cause di fallimento. Prima di scrivere il codice bisogna: chiarire i dati di input/output, discutere i corner cases, confrontare 2-3 approcci con la stima della Big O e solo dopo l'accordo con l'intervistatore scrivere la soluzione ottimale. Pattern corretto: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Errore 3: non conoscere la piattaforma. Il candidato risolve perfettamente gli algoritmi, ma non sa spiegare la differenza tra Activity e Fragment o tra weak/unowned in Swift. Per le posizioni mobile le conoscenze di piattaforma sono valutate alla pari degli algoritmi. Studiate: le differenze delle versioni dell'SDK (compileSdk vs minSdk vs targetSdk), le regole ProGuard/R8 per le librerie popolari, Swift Concurrency (async/await, actors) e MainActor. Un candidato su tre per una posizione iOS fallisce sulle domande sull'ARC.