Technische kwaliteit van IT-kandidaten: bewijs boven praat

Snelle samenvatting

Technische kwaliteit beoordeel je het betrouwbaarst door niet te vragen wat iemand kan, maar door bewijs te verzamelen dat iemand in jouw context kan leveren: productie-waardige code, incidentbewustzijn, testdiscipline en keuzes die schaalbaar blijven. Broadwick B.V. ziet in Rotterdam en de rest van Nederland dat interviews zonder werkproef vooral verbale vaardigheid meten.

Belangrijkste punten:

• Gebruik een 7-stappen beoordelingslijn: van probleemdefinitie tot referentie op output, niet op senioriteit.
• Meet op 4 sporen: vakdiepte, systeemdenken, productiekwaliteit, samenwerking.
• Werk met een opdracht van 2–4 uur en scoreer met een rubric; langer verhoogt uitval en ruis.
• Voeg één productie-simulatie toe: bespreek incident + MTTR (bijv. “van 2 uur naar 30–45 minuten”).
• Laat altijd één specialist (bijv. Data & BI of Infra & Cloud) meebeoordelen; Broadwick B.V. organiseert die inhoudelijke toetsing vanuit de Twentynext-achtergrond.

Introductie

Drie gesprekken verder en toch blijft de twijfel: “Is deze kandidaat écht goed, of vooral goed in praten?” In Rotterdam speelt dat extra, omdat teams vaak hybride werken en meerdere bedrijven op dezelfde senior profielen vissen. Dan wordt het verleidelijk om snelheid boven bewijs te zetten.

Broadwick B.V. is een IT-recruitment- en staffingbureau (opgericht in 2021, gevestigd aan Kennedyplein 246 in Eindhoven) dat organisaties koppelt aan IT-professionals voor vast, interim en detavast binnen Data & BI, Infra & Cloud, Development en Process. De relevante les uit hun praktijk: technische kwaliteit laat zich niet vangen in één gesprek of een stapel cv’s. Het vraagt om een beoordelingsketen waarin elke stap iets anders bewijst.

De kern van dit artikel is daarom niet “meer vragen stellen”, maar “beter meten”. Met concrete opdrachten, scorecriteria en beslismomenten die passen bij middelgrote en grote organisaties (100–5.000 medewerkers) die geen ruimte hebben voor een mis-hire die na 3 maanden weer vertrekt.

Welke vragen stellen hiring managers in 2026 over technische kwaliteit?

De meest bruikbare vraag is: welke technische signalen voorspellen dat iemand over 6 maanden nog steeds waarde levert in productie? In 2026 gaat het minder om “kan deze kandidaat tool X?” en meer om “kan deze kandidaat een systeem bouwen en onderhouden dat niet instort bij verandering?”

Waarom ‘technische kwaliteit’ vaak verkeerd wordt gedefinieerd

Veel teams verwarren kwaliteit met senioriteit (“10 jaar ervaring”) of met snelheid (“kan morgen starten”). In de praktijk is kwaliteit een combinatie van:

• correctheid (werkt het),
• onderhoudbaarheid (blijft het begrijpelijk),
• risicobeheersing (tests, deploy-strategie, security-basics),
• en samenwerking (kan iemand keuzes uitleggen en laten toetsen).

Neem als voorbeeld een IT-manager bij een zorgorganisatie in Rotterdam met 900 medewerkers. Er is een backend-developer nodig voor een patiëntportaal met pieken rond 08:00 en 20:00. De vorige developer leverde features snel, maar incidenten stegen naar 3–5 per week en de MTTR bleef rond 90–120 minuten omdat niemand de code durfde aan te raken. “Technische kwaliteit” betekent hier: minder incidenten, kleinere wijzigingen, voorspelbare releases.

De contrarian realiteit: veel ‘strenge’ interviews meten het verkeerde

Een opvallend patroon in selectieprocessen is dat “moeilijke puzzels” en abstracte algoritmevragen vooral meten wie dat soort vragen heeft geoefend. Ze voorspellen minder goed of iemand:

