Zo maakt u een programmeertest

What you'll need

• Een SkillCort-werkomgeving (of een demo)
• Een echt voorbeeld van de code die uw team schrijft — een bug, een kleine feature, een refactor
• Een senior engineer die de taak en de rubric bepaalt
• Een besluit over welke talen u accepteert

Step 1: Kies een realistische taak in plaats van een algoritmepuzzel

Kijk naar de pull requests van de afgelopen maand en kies een taak in de vorm van wat steeds terugkeert: een bug oplossen bij gegeven verkeerd gedrag, een kleine functie uitbreiden voor een nieuw geval, een rommelig blok refactoren of een datatransformatie schrijven. Die zeggen veel meer over het dagelijkse werk dan het omkeren van een binaire boom.

Maak hem zo groot dat een competente aanstelling er 30–45 minuten geconcentreerd werk aan heeft. Een puzzel beloont wie hem heeft geoefend; een realistische kleine taak beloont wie bestaande bedoelingen kan lezen, een verstandige wijziging kan maken en de code begrijpelijk kan houden — en daar neemt u iemand voor aan.

Haal framework- en bedrijfsspecifieke kennis eruit tenzij de rol die echt vereist, en geef alle context die de taak nodig heeft in de opdracht zelf. Een sterke engineer die uw stack nooit heeft aangeraakt, moet u nog steeds een gezond oordeel kunnen laten zien. Test de vaardigheid, niet de bekendheid met de weetjes van uw codebase.

• Komt terug in uw echte codebase, niet in boeken met sollicitatieoefeningen
• Heeft meer dan één redelijke oplossing
• Past in 30–45 minuten zonder heldendaden
• Door een beoordelaar in minder dan tien minuten te lezen

Step 2: Maak het code-item aan in de vragenbibliotheek

Maak een map voor de rol — bijvoorbeeld Backend Engineer — met tags voor vaardigheidsgebied en moeilijkheidsgraad, en maak vervolgens een item aan met het vraagtype code. Kandidaten schrijven en bewerken code rechtstreeks in het antwoordveld, en beoordelaars bekijken die later op dezelfde plek.

Vul het item met startcode in plaats van met een lege editor. Een korte functie met een beschreven bug, of een stub met een duidelijk contract, geeft elke kandidaat hetzelfde vertrekpunt en maakt hun wijzigingen direct vergelijkbaar. Echt werk begint bijna nooit bij een leeg bestand, en de test hoort dat ook niet te doen.

Step 3: Schrijf de opdracht naast de editor

Gebruik de side-by-side stimuluslay-out: de opdracht, de eisen en voorbeelden van in- en uitvoer aan de ene kant, de code-editor ernaast. De kandidaat hoeft nooit van de specificatie weg te scrollen om de oplossing te schrijven — dezelfde vorm als werken vanuit een ticket in een IDE.

Schrijf de opdracht zoals een goed ticket leest: huidig gedrag, verwacht gedrag, beperkingen, en twee of drie concrete voorbeelden. Zeg expliciet waar het u om gaat — "werkende code eerst; we lezen ook op helderheid" — zodat kandidaten zich richten op wat u werkelijk scoort. Onduidelijkheid in de opdracht wordt ruis in de resultaten.

Step 4: Bouw een rubric die meer dan correctheid scoort

Correcte uitvoer is noodzakelijk, maar niet voldoende. Bouw een matrixrubric met niveaus en drie of vier criteria — meestal correctheid, leesbaarheid en aanpak, eventueel het omgaan met randgevallen — elk met verankerde beschrijvingen van hoe sterke, acceptabele en zwakke code eruitziet. "Namen tonen de bedoeling, geen dode code" is te scoren; "schone code" niet.

Geef correctheid het zwaarste gewicht, maar houd de andere criteria echt: een nauwelijks werkende oplossing die niemand kan onderhouden is geen sterk signaal voor een aanstelling. Wanneer u de rubric koppelt, wordt die bevroren in een snapshot, zodat elke kandidaat in die afname tegen exact dezelfde norm wordt beoordeeld, ook als de versie in de bibliotheek later verandert.

Step 5: Stel samen en begrens de tijd in de builder

Maak het assessment op als secties, pagina's en blokken en importeer het code-item via het keuzevenster. Veel teams zetten er een korte eerste sectie met snelle beoordelingsvragen voor — een diff lezen, de bug in een snippet aanwijzen, via quick-paste als meerkeuze toegevoegd — en geven de programmeertaak een eigen sectie.

Stel de totale tijdslimiet in met ruimte om te lezen en na te denken, en gebruik een limiet per pagina op de programmeerpagina zodat de taak niet de hele poging opslokt. Geef de programmeersectie het zwaarste gewicht (bijvoorbeeld ×3) zodat de rolfit op het Decision Board het echte werk weerspiegelt en niet de warming-up. Schrijf instructies die de toegestane talen noemen en wat er gebeurt als de tijd om is.

Step 6: Bekijk vooraf, werk de checklist af en publiceer

Gebruik "Preview as candidate" en maak de taak zelf, of beter: laat een engineer die hem niet heeft geschreven hem onvoorbereid maken. Is diegene in tien minuten klaar, dan is de taak te makkelijk; lukt het niet binnen de limiet, versoepel dan de scope of de klok. Herstel de opdracht overal waar diegene aarzelde.

Werk daarna de publicatiechecklist af — die blokkeert "Publish" totdat scoring, timing en instructies compleet zijn. Een programmeertest zonder rubric of met een ongeteste tijdslimiet hoort nooit bij een kandidaat terecht te komen, en de checklist voorkomt dat.

Step 7: Stel integriteitscontroles in naar rato van wat er op het spel staat

Maak de afname aan met een naam en een tijdvenster, en kies daarna bewust welke beveiligingsopties u aanzet. Voor een standaard wervingsscreening zijn het blokkeren van kopiëren/plakken en Lockdown in volledig scherm met een redelijke overtredingslimiet meestal genoeg. Webcamopname, schermopname, detectie van een tweede scherm en identiteitscontroles bestaan voor afnames waar echt veel op het spel staat — certificering, laatste ronden — niet als standaardinstelling.

Alles wat u aanzet, wordt vóór de start van de kandidaat bij de toestemmings- en preflightstap gemeld. Integriteitssignalen zijn markeringen die een mens in context beoordeelt, nooit een grond voor automatische afwijzing — het verlaten van volledig scherm kan een melding zijn, geen fraude. Proportionaliteit voorkomt dat sterke kandidaten afhaken bij een sleepnet van toezicht.

Step 8: Beoordeel code met de rubric, met AI als ondersteuning

Beoordelaars bekijken elke inzending tegen de gedeelde rubric en klikken per criterium — correctheid, leesbaarheid, aanpak — op de niveaukaart die bij de code past. Twee beoordelaars inzetten bij grensgevallen of zwaarwegende gevallen houdt de norm eerlijk, en omdat iedereen scoort tegen hetzelfde bevroren rubricsnapshot, komen meningsverschillen naar boven als concrete verschillen per criterium in plaats van als vaag onderbuikgevoel.

AI kan een samenvatting van de inzending opstellen en scores per criterium voorstellen — een echt bruikbare eerste ronde bij code, waarbij model en versie voor de administratie worden gelogd. Maar een met naam genoemde engineer bevestigt of overschrijft elke score. AI is hier beslissingsondersteuning, nooit de beslisser: het verantwoordelijke oordeel over de code van een kandidaat is altijd menselijk.