Programmeeropdrachten bij solliciatieprocedures

[Macros]

Sinds kort ben ik weer aan het solliciteren voor een ontwikkelbaan. En kort door de bocht zijn er twee soorten solliciatie procedures. De eerste, waar je met een goede babbel en een mooi C.V. wordt aangenomen, en de tweede waar ze je laten bewijzen of je echt kan ontwikkelen. Ik ga liever voor een bedrijf werken dat de tweede variant gebruikt, omdat ik dan een grotere kans heb om met mensen samen te werken die ook echt kunnen ontwikkelen.
Nu vind ik die opdrachten wel erg interessant omdat er zo veel verschillende zijn. En ik later er wel een paar wil bedenken voor mensen die ik misschien moet interviewen.

Er zijn twee soorten opdrachten. Opdrachten die je meteen onder toezicht tijdens een gesprek op locatie moet doen. En opdrachten die je mee mag nemen als huiswerk. Voordeel van opdracht type 1 is dat er minder mogelijkheid is om vals te spelen door hulp te krijgen van iemand anders of het zelfs door iemand anders te laten maken. Maar een nadeel is dat de opdracht simpeler moet zijn omdat je gewoon niet zoveel tijd hebt.

Ik ken deze opdrachten:

Gesprekopdracht: Sollicitant kreeg een ontwikkelomgeving naar keuze en daarin moest hij de implementatie maken van een aantal simpele methodes. Elke methode had commentaar waarin omschreven stond wat de methode moest doen, en elke methode had een unittest, die de methode teste. Standaard faalde elke test. De taak van de sollicitant was om zoveel mogelijk tests te laten slagen. Door goede implementaties van de methodes te schrijven en voor extra bonuspunten mocht hij of zij de tests uitbreiden. Er werd bijgezegd dat tijd geen issue was, maar dat was het natuurlijk wel. Een snelle sollicitant wordt sneller aangenomen dan iemand die 15 min naar de code zat te staren.

Huiswerkopdracht: schrijf code die een int tussen de 1(inclusive) en 1.000.000.000 (exclusive) vertaald naar een string welke het getal als gesproken woord representeerd. Dus:
1 -> one
2 -> two
101 -> one hundred and one
etc

Huiswerkopdracht: schrijf een programma dat rock paper scissors tegen een speler kan spelen.

Wat vinden jullie van dit soort opdrachten en zijn er nog leuke opdrachten die jullie tegen zijn gekomen of zelf hebben gegeven aan sollicitanten. Het is niet de bedoeling om antwoorden van dit soort opdrachten te posten.

[Sick Nick]

Die opdrachten klinken een beetje als eerste jaars informatica practicum opdrachten, dat moet iedereen zonder problemen kunnen als je als programmeur aan de slag wilt.

[Xuj]

Persoonlijk vind ik het tweede soort opdrachten (huiswerk) te lang duren. Bij een sollicitatie zou ik eerder een opgave geven die misschien een minuut of vijf duurt om zo een snelle check te doen. Even kijken hoe mensen op zo'n vraag reageren en zien of ze functioneren onder druk. Het soort 'huiswerk' is ook haast een test om uit te vinden hoe goed iemand overweg kan met een zoekmachine: de meeste vragen zullen te vinden zijn op bijvoorbeeld StackOverflow.

Bij mijn eigen sollicitatie bij een bedrijf moest ik een sorteer functie schrijven die overweg kon met telefoonnummers en namen. Even een quicksort schrijven en je was klaar.

Maar het lijkt me dat je de vragen af laat wisselen afhankelijk van waarnaar je op zoek bent. Als je een C-programmeur zoekt lijkt het me wellicht handig om pointers te behandelen. Verder zou ik bijvoorbeeld iets vragen over recursieve functies...

[ Voor 5% gewijzigd door Xuj op 23-07-2011 20:12 ]

[Onbekend]

Programmeren is veel meer dan alleen maar code kloppen.
Helaas wordt er vaak alleen maar gekeken of je enigszins met die programmeertaal overweg kan.

Je kan (in theorie) voor zo'n test slagen door vele malen de code te kopiëren, goto's te gebruiken, geen pointers gebruiken en onnodig veel ram te op te eisen.


Bij ons op het bedrijf kijken we meestal alleen of de persoon al enige programmeerervaring heeft, en hoe die persoon met anderen kan communiceren. In de proeftijd wordt altijd snel duidelijk of iemand geschikt is of niet.
Want alleen dan kan je pas zien of hij/zij wel over de juiste kennis bezit en hoe snel iets aan te leren valt.

[Verwijderd]

Het concept van een programmeeropdracht klinkt heel leuk, maar het werkt alleen maar als de mensen die je zoekt onder het niveau zitten waarop je zelf zit.

Dan moet je dus eigenlijk gaan beslissen: "Hmm, hoe slim zouden de mensen zijn die dit gaan controleren?". Gok je te hoog, dan 'begrijpen ze je code niet' (want de oplossing is niet wat ze verwacht hadden, maar algoritmisch aantoonbaar beter). Gok je te laag, dan krijg je 'dit en dat had beter gekund' (maar dat weet je dan al van te voren).

Zo is het natuurlijk met de meeste sollicitaties; je moet een inschatting maken op basis van bijna geen informatie of het wel nut heeft om een technisch inhoudelijk correct antwoord te geven. Zo is het zelfs met de selectie van een bedrijf; op basis van een advertentie kun je in 95% van de gevallen bijna nooit iets zeggen over wat je functie zal inhouden of wat de arbeidsvoorwaarden zullen zijn, terwijl ik met 80% van aan mij aangeboden contracten gewoon niet akkoord ben gegaan en waar ik dus nooit zou hebben gesolliciteerd als ik dat van te voren had geweten.

Ik vraag me overigens af hoe andere mensen dat doen. Springt iedereen een gat in de lucht als hij/zij een baan heeft gevonden en tekent dan maar zo snel mogelijk?

[Matis]

Misschien is het leuker/handiger om een stukje code-review te doen met de sollicitant. Dit natuurlijk in de programmeertaal waarop jullie hem willen aannemen.

