Mobiele ontwikkelaarintestresultaten interpreteren: van scores tot aanwervingsbeslissingen

De score zegt zonder context niets

De meeste aanwervingsteams kijken naar een mobiele ontwikkelaarsbeoordeling score en vragen: "Is 72/100 goed?" Die vraag is achterwaarts. Een score zonder context is ruis.

De enige betekenisvolle vraag is: "Voor de rol waar we aannemen, wat weet deze kandidaat werkelijk en wat zullen ze leren?"

Eerst een rubric bouwen

Voordat je iets beoordeling, definieer je wat goed eruitziet. Zonder rubric, beoordeel je op intuïtie, en intuïtie verschilt van interviewer naar interviewer.

iOS beoordelingsrubric voorbeeld

Codecorrectheid (0–30 punten)

• Compileert het? (10 punten)
• Werken de kernvereisten? (15 punten)
• Worden grensgevallen behandeld (fouten, state-terugstelling)? (5 punten)

Architectuur (0–25 punten)

• Is state duidelijk beheerd (ViewModel-scheiding, geen spaghetti)? (10 punten)
• Is de code testbaar (losse koppeling, injecteerbare afhankelijkheden)? (10 punten)
• Is het over-geïngineerd voor scope? (5 punten)

Kennissignalen (0–20 punten)

• Correct gebruik van lifecycle-methoden (geen voortijdige optimisatie, geen lekkages)? (8 punten)
• Memory-veiligheid (geen retain-cycles, veilig unwrapping)? (7 punten)
• Async-patronen (async-await of Combine, geen callback-hel)? (5 punten)

Codekwaliteit (0–25 punten)

• Leesbaarheid en naamgeving? (10 punten)
• Geen duidelijke bugs of technische schuld? (10 punten)
• Commits zijn betekenisvol (als take-home)? (5 punten)

Totaal: 100 punten

Passeer drempel: 65–70 (afhankelijk van rollevel)

Android beoordelingsrubric voorbeeld

Codecorrectheid (0–30 punten)

• Compileert en draait het? (10 punten)
• Kernvereisten met? (15 punten)
• Grensgevallen afgehandeld? (5 punten)

Architectuur (0–25 punten)

• ViewModel en Repository-patroon correct gebruikt? (10 punten)
• Dependency injection setup (Hilt of handmatig)? (10 punten)
• Passende scheiding van zorgen? (5 punten)

Kennissignalen (0–20 punten)

• Coroutines correct gebruikt (niet blokkerend, juiste scope)? (8 punten)
• Lifecycle-begrip evident? (7 punten)
• Testingsetup (mockito, Espresso, of beide)? (5 punten)

Codekwaliteit (0–25 punten)

• Leesbaarheid en naamgeving? (10 punten)
• Geen duidelijke bugs of technische schuld? (10 punten)
• Gradle/build-configuratie logisch? (5 punten)

Totaal: 100 punten

Passeer drempel: 65–70

Wat scores werkelijk betekenen

85+: Sterke aanwerving

De kandidaat loste het probleem schoon op, dacht aan grensgevallen en schreef code die je niet zou aarzelen om te mergen. In een walkthrough leggen ze hun redenering duidelijk uit. Ze kunnen optimalisatie-denken missen of enig platform-kennis missen, maar ze zijn fundamenteel gezond.

Actie: Ga vol vertrouwen naar volgende ronde.

70–84: Adequaat, met lacunes

Ze losten het probleem op. Code werkt. Maar er zijn ruwe randkanten: misschien een potentieel geheugenlek, misschien is state-beheer in de war, misschien is foutafhandeling incompleet. In de walkthrough kunnen ze meeste van hun code uitleggen maar wankelen op grensgevallen.

Actie: Hangt af van rollevel. Voor junior rollen, dit is prima. Voor senior rollen, dit is een pas maar een zachte. Besteed de walkthrough aan het onderzoeken van de lacunes om groeitraject te begrijpen.

60–69: Technisch passeren, strategisch zorgwekkend

Code werkt maar het is duidelijk dat ze worstelden. Misschien hadden ze documentatie nodig voor platform-APIs, misschien is hun testing zwak, misschien is architectuur fragiel. Ze passeerden omdat vereisten met waren, niet omdat de oplossing goed is.

Actie: Interview ze diep. Score zegt "technisch capabel." Maar kunnen ze werkelijk het baan doen? Kunnen ze groeien? Zullen ze een put zijn voor code-review-tijd?

Onder 60: Niet klaar

Code is incompleet, compileert niet, of toont fundamenteel misverstand van het platform.

Actie: Waarschijnlijk passen tenzij ze uitzonderlijk groeipotentieel in de gesprek tonen.

De walkthrough is waar scores beslissingen worden

Een 72 score op zich is ambigu. In de walkthrough ontdek je waarom:

"Loop me door hoe je gebruikersvoorkeur naar schijf hebt opgeslagen. Wat is de flow van gebruikersinteractie tot persistentie?"

Sterk antwoord (72 → 80+): "Ik gebruik UserDefaults voor eenvoudige gegevens. Voor complexe gegevens gebruik ik Codable en JSON-serialisatie naar een bestand. Ik controleer op fouten bij lezen (bestand bestaat misschien niet) en schrijven (schijf misschien vol). Ik testte dit door het bestandssysteem te mocken."

