Test developer mobil: Exemple de întrebări
De ce exemplele de întrebări contează
Majoritatea evaluărilor pentru developeri mobili sunt construite greșit. Ele fie se înclinează spre trivia (care este numele metodei de ciclu de viață în Android 11?) fie sunt atât de deschise încât se prăbușesc sub propria greutate. Exemplele de întrebări corecte se află în mijloc: specific suficient pentru a fi evaluate, larg suficient pentru a dezvălui judecată.
Dacă construiți o evaluare mobilă de la zero, știind ce tipuri de întrebări funcționează este jumătate din bătălie. Iată modelele care într-adevăr prezic performanța muncii.
Întrebări specifice iOS
1. Ciclu de viață al view controller cu stare
"Un ecran de conectare se încarcă. La prima randare, aceasta preluează sesiunea auth din keychain. Dacă sesiunea este nevalidă, reîmprospătează token-ul de la server. Scrieți codul pentru viewDidLoad și viewWillAppear care gestionează asta fără apeluri API duplicate."
Testează: înțelegerea ciclului de viață ViewController, gestionarea stării, networking și programare defensivă. Nu este trivia. Un junior o scrie diferit decât un senior, și ambele versiuni sunt învățabile.
2. Scurgere de memorie în delegație
"Iată un view controller care deține o referință puternică la un delegat. Delegatul (un obiect manager) deține o referință puternică înapoi la view controller. Scrieți un test care detectează acest ciclu de reținere."
Asta merge dincolo de cunoștințele statice. Necesită înțelegerea problemei, proiectarea unui test și remedierea acesteia. Muncă reală.
3. SwiftUI + navigare async-await
"Aveți o stivă de navigare. Când se apasă un buton, trebuie să preluați date, să arătați o stare de încărcare, apoi să navigați la un ecran de detalii. Scrieți codul folosind async-await și @State."
Asta este actual. Elimină candidații care nu s-au ținut la curent și prioritizează oamenii care înțeleg modelele moderne de concurență.
Întrebări specifice Android
1. Ciclu de viață fragment cu stare salvată
"Un fragment afișează o listă de articole. Lista este preluată din rețea. Dacă utilizatorul rotește dispozitivul, lista ar trebui să persiste fără a reincărca. Scrieți codul folosind ViewModel și SavedInstanceState."
Testează: ciclu de viață, persistență de stare și modele de arhitectură moderne. Nu trivial, nu imposibil.
2. Injecție de dependență în teste
"Aveți un depozit care depinde de un serviciu API. Scrieți codul de configurare a testului care ridiculizează serviciul și asigură că depozitul gestionează corect o eroare 500."
Asta relevă dacă gândesc la testabilitate la momentul proiectării.
3. Permisiuni personalizate cu callback
"Solicitați permisiune de aparat foto la runtime. Dacă este negată, arătați o dialogare explicând de ce. Dacă este acordată, deschideți aparatul foto. Scrieți codul."
Practic, Android modern. Nu despre memorarea numelor API.
React Native (cross-platform)
1. Scurgere de stare de navigare
"Aveți două ecrane într-o stivă de navigare. Ecranul A preluează date când se montează. Când utilizatorul navighează la ecranul B și înapoi la A, datele ar trebui să fie reîncărcate, nu în cache. Scrieți codul folosind React Navigation și hooks."
Testează înțelegerea ciclului de viață al stării și o sursă comună de erori.
2. Performanță: FlatList cu imagini
"Aveți o FlatList care redă 1000 de articole cu imagini. Este lent. Scrieți codul care o remediază (keyExtractor, getItemLayout sau redimensionare de imagini)."
Debugging practic. Candidatul fie cunoaște problema fie nu.
3. Legătură cu modul nativ
"Trebuie să apelați o funcție nativă din JavaScript. Scrieți codul podului pentru iOS sau Android, inclusiv manipularea erorilor."
Testează dacă înțeleg granița și pot lucra peste ea.
Întrebări generale mobile (toate platformele)
1. Compromis în versionarea API-ului
"API-ul dvs. a schimbat o schemă de răspuns. Clienți vechi sunt încă în sălbăticie. Scrieți codul în clientul mobil care gestionează ambele versiuni."
Testează: pragmatism, programare defensivă și gândire de compatibilitate inversă.
2. Sincronizare de stare offline-first
"Utilizatorul editează un articol în timp ce este offline. Cum coadă acea editare și o sincronizați când conexiunea se întoarce? Scrieți pseudocodul."
Asta este la nivel de arhitectură. Răspunsul revelează maturitatea proiectării.
3. Performanță de pornire a aplicației
"Aplicația dvs. durează 4 secunde pentru a se lansa. Care sunt trei lucruri pe care le-ați verifica și de ce? Scrieți codul pentru una din ele."
Suficient deschis pentru a dezvălui gândirea. Specific suficient pentru a o folosi.
Cum să evaluați aceste întrebări
Nu evaluați pe bază de finisaj. Evaluați pe:
- Funcționează? Codul face ceea ce se cere?
- Ați implementa-o? Sunt situații extreme negestionate?
- Pot să o explice? Într-o sesiune de parcurgere, pot raționa despre alegerile lor?
Pentru munca mobilă în specific, o interviu live coding cu aceste tipuri de întrebări revelează mai mult decât artefactul singur, deoarece candidatul trebuie să navigheze în instrumente și incertitudinea lor în timp real.
Ce trebuie să evitați
Nu întrebați:
- "Care este diferența dintre referințele Strong și Weak?" (trivia)
- "Implementați o aplicație de chat completă" (prea larg, neevaluat)
- "Ce face această steag obscur?" (lipsit de sens)
Întrebați:
- Probleme cu criterii de succes clare
- Probleme care arată judecată (compromisuri, nu doar corectitudine)
- Probleme care arată ca muncă
Aceste exemple de întrebări ancorez evaluarea dvs. la muncă. Începeți cu ele, adăugați propriile variante specifice domeniului și validați evaluarea odată ce sunteți live.
Pași următori
Dacă evaluați developeri mobili la scară, având un set consistent de exemple pe toată echipa dvs. previne deriva. Utilizați acestea ca șablon, personalizați pentru stiva dvs. și iterați pe baza a ceea ce învățați din candidații angajați.