Een cv met ‘Power Platform’ zegt nog weinig. Zeker als je iemand zoekt voor een bedrijfskritische omgeving, wil je weten of die kandidaat vooral een paar losse Power Apps heeft gebouwd, of echt begrijpt hoe je een schaalbare oplossing neerzet. De vraag hoe beoordeel je Power Platform ervaring komt daarom al vroeg in het selectieproces op tafel – en terecht.
Wie alleen op certificaten, functietitels of aantallen jaren stuurt, loopt risico. Power Platform is breed. Een kandidaat kan sterk zijn in Canvas Apps, maar beperkt in modelgedreven apps. Iemand anders is uitstekend in Power Automate, maar minder thuis in security, ALM of Dataverse. Goede beoordeling vraagt dus om onderscheid. Niet alleen tussen junior en senior, maar vooral tussen type ervaring, diepgang en context.
Hoe beoordeel je Power Platform ervaring in de praktijk?
De beste manier is om ervaring te beoordelen langs drie lijnen tegelijk: wat iemand heeft gebouwd, in welke omgeving dat gebeurde en welke rol die persoon daarin had. Pas als die drie helder zijn, kun je iets zinnigs zeggen over niveau en geschiktheid.
Een developer die vijf jaar Power Platform op het cv heeft staan, klinkt interessant. Maar als die vijf jaar vooral bestonden uit kleine afdelingsapps zonder koppelingen, releaseproces of beheerdruk, dan zegt dat weinig over inzetbaarheid in een enterprise-team. Andersom kan iemand met twee jaar ervaring al sterk zijn, als die in een volwassen delivery-omgeving heeft gewerkt met Dataverse, solution management, deployment pipelines en duidelijke governance.
Daarom begint een goed gesprek niet met techniek, maar met context. Vraag wat voor organisatie het was, hoeveel gebruikers de oplossing had, hoe kritisch het proces was en wie eigenaar was van het platform. Dan zie je snel of iemand in een experimentele setting heeft gewerkt of in een omgeving waar stabiliteit, security en overdraagbaarheid echt meetellen.
Kijk verder dan Power Apps alleen
Veel opdrachtgevers gebruiken ‘Power Platform’ als verzamelnaam, terwijl de inhoud van de rol specifieker is. De ene vacature draait om Canvas Apps en gebruikersgemak. De andere vraagt juist om Dataverse-modellering, modelgedreven apps, business rules en integraties. Weer een andere rol leunt zwaar op Power Automate, rapportage of governance.
Als je ervaring wilt beoordelen, moet je dus eerst je eigen behoefte scherp hebben. Zoek je iemand die snel een businessoplossing kan opleveren? Iemand die een bestaand platformlandschap kan professionaliseren? Of iemand die bruggen slaat tussen functionele vraag en technische inrichting? Zonder die scherpte beoordeel je kandidaten al snel op algemene indruk in plaats van op relevante ervaring.
Waar let je op bij echte Power Platform senioriteit?
Senioriteit zit zelden in het aantal schermen dat iemand heeft gebouwd. Het zit eerder in de keuzes erachter. Waarom koos iemand voor Dataverse en niet voor SharePoint-lijsten? Wanneer is een Canvas App logisch en wanneer juist niet? Hoe voorkom je dat een snelle oplossing over zes maanden een beheerprobleem wordt?
Een sterke Power Platform professional kan dat soort afwegingen uitleggen. Niet theoretisch, maar vanuit projecten. Je hoort dan dat iemand rekening houdt met licenties, security-rollen, performance, beheerlast, overdraagbaarheid en aansluiting op de Microsoft-stack. Dat is een ander gesprek dan alleen uitleggen welke connectoren er zijn.
Ook Application Lifecycle Management zegt veel. Kandidaten die ervaring hebben met solutions, omgevingsstrategie, versioning en deployments begrijpen meestal beter wat er nodig is in teams waar meerdere mensen aan hetzelfde landschap werken. Wie uitsluitend in één persoonlijke of informele omgeving heeft gebouwd, mist daar vaak nog praktijkdiepte.
Dataverse, integraties en governance zijn goede graadmeters
Wie Power Platform ervaring beoordeelt, doet er goed aan extra scherp te zijn op Dataverse. Niet omdat iedere rol daar zwaar op leunt, maar omdat kennis van datamodellering, relaties, security en businesslogica vaak laat zien of iemand verder kijkt dan de gebruikersinterface.
Integraties zijn een tweede graadmeter. Een kandidaat die heeft gewerkt met API-koppelingen, Azure-componenten, custom connectors of hybride landschappen begrijpt meestal beter waar Power Platform ophoudt en waar andere technologie nodig is. Dat voorkomt overschatting van het platform én van de kandidaat.
Governance is de derde. Denk aan DLP policies, omgevingsbeheer, eigenaarschap, monitoring en afspraken over citizen development. Zeker in grotere organisaties maakt dat het verschil tussen losse initiatieven en een beheersbaar platform. Iemand hoeft geen governance-specialist te zijn, maar moet wel begrijpen waarom deze laag belangrijk is.
Goede interviewvragen geven betere signalen dan certificaten
Certificeringen zijn nuttig als signaal van basiskennis en leergierigheid. Ze zijn alleen geen bewijs van projectvolwassenheid. Iemand kan meerdere Microsoft-certificaten hebben en alsnog moeite hebben met stakeholdermanagement, architectuurkeuzes of het opschalen van oplossingen.
Stel daarom vragen die gedrag en besluitvorming zichtbaar maken. Vraag bijvoorbeeld naar een oplossing die onder tijdsdruk is gebouwd en later moest worden aangepast. Of naar een project waarin de eerste technische keuze niet de juiste bleek. Juist daar hoor je of iemand eigenaarschap neemt, trade-offs begrijpt en kan reflecteren op kwaliteit.
Nog waardevoller zijn vragen over samenwerking. Hoe werkte iemand met product owners, key users, beheerders of security? Wie requirements ophaalde, keuzes toelichtte en verwachtingen managede, is vaak breder inzetbaar dan iemand die vooral uitvoerend bouwde. In Power Platform-rollen is communicatie geen bijzaak. Veel projecten mislukken niet op techniek, maar op afstemming.
Vraag altijd naar de eigen bijdrage
Power Platform-projecten zijn vaak teamwerk. Daardoor klinkt ervaring soms groter dan die feitelijk was. Vraag dus altijd welk deel van de oplossing de kandidaat zelf heeft ontworpen, gebouwd of beheerd. Heeft die persoon de data-architectuur opgezet, of vooral schermen gemaakt binnen een bestaand kader? Was iemand leidend in het ontwerp, of vooral ondersteunend in delivery?
Dat is geen detail. Voor een medior rol kan stevige uitvoerende ervaring prima passen. Voor een lead- of architectrol wil je weten of iemand zelfstandig richting kan geven. Hoe concreter de kandidaat over de eigen bijdrage spreekt, hoe betrouwbaarder het beeld meestal wordt.
Veelgemaakte fouten bij het beoordelen van Power Platform ervaring
De meest voorkomende fout is Power Platform zien als één homogene skill. Dat leidt tot mismatch. Een uitstekende functioneel ingestelde consultant is niet automatisch de juiste persoon voor een technisch complexe integratierol. En een sterke developer met architectuurgevoel is niet per se de beste keuze voor stakeholderintensieve adoptietrajecten.
Een tweede fout is te veel waarde hechten aan Microsoft-terminologie. Kandidaten die vlot praten over componenten, features en roadmap-onderdelen maken vaak een goede eerste indruk. Maar als ze moeite hebben om uit te leggen waarom een oplossing werkte in de praktijk, ontbreekt er meestal iets. Sterke professionals kunnen techniek vertalen naar toepassing, risico en impact.
Een derde fout is cultuur en teamfit onderschatten. In low-code omgevingen werken mensen vaak dicht op business, beheer en IT-governance. Dan maakt het uit of iemand structuur brengt, helder communiceert en openstaat voor feedback. Zeker in compacte teams heeft een verkeerde match direct effect op delivery.
Hoe maak je beoordeling objectiever?
Objectiviteit ontstaat wanneer je vooraf bepaalt wat de rol echt vraagt. Maak onderscheid tussen must-haves en nice-to-haves. Bepaal of je zoekt op bouwkracht, architectuur, functionele analyse, stakeholdermanagement of platformbeheer. Pas daarna toets je kandidaten langs dezelfde meetlat.
Praktisch werkt een scorecard goed, zolang die inhoudelijk blijft. Denk aan platformonderdelen, projectcontext, zelfstandigheid, communicatieve vaardigheden en teamfit. Niet om mensen mechanisch af te vinken, maar om te voorkomen dat de kandidaat met het sterkste gesprek automatisch bovenaan eindigt.
Een korte case kan ook helpen, mits relevant. Laat iemand niet een theoretisch examen doen, maar bespreek een herkenbare situatie: een afdeling wil snel digitaliseren, data staat verspreid, security stelt eisen en beheer wil standaardisatie. Vraag hoe de kandidaat dit zou aanpakken. Dan zie je snel of iemand alleen bouwt, of ook over inrichting en organisatie nadenkt.
Voor organisaties die regelmatig low-code professionals aannemen, loont het om die beoordeling te standaardiseren. Dat versnelt de selectie en maakt gesprekken consistenter. Bij specialistische bemiddeling zie je dat direct terug in kwaliteit, omdat kandidaten vooraf al op de juiste inhoudelijke punten zijn getoetst. Dat is precies waarom een nichepartij als Schouten Low-Code Recruitment in dit soort profielen vaak sneller tot een duurzame match komt.
Het juiste niveau hangt altijd af van de omgeving
Er is niet één definitie van goede Power Platform ervaring. In een scale-up kan snelheid en pragmatisme zwaarder wegen dan formele governance. In een enterprise- of overheidsomgeving zijn security, documentatie, overdraagbaarheid en releasebeheer vaak bepalend. Eenzelfde kandidaat kan in de ene context uitstekend passen en in de andere minder.
Daarom is de beste vraag niet alleen: is deze kandidaat goed? De betere vraag is: is deze Power Platform ervaring goed voor onze situatie, ons team en onze fase? Zodra je dat onderscheid maakt, wordt beoordelen een stuk scherper en selecteer je minder op gevoel en meer op daadwerkelijke meerwaarde.
Wie Power Platform serieus inzet voor bedrijfskritische processen, doet er verstandig aan verder te kijken dan het cv. Niet om het moeilijker te maken, maar om sneller de juiste persoon te herkennen.
