Een technische PHP-test voor kandidaten is nuttig als die helpt een concrete vraag over het werk te beantwoorden: kan iemand een API onderhouden, een fout onderzoeken of samenwerken aan een bestaande applicatie? De test mag niet meten wie de meeste vrije tijd heeft, een specifieke tool kent of de persoonlijke voorkeuren van de beoordelaar raadt.
Om bruikbare resultaten te krijgen, moet het team eerst de relevante vaardigheden vaststellen, een passende vorm kiezen en beoordelen aan de hand van waarneembare criteria. De test is een onderdeel van het proces, geen vervanging voor een gesprek over ervaring, samenwerking en context.
Begin met de echte taken van de functie
Breng voordat je een opdracht opstelt in kaart wat iemand in de eerste maanden gaat doen. Voor een functie waarin het onderhouden van een bestaande applicatie centraal staat, zijn andere vaardigheden nodig dan voor een functie waarin nieuwe services worden ontwikkeld. In het eerste geval kunnen code lezen, fouten onderzoeken en kleine wijzigingen veilig doorvoeren belangrijk zijn; in het tweede bijvoorbeeld een API ontwerpen of grenzen tussen componenten definiëren.
Kies twee of drie prioritaire vaardigheden en koppel elke vaardigheid aan een waarneembare taak. Als de functie bijvoorbeeld vraagt om een PHP-API te onderhouden, kun je beoordelen hoe iemand invoer valideert en het gedrag bij ongeldige gegevens uitlegt. Het is niet nodig om in één test de hele taal, het framework en de architectuur te behandelen.
Maak ook onderscheid tussen essentiële vereisten en kennis die iemand kan opdoen. Als het team een tool na indiensttreding kan aanleren, kan het stellen van die tool als harde instroomeis geschikte kandidaten uitsluiten zonder de voorspellende waarde voor hun prestaties te verbeteren.
Kies de vorm op basis van wat je wilt observeren
Een code review past wanneer het werk bestaat uit het onderhouden van een bestaande codebase. Je kunt een kort fragment aanleveren met een defect of een discutabele keuze, en vragen de kandidaat risico's te laten herkennen, wijzigingen voor te stellen en aan te geven wat die zou testen. Zo krijg je inzicht in leesvaardigheid en beoordelingsvermogen zonder te eisen dat iemand vanaf nul een applicatie bouwt.
Een technisch gesprek is nuttig om keuzes, ervaring en communicatie te verkennen. Het werkt het best met vragen die aansluiten op concrete situaties en voldoende tijd bieden om aannames, alternatieven en gevolgen toe te lichten. Maak er geen geheugentest van over syntax of weinig relevante details.
Een afgebakende praktijkopdracht kan inzicht geven in implementatievaardigheden wanneer die centraal staan in de functie. Beperk de opdracht tot een kleine taak, zoals een validatie aanvullen of een foutgeval corrigeren in een zelfstandig voorbeeld. Als een uitgebreide oplossing nodig is, is het wellicht redelijker de beoordeling op te splitsen in een begeleide review en een gesprek, in plaats van uren huiswerk te eisen.
De vorm moet de kandidaat in staat stellen de beoordeelde vaardigheid te demonstreren, niet het beheersen van een specifieke omgeving belonen. Als de functie afhankelijk is van een bepaald framework, vermeld dan welk framework en waarom; zo niet, accepteer gelijkwaardige oplossingen en beoordeel de redenering.
Stel een opdracht op met duidelijke context en grenzen
Een goede opdracht beschrijft het doel, de minimale context, de beperkingen en hoe het resultaat moet worden ingeleverd. Vermeld welk gedrag wordt verwacht, welke delen van de code aangepast mogen worden, of afhankelijkheden beschikbaar zijn en hoeveel tijd de taak ongeveer zou moeten kosten. Geef ook aan of documentatie geraadpleegd mag worden en welke tools gebruikt mogen worden.
De opdracht moet representatief zijn, maar geen functionaliteit opleveren die direct in het product kan worden opgenomen. Vraag niet om een volledige integratie, een omvangrijke migratie of functionaliteit die het bedrijf wil uitbrengen. Lijkt de casus op een echte taak, gebruik dan een verkleind, fictief scenario zonder vertrouwelijke gegevens of code. Het resultaat van de selectie mag geen gratis productiewerk worden.
De geschatte tijd is een ontwerpgrens, geen snelheidstest. Vertel wat de kandidaat moet doen als niet alles afkomt en moedig aan om prioriteiten te stellen. Het is beter een gedeeltelijke oplossing te beoordelen die goed wordt toegelicht dan de voorkeur te geven aan iemand die buiten het selectieproces veel uren kon besteden.
Beoordeel aan de hand van een observeerbare rubric
Stel de rubric op voordat je kandidaten beoordeelt. Een korte schaal — bijvoorbeeld onvoldoende, voldoende en sterk — kan volstaan als elk niveau concrete aanwijzingen beschrijft. Vermijd vage labels zoals goede match of elegante code, die persoonlijke voorkeuren kunnen verhullen.
- Redenering: herkent aannames, licht keuzes toe en benoemt beperkingen of alternatieven.
- Correctheid en leesbaarheid: lost de voorgelegde casus op met begrijpelijke code en proportionele wijzigingen.
- Beveiliging: behandelt invoer, fouten en gevoelige gegevens passend bij de context van de opdracht.
- Tests: kiest relevante testgevallen en legt uit welk gedrag ze afdekken, ook als er geen volledige testsuite wordt geschreven.
- Samenwerking: stelt relevante vragen, communiceert onzekerheden en reageert op opmerkingen zonder meningsverschillen te verbergen.
Niet elk criterium weegt voor elke functie even zwaar. Bij een onderhoudsfunctie kunnen begrip en voorzichtigheid vooropstaan; bij een andere functie juist interfaceontwerp. Maak die prioriteiten expliciet en onderscheid kritieke fouten — zoals een duidelijke blootstelling van gegevens — van stilistische details die de uitkomst niet veranderen.
Bekijk het werk en vraag naar de gemaakte keuzes
De beoordeling moet volgens een vaste volgorde verlopen. Beoordelaars kunnen eerst onafhankelijk van elkaar een score geven en daarna het bewijsmateriaal vergelijken. Zo krijgt de eerste indruk minder invloed en worden onduidelijke criteria zichtbaar. Gaat de beoordeling uiteen, bespreek dan concrete codefragmenten en de rubric, niet intuïties over iemands persoonlijkheid.
Vraag tijdens de nabespreking naar een specifieke keuze: wat zou de kandidaat met meer tijd veranderen, welk testgeval zou die toevoegen of welk risico vond die het belangrijkst? De vragen moeten ruimte bieden om de redenering toe te lichten, niet plotseling eisen introduceren die niet in de opdracht stonden. Geef ruimte om keuzes toe te lichten die afwijken van wat het team zelf zou hebben gedaan.
Zie de reactie op een opmerking als bewijs van samenwerking, niet van gehoorzaamheid. Iemand kan een ander alternatief op goede gronden verdedigen. Het vermogen afwegingen toe te lichten en een oplossing aan te passen op basis van nieuwe informatie zegt vaak meer dan het overeenkomen met een voorkeur van de interviewer.
Beperk vooringenomenheid en bied redelijke alternatieven
Gebruik voor iedereen die naar dezelfde functie solliciteert dezelfde instructies, criteria en tijd. Verberg waar mogelijk niet-relevante gegevens tijdens de eerste beoordeling en beperk ongestructureerde opmerkingen. Accepteer gelijkwaardige vormen als die dezelfde vaardigheid meten: een begeleid gesprek kan een thuisopdracht vervangen wanneer het doel is de redenering te begrijpen.
Vraag vooraf of een aanpassing van de vorm of toegankelijkheidsvoorziening nodig is en spreek zonder nadelige gevolgen een alternatief af. Ga er niet van uit dat pauzes, spreektempo of een informele communicatiestijl iets zeggen over het technische niveau. Ga ook consistent om met het gebruik van documentatie: in het dagelijkse werk kan het normaal zijn om naslagwerken te raadplegen.
Herken een onevenredige test voordat je die publiceert
Bekijk de opdracht vanuit het perspectief van een kandidaat. Past de omvang binnen de aangegeven tijd? Is er voldoende informatie om te beginnen zonder vereisten te hoeven raden? Worden vaardigheden voor de functie beoordeeld, of bekendheid met een onverklaarde interne conventie? Kan het team het resultaat direct commercieel benutten? Een zorgwekkend antwoord op die laatste vraag betekent dat de opdracht moet worden verkleind of vervangen.
Ook een lange lijst met vereisten, een beoordeling op basis van persoonlijke smaak, tegenstrijdige instructies of de impliciete belofte dat alleen een perfecte oplossing volstaat, zijn waarschuwingssignalen. Als het team zelf meerdere uren nodig heeft om de opdracht op te lossen, is die waarschijnlijk niet goed genoeg afgebakend voor een eerste selectieronde.
Checklist om het proces te verbeteren
- Koppel elk criterium aan een echte verantwoordelijkheid van de functie.
- Kies de kortste vorm waarin de gezochte vaardigheid kan worden waargenomen.
- Communiceer de context, tools, tijdslimieten en voorwaarden voor het inleveren.
- Definieer beoordelingsniveaus met voorbeelden van bewijs voordat je resultaten ontvangt.
- Stel vergelijkbare vervolgvragen en geef kandidaten ruimte om alternatieven toe te lichten.
- Verzamel feedback van kandidaten en beoordelaars om onduidelijkheden of onnodige belasting op te sporen.
Een technische PHP-test voor kandidaten hoeft niet complex te zijn om zorgvuldig te zijn. De kwaliteit hangt ervan af of de test iets relevants meet, met een redelijke belasting en een consistente beoordeling. Als de resultaten na meerdere wervingsrondes niet helpen om de vereiste vaardigheden voor de functie te onderscheiden, herzie dan het ontwerp voordat je de moeilijkheidsgraad verhoogt.
