# Developers screenen in Servië: wat wij toetsen en wat jij toetst

URL: https://brainpowergroup.eu/nl/blog/developers-screenen-in-servie
Datum: 2025-07-23 (bijgewerkt 2026-09-23)
Door: Milos, Brainpower Group

Wij toetsen Engels en techniek, ook met een korte opdracht in jouw stack. Jij toetst of de kandidaat bij je team past, en de proefperiode laat zien hoe die werkt.

Een technische screening bestaat bij mij uit drie delen: een gesprek over motivatie en Engels, een technisch gesprek en een korte opdracht in de stack van de klant. Daarmee toetsen wij of iemand het werk kan. Daarna spreek jij de kandidaat zelf, want jij kunt het beste beoordelen of die persoon in jouw team en jouw codebase past. Jij beslist ook wie er komt.

## Eerst het profiel, dan pas kandidaten

Voordat ik een kandidaat spreek, wil ik weten wat de developer bij jou gaat doen. "Senior React-developer" zegt weinig. Ik vraag naar de stack en de versies die je draait, naar de staat van de codebase en naar wat iemand in de eerste maanden moet opleveren. Wie een nieuw Next.js-project opzet, heeft andere sterke punten nodig dan wie bugs oplost in een Laravel-applicatie van acht jaar oud.

Ik vraag ook hoe jullie werken. Reviewen jullie elkaars pull requests? Is er een tech lead? Gaat het meeste overleg schriftelijk, of zit het team een groot deel van de dag in calls? Ook die antwoorden bepalen welke developer past, los van de stack.

## Het eerste gesprek: Engels en motivatie

Onze werktaal is Engels. In het eerste gesprek let ik erop of iemand in het Engels een technisch probleem kan uitleggen en kan doorvragen als iets onduidelijk is. Een accent maakt niet uit, maar iemand moet in een stand-up in twee zinnen kunnen zeggen waar het vastzit.

Ik vraag ook waarom iemand in een klantteam wil werken. Wie bij een klant zit, werkt in de tools en het ritme van die klant, en dat moet je willen. Een developer die liever zelf een product van begin tot eind bouwt, past soms beter bij de projecten die we zelf uitvoeren.

## Het technische gesprek

In het technische gesprek laat ik de kandidaat een project uit de afgelopen jaren uitleggen, en ik vraag door op de keuzes. Waarom deze database? Wat zou je nu anders doen? Wat ging er mis in productie, en hoe heb je de oorzaak gevonden?

Aan de antwoorden hoor je snel of iemand het werk zelf heeft gedaan of er vooral naast zat. Iemand die een systeem goed kent, kan ook vertellen wat er niet goed aan is.

Ik vraag altijd hoe iemand AI-codeertools gebruikt, want onze developers werken dagelijks met tools als Claude Code. Ik wil horen hoe een kandidaat de output controleert, wanneer de tool niet te vertrouwen is en wat hij doet als gegenereerde code werkt maar niemand snapt waarom. Welke afspraken je daarover in een team maakt, beschrijf ik in [mijn stuk over AI-codeertools in een remote team](/nl/blog/ai-codeertools-in-een-remote-team).

## Een korte opdracht in jouw stack

Algoritmepuzzels geef ik liever niet, want die meten vooral of iemand puzzels heeft geoefend. Een opdracht die lijkt op het echte werk zegt meer. Twee vormen werken goed:

- een kleine feature bouwen in de stack van de klant, met tests, in een paar uur;
- een bestaande pull request reviewen waarin fouten zitten, zoals een ontbrekende autorisatiecheck of een N+1-query.

AI-tools mogen bij de opdracht, want de developer gebruikt ze straks bij jou ook. Daarna bespreken we de code samen en moet de kandidaat elke regel kunnen uitleggen. Dat gesprek achteraf is voor mij het belangrijkste deel van de opdracht, omdat je daar ziet of iemand begrijpt wat er staat.

## Wat jij als klant toetst

Komt een kandidaat door onze screening, dan weet je dat de technische basis klopt. Jouw gesprek kan dan over andere dingen gaan. Mijn advies is om je tech lead of een senior developer uit je team mee te laten praten.

Leg een echt ticket uit je backlog voor en vraag hoe de kandidaat het zou aanpakken. Let vooral op de vragen die terugkomen. Goede developers vragen naar randgevallen, naar de bestaande code en naar wat "klaar" betekent. Zo zie je of iemand jouw domein snel oppakt.

Daarnaast toets je of het klikt met de mensen met wie de developer elke dag gaat werken. Dat kunnen wij niet voor je beoordelen.

Heb je eisen die specifiek zijn voor jouw situatie, zoals ervaring in een gereguleerde sector of met een tool die jullie veel gebruiken? Zeg het vooraf. Dan nemen we het mee in onze screening en hoef je het niet zelf uit te zoeken.

## Waarop ik afwijs

Een paar signalen zijn voor mij reden om iemand niet voor te stellen, ook als de opdracht goed was:

- de kandidaat kan code uit de eigen opdracht niet uitleggen;
- het verhaal over eerdere projecten blijft vaag, ook na doorvragen;
- iemand stelt in het hele traject geen enkele vraag over het werk;
- het Engels is te zwak om in een overleg een probleem uit te leggen.

Het laatste punt weegt zwaar. Een remote developer die niet om hulp kan vragen, zit soms dagen vast zonder dat iemand het merkt. Op afstand zie je dat vaak pas als een ticket veel te lang openstaat.

## De proefperiode is de laatste toets

Een gesprek en een opdracht blijven een momentopname. Daarom start elke developer met een proefperiode van twee weken, en werkt het niet, dan betaal je niets. In die twee weken zie je wat een screening niet laat zien: hoe iemand met jouw codebase omgaat en hoe iemand reageert op review.

Geef in die weken echte tickets, review de eerste pull requests grondig en spreek na een week af hoe het gaat. Wat een nieuwe developer in de eerste dagen van jou nodig heeft, beschrijft Aleksa in [het stuk over de eerste twee weken](/nl/blog/remote-developer-onboarden-eerste-twee-weken). Hoe het hele traject loopt, van profiel tot start, lees je bij [onze werkwijze](/nl/werkwijze).

## Veelgestelde vragen

**Hoe test je de technische vaardigheden van een remote developer?**

Met een gesprek over eerder werk en een korte opdracht die lijkt op het echte werk, in de stack van de klant. Daarna moet de kandidaat de eigen code kunnen uitleggen. Dat gesprek zegt meer dan een algoritmepuzzel.

**Moet ik als klant zelf nog een technisch interview doen?**

Wij toetsen of iemand het werk kan. In jouw gesprek toets je vooral of de kandidaat jouw domein snel oppakt en bij je team past. Laat je tech lead meepraten en leg een echt ticket voor.

**Mogen kandidaten AI-tools gebruiken bij een technische opdracht?**

Bij ons wel, want ze gebruiken die tools straks ook in hun dagelijkse werk. Wel moet de kandidaat daarna elke regel van de oplossing kunnen uitleggen.

---

Bron: https://brainpowergroup.eu/nl/blog/developers-screenen-in-servie
Brainpower Group, contact: https://brainpowergroup.eu/nl/contact, hello@brainpowergroup.eu
