Je staat op het punt een software developer te interviewen. Je weet hoe je een goed gesprek voert, maar de technische kant? Dat is het terrein van de hiring manager. Toch verwacht iedereen dat jij de juiste sollicitatievragen voor een software developer paraat hebt.
Goed nieuws: je hoeft de code niet te begrijpen om een sterk gesprek te voeren. De vragen die het meeste onthullen over een developer zijn zelden puur technisch. Ze gaan over hoe iemand denkt, samenwerkt en omgaat met problemen.
Hier vind je concrete vragen per competentiegebied, een kort kader om antwoorden te beoordelen en signalen waarop je moet letten.
Van onzeker naar zelfverzekerd voor het gesprek met een developer
Concrete vragen, een scoringskader en waarschuwingssignalen voor recruiters zonder technische achtergrond.
Waarom een IT-gesprek anders is dan andere gesprekken
Een sollicitatiegesprek met een software developer voer je in een andere context dan de meeste andere gesprekken. Er is een kennisasymmetrie: de kandidaat weet technisch veel meer dan jij. Dat voelt ongemakkelijk, maar het hoeft geen probleem te zijn zolang je je eigen rol helder hebt.
Daarbij komt dat de IT-arbeidsmarkt sterk gesplitst is. Senior developers en specialisten in AI-gerelateerde vakgebieden worden door meerdere bedrijven tegelijk benaderd en beoordelen ook jou en de organisatie. Een gesprek dat aanvoelt als een verhoor werkt averechts. Junior developers en generalisten opereren in een minder krappe markt, maar ook daar geldt: getalenteerde juniors hebben nog steeds keuze. Enthousiasmeren blijft nodig, ongeacht het ervaringsniveau van de kandidaat.
Jouw taak is niet om de techniek te doorgronden. Jouw taak is om te beoordelen of deze persoon past bij het team, de manier van werken en de rol. En om de kandidaat een eerlijk beeld te geven van de organisatie. Dat is een vaardigheid die jij wΓ©l hebt, en die de hiring manager lang niet altijd heeft.
Drie niveaus van beoordeling
De juiste sollicitatievragen voor een software developer kiezen begint met weten wat je per niveau wilt meten. Voor elk niveau zijn andere vragen en andere gesprekspartners nodig.
- Niveau 1: Technische competenties β wat iemand kan. Beoordeel dit samen met de hiring manager of via een technische werkproef.
- Niveau 2: Samenwerking en communicatie β hoe iemand werkt. Dit is jouw terrein als recruiter.
- Niveau 3: Leervermogen en groei β hoe iemand zich ontwikkelt. Ook jouw terrein.
Als recruiter zonder technische achtergrond focus je op niveau 2 en 3. Voor niveau 1 schakel je de hiring manager in, of zet je een technische werkproef in als selectiemiddel. Een werkproef geeft een betrouwbaarder beeld van technische vaardigheden dan elke vraag ooit kan geven, omdat je gedrag in context meet in plaats van een zelfpresentatie.
Sollicitatievragen voor een software developer: per competentiegebied
Technische competenties toetsen: ook zonder zelf technicus te zijn
Je hoeft technische antwoorden niet inhoudelijk te beoordelen. Wat je beoordeelt: kan de kandidaat de techniek uitleggen zodat jij het begrijpt? Dat geeft informatie over hoe iemand omgaat met niet-technische gesprekspartners. Maar vlot praten en goed samenwerken zijn niet hetzelfde. Sommige developers β en in de IT-sector is de vertegenwoordiging van neurodivergente mensen hoger dan gemiddeld β communiceren minder vloeiend in een live gesprek, maar werken in de praktijk uitstekend via documentatie, code reviews of tickets. Een minder vlotte prater in het gesprek kan in een gestructureerde werkomgeving een absolute topper zijn. Beoordeel daarom communicatievaardigheid in context, niet als absolute drempel.
- “Leg me uit wat je bij je vorige werkgever hebt gebouwd, alsof ik geen developer ben.”
- “Wat was technisch het lastigste aan je laatste project? Hoe heb je dat opgelost?”
- “Welke technische keuze heb je gemaakt die je achteraf anders zou aanpakken? Wat weet je nu dat je toen niet wist?”
Bij competentiegerichte selectie gaat het niet om of iemand een specifieke programmeertaal kent, maar om hoe iemand redeneert en problemen aanpakt. Die capaciteit zegt meer over toekomstig succes dan een specifieke toolset.
Samenwerking en communicatie in een development team
Software wordt zelden solo gebouwd. Hoe iemand omgaat met feedback, meningsverschillen en samenwerking in een team is een van de sterkste voorspellers voor succes op de lange termijn. Gebruik de STARR-methode om concrete antwoorden te krijgen in plaats van meningen over zichzelf.
- “Beschrijf een situatie waarin een codereview leidde tot discussie. Wat was jouw rol daarin?”
- “Hoe ga je om met een collega die structureel andere technische keuzes maakt dan jij?”
- “Vertel over een moment dat je iets moest uitleggen aan iemand zonder technische achtergrond. Hoe heb je dat aangepakt?”
- “Wat is jouw voorkeursstijl in een team: zelfstandig werken of veel afstemmen? Geef een concreet voorbeeld.”
De vragen over communicatie zijn ook een directe test in het gesprek zelf. Luister niet alleen naar het antwoord, maar naar hoe iemand het brengt.
Leervermogen en professionele groei
De technologie in de IT-sector verandert snel. Een developer die niet actief leert, raakt over twee jaar achterhaald. Leervermogen is daarmee een van de meest relevante competenties voor deze doelgroep. Let op het verschil tussen iemand die leert omdat het wordt verwacht, en iemand die nieuwsgierig is van nature.
- “Welke technologie of aanpak heb je het afgelopen jaar zelf opgepakt, buiten je werk om?”
- “Wat was de laatste keer dat je iets in je werk hebt geleerd van een fout? Wat was die fout?”
- “Hoe houd je bij wat er speelt in jouw vakgebied?”
- “Wanneer heb je voor het laatst iets nieuws geleerd dat je aanpak heeft veranderd?”
Meer over welke vragen je aan een sollicitant stelt en welke je beter kunt vermijden, lees je in dit artikel.
Hoe beoordeel je de antwoorden?
Een goed antwoord op een gedragsgerichte sollicitatievraag voor een software developer is concreet, specifiek en beschrijft een echte situatie. De kandidaat vertelt wat er was, wat ze hebben gedaan en wat het resultaat was. Dat is de kern van de STARR-structuur: Situatie, Taak, Actie, Resultaat en Reflectie.
Een zwak antwoord is vaag, generiek of beschrijft wat iemand “altijd doet” in plaats van wat ze eenmalig hebben gedaan. “Ik ben altijd goed in samenwerken” is geen antwoord op een gedragsgerichte vraag. Het is een mening. Vraag door: “Kun je dat illustreren met een concreet voorbeeld?” Herhaal dit zo vaak als nodig.
Voor technische vragen geldt: beoordeel de helderheid van de uitleg, niet de inhoud. Heeft de kandidaat jou kunnen meenemen in het verhaal? Dat is informatie over communicatievaardigheid.
Wees ook alert op cognitieve biases in selectiegesprekken die je oordeel kunnen vertekenen, zoals de neiging om iemand positiever te beoordelen die op jou lijkt of sterk overkomt in de eerste vijf minuten.
Waarschuwingssignalen die je niet mag missen
Sommige antwoorden verdienen extra aandacht. Niet als bewijs van ongeschiktheid, maar als aanleiding om verder te vragen. Hieronder vier patronen die je regelmatig tegenkomt in IT-gesprekken.
Patronen die vragen om doorvragen
Geen van deze patronen is op zichzelf een afwijzingsgrond. Ze zijn een signaal dat je dieper moet vragen voordat je een oordeel vormt.
- “Wij” als standaardtaal: Veel kandidaten zeggen “wij hebben dat gebouwd” zonder dat ze persoonlijke bijdrage willen verhullen. In hechte Agile teams of bepaalde culturen is “ik” nemen voor teamresultaten ongebruikelijk. Vraag daarom neutraal door: “Wat was specifiek jouw aandeel daarin?” β dat is geen signaal van iets negatiefs, maar een verzoek om verduidelijking.
- Structurele kritiek op vorige werkgevers: Een keer kritisch reflecteren is gezond. Herhaalde negatieve verhalen over anderen zijn een patroon om te onderzoeken, niet te negeren.
- Geen antwoord op de reflectievraag: Iemand die nooit iets anders zou doen, leert niet van ervaring. Vraag door: “Was er niets wat je achteraf anders zou aanpakken?”
- Vaagheid over technische keuzes: Een developer die niet kan uitleggen waarom ze een bepaalde keuze hebben gemaakt, heeft die keuze mogelijk niet zelf gemaakt of niet volledig begrepen.
- Opvallend vlotte antwoorden bij remote gesprek: Developers gebruiken in hun dagelijkse werk voortdurend AI-tools. Dat is normaal en zegt op zichzelf niets negatiefs. Wat wΓ©l informatie geeft: een kandidaat die AI live raadpleegt maar dat niet transparant maakt, terwijl jij daadwerkelijke werkervaring wilt toetsen. Maak het bespreekbaar: “Ik zie dat je iets opzoekt β kun je me vertellen hoe die tool je helpt bij dit soort problemen?” Dat gesprek zegt vaak meer over senioriteit dan het antwoord zelf.
Meer over het voorkomen van selectiefouten lees je in het artikel over veelgemaakte fouten bij werving en selectie.
AI-gebruik in het gesprek: wantrouwen of bespreekbaar maken?
Developers gebruiken dagelijks AI-tools. Het is geen rood vlag als iemand dat ook in een gesprek doet. Wat je wΓ©l wilt toetsen is of iemand zelfstandig kan redeneren en eigen ervaringen heeft. Maak het daarom bespreekbaar in plaats van het te verbieden. Een werkproef op locatie of met gedeeld scherm geeft sowieso een betrouwbaarder beeld van technische kennis dan een remote vraagrondje.
Ontdek een IT Recruitment strategie die werkt
Leer hoe je IT-vacatures snel invult, ook in een krappe markt. Van sourcingstrategie tot het selectieproces.
Veelgestelde vragen over sollicitatievragen voor een software developer
Welke vragen stel je bij een sollicitatiegesprek met een software developer?
Bij een sollicitatiegesprek met een software developer stel je vragen op drie niveaus: technische competenties, samenwerking en leervermogen. Als recruiter zonder technische achtergrond focus je op gedragsgerichte vragen. Voorbeelden zijn: “Beschrijf een situatie waarin je het niet eens was met een technische keuze van een collega. Wat heb je gedaan?” en “Welke technologie heb je het afgelopen jaar zelf opgepakt, buiten je werk om?” Laat de hiring manager de technische inhoud beoordelen.
Hoe beoordeel ik een software developer als ik geen technische kennis heb?
Zonder technische kennis beoordeel je een software developer op communicatievaardigheid, samenwerking en leervermogen. Gebruik gedragsgerichte vragen gebaseerd op de STARR-methode. Vraag de kandidaat technische keuzes te verklaren zonder jargon: als ze dat niet kunnen, is dat zelf informatie. Laat de hiring manager de technische inhoud beoordelen, of gebruik een werkproef als objectief selectiemiddel.
Wat is het verschil tussen een technisch interview en een gedragsinterview?
Een technisch interview toetst de vakkennis van een developer, zoals programmeervaardigheden en probleemoplossend denken in code. Dat wordt afgenomen door een hiring manager of senior developer. Een gedragsinterview richt zich op hoe iemand heeft gehandeld in eerdere situaties: samenwerking, omgaan met feedback en druk. Recruiters voeren het gedragsinterview. Beide zijn nodig voor een volledig beeld van de kandidaat.
Hoe lang duurt een sollicitatiegesprek met een IT-kandidaat?
Een goed gesprek met een IT-kandidaat duurt 45 tot 60 minuten. Plan in die tijd ruimte voor drie Γ vier gedragsgerichte vragen met doorvragen, een korte toelichting op de rol en de organisatie, en tijd voor de vragen van de kandidaat. Combineer dit gesprek bij voorkeur met een aparte technische toets of werkproef op een ander moment in het proces.
Welke vragen mag je niet stellen bij een sollicitatiegesprek met een developer?
Bij een sollicitatiegesprek mag je geen vragen stellen over gezinssamenstelling, zwangerschap, religie, seksuele gerichtheid, nationaliteit of politieke opvattingen. Dit geldt ook voor IT-gesprekken. Vragen over beschikbaarheid, reistijd en werkvergunning zijn toegestaan als ze direct relevant zijn voor de functie. Vragen naar het huidige salaris zijn juridisch niet verboden, maar worden sterk afgeraden: de Europese richtlijn loontransparantie (in implementatie) beweegt hier nadrukkelijk van af en zal dit in de nabije toekomst aan banden leggen. Lees meer over de regels rondom sollicitatievragen.
Hoe herken je of een kandidaat AI gebruikt tijdens een remote gesprek?
Signalen dat een kandidaat een AI-tool raadpleegt tijdens een remote gesprek: antwoorden komen zonder aarzeling, zijn opvallend volledig en klinken als documentatie. Vraag direct door op de persoonlijke context: “Hoe werkte dat precies in jouw situatie?” en “Wat ging er mis?” Eigen ervaringen zijn onregelmatig en specifiek. Gegenereerde antwoorden zijn glad en algemeen. Overweeg bij technische toetsing een werkproef met gedeeld scherm of een gesprek op locatie.
Over de auteur
Jacco Valkenburg is recruitment architect en auteur 8 vakboeken. Hij heeft ruim 25 jaar IT recruitment ervaring en begeleidt organisaties onder andere bij het opzetten van selectieprocessen.
