Wat kan ik verwachten van een programmeertest?

[AGee]

Hoi,

Binnenkort ga ik op voor een baan in de ICT. Nu is me verteld door de recruiter dat een "softwaretest"
onderdeel uit kan maken van de sollicitatie-procedure. Na even doorvragen, blijkt dit om een test op
papier te gaan over C of C++. Op internet (zelfs hier op dit forum) zie verschillende reacties van mensen die
een soortgelijke test hebben gehad, maar nergens kan ik preciezere details vinden. Kan iemand mij
vertellen wat ik kan verwachten van zo'n test? Misschien mensen die zo'n test aanbieden en/of zelf
gemaakt hebben? Is het misschien te vergelijken met zoiets?

Groetjes,
Een (voormalig) informatica-student die al een poosje niet meer in C geprogrammeerd heeft.

[beany]

Mja, verschilt heel erg wat voor soort vragen je krijgt. Van doordenkers tot strikvragen tot idiote vragen.

Je kan je er ook niet op voorbereiden denk ik. Het is gewoon testen van je kennis

[AGee]

beany schreef op vrijdag 08 oktober 2010 @ 14:16:
Van doordenkers tot strikvragen tot idiote vragen.

Klinkt als een soort assessment / iq-test-achtig, waar je je wel degelijk op kunt voorbereiden (ongeacht wat
assessment-bureau's ook zeggen), maar de vraag of je je kunt voorbereiden gaat wat mij betreft al een beetje
off-topic. Ben gewoon benieuwd wat ik kan verwachten....

[beany]

Wat ik eigenlijk bedoelde is dat je nooit weet wat je kan verwachten omdat het ene bedrijf er serieus werk van maakt en het andere bedrijf er serieus werk van denkt te maken, maar in werkelijkheid een stagiaire wat vraagjes laat opstellen.

Zo heb ik eens een test gedaan, omdat ze wilden weten of ik goed kon programmeren in .Net. De test had alleen maar vragen over SQL(ik heb nog gevraagd of ik wel de goede test had gekregen, dit was zo).

[FrankTM]

beany schreef op vrijdag 08 oktober 2010 @ 14:29:
[..]
Zo heb ik eens een test gedaan, omdat ze wilden weten of ik goed kon programmeren in .Net. De test had alleen maar vragen over SQL(ik heb nog gevraagd of ik wel de goede test had gekregen, dit was zo).

dus toen heb je maar bedankt voor de functie?

[Jeroen V]

naitsoezn schreef op vrijdag 08 oktober 2010 @ 14:22:
Klinkt als een soort assessment / iq-test-achtig, waar je je wel degelijk op kunt voorbereiden (ongeacht wat
assessment-bureau's ook zeggen),

Je weet niet wat je moet verwachten, maar je weet wel dat je je kunt voorbereiden? Apart

Ik heb een tijdje geleden een C# test gedaan, en die was vrijwel onmogelijk om voor te bereiden. Niet omdat het nou zo ontzettend moeilijk was, maar omdat het gewoon zo ontzettend veel was. Het lukt je niet om in een paar dagen al die kennis te vergaren, die testen lukken je alleen als je de kennis paraat hebt. (of als je maanden hebt om je voor te bereiden)

[Voor 0% gewijzigd door AGee op 05-09-2016 12:13. Reden: nickchange edit]

[AGee]

beany schreef op vrijdag 08 oktober 2010 @ 14:29:
Wat ik eigenlijk bedoelde is dat je nooit weet wat je kan verwachten omdat het ene bedrijf er serieus werk van maakt en het andere bedrijf er serieus werk van denkt te maken, maar in werkelijkheid een stagiaire wat vraagjes laat opstellen.

Ok, dat snap ik, maar krijg je dan kennis/interpreteer-vragen (zoals: "wat is de output van dit stukje code", "hoe declareer je een pointer" of "wat is de syntax van een for/while/do/etc-loop") of krijg je de opdracht om een stukje software te schrijven om een bepaald probleem op te lossen?

[AGee]

Jeroen V schreef op vrijdag 08 oktober 2010 @ 14:40:
[...]


Je weet niet wat je moet verwachten, maar je weet wel dat je je kunt voorbereiden? Apart

Nou, ik weet idd niet wat ik moet verwachten, vandaar dit topic , maar iq-tests kun je prima voorbereiden hoor, zonder in een paar dagen een heel leven aan kennis op te doen. Oefenen is in veel gevallen al een zeer goede voorbereiding (vooral als je er even uit geweest bent), maar als je niet weet wát je moet oefenen is het inderdaad vrij zinloos (oefenen op cijferreeksen terwijl je een taal-toets voorgeschoteld krijgt bijvoorbeeld)...

[Voor 7% gewijzigd door AGee op 08-10-2010 14:50]

[TheDane]

Vaak gaat 't bij dat soort vragen niet eens om de vraag correct te beantwoorden, of het probleem op te lossen, maar juist om hoe je dat doet. Schiet je direct in paniek als in de test om een optimalisatie voor het berekenen van pi gevraagd wordt, of kun je het probleem analytisch aanpakken en een gestructureerde opzet maken voor het oplossen van een dergelijk vraagstuk. En dat kun je, inderdaad, zoals gezegd, prima oefenen.

[MuddyMagical]

TheDane schreef op vrijdag 08 oktober 2010 @ 14:51:
Vaak gaat 't bij dat soort vragen niet eens om de vraag correct te beantwoorden, of het probleem op te lossen, maar juist om hoe je dat doet. Schiet je direct in paniek als in de test om een optimalisatie voor het berekenen van pi gevraagd wordt, of kun je het probleem analytisch aanpakken en een gestructureerde opzet maken voor het oplossen van een dergelijk vraagstuk. En dat kun je, inderdaad, zoals gezegd, prima oefenen.

Met ^^

En het is belangrijker om mensen te hebben die analytisch kunnen denken en problemen kunnen aanpakken dan mensen die uit hun hoofd de declaratie van een for/while loop kunnen opzeggen.

[Kettrick]

MuddyMagical schreef op vrijdag 08 oktober 2010 @ 14:57:
[...]
En het is belangrijker om mensen te hebben die analytisch kunnen denken en problemen kunnen aanpakken dan mensen die uit hun hoofd de declaratie van een for/while loop kunnen opzeggen.

Deels waar, maar toch zijn een flink aantal bedrijven cijfermatig bezig als het om tests gaat. Ik heb tests gezien voor java middleware developers waar nog doodleuk om Swing meuk gevraagd wordt .

[beany]

FrankTM schreef op vrijdag 08 oktober 2010 @ 14:38:
[...]


dus toen heb je maar bedankt voor de functie?

Na 3 weken, toen bleek dat het werk vooral uit C++ werk bestond(dont ask...)

naitsoezn schreef op vrijdag 08 oktober 2010 @ 14:43:
[...]

Ok, dat snap ik, maar krijg je dan kennis/interpreteer-vragen (zoals: "wat is de output van dit stukje code", "hoe declareer je een pointer" of "wat is de syntax van een for/while/do/etc-loop") of krijg je de opdracht om een stukje software te schrijven om een bepaald probleem op te lossen?

Ehm... ja!

Nogmaals: het kan van alles zijn.

Meest domme vragen vind ik altijd: Welke methode van de class Console gebruik je om iets naar de console te schrijven waarbij automatisch een CRLF wordt toegevoegd?

Voor dit soort problemen(vraagstukken) heb je MSDN(of welke documentatie dan ook). De interessante vragen zijn de logica vragen e.d.

[Voor 0% gewijzigd door AGee op 05-09-2016 12:14. Reden: nickchange edit]

[Kettrick]

beany schreef op vrijdag 08 oktober 2010 @ 15:00:

Meest domme vragen vind ik altijd: Welke methode van de class Console gebruik je om iets naar de console te schrijven waarbij automatisch een CRLF wordt toegevoegd?

Voor dit soort problemen(vraagstukken) heb je MSDN(of welke documentatie dan ook). De interessante vragen zijn de logica vragen e.d.

Het gaat helaas nog een stukje verder, je wordt geacht stukken coden te voorspellen welke werkelijk onleesbaar zijn. Tijdens dat soort tests mis ik altijd de "I would kill my colleague" knop .

Het beheersen van eenvoudige API methods lijkt me redelijk nuttig om te testen , zolang het relevant is voor de functie.

[DexterDee]

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.

[AGee]

DexterDee schreef op vrijdag 08 oktober 2010 @ 15:39:
...

Kijk, daar kan ik wat mee. Dank!

[Hillie]

Op amazon kun je wat boeken vinden over 'cracking the code interview', of iets dergelijks. Er wordt nogal veel gebruik gemaakt van standaardvragen naar het schijnt. Zelf vis ik altijd in een gesprek uit hoeveel bullshit iemand praat, meer over methodologie e.d. dan een daadwerkelijk stukje coden. Maar da's mijn persoonlijke voorkeur.

[chucky]

Meestal zijn die tests geschreven door een van de seniors in het bedrijf, en ze verschillen dus voor elk bedrijf, en soms nog per functie..

Ik heb er ooit in gedaan over C++ / C, en dan ging gewoon over de taal.. Wanneer gebruik je het "friend" keyword, wat is het verschil tussen static en const, wat is een static const en wanneer gebruik je die.. Wat is een singleton.. Etc.

[Voor 46% gewijzigd door chucky op 08-10-2010 20:56]

[Frips]

Het bedrijf waar ik werk maakt gebruik van een aantal verschillende tests. Het type test is afhankelijk van het ervaringsniveau van de sollicitant (junior / senior).

Meestal krijg je in de eerste ronde een aantal standaard vragen die bedoeld zijn om zeer onervaren programmeurs eruit te filteren. Soms wordt hiervoor gebruik gemaakt van een standaard online examen van b.v. Blackbelt (http://www.blackbeltfactory.com).
Als je goed scoort met zo'n test wil het niet zeggen dat je een goeie programmeur bent, maar als je zwaar onvoldoende scoort dan zegt dat wel iets. Scheelt iedereen een boel tijd als die mensen meteen afgewezen worden. Dit kun je natuurlijk prima thuis oefenen.

Als je daarna het eerste interview doorkomt, dan krijg je een programmeer test die je thuis mag maken. Hier krijg je 24 of 48 uur voor (afhankelijk van test). Het gaat hier niet om kleine puzzeltjes of feitjes die je kunt googelen, maar om complexere problemen waar het vooral gaat om je design skills. Uiteraard kun je dit samen met je buurjongen maken, maar dan val je wel door de mand als je de code tijdens het volgende interview mag verdedigen

[Rhy]

Ik denk dat je worstcase scenario wat vragen krijgt over pointers, stacks en OO. Dat scheidt namelijk het gros van de script kiddies van de programmeurs. En ieder programmeer bedrijf wil natuurlijk graag het laatste.