Dit toont dat ze het domein begrijpen. 72 was conservatief scoren; ze zijn werkelijk sterk.

Zwak antwoord (72 → 55): "Uh, ik ben niet zeker. Misschien heb ik het ergens opgeslagen? Ik dacht niet veel na over fouten."

Dit toont dat ze gokten. Ze zijn onder drempel.

Veelgemaakte interpretatiefouten

Fout 1: "Niet afgemaakt" verwarren met "weet niet"

Als toets 90 minuten is en ze liepen uit tijd, dat is signaal over tijd-beheer en scope-inschatting, niet competentie. Iemand die minder code schrijft maar erover nadenkt is beter dan iemand die snel en slecht schrijft.

Pas je interpretatie aan:

• Voltooiden ze kernvereisten? (Ja: niet belangrijkste rode vlag)
• Voltooiden ze en gingen dan voor stretch-doelen? (Ja: sterk signaal)
• Voltooiden ze maar het is slordig? (Slecht signaal)

Fout 2: Één aspect overgewichtig

Naalden ze de functie maar schreven geen tests, is dat deal-breaker? Hangt af van rol en team. Een startup kan geen tests accepteren als ingenieur sterk op features is. Een volwassen platform-team mag ze elimineren voor zwakke testingcultuur.

Beslissing je weging voor je beoordeelt.

Fout 3: Het verkeerde ding voor platform beoordelen

iOS: Als ze functie bouwden maar gebruikten verouderde UIView in plaats van SwiftUI, niet mislukking. Beslissing wat voor je team telt. Als je legacy-code onderhoudt, ze moeten beide kennen.

Android: Java in plaats van Kotlin gebruiken, zelfde vraag. Achterwaartse compatibiliteit telt alleen als het voor je werk telt.

Fout 4: Aannemen zwakke score betekent zwakke ingenieur

Soms hebben sterke ingenieurs een slechte dag. Ze misunderstand vereisten. Ze spendeerden 30 minuten op detail dat niet telde. Ze raakten gestrest en schreven slordig code.

Toets is één signaal. Walkthrough en referentie-gesprekken zijn anderen. Gebruik het volledige plaatje.

Grensscores afhandelen

65–70 bereik

Plan gericht tweede toets: "Hier's een gelijkaardig probleem. Dit keer, focus op architectuur." Kijk of ze hoger scoren (test-angst, niet competentie) of lager (werkelijk worstelen).

Of ga naar live coding ronde. Soms code mensen beter in real-time met feedback dan alleen.

60–64 bereik

Voor weigering, vraag: Wat precies is de lacune?

• Ontbrekende platformkennis? (Fixeerbaar, niet blocker voor juiste cultuur)
• Zwak probleemoplossing? (Moeilijk te fixen)
• Goed denken, slechte uitvoering? (Kan verbeteren)
• Verkeerde rol-pasvorm? (Andere toets zou sterkte tonen)

Als lacune leerlaar is, overweeg aannemen en investeren in onboarding. Als fundamenteel, pas.

Beoordelingsvaliditeit bouwen in loop der tijd

Zodra je een paar mensen met toets aanwerft, controleer: Scoorden hoge scorers goed? Worstelden lage scorers?

• Als 75+ scorers allemaal slaagden en 65-scorers allemaal mislukten, je drempel is goed.
• Als sommige 70-scorers nu top-uitvoerders zijn, misschien beoordeel je te hard.
• Als 80-scorers underperformen, misschien toets niet voorspellend.

Volg dit in loop der tijd. Pas rubrieken aan op basis van wat je leert.

Rode vlaggen in beoordelinginterpretatie

"Code is lelijk maar werkt"

Code zal werden onderhouden. Lelij compound in loop der tijd.

"Ze kennen async-await niet"

Als rol async-code vereist, probleem. Zo niet, alleen ontbrekende kennis.

"Ze losten het anders op dan ik zou"

Anders betekent niet verkeerd. Evalueer tegen rubric, niet tegen voorkeur.

"Ze gebruikten bibliotheek in plaats van scratch bouwen"

Slimme ingenieurs gebruiken biblioteken. Bestraffen dat is achterwaarts.

Scores naar aanwervings-meeting brengen

Zeg niet gewoon "72/100." Zeg:

"Ze scoorden 72/100. Specifiek: sterk op correcheid (28/30), zwakker op architectuur (18/25). In de walkthrough toonden ze solide lifecycle- en state-management-begrip. Lacune is in testability- en fout-grensgevallen-denken. Voor mid-level rol, dit accepteerbaar. Voor senior, ze zouden groei moeten tonen."

Dit is aanwervingsbeslissing, niet score-aflezen.

Consistente beoordeling bouwen over teams

• Dezelfde rubric gebruiken voor alle kandidaten op niveau
• Op rubric beoordelen, niet ingewandeling
• Twee mensen onafhankelijk beoordelen, lacunes bespreken
• Redenering documeren
• Rubric aanpassen na cyclus gebaseerd op resultaat

Zodra je aanneemt en succesvol zijn, revisit toets. Wat score kregen zij? Valideer rubric werkte.

Zo beoordeel je mobiele ontwikkelaars schaal zonder team uit te branden of slechte aanwervingen te doen.