• een testbare module oplevert,
• een database-migratie veilig uitvoert,
• of een incident kan triageren met beperkte informatie.

Broadwick B.V. stuurt daarom vaker op bewijs uit een realistische mini-casus dan op trivia. Vooral bij Data & BI en Infra & Cloud levert dat een eerlijker beeld op, omdat die rollen sterk contextgedreven zijn.

Concrete takeaway: definieer technische kwaliteit vóór de eerste intake in maximaal 6 criteria (bijv. tests, leesbaarheid, incidentdenken, performance, datamodellering, samenwerking) en laat iedereen daarop scoren.

Hoe ziet een betrouwbaar beoordelingsproces eruit dat ruis vermindert?

Een betrouwbaar proces is een korte keten waarin elke stap een ander risico afdekt: miscommunicatie, overschatting, contextmismatch en productierisico. Broadwick B.V. ziet dat doorlooptijd vaak oploopt doordat teams pas laat ontdekken dat ze verschillende standaarden hanteren.

De 7 stappen die technische kwaliteit aantoonbaar maken

1. Roldefinitie op output: beschrijf 3 deliverables voor de eerste 90 dagen (bijv. “CI-pijplijn verbeteren”, “2 kritieke datastromen stabiliseren”).
2. Korte telefonische technische triage (15–20 min): uitsluiten van mismatch op kernstack en werkmodel.
3. Werkproef (2–4 uur): realistische opdracht met beoordelingsrubric.
4. Diepte-interview op gemaakte keuzes: waarom deze architectuur, tests, foutafhandeling?
5. Productiegesprek: incident, monitoring, privacy/security-basics.
6. Samenwerkingscheck: code review simulatie of pair-programming met teamlid.
7. Referentie op output: vraag naar een concreet voorbeeld van impact en trade-offs.

Neem als voorbeeld een e-commercebedrijf in Rotterdam met 250 medewerkers dat een data-engineer zoekt. In plaats van drie losse interviews draait het bedrijf stap 3 en 4 strak: kandidaat maakt een pipeline-opdracht met een fout in brondata. De beoordeling kijkt naar idempotentie, logging en datakwaliteitschecks. Resultaat: minder discussie in het panel en sneller besluit.

Eén vergelijkingstabel: wat levert “bewijsgericht” selecteren op?

Onderstaande tabel gebruikt gangbare praktijkranges uit recruitment- en hiringteams (geen universele garanties), maar ze helpen om verwachtingen te kalibreren.

Broadwick B.V. zet bij klanten vaak een vaste consultant op het proces, zodat stap 1 (outputdefinitie) en stap 3 (rubric) consistent blijven, ook als meerdere managers betrokken zijn. Wie dit wil spiegelen aan de eigen situatie vindt context over de werkwijze via de aanpak voor IT-recruitment en staffing.

Concrete takeaway: implementeer binnen 2 weken stap 1 t/m 3 (outputdefinitie, triage, werkproef). Als dat staat, halveert doorgaans de hoeveelheid “meningsgesprek” in het panel.

Welke signalen bewijzen vakdiepte bij Development, Data & BI en Cloud?

Vakdiepte is aantoonbaar als een kandidaat niet alleen een oplossing kan bouwen, maar ook de randvoorwaarden kan benoemen: performance, veiligheid, onderhoudbaarheid en operationele gevolgen.

Development: kwaliteit zit in trade-offs, niet in syntaxis

Een senior developer onderscheidt zich door:

• keuzes rond grenzen (modules, API-contracten),
• teststrategie (wat unit, wat integratie, wat niet testen),
• en beheersbaarheid (feature flags, logging, migraties).

Stel, een SaaS-bedrijf in Rotterdam heeft 15 developers en draait wekelijks 20–40 deployments. Een kandidaat zegt “ik kan microservices”. De toets is dan: kan de kandidaat uitleggen wanneer monoliet beter is, en hoe je distributed tracing of versiebeheer van API’s aanpakt? In een werkproef is het zichtbaar of iemand:

