Come valutare i developer mobile: framework completo

Il problema dell'hiring mobile

L'hiring di developer mobile è più difficile di quello web o backend perché si frammenta tra piattaforme. Un specialista iOS e una specialista Android sono quasi funzioni lavorative diverse.

Layer 1: screen iniziale (30 min)

Inizia con una sfida di live coding su un problema realistico.

"Ecco un flusso di login rotto. Il bug: il session token non viene salvato dopo login riuscito. Trova e sistema in 30 min."

Cosa misuri: sanno leggere codice non familiare? Capiscono il state management della piattaforma? Possono localizzare il bug senza trial-and-error?

Layer 2: valutazione tecnica approfondita (90 min)

Take-home specifico all'area di focus.

Per iOS: view controller che fetcha da una mock API, gestisce errori, mostra risultati con paginazione, persiste lo stato.

Per Android: stesso problema in termini Android.

Per React Native: schermata che fetcha, gestisce loading/error.

Layer 3: walk-through (30 min)

Non opzionale. "Perché hai messo lo stato nel VC vs ViewModel? Cosa succede se la richiesta è pending e l'utente ruota il dispositivo? Come testeresti?"

Layer 4: system design (per senior+)

"Stai costruendo un'app di photo editing. Gli utenti caricano foto editate sul cloud. L'app deve funzionare offline. Portami attraverso la tua architettura."

Cosa NON fare

• Problemi stile LeetCode (irrelevanti per mobile)
• Trivia di piattaforma
• Take-home troppo aperto
• Saltare il walk-through

Aggiustare per livello

Junior: schermata semplice, focus su correttezza. Mid: state management, paginazione, test, edge case. Senior: vincoli di performance, pensiero architetturale.

Implementazione a scala

Piattaforma ClarityHire per setup tecnico.