Een low-code developer lijkt op papier vaak sneller gevonden dan een traditionele softwaredeveloper. Het lastige begint pas daarna: low-code developer screenen, waar op letten als de cv’s vol staan met dezelfde termen, certificaten en platformnamen? Juist bij bedrijfskritische applicaties maakt een verkeerde keuze direct verschil in delivery, onderhoud en samenwerking met de business.
Low-code developer screenen: waar op letten in de praktijk
De eerste fout die veel organisaties maken, is low-code als één profiel behandelen. Iemand met jaren ervaring in Mendix is niet automatisch inzetbaar op OutSystems of Thinkwise. Ook binnen Microsoft Power Platform zit veel verschil tussen een kandidaat die vooral Power Apps bouwt en iemand die complexe oplossingen neerzet met Dataverse, Power Automate, integraties en governance.
Screenen begint daarom niet bij beschikbaarheid of tarief, maar bij de precieze context van de rol. Gaat het om nieuwbouw of doorontwikkeling? Werkt de developer in een productteam, consultancysetting of enterprise-omgeving met strakke security-eisen? Is er vooral behoefte aan snelheid, of juist aan iemand die technische keuzes kan onderbouwen richting architectuur en stakeholders? Zonder dat kader voer je al snel gesprekken op een te algemeen niveau.
Een goed cv is hooguit een startpunt. In low-code zegt projectcontext vaak meer dan een functietitel. Een candidate kan zichzelf senior noemen, maar als de projecten vooral intern en kleinschalig waren, zegt dat nog weinig over geschiktheid voor een omgeving met meerdere scrumteams, integratielandschappen en strenge releaseprocessen.
Kijk eerst naar platformdiepte, niet alleen naar platformnaam
Platformervaring moet concreet zijn. Vraag niet alleen óf iemand met Mendix, OutSystems of Power Platform heeft gewerkt, maar hoe diep die ervaring gaat. Heeft de developer zelf applicaties ontworpen en gebouwd, of vooral bestaande flows aangepast? Was hij of zij verantwoordelijk voor domeinmodellering, security, deployment en performance, of lag dat bij anderen?
Bij senior profielen wil je horen hoe iemand technische keuzes maakt binnen de beperkingen van het platform. Een developer die alleen features oplevert, is iets anders dan iemand die ook begrijpt wanneer low-code nog passend is en wanneer een custom component, integratie of andere architectuurkeuze nodig is. Dat onderscheid zie je niet altijd terug in een cv, maar wel in een inhoudelijk gesprek.
Certificeringen kunnen helpen, maar ze zijn geen bewijs van senioriteit. Ze laten zien dat iemand de basis of een bepaald niveau van het platform beheerst. Ze vertellen minder over hoe iemand omgaat met legacy, stakeholderdruk of een applicatie die in productie al jaren bedrijfskritisch is. Certificaten zijn dus relevant, maar nooit doorslaggevend.
Vragen die platformervaring echt toetsen
Goede screeningvragen gaan over gemaakte keuzes. Vraag bijvoorbeeld welke integraties iemand zelf heeft opgezet, hoe omgegaan is met performanceproblemen, hoe rollen en rechten zijn ingericht of hoe deployments zijn georganiseerd tussen ontwikkel-, test- en productieomgevingen. Dan hoor je snel of iemand uit de praktijk praat of vooral theorie herhaalt.
Ook interessant is hoe een developer samenwerkt met business en beheer. Low-code zit vaak dicht op de operatie. Iemand die technisch sterk is maar requirements niet scherp krijgt, veroorzaakt alsnog vertraging.
Let op het verschil tussen bouwen en leveren
Veel organisaties zoeken een developer, maar hebben in werkelijkheid iemand nodig die kan leveren binnen een team en organisatiecontext. Dat klinkt subtiel, maar het verschil is groot. Een technisch vaardige low-code developer is niet automatisch effectief in een omgeving met veel afstemming, strakke deadlines en meerdere belangen.
Let daarom op eigenaarschap. Neemt iemand verantwoordelijkheid voor de kwaliteit van wat live gaat? Denkt de kandidaat mee over onderhoudbaarheid, documentatie en overdraagbaarheid? Of ligt de focus vooral op snel iets werkend krijgen? In een demo lijkt dat laatste aantrekkelijk, maar op langere termijn wordt het vaak duurder.
Voor interim-opdrachten weegt dit nog zwaarder. Dan moet iemand vaak snel instappen, de bestaande situatie lezen en zonder lange inwerktijd productief zijn. Een freelancer met sterke platformkennis maar weinig gevoel voor teamdynamiek of stakeholdermanagement kan dan alsnog minder effectief zijn dan een inhoudelijk iets lichter profiel met meer organisatiesensitiviteit.
Communicatieve vaardigheden zijn geen bijzaak
Bij low-code zitten business en development dichter op elkaar dan in veel traditionele ontwikkelomgevingen. Daardoor zijn communicatieve vaardigheden niet nice to have, maar onderdeel van het vak. Een developer moet requirements kunnen uitvragen, onduidelijkheden benoemen en soms ook simpelweg nee durven zeggen tegen onrealistische wensen.
Screen dit heel concreet. Kan iemand uitleggen waarom een oplossing is gekozen in taal die ook een niet-technische stakeholder begrijpt? Kan de kandidaat voorbeelden geven van lastige gesprekken over scope, planning of kwaliteit? Dan krijg je zicht op de vraag of iemand alleen bouwt, of ook echt bijdraagt aan voorspelbare delivery.
Voor consultants en senior developers is dit helemaal cruciaal. Daar verwacht je vaak dat zij richting geven, junioren meenemen en opdrachtgevers inhoudelijk meenemen in keuzes. Wie dat niet kan, blijft hangen op uitvoerend niveau – ook als de technische basis goed is.
Teamfit en cultuurfit bepalen of iemand blijft
Een inhoudelijk passend profiel kan alsnog mislukken als de teamfit ontbreekt. Zeker in low-code teams, waar samenwerking vaak intensief is en lijnen kort zijn, werkt een mismatch snel door in kwaliteit en snelheid. De vraag is dus niet alleen of iemand het platform beheerst, maar ook hoe diegene werkt.
Heeft de kandidaat structuur nodig of floreert hij of zij juist in een veranderlijke omgeving? Past iemand beter in een volwassen enterprise-team met governance en vaste processen, of juist in een scale-up waar veel nog wordt ingericht? Beide kunnen goede developers zijn, maar niet in dezelfde context.
Vraag daarom naar werkwijze en voorkeuren, niet alleen naar ervaring. Hoe gaat iemand om met feedback? Hoe wordt samengewerkt met testers, product owners en architects? Wat vindt de kandidaat prettig in een team en waar haakt iemand op af? Juist die antwoorden helpen om een duurzame match te maken.
Let op signalen van overschatting
In een krappe markt presenteren kandidaten zich soms breder dan hun praktijkervaring rechtvaardigt. Dat is niet altijd bewust, maar wel risicovol. Termen als solution architect, lead developer of senior consultant worden in low-code vrij snel gebruikt. De inhoud achter die titel verschilt sterk per organisatie.
Toets daarom op voorbeelden. Heeft iemand echt technische richting bepaald, of vooral een coördinerende rol gehad? Is er gewerkt aan bedrijfskritische applicaties met echte gebruikersvolumes, of vooral aan prototypes en interne tools? Hoe meer je doorvraagt op context, verantwoordelijkheden en resultaten, hoe minder ruimte er blijft voor vaagheid.
Een ander signaal is als een kandidaat alleen succesverhalen vertelt. Sterke professionals kunnen meestal ook benoemen wat misging, welke keuzes achteraf anders hadden gekund en waar de grenzen van hun expertise liggen. Dat soort zelfinzicht is vaak een beter teken dan een perfect gepolijst verhaal.
Stem je screening af op vaste werving of interim
Niet elk selectieproces hoeft hetzelfde te zijn. Bij vaste werving kijk je sterker naar groeipotentieel, leervermogen en langetermijnfit. Bij interim draait het vaker om directe inzetbaarheid, zelfstandigheid en snelheid van impact. Dat vraagt dus ook om andere accenten in je screening.
Voor loondienst is het logisch om te kijken of iemand zich binnen het gekozen platform verder kan ontwikkelen, of een teamrol past en of er motivatie is voor de specifieke omgeving. Voor freelance opdrachten wil je sneller zekerheid over beschikbaarheid, bewezen vergelijkbare inzet en hoe snel iemand productief kan zijn.
Wie die twee door elkaar haalt, loopt vertraging op. Dan voer je óf te veel gesprekken voor een interim-opdracht, óf je selecteert voor een vaste rol te veel op korte termijn en te weinig op duurzame aansluiting.
Wanneer specialistische screening het verschil maakt
Juist omdat low-code een niche is, werkt een generieke intake vaak niet goed genoeg. Als een gesprekspartner het verschil tussen platformen, teamrollen en senioriteitsniveaus niet scherp heeft, blijven gesprekken te algemeen. Dan worden kandidaten doorgestuurd die technisch nét niet passen of communicatief onvoldoende sterk zijn voor de rol.
Specialistische screening voorkomt dat. Niet door het proces zwaarder te maken, maar door eerder de juiste vragen te stellen. Dat scheelt tijd aan de voorkant en voorkomt kostbare missers achteraf. Voor organisaties die snel capaciteit nodig hebben, is dat vaak het verschil tussen een bruikbare shortlist en veel ruis.
Bij Schouten Low-Code Recruitment ligt die focus daarom op inhoudelijke intake, platformspecifieke selectie en een scherpe beoordeling op communicatie en teamfit. Zeker bij nicheprofielen op Mendix, OutSystems, Thinkwise en Microsoft Power Platform is dat geen luxe, maar een voorwaarde om tempo en kwaliteit te combineren.
De beste screening is concreet
Wie een low-code developer wil beoordelen, moet wegblijven van algemene termen als senior, allround en hands-on. Die woorden zeggen pas iets als je ze vult met projectcontext, technische diepgang, communicatieve rol en teamomgeving. Hoe concreter je screening, hoe groter de kans op een kandidaat die niet alleen kan starten, maar ook echt blijft toevoegen.
Een goed gesprek levert dan meer op dan een mooi cv ooit kan. En precies daar win je tijd: niet door sneller te gokken, maar door eerder scherp te zijn. Wil je sparren over een low-code rol of een intake plannen, dan helpt een inhoudelijk gesprek meestal sneller dan nog een extra vacaturetekst.