Een software developer selecteren was al ingewikkeld als je geen programmeur bent. Nu AI de code schrijft, is de verwarring compleet: hoe beoordeel je iemand op een vaardigheid die een machine ook kan uitvoeren?
De klassieke coding test geeft je geen bruikbaar antwoord meer.
Hier lees je welk selectieproces werkt en hoe je een sterke developer herkent, ook zonder technische achtergrond.
Zo selecteer je een developer in het AI-tijdperk
Een praktische gids voor recruiters en hiring managers zonder technische achtergrond.
Waarom de coding test niet meer volstaat
Lange tijd was het antwoord op “hoe selecteer je een software developer?” simpel: geef ze een codeeropdracht en kijk wat ze produceren. Die logica klopte toen developers elke regel zelf schreven. Sindsdien is er veel veranderd. Onderzoek van CoderPad onder techbedrijven laat zien dat abstracte algoritmepuzzels in 2025 grotendeels zijn vervangen door projectgebaseerde opdrachten. De reden: voor veel rollen meten klassieke tests geheugen en stresstolerantie onder kunstmatige tijdsdruk, niet werkprestatie.
Dat geldt niet voor alle rollen. Voor posities waarbij performance, geheugenoptimalisatie of wiskundige complexiteit centraal staan, blijft algoritmisch inzicht relevant. AI genereert regelmatig werkende code die slecht presteert op resources. Een developer zonder grondige kennis van datastructuren en complexiteit herkent die problemen niet. Voor zulke rollen is een technische toets nog steeds een zinvol selectie-instrument, mits je meet wat je wilt meten: begrip, niet memorisatie.
Wat wel breed veranderd is: de standaard take-home opdracht op basis van geïsoleerde puzzels zonder context geeft weinig voorspellende waarde meer voor de meeste softwarerollen. Een developer die vandaag met een AI-assistent werkt, besteedt meer tijd aan het beoordelen, debuggen en verbeteren van gegenereerde code dan aan het schrijven van nul af aan. Stem je selectiemethode af op wat de rol echt vraagt.
Wat je nu wel beoordeelt bij een developer
Bij het selecteren van een software developer in 2026 zijn vier competenties leidend. Ze zijn ook voor een niet-technische recruiter goed te beoordelen, mits je de juiste vragen stelt en weet waar je op let.
Probleemanalyse: Kan de kandidaat een complex vraagstuk opsplitsen in behapbare deelproblemen? Dat is de kern van softwareontwikkeling, met of zonder AI. Een goede developer begint niet met code schrijven, maar met begrijpen wat het probleem precies is.
Kritisch oordeel over AI-output: Neemt de kandidaat gegenereerde code blindelings over, of weet ze fouten te herkennen, aannames te bevragen en de kwaliteit te beoordelen? Canva stelde in 2025 vast dat de sterkste kandidaten AI strategisch inzetten voor afgebakende deeltaken en de output daarna kritisch doorlichten. Dat onderscheidt een sterke developer van een gemiddelde.
Communicatie: Kan de developer uitleggen wat ze doen en waarom ze voor een bepaalde aanpak kiezen? In agile teams is dat geen bijzaak. Een developer die de eigen redenering niet kan verwoorden, levert problemen op in code reviews, standups en samenwerking met producteigenaren.
Debuggen en foutherstel: AI-tools genereren regelmatig code die gedeeltelijk klopt maar een fout bevat. De vaardigheid om die fout te vinden en te corrigeren, is een sterk signaal van technisch begrip. Dat is iets wat je kunt toetsen zonder zelf te kunnen programmeren, door de kandidaat hardop te laten redeneren.
Een selectieproces in drie stappen
Een goed selectieproces voor een software developer hoeft niet lang te zijn. Drie stappen zijn voldoende om een betrouwbaar beeld te krijgen. Elk van deze stappen is ook te hanteren als je zelf geen technische achtergrond hebt.
Stap 1: gestructureerd interview over eerdere projecten
Begin met een gestructureerd interview op basis van de STARR-methode. Vraag naar concrete situaties uit het verleden: “Vertel over een project waarbij de technische aanpak halverwege moest veranderen. Wat was jouw rol daarin?” Zo kom je te weten hoe de kandidaat omgaat met veranderende eisen, iets wat in elke softwarerol voorkomt.
Stel ook gericht vragen over AI-gebruik: “Welke AI-tools gebruik je in je dagelijkse werk? Beschrijf een situatie waarin de output je tegenviel en wat je toen deed.” Het antwoord vertelt je meer over technisch inzicht dan een willekeurige algoritmepuzzel. Zo selecteer je een software developer op gedrag dat je in de praktijk ook terugziet.
Stap 2: praktische opdracht op basis van echt werk
Vervang de abstracte coding test door een werkproef die lijkt op echt werk. Geen puzzels, maar een kleine, afgebakende taak die aansluit bij wat de rol vraagt. Denk aan: een stuk bestaande code doornemen en verbeterpunten benoemen, of een korte technische specificatie vertalen naar een aanpak.
Geef daarbij expliciet aan dat de kandidaat AI-tools mag gebruiken. Maar: een take-home opdracht geeft pas bruikbaar signaal als je het resultaat live nabespreekt. Zonder dat nagesprek meet je niets. Een kandidaat die AI-gegenereerde code inlevert zonder die te begrijpen, valt pas door de mand wanneer je doorvraagt: “Waarom heb je hier voor deze aanpak gekozen?” of “Wat zou er gebeuren als de invoer tien keer groter wordt?” Beperk de tijdsinvestering tot maximaal twee uur. Sterke developers hebben opties, en een te zware opdracht kost je kandidaten nog voor het gesprek.
Stap 3: code review gesprek
Laat de kandidaat in een live gesprek een stuk code beoordelen: bij voorkeur code die een senior developer heeft aangeleverd. Vraag: “Wat zie je hier, wat zou je veranderen en waarom?” Je hoeft de code zelf niet te begrijpen om te beoordelen of de kandidaat helder en gestructureerd redeneert. Wie bij dit gesprek stil wordt of alleen oppervlakkig reageert, geeft daarmee een belangrijk signaal af.
Dit gesprek is ook de plek om te toetsen of de kandidaat met voldoende technische diepgang kan uitleggen wat de code doet en waarom bepaalde keuzes goed of slecht zijn. Communicatievaardigheid en technisch inzicht komen hier samen.
Rol en grenzen als niet-technisch recruiter
Recruiters en hiring managers zonder programmeervaardigheid kunnen een groot deel van het selectieproces goed begeleiden. Ze zijn niet de aangewezen persoon om technische inhoud te beoordelen. Dat onderscheid is belangrijk, want de verleiding is groot om op basis van een overtuigend verhaal conclusies te trekken over technische vaardigheid.
Let op: AI-fraude bij developer-selectie
Een groeiend praktijkprobleem in 2025 en 2026: kandidaten die AI gebruiken om door selectiegesprekken heen te komen terwijl ze de functie technisch niet aankunnen. Denk aan onzichtbare prompters die realtime antwoorden influisteren tijdens video-interviews, of take-home opdrachten die volledig door AI zijn gemaakt maar door de kandidaat als eigen werk worden gepresenteerd. The Pragmatic Engineer documenteerde in 2025 meerdere gevallen waarbij bedrijven bijna een aanbod deden aan iemand die de rol technisch volledig ontbeerde.
Praktische tegenmaatregelen: voer altijd een live nagesprek over de werkproef waarbij je specifieke keuzes uitvraagt, verifieer identiteit voordat je een aanbod doet, en overweeg voor cruciale rollen een fysiek gesprek of een live coding-sessie waarbij je het scherm meekijkt. Een kandidaat die de kleur van een button niet kan aanpassen in de code die ze “zelf schreef”, is een reëel scenario.
De praktische taakverdeling: jij beoordeelt communicatie, redeneerproces, samenwerking en de aanpak van de werkproef. Een senior developer of tech lead beoordeelt de technische correctheid van redenering en code, de kwaliteit van de oplossing en het gebruik van AI-tools. Dat is geen optionele toevoeging aan het proces. Het is een vereiste als je iemand aanneemt voor een rol die je zelf niet kunt uitvoeren.
Stel tijdens het gesprek vragen als: “Leg dit uit alsof ik geen developer ben.” Een kandidaat die dat niet kan, heeft moeite met de samenwerking die de meeste softwarerollen vragen. Maar klinkt de uitleg technisch correct terwijl je het niet kunt verifiëren, gebruik dat als aanleiding om dieper door te vragen via de tech lead, niet als bevestiging.
Let ook op confidence bias: zelfverzekerd overkomen staat los van daadwerkelijke vaardigheid. Gebruik een gevalideerd assessment als aanvulling als je het beeld wilt aanscherpen. Bekijk ook hoe je een assessment kiest dat past bij de specifieke rol.
Dunning-Kruger in developer-selectie
Een kandidaat kan zeer gestructureerd en overtuigend praten over een technisch proces, terwijl de inhoud ronduit onjuist is. Als recruiter zonder technische achtergrond heb je geen referentiekader om dat te herkennen. Goede communicatie is een noodzakelijke voorwaarde voor een sterke developer, maar geen bewijs van technische kwaliteit. Behandel jouw beoordeling van het gesprek als aanvullend signaal, niet als eindoordeel.
Drie fouten die je selectie ondermijnen
Fout 1: de opdracht te lang maken. Een take-home opdracht van meer dan vier uur kost je goede kandidaten. Sterke developers hebben opties en haken af. Houd het op maximaal twee uur.
Fout 2: AI verbieden tijdens de opdracht. Dat toets je op een vaardigheid die in de praktijk niet bestaat. Laat AI-gebruik toe, maar alleen in combinatie met een verplicht live nagesprek. Een take-home zonder debrief geeft geen bruikbaar beeld meer.
Fout 3: selecteren op cv-trefwoorden. Bekendheid met een specifieke programmeertaal zegt weinig over probleemoplossend vermogen. Beoordeel op aanpak, niet op technologielijstjes.
Wil je dieper ingaan op de valkuilen die selectiegesprekken ondermijnen? Lees dan over de 20 cognitieve biases bij selectiegesprekken die de kwaliteit van je beslissingen beïnvloeden. Veel van die biases spelen ook bij technische rollen, en juist bij het selecteren van een software developer is dat risico groot.
Developers selecteren die presteren
Leer hoe je technisch talent werft en beoordeelt, ook zonder technische achtergrond.
Veelgestelde vragen over selecteren van developers
Hoe selecteer je een software developer zonder technische kennis?
Als niet-technisch recruiter beoordeel je communicatie, redeneerproces en samenwerking. De technische inhoud laat je beoordelen door een senior developer of tech lead. Die taakverdeling is geen optionele stap, maar een vereiste. Een kandidaat kan overtuigend overkomen terwijl de technische redenering onjuist is. Zonder referentiekader herken je dat niet. Jouw beoordeling is een aanvullend signaal, geen eindoordeel over technische geschiktheid.
Heeft een coding test nog zin bij het selecteren van een software developer?
Dat hangt af van de rol. Voor posities waarbij performance, geheugenoptimalisatie of wiskundige complexiteit centraal staan, blijft algoritmisch inzicht relevant. AI genereert regelmatig werkende code die slecht presteert op resources. Een developer zonder grondige kennis herkent die problemen niet. Voor de meeste andere softwarerollen geldt: een abstracte puzzel geeft weinig voorspellende waarde. Wat beter werkt, is een praktische werkproef op basis van echt werk, waarbij AI-gebruik is toegestaan.
Hoe lang mag een selectieproces voor een developer duren?
Een selectieproces van meer dan drie weken kost je sterke kandidaten. Streef naar: een eerste gesprek binnen een week na sollicitatie, een werkproef van maximaal twee uur, en een afrondend gesprek met de tech lead. Drie tot vier contactmomenten in twee weken is realistisch en respectvol voor de kandidaat.
Wat is een goede werkproef voor een software developer?
Een goede werkproef voor een developer is gebaseerd op echt werk: bestaande code beoordelen, een kleine aanpassing doorvoeren of een technische specificatie analyseren. Beperk de tijdsinvestering tot maximaal twee uur en geef expliciet toestemming voor het gebruik van AI-tools. Verplicht daarna een live nagesprek: vraag specifiek door op de gemaakte keuzes. Zonder dat nagesprek is de werkproef geen betrouwbaar selectie-instrument, omdat je geen onderscheid kunt maken tussen iemand die de code begrijpt en iemand die AI-output heeft ingeleverd zonder dat te kunnen doorgronden.
Welke vragen stel je in een selectiegesprek met een software developer?
Stel situatievragen op basis van de STARR-methode: “Beschrijf een project waarbij je een fout in je eigen code pas laat ontdekte. Wat deed je?” en “Hoe gebruik je AI in je dagelijkse werk, en wanneer vertrouw je het resultaat niet?” Vraag ook naar samenwerking: “Hoe ga je om met feedbackgesprekken over code met iemand die het niet met je eens is?” Deze vragen geven meer inzicht dan technische kennistoetsen.
Over de auteur
Jacco Valkenburg is recruitment architect en auteur van Eerlijk over selectie. Hij heeft ruim 25 jaar ervaring in IT recruitment en tientallen interim recruitment projecten op dat gebied succesvol afgerond.
