Een kandidaat die “ervaring met low-code” op het cv zet, kan in de praktijk van alles bedoelen. Van een paar interne flows in Power Platform tot jarenlange delivery op Mendix of OutSystems in bedrijfskritische omgevingen. Juist daarom is platformervaring toetsen bij sollicitanten geen formaliteit, maar een harde voorwaarde als je verkeerde hires, vertraging in projecten en ruis in het team wilt voorkomen.
Bij low-code recruitment gaat het verschil vaak niet zitten in algemene ontwikkelervaring, maar in de diepte van platformkennis. Een developer kan technisch sterk zijn en toch tijd nodig hebben om productief te worden op een ander platform. Andersom kan iemand met minder jaren ervaring juist direct waarde leveren als hij of zij precies de juiste certificeringen, delivery-context en samenwerkingservaring meebrengt. Wie daar in het selectieproces te globaal naar kijkt, koopt snelheid in op papier en levert in de praktijk in op kwaliteit.
Waarom platformervaring toetsen bij sollicitanten zo vaak misgaat
De klassieke fout is dat organisaties platformervaring te breed interpreteren. “Low-code is low-code” klinkt logisch, maar klopt zelden als je teams bouwt rond specifieke stacks, governance-eisen en deliverymodellen. Mendix, OutSystems, Thinkwise en Microsoft Power Platform vragen elk om een andere manier van modelleren, deployen, samenwerken en beheren.
Daar komt bij dat functietitels weinig zekerheid geven. Een “low-code developer” kan hands-on bouwen, maar ook vooral configureren, requirements ophalen of beheer doen. Een consultant kan inhoudelijk sterk zijn, maar minder geschikt voor een interne productrol. En een solution architect kan uitstekend richting geven, terwijl je eigenlijk iemand zoekt die morgen user stories wegwerkt in een bestaand scrumteam.
Wie alleen op titel, aantal jaren ervaring of certificaten selecteert, mist de kern. Je wilt weten wat iemand echt heeft gebouwd, in welke context, met hoeveel zelfstandigheid en met welk resultaat.
Waar je wél op moet toetsen
Goede beoordeling van platformervaring begint met scherpte in de vacature. Niet alleen welk platform centraal staat, maar ook welk type werk. Zoek je iemand voor greenfield ontwikkeling, doorontwikkeling, integraties, governance of teamlead taken? Zonder die duidelijkheid stel je in gesprekken al snel de verkeerde vragen.
Daarna kijk je naar vier lagen. De eerste is platformdiepte. Heeft de kandidaat daadwerkelijk gewerkt met de modules, componenten en deploymentvraagstukken die voor jouw omgeving relevant zijn? De tweede is context. Er is verschil tussen een intern verbeterproject en een bedrijfskritische applicatie met veel gebruikers, complexe security en meerdere koppelingen. De derde laag is rolvolwassenheid. Werkte iemand onder strakke begeleiding of trok hij of zij zelf oplossingen, refinements en stakeholderafstemming? De vierde is overdraagbaarheid. Soms is ervaring op een aanpalend platform prima, maar dan moet je eerlijk zijn over de leercurve en de ruimte die je team daarvoor heeft.
Die vier lagen samen geven een veel betrouwbaarder beeld dan een cv ooit kan doen.
Platformervaring toetsen bij sollicitanten in het gesprek
Het inhoudelijke interview hoeft geen technisch kruisverhoor te zijn, maar wel concreet. Vermijd brede vragen als “Vertel eens over je ervaring met Mendix”. Die leveren meestal ingestudeerde antwoorden op. Beter is om terug te gaan naar een specifiek project en dat uit te vragen.
Vraag bijvoorbeeld welke applicatie iemand heeft gebouwd, wat de businessdoelstelling was, hoeveel gebruikers er waren en welke onderdelen hij of zij zelf heeft opgepakt. Vraag ook hoe integraties zijn ingericht, hoe omgegaan werd met performance, security of releasebeheer, en waar het project technisch lastig werd. Dan hoor je snel of iemand vanuit eigen ervaring spreekt of vooral het verhaal van het team herhaalt.
Interessant is ook hoe een kandidaat praat over keuzes. Waarom is een bepaalde oplossing gekozen? Wat werkte achteraf minder goed? Waar zat technische schuld? Kandidaten met echte platformervaring kunnen bijna altijd concreet reflecteren. Kandidaten die oppervlakkig betrokken waren, blijven vaak hangen in algemeenheden.
Let daarnaast op de taal die iemand gebruikt. Niet om op jargon af te rekenen, maar om vakvolwassenheid te herkennen. Iemand die echt op een platform heeft geleverd, spreekt meestal precies over componenten, deploymentstappen, afhankelijkheden en samenwerking met business of testers. Dat klinkt anders dan iemand die alleen “mee heeft gedraaid”.
Certificeringen zijn nuttig, maar niet doorslaggevend
Certificeringen helpen om basiskennis en leerlijn te duiden. Zeker bij platformen waar trainingen en niveaus goed zijn ingericht, geven ze houvast. Maar een certificaat is geen garantie voor productiviteit in jouw team. Er zijn kandidaten met meerdere badges die nog weinig hebben gebouwd in complexe omgevingen. Er zijn ook sterke professionals die minder gecertificeerd zijn, maar wel jarenlang delivery hebben gedaan.
Gebruik certificeringen dus als signaal, niet als eindbeoordeling. Vooral de combinatie telt: certificaat plus recente praktijk plus duidelijke projectvoorbeelden.
Een case werkt alleen als die realistisch is
Veel organisaties zetten een case of opdracht in om platformervaring te toetsen bij sollicitanten. Dat kan goed werken, mits de opdracht lijkt op het echte werk. Een kunstmatige test met losse puzzels zegt weinig over functioneren in een team, omgaan met requirements of keuzes maken onder tijdsdruk.
Een goede case is compact en relevant. Denk aan het uitwerken van een eenvoudige businessflow, het beoordelen van een oplossingsrichting of het bespreken van een bestaande applicatie-opzet. Zo toets je niet alleen technische vaardigheid, maar ook denkproces, communicatie en prioritering.
Voor senior profielen is een gesprek over een eerder project vaak waardevoller dan een lange thuisopdracht. Zeker in een krappe markt haken sterke kandidaten snel af als het proces onnodig zwaar wordt. Snelheid blijft belangrijk, maar snelheid zonder inhoud kost uiteindelijk meer tijd.
De valkuil van platformverwantschap
Een veelgestelde vraag is of ervaring op het ene platform voldoende is voor een rol op het andere. Het eerlijke antwoord is: soms. Een ervaren OutSystems developer kan bijvoorbeeld bepaalde concepten sneller oppakken op Mendix dan iemand zonder low-code achtergrond. Maar dat betekent niet automatisch dat die persoon direct inzetbaar is in een team met strakke deadlines.
Het hangt af van de rol, de senioriteit van het team en de ruimte om in te leren. Zoek je een medior die vanaf week één zelfstandig stories oppakt in een bestaande Mendix-omgeving? Dan wil je meestal echte Mendix-ervaring. Zoek je een bredere consultant of architect met sterke low-code basis en een team dat kan begeleiden? Dan kan platformverwantschap wel degelijk interessant zijn.
Maak die afweging expliciet. Anders ontstaan misverstanden tussen hiring manager, recruiter en kandidaat, met teleurstelling na de start als gevolg.
Vergeet communicatie en teamfit niet
Bij low-code zijn techniek en business vaak nauwer met elkaar verweven dan in traditionele developmentrollen. Daarom moet je platformervaring altijd in samenhang beoordelen met communicatieve vaardigheden. Kan iemand requirements scherp krijgen? Durft iemand terug te praten als een oplossing niet schaalbaar is? Kan een developer uitleggen waarom een keuze impact heeft op beheer, security of doorlooptijd?
Ook teamfit is geen zacht criterium. In kleine low-code teams heeft één verkeerde hire direct effect op delivery. Iemand kan inhoudelijk sterk zijn, maar niet passen in een omgeving met veel stakeholdercontact, weinig documentatie of juist strakke enterprise-governance. Dat moet je in gesprekken testen met echte situaties, niet met standaardvragen over “sterke en zwakke punten”.
Hoe je als organisatie sneller en beter selecteert
De kwaliteit van je beoordeling valt of staat met de intake aan de voorkant. Als niet helder is welke platformervaring echt nodig is, blijft selectie onnodig breed. Bespreek daarom vooraf welke projecten lopen, welke taken in de eerste drie maanden op tafel liggen en waar de nieuwe collega direct op moet kunnen meedraaien.
Zet daarna een compact proces neer. Een eerste gesprek om context en motivatie te toetsen, een inhoudelijk gesprek met iemand die het platform echt begrijpt, en alleen waar nodig een korte case. Meer rondes zijn zelden beter. Wat helpt, is een vaste beoordelingslijn per kandidaat: platformdiepte, projectcontext, zelfstandigheid, communicatie en teamfit. Dan vergelijk je niet op onderbuikgevoel, maar op relevante criteria.
Voor organisaties die weinig volume in low-code hiring hebben, is dat vaak precies waar het misgaat. Er wordt wel zorgvuldig gesproken, maar niet altijd scherp genoeg op platformniveau. Een gespecialiseerde partij als Schouten Low-Code Recruitment kan daar tempo en precisie in brengen, juist omdat de nuances tussen rollen en platformen al aan de voorkant worden uitgefilterd.
Wat kandidaten hiermee winnen
Ook voor kandidaten is dit beter. Wie eerlijk en concreet wordt bevraagd op platformervaring, komt sneller op de juiste plek terecht. Dat voorkomt rollen waarin de verwachting niet klopt, de technische omgeving tegenvalt of de leercurve onderschat is. Een duurzame match begint niet bij een mooi cv, maar bij een realistisch beeld van wat iemand kan, wil en direct kan bijdragen.
De beste gesprekken over platformervaring voelen daarom niet als een test, maar als een inhoudelijke intake. Je wilt begrijpen wat iemand echt heeft gedaan en wat jouw team echt nodig heeft. Als die twee scherp naast elkaar liggen, wordt selecteren sneller, eerlijker en merkbaar beter.
Wie low-code professionals aanneemt voor bedrijfskritische applicaties, doet er goed aan om minder te vertrouwen op algemene profielen en meer op aantoonbare praktijk. Dat maakt je selectie misschien iets kritischer aan de voorkant, maar het scheelt veel herstelwerk achteraf.