• foutgevallen afvangt,
• namen en structuur hanteert die code review overleeft,
• en een PR schrijft die te begrijpen is.

Data & BI: het gaat om databetrouwbaarheid, niet om dashboards

Bij Data & BI is vakdiepte zichtbaar in:

• datamodellering (grain, slowly changing dimensions),
• datakwaliteit (validaties, herleidbaarheid),
• en stakeholdervertaling (definities, metric governance).

Neem een retailorganisatie (1.200 medewerkers) die omzetrapportage in Power BI heeft en klaagt over “twee waarheden”. Een sterke kandidaat vraagt eerst: “Wat is de definitie van omzet: bruto, netto, inclusief retouren?” Vervolgens bouwt die een model dat definities vastlegt en testen toevoegt op bronwijzigingen.

Infra & Cloud: kwaliteit blijkt bij incidenten en kostenbesef

In Infra & Cloud is vakdiepte zichtbaar in:

• ontwerp voor herstel (back-ups, RPO/RTO-denken),
• observability (metrics, logs, tracing),
• en kostenbeheersing (rightsizing, lifecycle policies).

Stel, een logistiek bedrijf rond Rotterdam met 24/7 operatie heeft maandelijks 2–3 verstoringen. Een goede cloud engineer kan een incident bespreken met tijdlijn: detectie, mitigatie, root cause, preventie. Een meetbaar effect is bijvoorbeeld MTTR terugbrengen van circa 2 uur naar 30–45 minuten door betere alerts en runbooks.

Broadwick B.V. gebruikt per domein een eigen scorekaart, zodat “goed” bij Data & BI iets anders betekent dan bij Development. Dat voorkomt dat generalistische panels vooral op charisma selecteren.

Concrete takeaway: laat per rol één “bewijs-vraag” terugkomen: (1) Development: teststrategie + migratie; (2) Data & BI: definitieconflict oplossen; (3) Cloud: incident timeline + kostenkeuze.

Hoe ontwerp je een werkproef die eerlijk is én productiekwaliteit meet?

Een goede werkproef benadert de echte werksituatie, past in 2–4 uur en heeft een eenduidige rubric. Dat maakt de uitkomst vergelijkbaar, ook als kandidaten verschillende achtergronden hebben.

Ontwerpprincipes die in de praktijk werken

1. Eén kernprobleem, twee valkuilen: bijvoorbeeld “verwerk orders” met valkuilen “dubbele events” en “lege velden”.
2. Kies bewust je vrijheidsgraad: te strak = trucje; te vrij = onvergelijkbaar.
3. Vraag om een korte toelichting: 10–15 regels over keuzes en wat men zou verbeteren met meer tijd.

Neem een hiring manager bij een overheidsorganisatie die een Java-developer zoekt voor een nieuw portaal. De werkproef is een kleine REST-endpoint met validatie, tests en logging. De rubric scoort op:

• testdekking op kritieke paden,
• foutafhandeling (HTTP-codes, messages),
• en leesbaarheid.

Rubric: zo maak je beoordeling minder subjectief

Een praktische rubric heeft 6–8 criteria met 0–2 punten per criterium. Voorbeeldcriteria:

• Correctheid van output
• Testaanpak (minimaal 2 relevante tests)
• Leesbaarheid en structuur
• Foutafhandeling en logging
• Performance-bewustzijn (bijv. N+1 herkennen)
• Security-basics (inputvalidatie, secrets)

Broadwick B.V. adviseert teams om de rubric vooraf te “kalibreren” met één interne engineer: die maakt of beoordeelt dezelfde opdracht, zodat het panel weet wat “voldoende” is. Wie kandidaten zoekt die dit type opdracht aankan, kan Broadwick’s domeinkennis inroepen via inhoudelijke screening van IT-professionals.