Introduceer (me opzet) een aantal gevaren en mogelijke fouten (precedence, associativity etc.) en laat de sollicitant er een aantal uitpikken. Je kunt ook een discrepantie introduceren tussen het commentaar en de daadwerkelijke uitkomst van de code. Op die manier kun je redelijk eenvoudig kijken of hij ook geschikt is voor XP

Het lijkt me wel netjes om dit vooraf aan te geven, dat de sollicitant als intake ook de code-review moet doen. Dan is hij er semi op voorbereid.

Het feit dat ze jou van die opdrachtjes laten maken, getuigt juist als onkunde vanuit het bedrijf.

[ Voor 7% gewijzigd door Matis op 24-07-2011 14:39 ]

[qadn]

Dat zijn "huiswerk" opdrachten? Really?

Wat mij betreft zijn die voorbeelden veels, maar dan ook veels te makkelijk.

Toegegeven als iemand daar niet uitkomt ...

Maar zoals eerder aangegeven in de thread; eerstejaars-informatica dingusjes.

Een aardige "ter plekke" opdracht die ik een keer gehad had ging over het omgaan met strings die te groot waren om in het geheugen te passen. En daar dan een aantal functies op implementeren. (reverse, sort op character-niveau, etc.)

Een aardige "huiswerk" opdracht die ik gehad had ging over 10 zinnen uit de engelse taal, alle leestekens, whitespace en capitalisation verwijderd. Alle 10 op dezelfde manier door elkaar gehusseld (dus letter 42 op plek x voor alle 10 de zinnen).
Zoek uit wat de zinnen waren. Documenteer de gedachtengang en de experimenten.

[-DarkShadow-]

Ik denk dat interviewopdrachten beter over problemen kunnen gaan dan over code. Leg een probleem voor aan de sollicitant en discussieer over een oplossing. Je zal snel merken of dat de sollicitant de niet voor de hand liggende valkuilen van het probleem opmerkt en of dat de sollicitant alle aangereikte informatie goed verwerkt wat imho veel belangrijker is dan debugvaardigheden.

Ik denk dat on-site programmeeropdrachten erg verstoord worden door ruis. Een sollicitant die de afgelopen drie maanden heeft gewerkt met dezelfde ontwikkelomgeving en taal als tijdens de opdracht zal misschien sneller klaar zijn dan een betere sollicitant die het afgelopen jaar in een andere taal heeft gewerkt. De betere sollicitant heeft misschien drie dagen nodig om weer op gang te komen met de gebruikte taal, maar levert vanaf dat moment betere resultaten. Ook gaan zenuwen en andere factoren heel erg meespelen met dit soort opdrachten.

[ Voor 42% gewijzigd door -DarkShadow- op 24-07-2011 15:37 ]

[defiant]

Onbekend schreef op zaterdag 23 juli 2011 @ 20:19:
In de proeftijd wordt altijd snel duidelijk of iemand geschikt is of niet.
Want alleen dan kan je pas zien of hij/zij wel over de juiste kennis bezit en hoe snel iets kan aanleren valt.

Dit wordt naar mijn mening te weinig gedaan, als ik soms lees door wat voor een HRM procedures sommige bedrijven hun kandidaten laten gaan, dat lijkt me dat eerder afschrikwekkend werken dan uitnodigend.

[Verwijderd]

Het is een teken van wantrouwen als bedrijven sollicitanten programmeer opdrachten laten uitvoeren tijdens de sollicitatie. Als een bedrijf niet gelooft dat ik de kennis en ervaring heb die op m'n cv staat, dan zouden ze me meteen moeten afwijzen in plaats van tests te geven.

Anderzijds zou ik niet willen werken voor een bedrijf dat twijfelt aan de kennis en ervaring die ik op m'n cv heb staan. Lijkt me bij voorbaat al een breuk in de vertrouwensrelatie.

De proeftijd is juist uitgevonden om slechte kandidaten alsnog kwijt te raken.

[Finwe]

Verwijderd schreef op zondag 24 juli 2011 @ 16:38:
Het is een teken van wantrouwen als bedrijven sollicitanten programmeer opdrachten laten uitvoeren tijdens de sollicitatie. Als een bedrijf niet gelooft dat ik de kennis en ervaring heb die op m'n cv staat, dan zouden ze me meteen moeten afwijzen in plaats van tests te geven.

Anderzijds zou ik niet willen werken voor een bedrijf dat twijfelt aan de kennis en ervaring die ik op m'n cv heb staan. Lijkt me bij voorbaat al een breuk in de vertrouwensrelatie.

De proeftijd is juist uitgevonden om slechte kandidaten alsnog kwijt te raken.

Mmm dat jij zo eerlijk en netjes bent betekent niet dat andere programmeurs dat ook zijn. Het is algemeen bekend dat mensen hun CV's opleuken. Dit is wel eens leuk om te lezen: http://www.codinghorror.c...-programmers-program.html. Ik denk dat programmeer-opdrachten uitvoeren juist de enige manier is om een goede kandidaat te vinden.

Natuurlijk heb je de proef-periode van een maand, maar als je eerst 5 proef-periodes van een maand doormoet voordat je de goede hebt gevonden, ben je een heleboel tijd en geld kwijt. Nee, dan stel ik liever wat vragen.

[Verwijderd]

Je zou het ook andersom kunnen stellen. Van ontwikkelaars met een WO opleiding heb ik al vaker gehoord dat het niveau in het bedrijfsleven heel erg tegenvalt ten opzichte van de universiteit. Als ik met met een WO opleiding tijdens sollicitatiegesprekken de interviewers allerlei ingewikkelde technische programmeer vragen ga stellen om er achter te komen hoe het niveau in het betreffende bedrijf is zal dat worden gezien als dominant of arrogant gedrag en kan ik de baan vergeten.

[Verwijderd]

Verwijderd schreef op zondag 24 juli 2011 @ 18:19:
Je zou het ook andersom kunnen stellen. Van ontwikkelaars met een WO opleiding heb ik al vaker gehoord dat het niveau in het bedrijfsleven heel erg tegenvalt ten opzichte van de universiteit. Als ik met met een WO opleiding tijdens sollicitatiegesprekken de interviewers allerlei ingewikkelde technische programmeer vragen ga stellen om er achter te komen hoe het niveau in het betreffende bedrijf is zal dat worden gezien als dominant of arrogant gedrag en kan ik de baan vergeten.

