In mijn rol neem ik ook mensen aan en een programmeertest is soms onderdeel van mijn aannamebeleid. De test heb ik zelf ontwikkeld en bevat een kleine praktijkopdracht die in een paar uur afgerond kan worden. Hierbij mag gebruik gemaakt worden van een PC met internet toegang en een werkende programmeeromgeving.
Het resultaat is een kleine applicatie en bijbehorende broncode. Deze wordt door mij geëvalueerd op correcte werking, semantiek, afwerking, inline documentatie, architectuur en robuustheid.
De opdracht vereist het gebruik van een aantal technieken die ook in onze live programmatuur toegepast worden en bestaat uit 'verplichte' en 'optionele' doelen. Je moet hierbij denken aan dingen als client/server socket communicatie, inter process communicatie technieken en concurrency.
Uit de resultaten kan ik erg veel afleiden. Als er veel optionele doelen zijn gerealiseerd, dan is de kans groot dat de programmeur bekend was met een groot deel van de gevraagde technieken. Iemand die minder bekend is met deze technieken, maar goed kan googlen, zal de opdracht werkend afronden, maar niet genoeg tijd hebben om veel optionele doelen te verwerken. Iemand die de gevraagde technieken niet meester is en de gevraagde informatie niet op tijd kan uitzoeken, zal een partieel werkende opdracht overhandigen.
Verder kun je uit de code erg veel afleiden. De keuze van het objectmodel, de gebruikte OOP technieken (zijn het voornamelijk static utility libraries, of is er sprake van interfaces, abstracts, correcte overerving, etc...). Source code documentatie geeft ook een interessant inzicht. Wordt er semantisch beschreven wat een stuk sourcecode nu doet, of staan er zaken in als "variabele a wordt op 0 gezet". Verder kijk ik ook kritisch of er defensief genoeg geprogrammeerd is. Als er een resource gemaakt wordt, dient gecontroleerd te worden of dit is gelukt. Ook dienen exceptions op het correcte niveau gegooid te worden en op het correcte niveau weer afgehandeld te worden. Door de applicatie te draaien en deze van verkeerde input te voorzien of resources onbeschikbaar te maken kan gemakkelijk worden gekeken hoe het is gesteld met de robuustheid.
Deze aanpak verschilt veel met bijvoorbeeld een papieren (multiple-choice) test. Daar ligt de focus vaak op het leren onthouden van functies, parameter volgorde, syntax en kennis van systeem libraries. Ik vind het niet erg als een kandidaat niet precies weet hoe een functie heet of wat de parameter volgorde is. Dat soort dingen kun je op internet in 2 tellen terug vinden. Ik vind het waardevoller dat een kandidaat zelfstandig een vraagstuk c.q. opdracht kan uitvoeren en een kwalitatief hoogwaardig stuk code oplevert binnen een redelijke tijd. Hoeveel hij hiervoor gegoogled heeft, is voor mij niet interessant. Dat mag hij onder werktijd voor een echte opdracht ook doen.
In jouw geval vermoed ik dat het een test zal zijn die zich zal toespitsen op de syntax van C/C++, memory management (pointers, malloc, etc), structuur (object orientatie, structs, etc), het gebruik van standaard libraries, oplossen van kleine vraagstukjes en wellicht iets over compilen en linken.
Klik hier om mij een DM te sturen • 3245 WP op ZW