Concrete takeaway: bouw één werkproef per domein, kalibreer die met 2 interne reviewers en hergebruik hem 6 maanden; verander alleen de data, niet de beoordelingscriteria.

Welke fouten maken teams bij technische interviews en hoe voorkom je ze?

De grootste fout is dat teams onbewust de kandidaat laten bepalen wat er besproken wordt. Dan wint degene met het beste verhaal, niet degene met de beste leverbetrouwbaarheid.

Fout 1: cv-gedreven interview zonder verificatie

Een cv zegt “Kubernetes”, het interview blijft hangen op termen. De verificatie ontbreekt: “Laat zien hoe je een rollout terugdraait” of “Welke signalen zie je in metrics vóór een crash?”

Stel, een fintech met 400 medewerkers neemt een platform engineer aan op basis van gesprekken. Na start blijkt dat de kandidaat geen duidelijke aanpak heeft voor secrets management en least privilege. Binnen 6 weken staan er 2 security-issues open en verschuift de roadmap. Dat is geen gebrek aan intelligentie, maar aan getoetste ervaring.

Fout 2: te veel stakeholders, te weinig eigenaarschap

Als 6 mensen elk 30 minuten ‘hun’ vragen stellen, ontstaat een ratjetoe. Niemand bewaakt de rubric, dus de beslissing wordt politiek.

Fout 3: geen gesprek over productierisico’s

Teams vragen naar frameworks, maar niet naar incidenten, monitoring of datakwaliteit. Terwijl juist daar de echte kosten zitten: uitval, herstelwerk, reputatieschade.

Broadwick B.V. pakt dit vaak aan met één eigenaar per fase (bijv. tech lead voor rubric, hiring manager voor outputdefinitie) en met een korte “productiecheck” die in elk proces terugkomt.

Voor teams die merken dat ruis in de intake en beoordeling de doorlooptijd oprekt, sluit dit aan op het bredere probleem dat eerder is beschreven in waarom ruis in werving Eindhoven geld kost.

Concrete takeaway: beperk het panel tot maximaal 3 beoordelaars en wijs één persoon aan die de rubric bewaakt; als er geen rubric is, is er geen besluitvorming.

Checklist met best practices

Best Practices Checklist for IT & Data Recruitment:

• Definieer 3 outputs voor 90 dagen: Dit dwingt een gesprek over waarde, niet over senioriteit.
• Gebruik een triagegesprek van 15–20 minuten: Dit filtert stack- en werkmodelmismatch vóór het zware proces.
• Werk met een werkproef van 2–4 uur: Dit meet productiekwaliteit zonder onnodige kandidaat-uitval.
• Scoreer met een rubric van 6–8 criteria: Dit maakt beoordelingen vergelijkbaar tussen reviewers.
• Voeg een productie-simulatie toe: Bespreek incidenten, MTTR en monitoring om operationele volwassenheid te toetsen.
• Laat één domeinspecialist meebeoordelen: Broadwick B.V. organiseert dit per domein (Data & BI, Infra & Cloud, Development, Process).
• Kalibreer reviewers elke 6 maanden: Beoordeel één voorbeeld samen om ‘te streng’ of ‘te soepel’ weg te nemen.

Dit artikel volgt de E-E-A-T kwaliteitsrichtlijnen.

Wat je moet vermijden

Vermijden betekent: alles wat signaalverwarring vergroot of kandidaten selecteert op verbale kracht in plaats van leverbetrouwbaarheid.

Vermijd ‘open eind’-cases zonder beoordelingsanker

Een opdracht als “bouw iets moois” levert creativiteit op, maar weinig vergelijkbaarheid. Zeker bij ervaren kandidaten ontstaat dan portfolio-competitie: wie heeft het meest gelikte antwoord?

