Hoe je Mobiele Developers Beoordeelt: Een Compleet Kader
Het mobiele inhuringprobleem
Mobiele developer inhuring is moeilijker dan web of backend inhuring omdat het splitst over platforms. Een iOS-specialist en een Android-specialist zijn bijna verschillende jobfuncties. React Native engineers worden anders geëvalueerd dan native specialisten. Toch gebruiken meeste bedrijven dezelfde beoordeligstestrategia voor alles.
Dat is de eerste fout. De tweede is het beoordelen van platformspecifieke trivia. De derde is het gebruiken van huiswerk zo open-ended dat het eerlijk kan worden beoordeeld.
Dit kader corrigeert alles drie.
Laag 1: Initieel scherm (30 minuten)
Begin met een live codering challenge op een realistisch probleem, geen puzzel.
Wat geef je ze
"Hier is een verbroken loginflow in [iOS/Android/React Native]. De bug is dat het zittingstoken niet wordt opgeslagen na succesvol inloggen. Zoek en repareer het in 30 minuten. Je kunt docs gebruiken, StackOverflow, alles behalve het uitvoeren van de code."
Dit is geen LeetCode probleem. Er is geen verborgen truuk. Het is een realistische debuggingtaak.
Wat meet je
- Kunnen ze onbekende code lezen?
- Begrijpen ze statusbeheer van het platform?
- Kunnen ze de bug vinden zonder trial-and-error?
- Hoe gaan ze met ambiguïteit om (als code meerdere problemen heeft)?
Trivia-kennis speelt bijna geen rol. Platformervaring wel. Vermogen om sequentieel te denken wel.
Laag 2: Diepe technische beoordeling (90 minuten)
Na het scherm, ga je naar een huiswerk beoordeling specifiek voor hun focusgebied.
Voor iOS-kandidaten
Geef ze een view controller die moet:
- Gegevens van een mock API ophalen
- Fouten afhandelen (netwerk, auth, parsing)
- Resultaten in een tabel weergeven met paginering
- Status behouden wanneer view controller opnieuw wordt aangemaakt
90 minuten, geen truken. Beoordeel op: compileert het, werken de vereisten, is het testbaar, zou je het mergen?
Voor Android-kandidaten
Hetzelfde probleem, maar in Android-termen: een fragment met ViewModel, repository layer en RecyclerView. Dezelfde rubrieken.
Voor React Native
Een scherm dat gegevens ophaalt, loading/error states behandelt en navigeert op basis van resultaat. Met correct hook management en geen geheugenlekken.
De beoordeling leert hen het platform niet. Het veronderstelt dat ze het kennen. Slechte kandidaten falen hier. Middelgoedbevel-kandidaten slagen. Senior kandidaten slagen snel en elegant.
Laag 3: Walk-through gesprek (30 minuten)
Dit is niet optioneel. Het artefact alleen is niet genoeg.
Laat de kandidaat hun code uitleggen. Vraag:
- "Waarom heb je staat in ViewController vs. de View Model gezet?"
- "Wat gebeurt er als het netwerkaanvraag in afwachting is en de gebruiker draait het toestel?"
- "Hoe zou je dit testen?"
- "Wat zou je veranderen als deze lijst 50.000 items had?"
Deze vragen onthullen of de kandidaat werkelijk de code begrijpt die ze schreven of dat ze het ergens vandaan kopieerden. AI-hulp wordt irrelevant omdat de walk-through oordeel test, niet het artefact.
De walk-through onthult ook domeinkennis gaten. Een kandidaat die het probleem oplostte maar nooit over batterijdrain of achtergrondtaaklimieten heeft nagedacht, is waarschijnlijk junior.
Laag 4: Systeemontwerp (als je senior+ inhuurt)
Voor senior rollen, voeg een 30-minuten discussie toe:
"Je bouwt een fotobewerk-app. Gebruikers uploaden bewerkte foto's naar de cloud. De app moet offline werken, netwerkfouten netjes afhandelen en synchroniseren wanneer de verbinding terugkeert. Loop me door je architectuur."
Dit gaat niet over de exacte architectuur. Het gaat erom of ze denken in terms van afwegingen (lokale opslag vs. cloud, sync strategie, retry logica). Junior engineers hebben "een" architectuur. Senior engineers hebben architectuur redenering.
Wat je niet moet doen
Gebruik geen LeetCode-stijl problemen
"Implementeer een gebalanceerde binaire zoekboom" heeft niets met mobiele ontwikkeling te maken. Het is een filter voor mensen die competitieve programmering hebben gestudeerd, niet voor mensen die apps bouwen.
Vraag geen platformtrivia
"Wat is het verschil tussen dispatch_once en DispatchQueue.once?" is geen bruikbaar signaal. Of ze weten het of ze slaan het in twee seconden op. Ga verder.
Maak de huiswerk niet te open-ended
"Bouw een Twitter-kloon" is onmogelijk eerlijk te beoordelen. Verschillende kandidaten interpreteren het anders. Stel beperkingen in: drie schermen, 90 minuten, specifieke vereisten.
Sla de walk-through niet over
Het artefact bewijst dat ze kunnen coderen. De walk-through bewijst dat ze begrijpen de code. Beide matteren voor senior hires.
Hoe je aanpast voor ervaringsniveau
Junior (0–2 jaar)
- Eenvoudig scherm (één API-aanroep, toon resultaten, foutafhandeling)
- Test geen async edge cases of optimalisatie
- Focus op juistheid en leesbaarheid
- Walk-through moet mild zijn; ze bouwen nog steeds fundamentals
Middelgoed (2–5 jaar)
- Complexer statusbeheer
- Paginering of lazy loading
- Testvereisten
- Edge cases (offline, timeout, toestemming geweigerd)
- Walk-through onderzoekt gaten
Senior (5+ jaar)
- Voeg prestatiebeperkingen toe
- Test voor architectuur denken
- Verwacht dat ze verduidelijkingsvragen stellen
- Walk-through graaft in afwegingen en implicaties
Eerlijk en geldig maken
Gebruik dezelfde beoordeling voor alle kandidaten op een niveau. Dit laat je resultaten consistent interpreteren en spot of de beoordeling werkelijk meet wat je denkt.
Track inhuurresultaten. Hebben mensen die de beoordeling passeerden succes in de rol? Zo niet, is de beoordeling fout, niet de kandidaten.
Documenteer scoringsrubriek voordat je de beoordeling gebruikt. Hoe ziet "goed" eruit? Wat is een pass? Ambiguïteit doodt eerlijkheid.
Implementatie op schaal
Als je meerdere mobiele developers beoordeelt, overweeg een platform te gebruiken zoals ClarityHire dat de technische setup afhandelt. Je kunt de beoordeling eenmaal instellen, herhaaldelijk gebruiken en resultaten in de loop van tijd volgen.
Het beoordel framework werkt het beste als je:
- Het consistent houdt
- Het objectief beoordeelt
- Herhaalt op basis van of inhuuringen slagen
Dit is de basis voor geldige en eerlijke mobiele beoordelingen.