Test Mobile Developer Domande Esempio: Cosa Chiedere

Perché le domande di esempio importano

La maggior parte delle valutazioni di mobile developer sono costruite male. O si inclinano su trivia (qual è il nome del metodo del lifecycle in Android 11?) o sono così open-ended che crollano sotto il loro peso. Le giuste domande di esempio stanno nel mezzo: specifiche abbastanza per essere graded, broad abbastanza per rivelare giudizio.

Se stai costruendo una valutazione mobile da zero, sapere quale tipo di domande funzionano è metà della battaglia. Ecco i pattern che effettivamente predicono la job performance.

Domande specifiche iOS

1. View controller lifecycle con stato

"Una login screen carica. Al primo render, fetches la auth session dal keychain. Se la sessione è invalida, refreshes il token dal server. Scrivi il codice per viewDidLoad e viewWillAppear che gestisce questo senza duplicate API calls."

Questo testa: comprensione del ViewController lifecycle, state management, networking, e programmazione difensiva. Non è trivia. Un junior la scrive diversamente da un senior, e entrambi sono imparabili.

2. Memory leak in delegazione

"Qui c'è un view controller che tiene un strong reference a un delegate. Il delegate (un manager object) tiene un strong reference di nuovo al view controller. Scrivi un test che cattura questo retain cycle."

Questo si muove oltre la conoscenza statica. Richiede capire il problema, progettare un test, e fixarlo. Lavoro reale.

3. SwiftUI + async-await navigation

"Hai uno navigation stack. Quando un button è tappato, devi fetchare dati, mostrare uno stato loading, poi navigare a uno detail screen. Scrivi il codice usando async-await e @State."

Questo è current. Elimina candidati che non hanno tenuto il passo e prioritizza persone che capiscono pattern di concorrenza moderni.

Domande specifiche Android

1. Fragment lifecycle con saved state

"Un fragment mostra una lista di item. La lista è fetched dalla network. Se l'utente ruota il device, la lista dovrebbe persistere senza re-fetching. Scrivi il codice usando ViewModel e SavedInstanceState."

Testa: lifecycle, state persistence, e pattern di architettura moderni. Non banale, non impossibile.

2. Dependency injection nei test

"Hai un repository che dipende da un API service. Scrivi il codice di setup del test che mocks il service e assicura che il repository gestisce un 500 error correttamente."

Questo rivela se pensano alla testability al design time.

3. Permessi custom con callback

"Richiedi camera permission al runtime. Se negato, mostra un dialogo spiegando perché. Se granted, apri la camera. Scrivi il codice."

Pratico, Android moderno. Non su memorizzazione di nomi di API.

React Native (cross-platform)

1. Navigation state leak

"Hai due screen in uno navigation stack. Screen A fetches dati quando monta. Quando l'utente naviga a Screen B e ritorna ad A, i dati dovrebbero essere re-fetched, non cached. Scrivi il codice usando React Navigation e hooks."

Questo testa comprensione del state lifecycle e una fonte comune di bug.

2. Performance: FlatList con immagini

"Hai una FlatList che renderizza 1000 item di immagini. È lenta. Scrivi il codice che la fissa (keyExtractor, getItemLayout, o image resizing)."

Debugging pratico. Il candidato o conosce il problema o no.

3. Bridge al modulo nativo

"Devi chiamare una funzione nativa da JavaScript. Scrivi il codice di bridge per iOS o Android, includendo error handling."

Questo testa se capiscono il confine e possono lavorare attraverso di esso.

Domande mobile generali (tutte le piattaforme)

1. API versioning trade-off

"La tua API ha cambiato uno response schema. Vecchi client sono ancora in the wild. Scrivi il codice nel mobile client che gestisce entrambe le versioni."

Testa: pragmatismo, programmazione difensiva, e backward compatibility thinking.

2. Offline-first state sync

"L'utente modifica un item mentre offline. Come codi quello edit e lo sincronizzi quando la connessione ritorna? Scrivi lo pseudocode."

Questo è architecture-level. La risposta rivela design maturity.

3. App startup performance

"La tua app impiega 4 secondi a lanciare. Quali sono tre cose che controlleresti e perché? Scrivi il codice per una di loro."

Open-ended abbastanza da rivelare il thinking. Specifico abbastanza da ancorarla.

Come grare queste domande

Non grade sulla polish. Grade su:

• Funziona? Il codice fa quello che è chiesto?
• Lo deployeresti? Ci sono edge cases unhandled?
• Possono spiegarlo? In una walk-through, possono ragionare sui loro scelte?

Per il lavoro mobile specificamente, una live coding interview con questo tipo di domande rivela di più che l'artifact solo perché il candidato deve navigare gli strumenti e la loro incertezza in real time.

Cosa evitare

Non chiedere:

• "Qual è la differenza tra Strong e Weak references?" (trivia)
• "Implementa un'intera app di chat" (troppo broad, ungraded)
• "Cosa fa questo flag oscuro?" (senza senso)

Do chiedere:

• Problemi con criteri di successo chiari
• Problemi che mostrano giudizio (trade-off, non solo correttezza)
• Problemi che assomigliano al lavoro

Queste domande di esempio ancora la tua valutazione al lavoro. Inizia con loro, aggiungi le tue varianti domain-specific, e valida la valutazione una volta che sei live.

Prossimi step

Se stai valutando mobile developer a scale, avere un insieme consistente di esempi attraverso il tuo team previene il drift. Usa questi come template, customizza per il tuo stack, e itera basato su cosa impari dai candidati assunti.