Hoe wij screenen
Elke engineer die we plaatsen doet twee live assessments van zestig minuten in een echte codebase: één met AI-tools uit en één met de eigen agents aan. Je ziet beide scorecards voordat je kennismaakt.
-
01
Stap 1
Beoordeling aanmelding
Opgeleverde code met een commitgeschiedenis die iteratie laat zien, passend bij de rol en de stack. Geen tutorialprojecten en geen claims over AI-tooling zonder code erachter.
-
02
Stap 2
Kennismakingsgesprek
Beantwoordt de vraag die je stelt, niet de vraag waarop ze zich hebben voorbereid.
-
03
Stap 3 · Assessment 1
Fundamentals assessment
Zestig minuten in een onbekende codebase, met AI-tools uitgeschakeld. Zo zie je of iemand zelfstandig een systeem kan lezen, het echte probleem kan vinden en afwegingen kan onderbouwen.
Bekijk de scorecard -
04
Stap 4 · Assessment 2
AI-native assessment
Zestig minuten aan nieuwe tickets, met de eigen agents aan. Zo zie je hoe iemand het werk plant, de output van de agent controleert en bepaalt wat veilig live kan.
Bekijk de scorecard -
05
Stap 5
Gesprek met leadership en referenties
Voor senior en klantgerichte rollen: een consistent verhaal in gesprekken met twee interviewers, bevestigd door voormalige leidinggevenden.
-
06
Stap 6
Besluit
We bekijken alle scorecards samen en leggen de onderbouwing schriftelijk vast. De sterke indruk van één interviewer weegt niet op tegen een scorecard die de lat niet haalde.
-
07
Stap 7
Op de shortlist geplaatst
Engineers die elke stap doorstaan, matchen we met jouw rollen en stack. Hun scorecards krijg je te zien voordat je kennismaakt.
Vraag een shortlist aan
Waarom we take-home opdrachten en codingtests hebben afgeschaft
Elke take-home ziet er tegenwoordig hetzelfde uit, omdat elke take-home door een model is geschreven. LeetCode meet patroonherkenning onder tijdsdruk. Geen van beide toont de fundamenten, en geen van beide toont de agent-vaardigheden.
Daarom vervingen we beide door twee live assessments in een echte codebase: één zonder agents, één met. Dit zijn de scorecards die we invullen voor elke engineer die we plaatsen.
Assessment 1 · AI-tools uit
De fundamentals assessment
De engineer krijgt een codebase die hij of zij nog niet kent, een handvol tickets waaronder één productiebug, en zestig minuten om ze af te werken. Het verloopt als een gewone werksessie, zonder AI-tools.
Bekijk de scorecardAssessment 2 · AI-tools aan
De AI-native beoordeling
De engineer krijgt een nieuwe set tickets in hetzelfde soort codebase, plus de AI-coding-tools die hij of zij normaal gebruikt. Zo zie je wat iemand doet als een agent het meeste werk doet: of die eerst een plan maakt, of die leest wat terugkomt en of die een wijziging kan uitleggen die hij of zij niet zelf heeft getypt.
Bekijk de scorecardWaarom basiskennis ertoe doet bij het werken met agents
De engineer krijgt een codebase die hij of zij nog niet kent, een handvol tickets waaronder één productiebug, en zestig minuten om ze af te werken. Het verloopt als een gewone werksessie, zonder AI-tools.
Hoe goed eruitziet
- Leest de dataflow en foutmodi voordat er code wordt aangeraakt
- Pakt de productionbug als eerste op en kan aangeven wat die raakt
- Herleidt het symptoom tot de grondoorzaak
- Voegt de test toe die de bug had moeten opvangen
Hoe slecht eruitziet
- Lost het symptoom op en gaat verder
- Behandelt elk ticket als hetzelfde risico
- Kan zeggen dat een wijziging werkt, maar niet waarom
- Wijzigt gedeelde code zonder te controleren wie ervan afhankelijk is
De scorecard · zes criteria
Communicatie
Beschrijft afwegingen hardop en zegt wat ze niet hebben afgerond, in plaats van stil te vallen. Vraagt om verduidelijking als een ticket ambigu is, in plaats van te raden.
Niveau Engels
Spreekt en schrijft helder en wordt goed begrepen. Kan een standpunt onderbouwen en houdt het vol bij een vervolgvraag.
Prioritering
De volgorde waarin ze tickets oppakken klopt bij de aangegeven urgentie. De productiebug komt altijd als eerste.
Debuggen
Vindt oorzaken op een gestructureerde manier, van symptoom naar oorzaak, niet door trial and error. Test de oplossing voordat het als klaar wordt beschouwd.
Context-switch discipline
Houdt bij welke tickets openstaan en waar elk ticket staat bij een context-switch. Pakt een taak op zonder alles opnieuw te hoeven lezen.
Technisch begrip
Toont diepgang in de stack, in de complexe flows van de applicatie en in de terminal. Start de applicatie en bekijkt de codebase voordat er iets verandert.
Agents bouwen alles wat je ze geeft
De engineer krijgt een nieuwe set tickets in hetzelfde soort codebase, plus de AI-coding-tools die hij of zij normaal gebruikt. Zo zie je wat iemand doet als een agent het meeste werk doet: of die eerst een plan maakt, of die leest wat terugkomt en of die een wijziging kan uitleggen die hij of zij niet zelf heeft getypt.
Hoe goed eruitziet
- Legt aannames, beperkingen en edge cases schriftelijk vast
- Markeert wijzigingen die betrekking hebben op data, authenticatie of facturering
- Bekijkt de diff en vraagt de agent waarom deze aanpak is gekozen
- Laat iets herbruikbaars achter
Hoe slecht eruitziet
- Dezelfde reviewdiepte voor een tekstwijziging als voor een migratie
- "De agent heeft het gedaan" als verklaring
- Herformuleert de prompt in plaats van de context te corrigeren
- Accepteert een plan dat dupliceert wat al in de repo staat
De scorecard · zes criteria
Verificatie van AI-output
Herkent gehallusineerde API's, subtiel onjuiste logica of beveiligingsfouten in gegenereerde code voordat het wordt uitgerold, in plaats van het te vertrouwen omdat het compileert.
Tool-orkestratie
Weet wanneer werk aan de agent wordt overgedragen (scaffolding, boilerplate, tests) en wanneer zelf coderen de juiste keuze is (nieuwe logica, lastige edge cases), en laat beide parallel lopen in worktrees.
Spec-gedreven ontwikkeling
Breekt een vaag ticket op in stukken die klein genoeg zijn voor de tool om goed uit te voeren, in plaats van de hele ambigue vraag in één keer erin te gooien.
Prompt- en contexttechniek
Richt de prompt en de taakomgeving zo in dat de tool bruikbare output levert in één of twee pogingen, in plaats van steeds dezelfde vage vraag opnieuw te stellen.
AI-versneld debuggen
Gebruikt de agent voor root-cause analysis, log-triage en stack traces, zonder de stap over te slaan om de fout zelf te reproduceren en te begrijpen.
Context-switch discipline
Ook hier scoren we hoe iemand omgaat met context switches, nu met draaiende agents. Een goede engineer weet wat elke agent doet, keert terug naar de juiste agent en laat notificaties niet bepalen wanneer hij wisselt.
Wat senior engineers onderscheidt van snelle engineers
Ze passen niet op een scorecard, dus letten we er in beide assessments op.
01
Oordeel naar risico
Een tekstwijziging, een laagrisico-refactor en een betaalmigratie verdienen niet dezelfde review. Goede engineers werken sneller bij de eerste en vertragen sterk bij de derde. Agents produceren alle drie met dezelfde snelheid en hetzelfde vertrouwen.
Tijdens de assessment
Leest de kandidaat de migration diff regel voor regel en scant hij de copy-wijziging? Brengt hij de blast radius ter sprake voordat wij dat doen?
02
Eigenaarschap
Als je het merget, ben je er verantwoordelijk voor. Tests, observability, uitrol en het debuggen na de release horen bij het werk, of de code nu door een persoon of een agent is geschreven.
Tijdens de assessment
“De agent heeft het gedaan” accepteren we niet als uitleg in een assessment. Je team accepteert het ook niet in een incident review.
03
Hefboomwerking
De beste engineers ronden het ticket af en laten de repo beter achter voor de volgende agent: een herbruikbaar commando, een strakkere CLAUDE.md, een test die de hele categorie bugs afvangt en niet alleen dat ene geval.
Tijdens de assessment
Heeft iets wat ze tijdens het uur hebben gebouwd het volgende ticket makkelijker gemaakt, of lieten ze de repo precies zoals ze hem aantroffen?
Whitepaper
The Next 10X Engineer
Waarom de beste engineers nu minder code schrijven, en hoe je ze onderscheidt van de rest.
Veertien pagina's van Bo Wesdorp, onze CTO: wat het vak nu inhoudt, wat AI-native betekent, waarom het oude wervingsproces niet meer werkt, en beide scorecards volledig uitgewerkt.
Publiceren jullie je assessment?
Ja. Beide assessments, hoe goed en slecht werk eruitzien en de twaalf criteria op de twee scorecards staan op deze pagina en in de whitepaper The Next 10X Engineer.
Kan ik de resultaten van een kandidaat inzien?
Ja. Elke engineer op de shortlist komt met beide ingevulde scorecards. Je ziet ze voordat je iemand ontmoet.
Wie voert de assessments uit?
Senior engineers die elke dag productiesoftware bouwen met deze tools voeren beide assessments uit. Recruiters beoordelen geen kandidaten.
Waarom geen take-home of een coderingstest?
Elke take-home wordt nu door een model geschreven, en LeetCode-achtige tests meten patroonherkenning onder tijdsdruk. Geen van beide toont de fundamenten of de agent-vaardigheden.
Bekijk de scorecards voordat je iemand ontmoet
Vertel ons de rol. We sturen binnen vijf werkdagen benoemde engineers met beide ingevulde scorecards.
ISO 27001Gecertificeerd