/me is blij dat hij niet de enige is die dat ziet

Ik was het ook al eens met die andere opmerkingen. Dat dat nog kan gebeuren hier.

[ Voor 6% gewijzigd door Verwijderd op 24-07-2011 18:27 ]

[Onbekend]

Finwe schreef op zondag 24 juli 2011 @ 17:03:
Natuurlijk heb je de proef-periode van een maand, maar als je eerst 5 proef-periodes van een maand doormoet voordat je de goede hebt gevonden, ben je een heleboel tijd en geld kwijt. Nee, dan stel ik liever wat vragen.

Je neemt natuurlijk niet blind een sollicitant aan. Als je in het sollicitatiegesprek een beetje doorvraagt kom je snel achter wat hij allemaal heeft geprogrammeerd en wat zijn rol in het hele ontwikkelproces was. Met nog wat meer vragen pik je zo de juiste mensen eruit. Helaas is het leermogelijkheid niet gemakkelijk in het sollicitatiegesprek te bepalen.

[sub0kelvin]

Ik ben voor het gebruik van programmeeropdrachten, maar niet zoals ze hier worden gepresenteerd.
Bij het bedrijf waar ik werk richten we ons met name op mensen met max 2 jaar ervaring. Wij maken bij sollicitaties gebruik van een open programmeeropdrachtje die tussen het eerste en het tweede gesprek (normaliter een week later) gemaakt moet worden. Bij een evt. sollicitatie van een senior is het sollicitatieproces uiteraard totaal anders, en wordt er bijv. geen opdracht gegeven.

Aangezien we webapplicaties in Java en C# maken, vragen we de mogelijke collega een kleine webapplicatie te maken. Bij voorkeur met de frameworks en technieken die wij ook gebruiken, maar niets is verplicht. Al zouden ze het in Lisp schrijven, dat boeit niet. In het 2e gesprek wordt dan een code-review gedaan van de applicatie, samen met de sollicitant. We doen dit niet om te kijken of degene kan programmeren, dat geloven we wel, anders hadden we hem/haar niet voor een 2e gesprek uitgenodigd.

Het gaat er ons om hoe de sollicitant in z'n schoenen staat ten opzichte van z'n eigen code. Was hij/zij bewust van z'n beslissingen en staat hij er ook achter? Hoe brengt de kandidaat kennis over de werking van zijn eigen creatie over? Hoe gaan ze om met deadlines? Is er gekozen voor de makkelijke uitweg, of voor een uitdaging? Hoe gingen ze om met de problemen die ze tegenkwamen? Kunnen ze iets vertellen over de voor- en nadelen van gekozen technieken, is men perfectionist of pragmatist, hoe hebben ze de evt. nieuwe kennis vergaard ... dat soort dingen. Tenslotte prikken we hier en daar wat gemeen om te testen hoe hij/zij omgaat met (terechte en onterechte ) kritiek op hun werk.

Dat zijn namelijk allemaal dingen die je tegenkomt of moet kunnen als je nauw in een team samenwerkt en van elkaar afhankelijk bent. We hopen zo wat beter inzicht te krijgen in hoe die persoon daar mee om gaat en of het dus een passende teamgenoot is.

Het leuke aan deze methode vind ik dat je de meest uiteenlopende creaties tegenkomt; sommigen duiken met liefde het onbekende in en maken toch de mooiste applicaties met databasekoppelingen, grafisch gelikt en ook nog unittests en documentatie. Anderen zeggen de kennis te hebben maar lopen de kantjes ervan af en maken het minimale zelfs maar half af. Of iemand die een wat rommelige applicatie had geschreven, maar dat 'bewust' had gedaan omdat ze zich had gefocust op het laten zien van allerlei interessante trucjes.

M.i. haal je dat soort passie en inzet er niet uit met gewoon wat vragen te stellen of met gesloten opdrachten. Daar moet bij worden gezegd dat wij bijna nooit werken met een proeftijd: je krijgt bij ons meestal een jaarcontract. Dus er is een soort van risico dat we willen beperken. In plaats van onnodig risico te nemen, kan je iemand met een kleine CV dan m.i. het beste de kans geven zich te bewijzen met een simpele opdracht.
----

Goed, dan de opdrachten zoals de TS heeft genoemd. Dat zijn vooral algoritmische tests en stress tests die veel minder inzicht geven in hoe iemand in werkelijkheid functioneert en produceert. Code kloppen kunnen de meesten wel, en algoritmes uitschrijven ook wel. Dus ik vind zo'n opdracht niet echt iets toe voegen aan het sollicitatieproces.

Matis' voorstel om een gesimuleerde code-review te doen vindt ik een mooie, misschien dat ik die ook eens ga introduceren. Blijft het voor ons ook wat leuker: variatie van spijs doet eten, niet waar? En daarnaast ben ik het eens met Dr. Rockzo en gang-ster dat als je een goed gevoel hebt bij een ervaren persoon met een uitgebreid en duidelijk CV, je diegene niet moet lastigvallen met tests.

ai, veel tekst!
tl;dr: bij kandidaten met weinig ervaring vind ik code-reviews (op eigen of geselecteerde code) erg handig en nuttig, maar triviale goed/fout of punten-opdrachtjes niet.

[Macros]

Bij elke test lijkt me het inderdaad handig om een code review met de kandidaat te doen. Wat je ook wel vaak hoort dat kandidaten wat code moeten opsturen wat ze ooit zelf hebben gemaakt en waarop ze trots zijn.

Ik denk juist niet dat alleen afgaan op het C.V. werkt. Op de universiteit heb ik ook een aantal studenten gezien die heel ver kwamen zonder een regel code te kunnen schrijven. Dat soort mensen kunnen ook goed gedijen in de wat grotere bedrijven. Als je een goede babbel hebt en organisatorisch goed bent dan willen managers nog wel eens een oogje dicht knijpen.

sub0kelvin, heb je een voorbeeldje van 1 van die webapplicaties die jij of iemand ooit heeft gemaakt? Met GWT en google appengine is het erg makkelijk om die programmeer opdrachtje in de cloud te hangen zonder dat het je een cent kost