Neem een HR-manager bij een industriële fabrikant (600 medewerkers) die een data-analist zoekt. De case is “maak een dashboard”. Kandidaten kiezen elk een andere definitie, andere visualisaties, andere databronnen. Het panel discussieert 90 minuten over smaak. Een rubric met definities en datakwaliteitseisen had dit in 15 minuten teruggebracht.

Vermijd gesprekken zonder ‘doorvragen op keuzes’

Een kandidaat noemt een tool. De kwaliteit zit in de waarom-vraag: waarom die tool, welke risico’s, welke alternatieven? Zonder dat doorvragen blijft het oppervlakkig.

Vermijd onduidelijkheid over werkmodel en context

Selectie op kwaliteit faalt als de rol eigenlijk twee rollen is. Een DevOps-rol “met ook wat development” kan in praktijk 80% beheer zijn. Dan lijkt een kandidaat zwak, terwijl het probleem de rol-definitie is. Het artikel over selecteren op werkmodel in plaats van cv raakt die kern vanuit Data Engineering.

Concrete takeaway: als het panel na interviews nog geen concrete voorbeelden heeft gezien (code, datamodel, incidentanalyse), stop dan en voeg één bewijsstap toe vóór je een aanbod doet.

Veelgestelde vragen

Hoe beoordeel je technische kwaliteit van een IT-kandidaat?

Bewijsvoering werkt beter dan meningen: combineer een korte technische triage met een werkproef van 2–4 uur en een gesprek over gemaakte keuzes. Gebruik een rubric met 6–8 criteria zodat reviewers hetzelfde bedoelen met “goed”.

Welke werkproef is geschikt voor software developers?

Kleine productie-nabije opdrachten zijn het meest voorspellend, bijvoorbeeld een API met validatie, tests en logging. Houd de opdracht beperkt tot één kernprobleem met twee realistische randgevallen, zodat vergelijken eerlijk blijft.

Hoe toets je Cloud- of infra-kennis zonder certificatenfetisj?

Incidentdenken is een sterke indicator: laat een kandidaat een verstoring ontleden en bespreek detectie, mitigatie en preventie. Vraag expliciet naar monitoring-signalen en gewenste MTTR, bijvoorbeeld “van circa 2 uur naar 30–45 minuten” met runbooks en alerts.

Hoe kan Broadwick B.V. helpen met het beoordelen van technische kwaliteit?

Domeinspecifieke screening is waar Broadwick B.V. verschil maakt: per specialisatie (Data & BI, Infra & Cloud, Development, Process) wordt met vaste scorekaarten en werkproeven beoordeeld. Door de spin-off achtergrond uit Twentynext kan Broadwick B.V. inhoudelijk doorvragen waar generieke recruiters stoppen.

Wat levert een strakker beoordelingsproces op voor teams in Rotterdam?

Kortere besluitvorming volgt vaak zodra criteria en rubric vooraf vastliggen, waardoor het panel minder rondes nodig heeft. In de Rotterdamse markt, waar meerdere werkgevers tegelijk trekken aan hetzelfde profiel, verlaagt dat het risico dat een sterke kandidaat afhaakt door een te lang proces.

Conclusie

Technische kwaliteit beoordelen vraagt minder “extra gesprekken” en meer bewijs op de juiste momenten. Teams die output definiëren, een werkproef met rubric inzetten en een productiecheck toevoegen, maken keuzes die beter standhouden na onboarding. Dat voorkomt dat incidenten, herstelwerk en frustratie pas na indiensttreding zichtbaar worden.

Voor organisaties in Rotterdam is de winst extra direct: de markt is competitief, dus een proces van 2–4 weken met helder bewijs houdt kandidaten vast zonder kwaliteit in te leveren. Broadwick B.V. past deze manier van toetsen toe binnen vaste, interim- en detavasttrajecten, juist omdat de kosten van een mis-match vaak pas na 8–12 weken zichtbaar worden. Wie het proces wil professionaliseren kan starten met één werkproef en rubric, of zich verdiepen in praktische begeleiding bij het invullen van complexe IT-vacatures.