Mobiele ontwikkelaar test voorbeeldvragen: Wat te vragen
Waarom voorbeeldvragen belangrijk zijn
De meeste mobiele ontwikkelaar evaluaties zijn fout gebouwd. Ze leunen naar trivia (wat is de lifecycle methode naam in Android 11?) of ze zijn zo open-ended dat zij instorten onder hun eigen gewicht. De juiste voorbeeldvragen zitten ertussenin: specifiek genoeg om te beoordelen, breed genoeg om oordeel te onthullen.
Als je een mobiele evaluatie van nul bouwt, is weten wat soorten vragen werken half de strijd. Hier zijn de patronen die werkelijk werkprestaties voorspellen.
iOS-specifieke vragen
1. View controller lifecycle met toestand
"Een login scherm wordt geladen. Bij eerste weergave haalt het de auth sessie uit de sleutelhanger. Als de sessie ongeldig is, vernieuwt het het token van de server. Schrijf de code voor viewDidLoad en viewWillAppear die dit afhandelt zonder dubbele API gesprekken."
Dit test: begrip van ViewController lifecycle, toestandsbeheer, netwerken en defensieve programmering. Het is geen trivia. Een junior schrijft het anders dan een senior, en beide versies zijn lerenswaardig.
2. Geheugenlek in delegatie
"Hier is een view controller die een sterke referentie naar een delegate houdt. De delegate (een managerobject) houdt een sterke referentie terug naar de view controller. Schrijf een test die deze retain cycle vangt."
Dit gaat verder dan statische kennis. Het vereist het probleem begrijpen, een test ontwerpen, en het repareren. Echt werk.
3. SwiftUI + async-await navigatie
"Je hebt een navigatie stack. Wanneer een knop wordt aangetikt, moet je gegevens ophalen, een laadstatus tonen, dan navigeren naar een detail scherm. Schrijf de code met async-await en @State."
Dit is actueel. Het elimineert kandidaten die niet bijgehouden hebben en geeft voorrang aan personen die moderne concurrency patronen begrijpen.
Android-specifieke vragen
1. Fragment lifecycle met opgeslagen toestand
"Een fragment toont een lijst met items. De lijst wordt uit het netwerk opgehaald. Als de gebruiker het apparaat draait, zou de lijst moeten bestaan zonder opnieuw op te halen. Schrijf de code met ViewModel en SavedInstanceState."
Test: lifecycle, toestandspersistentie en moderne architectuurpatronen. Niet triviaal, niet onmogelijk.
2. Dependency injection in testen
"Je hebt een repository die afhangt van een API service. Schrijf de test setup code die de service nabootst en zorgt dat de repository een 500 fout juist afhandelt."
Dit onthult of zij op testbaarheid denken op ontwerptijd.
3. Aangepaste toestemmingen met callback
"Vraag camertoestemming op runtime. Indien geweigerd, toon een dialoog waarom. Indien toegekend, open de camera. Schrijf de code."
Praktisch, modern Android. Niet over het onthouden van API namen.
React Native (cross-platform)
1. Navigatie toestand lek
"Je hebt twee schermen in een navigatie stack. Scherm A haalt gegevens op wanneer het wordt gekoppeld. Wanneer de gebruiker naar Scherm B navigeert en terug naar A gaat, zouden gegevens opnieuw moeten worden opgehaald, niet gecached. Schrijf de code met React Navigation en hooks."
Dit test toestand lifecycle begrip en een veelvoorkomende bron van bugs.
2. Prestatie: FlatList met afbeeldingen
"Je hebt een FlatList met 1000 afbeeldingsitems. Het is traag. Schrijf de code die het repareren (keyExtractor, getItemLayout of afbeelding vergroten)."
Praktisch debuggen. De kandidaat weet het probleem of niet.
3. Brug naar native module
"Je moet een native functie vanuit JavaScript aanroepen. Schrijf de brug code voor iOS of Android, inclusief foutafhandeling."
Dit test of zij de grens begrijpen en erover kunnen werken.
Algemene mobiele vragen (alle platforms)
1. API versie trade-off
"Je API heeft een response schema gewijzigd. Oude cliënten zijn nog in omloop. Schrijf de code in de mobiele client die beide versies afhandelt."
Test: pragmatisme, defensieve programmering en achterwaarts compatibiliteit denken.
2. Offline-first toestand sync
"De gebruiker bewerkt een item terwijl offline. Hoe wachtrij je die bewerking en syncroniseer je deze wanneer de verbinding terugkomt? Schrijf de pseudocode."
Dit is architectuurniveau. Het antwoord onthult ontwerp volwassenheid.
3. App startup prestatie
"Je app duurt 4 seconden om te starten. Wat zijn drie dingen die je zou controleren en waarom? Schrijf de code voor een ervan."
Open-ended genoeg om denken te onthullen. Specifiek genoeg om het te gronden.
Hoe deze vragen te scoren
Scoor niet op glans. Scoor op:
- Werkt het? Doet de code wat werd gevraagd?
- Zou je het inzetten? Zijn er edge cases niet afgehandeld?
- Kunnen zij het uitleggen? In een walkthrough, kunnen zij over hun keuzes redeneren?
Voor mobiel werk specifiek, een live coding interview met deze soort vragen onthult meer dan artifact alleen omdat de kandidaat de tools en hun eigen onzekerheid in realtime moet navigeren.
Wat te vermijden
Vraag niet:
- "Wat is het verschil tussen Strong en Weak references?" (trivia)
- "Implementeer een volledige chat app" (te breed, ongescoord)
- "Wat doet deze obscure vlag?" (zinloos)
Vraag wel:
- Problemen met duidelijke succescriteria
- Problemen die oordeel tonen (trade-offs, niet alleen correctheid)
- Problemen die lijken op werk
Deze voorbeeldvragen ankerden je evaluatie aan de baan. Begin ermee, voeg je eigen domeinspecifieke varianten toe, en valideer de evaluatie eenmaal live.
Volgende stappen
Als je mobiele ontwikkelaars op schaal beoordeelt, helpt het hebben van een consistente verzameling voorbeelden tussen je team drift voorkomen. Gebruik deze als sjabloon, pas aan voor je stapel en herhaald gebaseerd op wat je van aangeworven kandidaten leert.