[sub0kelvin]

Macros schreef op zondag 24 juli 2011 @ 21:06:
sub0kelvin, heb je een voorbeeldje van 1 van die webapplicaties die jij of iemand ooit heeft gemaakt? Met GWT en google appengine is het erg makkelijk om die programmeer opdrachtje in de cloud te hangen zonder dat het je een cent kost

Andermans werk ga ik niet online zetten, en zelf ben ik de uitzondering die de regel bevestigt: ik hoefde geen programmeeropdracht te doen. Dus ik kan je geen concrete voorbeelden laten zien. Maar ik zie ook niet precies wat je daar aan zou hebben.

Wij werken onder Java met Wicket-Spring-Hibernate (en in C# met MVC-Spring-NHibernate), daarom beginnen de meesten met de Wicket 1.4 quickstart en werken vanaf daar door naar de applicatie die ze in hun hoofd hebben. Dat varieert dan van een extreem simpele CRUD DVD-catalogus tot een blog-engine(tje) met autorisatie en een SOAP-koppeling voor externe invoer van blogs, en alles daar tussenin.

We geven dus geen concrete opdracht, want het maakt ons eigenlijk niets uit wat het doet. Het gaat om de code en het totaalplaatje wat daar bij hoort.

[Macros]

Wij gebruiken ook Wicket. Ik denk dat ook wel goed is omdat Wicket best een steile leercurve heeft. Als het dus lukt om iets snel in elkaar te bakken, dat betekent dat die persoon wel iets in zijn mars heeft. Er zijn mensen op mijn werk die na een paar maanden Wicket nog steeds zitten aan te rommelen omdat ze het gebruik van models niet begrijpen.

[Alarmnummer]

Ik heb zelf een aantal jaren bij Xebia gewerkt. Een 'kleine' consultancy club in het midden van het land. Ik heb toen ik er ging werken ook een assessment gekregen in de vorm van een programmeeropdracht. Het leuke dat ik er aan vond is dat het een erg vrije opdracht was, maw iedereen kan zijn eigen draai er aan geven.

Ik heb er uiteindelijk geen code bijgeschreven, maar alleen een analyze gemaakt van de concurrency bugs. Ik heb er uiteindelijk 3.5 jaar gewerkt. Ik heb in deze periode zelf ook veel assessments afgenomen en je kunt snel het kaft van het koren scheiden. Dito geld voor mensen die wat nerveus zijn kan je mbv zo'n opdracht toch veel meer van zichzelf laten zien.

Kortom: aanrader.

Ik heb verder een hekel aan programmeer-opdrachten op de spot. Niet ieders hersenen die werken gelijk onder druk en je hebt snel genoeg in de gaten als iemand zijn eigen opdracht niet heeft gemaakt.

Een andere manier om te kijken wat je in huis haalt, is na te vragen welke open source project de persoon in kwestie aan mee werkt.

[ Voor 10% gewijzigd door Alarmnummer op 24-07-2011 22:39 ]

[Finwe]

Verwijderd schreef op zondag 24 juli 2011 @ 18:19:
Je zou het ook andersom kunnen stellen. Van ontwikkelaars met een WO opleiding heb ik al vaker gehoord dat het niveau in het bedrijfsleven heel erg tegenvalt ten opzichte van de universiteit. Als ik met met een WO opleiding tijdens sollicitatiegesprekken de interviewers allerlei ingewikkelde technische programmeer vragen ga stellen om er achter te komen hoe het niveau in het betreffende bedrijf is zal dat worden gezien als dominant of arrogant gedrag en kan ik de baan vergeten.

Daar ben ik het mee eens, als je programmeer-interviews afneemt moet je zelf eigenlijk hetzelfde (of een hoger) niveau hebben dan degene die je interviewt, anders wordt het een raar gesprek En zo'n persoon vinden is niet bij ieder bedrijf zo makkelijk. Als je merkt dat degene die je interviewt beter is dan jezelf zou ik hem trouwens direct aannemen, maar ik kan me voorstellen dat er ook mensen zijn die het als vervelend of arrogant bestempelen, of bang zijn dat er een "concurrent" bijkomt.

Een programmeer-opdracht hoeft ook niet zo te zijn van: dit is het probleem, zoek het zelf maar uit en schrijf het algoritme maar op. Het is vaak ook een levendige (soms zelfs leuke) discussie tussen interviewer en sollicitant, waarmee je samen naar een oplossing toewerkt. Het gaat erom dat je ziet hoe iemand een probleem tackled. En dat je uiteindelijk code ziet is toch wel handig, zo komen er toch regelmatig mensen langs die bijvoorbeeld objecten op de stack leggen en doodleuk een pointer naar zo'n object buiten z'n life-time scope gebruiken. Ik vraag me toch af hoe je dit soort mensen eruit pikt zonder ze code te laten schrijven. Misschien door ze echt heel gerichte vragen te stellen...maarja dan kan je ze net zo goed de bijbehorende code laten schrijven.

[Blue-eagle]

Bij dit soort opdrachten vraag ik me dan af.. wat nou als de programmeur simpelweg het antwoord niet weet? Ik bedoel: Je neemt een vraagstuk waar hij geen ervaring mee heeft. De beste methode om het probleem op te lossen zou waarschijnlijk een zoekopdracht zijn via Google. Als je slim zoekt ben je zo direct al een hele lading mogelijke bugs voor, en heb je wellicht een meer optimale oplossing dan waar je zelf op uitgekomen zou zijn.

TL;DR: Sta je de ontwikkelaar toe Google te gebruiken? Ik zou hem alle middelen willen bieden, persoonlijk.

Edit: Ontwikkelomgevingen waar internet niet handig beschikbaar is (zoals overheid, bankwezen, et cetera) daargelaten, natuurlijk.

[ Voor 11% gewijzigd door Blue-eagle op 25-07-2011 00:13 ]

[mrmrmr]

Bij programmeurs is het essentieel te beschikken over code die door de sollicitant is ontwikkeld. Soms is dat niet voorhanden (copyright, meerdere mensen hebben eraan gewerkt), en dan is een opdracht een goed alternatief.

Een opdracht die geen functioneel doel dient, daar heb je niet zoveel aan. Dat is schoolwerk. Een opdracht die in de praktijk in het betreffende bedrijf wel voorkomt, daar heb je wat aan. Je kunt dan beoordelen hoe een persoon het aanpakt. Het gaat niet alleen om eindresultaat, maar ook hoe dat wordt bereikt. Stijl, rekening houden met toekomstige updates, met veiligheid en documentatie.

Zo'n opdracht zou ook naar redelijkheid betaald moeten worden. Daarmee geef je als bedrijf aan dat je er niet lichtzinnig over denkt en de kandidaat krijgt (terecht) het gevoel dat hij/zij serieus genomen wordt.

Bedrijven die niet de benodigde kennis in huis hebben om een beoordeling te maken, kunnen er beter niet aan beginnen.

[sub0kelvin]

Finwe schreef op maandag 25 juli 2011 @ 00:06:
Daar ben ik het mee eens, als je programmeer-interviews afneemt moet je zelf eigenlijk hetzelfde (of een hoger) niveau hebben dan degene die je interviewt, anders wordt het een raar gesprek

Wat ik tot dusver heb gemerkt valt dat reuze mee. Ook iemand met minder ervaring kan een ander van een hoger niveau herkennen en beoordelen waar deze ongeveer staat. Tijdens zo'n interview richt je je namelijk niet alleen op of iemand een shitload aan technische kennis in huis heeft. Natuurlijk moet je niet iemand met 1 jaar ervaring niet tegenover iemand met 15 jaar werkervaring zetten. Maar dat heeft veel meer redenen.

Sowieso, de meeste mensen zijn geen generalisten maar specialisten. Bij het afnemen van een sollicitatie zul je dus, zelfs als zeer ervaren ontwikkelaar, iemand voor je krijgen die vaak ergens beter in is.
Maar met zelfkennis over wat je wel en _niet_ weet, plus de ervaringen die je hebt met collega's en hun kennis (die ook van hoger en lager niveau dan jou zullen zijn), kun je een groot deel van de mensen wel ergens op de niveau-meetlat plaatsen. En het maakt over het hele sollicitatie-proces erg weinig uit of je iemand een stapje te hoog of te laag hebt geschat: er spelen zo veel factoren mee of iemand geschikt is voor een functie. Ik durf te wedden dat niemand exact goed wordt geschat bij een sollicitatie, daarvoor is het proces te kort en niet geschikt.

Als je merkt dat degene die je interviewt beter is dan jezelf zou ik hem trouwens direct aannemen ...

Natuurlijk niet! Iemand kan een goddelijke developer zijn, als hij niet in het team past, vastgeroest is in zijn goddelijkheid, zijn kennis niet kan overbrengen, niet tegen kritiek kan of een van de 1001 andere mogelijke gebreken vertoont kan dat een hele goede reden zijn hem toch niet aan te nemen. Om dat te zien in een sollicitant hoef je niet van het zelfde technische niveau te zijn, maar moet je natuurlijk wel technisch onderlegd zijn.

En dat heeft dan niks met arrogantie of bang zijn voor concurrentie te maken. Als je als interviewer je zo sterk laat leiden door dat soort gevoelens, dan vind ik dat je eigenlijk geen sollicitaties zou moeten afnemen.

Macros schreef op zondag 24 juli 2011 @ 22:01:
Er zijn mensen op mijn werk die na een paar maanden Wicket nog steeds zitten aan te rommelen omdat ze het gebruik van models niet begrijpen.

Really, maanden aanrommelen? Probeer eens het boek Wicket In Action. Als ze die van voor tot achter doornemen, of in elk geval hoofdstuk 1 t/m 3 (of 4?), zou het ze eigenlijk helemaal duidelijk moeten zijn. Als ze het dan nog niet snappen dan moet daar misschien iets mee worden gedaan. Bijv. verscherping van de sollicitatieprocedure of op een andere manier begeleiden/inwerken van nieuwe collega's.

[zircondan]

Zelf ben ik van mening dat je met de twee opgegeven opdrachten niet iemands kunde helemaal goed doorgrondt. Liever stel ik aan de sollicitant vragen m.b.t. hoe zij een problemen zouden aanpakken. Met het antwoord kan ik al aardig inschatten hoe goed iemand is. Programmeren is niet alleen maar een problemen oplossen in code, het is juist een probleem te begrijpen en deze te doorgronden.

Iemand die hele mooie code kan schrijven is heel erg handig, maar iemand die heel analytisch en creatief tegelijk een probleem op kan lossen is naar mijn mening evenveel waard.

Zelf werk ik graag met sociale mensen die samen met mij een probleem willen en kunnen oplossen. Iemand die helemaal alleen een probleem op kan lossen is voor het bedrijf handig totdat deze persoon om welke reden dan ook uitvalt. En nogmaals gelukkig is er ook nog de proeftijd. Mocht je als bedrijf 4x een 'verkeerde' persoon hebben aangenomen en hierachter te zijn gekomen tijdens de proeftijd, dan wordt het tijd zelf naar je eigen selectie procedure te kijken.

[Finwe]

sub0kelvin schreef op maandag 25 juli 2011 @ 09:16:
[...]

Wat ik tot dusver heb gemerkt valt dat reuze mee. Ook iemand met minder ervaring kan een ander van een hoger niveau herkennen en beoordelen waar deze ongeveer staat. Tijdens zo'n interview richt je je namelijk niet alleen op of iemand een shitload aan technische kennis in huis heeft. Natuurlijk moet je niet iemand met 1 jaar ervaring niet tegenover iemand met 15 jaar werkervaring zetten. Maar dat heeft veel meer redenen.

Dat geldt voor interviews zonder programmeer-opdrachten; echter, als je programmeer-opdrachten afneemt moet je zelf toch ook de nodige ervaring hebben wil je iemand goed kunnen beoordelen. Ik heb zelf programmeer-interviews gehad die vrij diep gingen, en als mijn interviewer niet evenveel ervaring had gehad als ik was dat nooit gelukt, en had hij mij ook niet goed op waarde kunnen schatten. Natuurlijk, hij had kunnen denken "hij is veel beter dan ik, neem maar aan". Maar als je 5 mensen interviewt, is het wel erg nuttig om ze enigszins goed in te schatten om te weten welke je nou moet aannemen. Natuurlijk komt het niet aan op een paar jaartjes meer of minder - maar meer dan 5 jaar verschil is een te groot verschil naar mijn mening.

Sowieso, de meeste mensen zijn geen generalisten maar specialisten. Bij het afnemen van een sollicitatie zul je dus, zelfs als zeer ervaren ontwikkelaar, iemand voor je krijgen die vaak ergens beter in is.
Maar met zelfkennis over wat je wel en _niet_ weet, plus de ervaringen die je hebt met collega's en hun kennis (die ook van hoger en lager niveau dan jou zullen zijn), kun je een groot deel van de mensen wel ergens op de niveau-meetlat plaatsen. En het maakt over het hele sollicitatie-proces erg weinig uit of je iemand een stapje te hoog of te laag hebt geschat: er spelen zo veel factoren mee of iemand geschikt is voor een functie. Ik durf te wedden dat niemand exact goed wordt geschat bij een sollicitatie, daarvoor is het proces te kort en niet geschikt.

Wederom, in het algemeen ben ik het met je eens, maar bij programmeer-opdrachten niet. Programmeer-opdrachten beginnen vaak zeer generalistisch; het gaat om zaken die iedere goede programmeur zou moeten weten. Denk aan data-structuren, algoritmes, run-time complexity, concurrency. Daarnaast gaat het om ervaring - door ervaring weet je wanneer je bepaalde dingen moet toepassen, wanneer je op je hoede moet zijn, etc.

Natuurlijk niet! Iemand kan een goddelijke developer zijn, als hij niet in het team past, vastgeroest is in zijn goddelijkheid, zijn kennis niet kan overbrengen, niet tegen kritiek kan of een van de 1001 andere mogelijke gebreken vertoont kan dat een hele goede reden zijn hem toch niet aan te nemen. Om dat te zien in een sollicitant hoef je niet van het zelfde technische niveau te zijn, maar moet je natuurlijk wel technisch onderlegd zijn.moeten afnemen.

Mee eens, "beter dan jezelf" is natuurlijk niet het enige criterium. Misschien is mijn mening ook een beetje biased - ik werk in Silicon Valley voor een bedrijf waar dagelijks zoveel CV's binnenkomen dat een goede en nauwkeurige interview-procedure ontzettend belangrijk is. In Nederland liggen de goede kandidaten niet voor het oprapen, dat weet ik dan ook weer uit ervaring.

[sub0kelvin]

Finwe schreef op maandag 25 juli 2011 @ 10:07:
Mee eens, "beter dan jezelf" is natuurlijk niet het enige criterium. Misschien is mijn mening ook een beetje biased - ik werk in Silicon Valley voor een bedrijf waar dagelijks zoveel CV's binnenkomen dat een goede en nauwkeurige interview-procedure ontzettend belangrijk is. In Nederland liggen de goede kandidaten niet voor het oprapen, dat weet ik dan ook weer uit ervaring.

Ik denk dat dit verschil inderdaad meespeelt. Ik herken bijvoorbeeld het eerder genoemde artikel http://www.codinghorror.c...-programmers-program.html en de bijbehorende statistieken totaal niet, volgens mij is dat vooral een Amerikaans probleem waar iedereen en z'n moeder reageert op vacatures en je dus flink moet filteren.

Wij werken meestal niet met specifieke vacatures, maar met juist met open vacatures die het hele jaar gelden en we nodigen ook regelmatig zelf mensen uit. Dan is het niet een kwestie van "wie is de beste",
maar "is deze geschikt voor functie XYZ", en dat is makkelijker te bepalen.

Natuurlijk komt het niet aan op een paar jaartjes meer of minder - maar meer dan 5 jaar verschil is een te groot verschil naar mijn mening.

Ik denk niet dat het een lineaire schaal is. Iemand met 2 jaar ervaring zal problemen krijgen bij het beoordelen van iemand met 10 jaar ervaring. Maar iemand met 10 jaar ervaring kan m.i. wel iemand met 20 jaar ervaring aan de tand voelen. Overigens loopt er bij ons niemand rond met 20 jaar ontwikkelervaring en volgens mij zit je in die categorie al lang niet meer te rommelen met algemene programmeer-interviews. Wederom sterk afhankelijk van de "is deze geschikt"- vs "wie is de beste"-mentaliteit.

[Hillie]

sub0kelvin schreef op maandag 25 juli 2011 @ 10:53:
Wederom sterk afhankelijk van de "is deze geschikt"- vs "wie is de beste"-mentaliteit.

Ook dat is nogal eens lastig. Net als finme zit ik in silicon valley, in een iets specialistischere hoek. Vorig jaar ook in een wervingstraject geholpen en als je dan ziet hoeveel CV's je ziet met "veel ervaring", maar de beste mensen kunnen basisconcepten niet eens beschrijven en koppelen. En dan heb ik het niet over zaken waarbij je toch zeker een paar jaar ervaring nodig hebt, nee doodgewone standaardconcepten die ik je in een uurtje uit kan leggen en waar niet-ingewijden ook zowat mee aan de slag kunnen. De hoeveelheid mensen die niet eens een basisgeschiktheid konden tonen vond ik eerlijk gezegd stuitend groot.

Maar goed, dan tref je ineens iemand die uit de modderpoel boven komt drijven en dan wordt het meer de "beste" vraag. Helaas zijn er zoveel prutsers, dat simpele codevraagstukken noodzakelijk blijken. Zelf wil ik graag ook begrip van concepten zien, dus (wel wat ideetjes opgedaan in dit topic) de volgende keer zal ik mensen eens laten filosoferen over een stuk code en bijbehorend vraagstuk.

[MSalters]

Het klassieke linkje voor dit soort topics. En uit die hoek komt ook de Fizz Buzz test. De eerste test is alleen bedoeld om prutsers buiten te houden.

[sub0kelvin]

Hillie schreef op maandag 25 juli 2011 @ 12:58:
[...]


Ook dat is nogal eens lastig. Net als finme zit ik in silicon valley, in een iets specialistischere hoek. Vorig jaar ook in een wervingstraject geholpen en als je dan ziet hoeveel CV's je ziet met "veel ervaring", maar de beste mensen kunnen basisconcepten niet eens beschrijven en koppelen.

Hoe kán dat?! Slecht onderwijs in de USA? Of zijn dat dan mensen die ronduit liegen op hun CV (niet bestaande vorige werkgevers enzo) of hebben ze hun slechte kwaliteiten tot dusver in elke baan kunnen verstoppen voor de baas?

offtopic:
Ik zou bijna naar de VS gaan voor een baan, gewoon om het gemiddelde niveau wat omhoog te brengen (en dat van iemand met nog maar een paar jaar werkervaring)

[RagaBaSH]

MSalters schreef op maandag 25 juli 2011 @ 13:10:
Het klassieke linkje voor dit soort topics. En uit die hoek komt ook de Fizz Buzz test. De eerste test is alleen bedoeld om prutsers buiten te houden.

Hah! ik wou net joelonsoftware er bij zetten. Precies passend bij deze discussie.

Ik ben dan wel geen programmeur, maar bij mijn sollicitatie heb ik een vergelijkbare issue gehad.
kleine achtergrond nodig: Ik ben consultant in de financieel zakelijke dienstverlening, en heb een bestuurskundige achtergrond.
Mijn interviewer vroeg me om de werking van een technisch item (mijn geval magetron) te beschrijven.

Het antwoord zelf maakt niet uit, maar waar op gelet wordt is of je 1. je uitleg helder en beknopt kan overbrengen. 2. de werking methodisch/procesmatig beschrijft en 3. hoe zeer je uit het veld geslagen wordt.

De antwoorden van mij en mijn collega's met vergelijkbare vragen liepen van de uitleg van verwarming op atomisch niveau door microgolven tot een functionele beschrijving van iemand die een bord rijst opwarmt.
Diegene die afvielen waren de mensen die zeiden: weet ik niet, hij doet het altijd gewoon als ik de knop indruk.

Tot slot denk ik dat de keus tussen huiswerk en gespreksopdracht gemaakt moet worden op basis van wat je zoekt.
Zoek je iemand die in een relatief statische omgeving veel kennis moet hebben van de al gebruikte technieken, dan kan je hem daar wellicht het best op testen met een huiswerkopdracht. (denk aan banken, verzekeraars, utiliteiten, eigenlijk alles waar IT ondersteunend is)
Zoek je iemand die de snelle veranderingen in technologie kan bijbenen heb je denk ik meer aan een gespreksopdracht. (detacheerders, softwarehuizen met eigen vernieuwend product, softwarehuizen die werken op projectbasis).

[Hillie]

sub0kelvin schreef op maandag 25 juli 2011 @ 14:04:
[...]

Hoe kán dat?! Slecht onderwijs in de USA? Of zijn dat dan mensen die ronduit liegen op hun CV (niet bestaande vorige werkgevers enzo) of hebben ze hun slechte kwaliteiten tot dusver in elke baan kunnen verstoppen voor de baas?

offtopic:
Ik zou bijna naar de VS gaan voor een baan, gewoon om het gemiddelde niveau wat omhoog te brengen (en dat van iemand met nog maar een paar jaar werkervaring)

De Amerikanen kwamen juist goed voor de dag. De betreffende mensen hebben allemaal contractingwerk gedaan en helaas zijn er nog teveel opdrachtgevers die niet echt opletten en die mensen dus aan de bak houden. Er zit helaas wel gewoon een hoop schroothout tussen het aanbod.

[Cubic X]

sub0kelvin schreef op maandag 25 juli 2011 @ 14:04:
[...]

Hoe kán dat?! Slecht onderwijs in de USA? Of zijn dat dan mensen die ronduit liegen op hun CV (niet bestaande vorige werkgevers enzo) of hebben ze hun slechte kwaliteiten tot dusver in elke baan kunnen verstoppen voor de baas?

offtopic:
Ik zou bijna naar de VS gaan voor een baan, gewoon om het gemiddelde niveau wat omhoog te brengen (en dat van iemand met nog maar een paar jaar werkervaring)

Volgens mij kom je als IT'er uit Nederland de VS niet binnen...ze hebben daar zelf genoeg goede IT'ers en voordat je in aanmerking komt voor een verblijfsvergunning moet je aantonen dat jij iets kan wat Amerikanen niet kunnen...Amerika is echt streng wat betreft het mogen wonen en werken in het land.

[Verwijderd]

sub0kelvin schreef op maandag 25 juli 2011 @ 10:53:
Ik denk niet dat het een lineaire schaal is. Iemand met 2 jaar ervaring zal problemen krijgen bij het beoordelen van iemand met 10 jaar ervaring. Maar iemand met 10 jaar ervaring kan m.i. wel iemand met 20 jaar ervaring aan de tand voelen. Overigens loopt er bij ons niemand rond met 20 jaar ontwikkelervaring en volgens mij zit je in die categorie al lang niet meer te rommelen met algemene programmeer-interviews. Wederom sterk afhankelijk van de "is deze geschikt"- vs "wie is de beste"-mentaliteit.

Jaren ervaring zijn totaal irrelevant. Het gaat erom wat je in die jaren doet. Ik heb tegenover personen gezeten met 15+ jaar of zelfs 20+ jaar ervaring, maar ik kon in een gesprek met die mensen niets van die ervaring terugzien.

Het bedrijfsleven maakt je in zekere zin dom. Op een universiteit wordt je bij interessante vakken met interessante open-ended practica bijv. veel meer geprikkeld.

[Finwe]

Cubic X schreef op maandag 25 juli 2011 @ 19:35:
[...]

Volgens mij kom je als IT'er uit Nederland de VS niet binnen...ze hebben daar zelf genoeg goede IT'ers en voordat je in aanmerking komt voor een verblijfsvergunning moet je aantonen dat jij iets kan wat Amerikanen niet kunnen...Amerika is echt streng wat betreft het mogen wonen en werken in het land.

Je komt wel binnen hoor, en ik weet dat Google tegenwoordig zelfs actief mensen uit Nederland (en andere landen) recruit als je de juiste keywords op je LinkedIn hebt staan. Goede mensen zijn ook in de VS ontzettend lastig te vinden...

Maar dan moet je wel wat programmeer-interviews doorkomen

[ Voor 4% gewijzigd door Finwe op 26-07-2011 00:14 ]

[Matis]

Verwijderd schreef op maandag 25 juli 2011 @ 23:29:
Jaren ervaring zijn totaal irrelevant. Het gaat erom wat je in die jaren doet. Ik heb tegenover personen gezeten met 15+ jaar of zelfs 20+ jaar ervaring, maar ik kon in een gesprek met die mensen niets van die ervaring terugzien.

Och, zo lastig is dat niet. Ik prik in deze ook door het flinterdunne laagje elitaire onzin heen

Het bedrijfsleven maakt je in zekere zin dom. Op een universiteit wordt je bij interessante vakken met interessante open-ended practica bijv. veel meer geprikkeld.

Gelukkig kun je met het volgen van vakken en open-ended practica een boterham verdienen
Wake up, wat stelt een opleiding nu daadwerkelijk voor? Je begint pas met leren, ontwikkelen en verbreden ná het behalen van je diploma. Dat vodje is niets meer dan een bewijs dat je een x-aantal jaar op school hebt gezeten, zonder ook maar één enkel bewijs te geven hoe succesvol of geprikkeld jij daar in was.

[Macros]

Matis schreef op dinsdag 26 juli 2011 @ 00:29:
[...]

Gelukkig kun je met het volgen van vakken en open-ended practica een boterham verdienen
Wake up, wat stelt een opleiding nu daadwerkelijk voor? Je begint pas met leren, ontwikkelen en verbreden ná het behalen van je diploma. Dat vodje is niets meer dan een bewijs dat je een x-aantal jaar op school hebt gezeten, zonder ook maar één enkel bewijs te geven hoe succesvol of geprikkeld jij daar in was.

Dat is wel heel kort door de bocht.

[Matis]

Macros schreef op dinsdag 26 juli 2011 @ 09:10:
Dat is wel heel kort door de bocht.

Agreed, maar ik word een beetje moe van het eeuwige elitaire gedrag van gang-ster. Kennelijk heeft hij ook niet door dat de samenleving JUIST door mindergeschoolden op gang gehouden wordt.

Tevens is hij nog steeds in de veronderstelling dat je met een universitaire opleiding/diploma per definitie als god in Frankrijk wordt binnengehaald bij elk willekeurig bedrijf ter wereld. Meteen een salaris van 100K krijgt, drie Thaise masseuses voor de ontspanning en nooit meer wat hoeft te leren. Je hebt immers alles al op je opleiding (open-ended practica) gehad.

Ik probeer aan te geven dat je als starter ontzettend hard moet knokken om jezelf te bewijzen en, mocht de baas het zien, er voor te zorgen dat er in je geïnvesteerd wordt. Dit kan zowel om te verdiepen als om te verbreden.

Zoals ik het schets, is wel heel erg kort door de bocht, maar middelt de beleving van gang-ster wel een beetje uit.
Althans, dat hoop ik

Ik ben momenteel 1,5 jaar full-time aan het werk. Heb me gelukkig al kunnen bewijzen tijdens mijn stage, waardoor ik al een stukje makkelijker binnenkwam. Maar dan nog, moet je je telkens blijven bewijzen. Zowel tegenover jezelf, als collega's als leidinggevende.

[ Voor 7% gewijzigd door Matis op 26-07-2011 09:24 ]

[Verwijderd]

Matis schreef op dinsdag 26 juli 2011 @ 09:22:
Agreed, maar ik word een beetje moe van het eeuwige elitaire gedrag van gang-ster. Kennelijk heeft hij ook niet door dat de samenleving JUIST door mindergeschoolden op gang gehouden wordt.

Ik denk daar toch heel anders over.

Tevens is hij nog steeds in de veronderstelling dat je met een universitaire opleiding/diploma per definitie als god in Frankrijk wordt binnengehaald bij elk willekeurig bedrijf ter wereld. Meteen een salaris van 100K krijgt, drie Thaise masseuses voor de ontspanning en nooit meer wat hoeft te leren. Je hebt immers alles al op je opleiding (open-ended practica) gehad.

Jouw ervaringen zijn misschien anders.

Ik probeer aan te geven dat je als starter ontzettend hard moet knokken om jezelf te bewijzen en, mocht de baas het zien, er voor te zorgen dat er in je geïnvesteerd wordt. Dit kan zowel om te verdiepen als om te verbreden.

Er is _geen_ enkele opleiding in Nederland die mij nog iets op mijn vakgebied kan leren. Die 'cursussen' die door het bedrijfsleven gegeven worden, zijn helemaal om te huilen. Daarom investeer ik ook in mezelf door bepaalde zaken van andere aangrenzende vakgebieden te leren, juist omdat ik me anders ga vervelen met alleen maar Informatica. Heb je toch suggesties voor daadwerkelijk interessante opleidingen die bedoeld zijn voor informatici waarvan je denkt dat ik dat onmogelijk al kan weten, dan kun je dat altijd zeggen.

Opleidingbureau's bestaan, doordat het goedkoper is om slecht personeel een opleiding te geven dan duur personeel aan te nemen. Andere redenen kan ik helaas niet verzinnen, hoe cynisch dit ook moet klinken.

Zoals ik het schets, is wel heel erg kort door de bocht, maar middelt de beleving van gang-ster wel een beetje uit.
Althans, dat hoop ik

Jouw ervaringen en mijn ervaringen hoeven weinig met elkaar te maken te hebben.

Ik ben momenteel 1,5 jaar full-time aan het werk. Heb me gelukkig al kunnen bewijzen tijdens mijn stage, waardoor ik al een stukje makkelijker binnenkwam. Maar dan nog, moet je je telkens blijven bewijzen. Zowel tegenover jezelf, als collega's als leidinggevende.

Poeh hé! Al anderhalf jaar, als je dat in seconden heel snel uitspreekt, dan lijkt het nog wat! (Dit noemen we overigens sarcasme. )