Je hebt een programmeertest nodig. Maar het zou 5-10 minuten moeten duren. 30 minuten maximaal. Er is geen 2 uur durende test die je precies vertelt hoe goed een programmeur is. Je zult niet kunnen zien of ze voortdurend onderhoudbare code schrijven, of dat ze altijd goed commentaar geven, of dat ze met onleesbare rotzooi van ‘slimme’ oplossingen voor problemen komen, etc. In 2 uur tijd is het enige wat je zult bereiken dat je erachter komt wie er ronduit liegt over het kennen van een taal/programmering.

Behalve dat je in veel minder tijd dan 2 uur ronduit fraude zou moeten kunnen opsporen. 5 minuten lang schrijven van FizzBuzz en 2-3 snelle vragen over taalspecifieke kenmerken zullen u vertellen of ze absoluut waardeloos zijn. En dat is ongeveer het beste wat je kunt doen in een sollicitatiegesprek.

Laat me je vertellen wat ik zou denken als ik een 2 uur durend examen zou krijgen voor het voorrecht om een sollicitatiegesprek te voeren:

“Ofwel denken deze mensen dat dit waarde heeft wat betekent dat ze geen idee hebben wat ze doen, OF, ze weten dat dit tijdverspilling is, maar om een of andere reden (waarschijnlijk blindelings volgen van de administratieve rompslomp van HR), zijn ze bereid om de kandidaten tijd te verspillen voordat de kandidaat zelfs maar wordt aangenomen. Stel je voor wat ze denken te kunnen doen als ze me eenmaal betalen.

Hoe dan ook, ik wil daar niet werken”

• *

Er is nog iets anders dat kandidaten zou kunnen verdrijven: De lengte van je sollicitatieprocedure. Je hebt mensen die een telefonisch interview doen. Dan een take home test die ze een week hebben om af te maken. Dan ga je de tests doornemen. Dan stel je een face interview met het management op. Dan (ik neem aan) doe je een paar gezichtsinterviews. Dan krijg je de man terug die je wilt inhuren. Wat is daar voor nodig? 2 weken? Langer?

In die tijd heb ik al 3 aanbiedingen gekregen. Ik heb er een aangenomen en ik begin volgende week. Denk je dat ik je 2 uur durende test ga doen?

Laat ik beginnen met te zeggen dat het aannemen van medewerkers in het algemeen een pathetisch onnauwkeurige wetenschap is, en dat je verschillende resultaten zult krijgen, wat je ook probeert. Dat gezegd hebbende, vond ik dat ik mijn gedachten hierover moest delen.

Ik denk dat programmeeroefeningen een mislukking zijn, vooral omdat je mensen krijgt die wanhopig zijn en veel te veel tijd hebben om het af te maken. Als ze een fulltime baan hebben, zou je moeten vragen hoeveel tijd/mentale energie ze van hun huidige werkgever nemen om voor iemand te werken die ze niet eens betaalt. Wil je dat ze dat soort dingen met je doen?

Bovendien, als ze goed zijn, zijn ze waarschijnlijk met veel werkgevers aan het interviewen. Raad eens welke ze prioriteit zullen geven? Degenen die niet vragen om projecten af te ronden voordat ze zelfs maar aan de telefoon komen met een ingenieursmanager.

Er is ook het probleem van plagiaat. Tuurlijk, ze komen in het persoonlijk gesprek aan het licht, maar tegen die tijd heb je al de tijd verspild van (vermoedelijk) hoogbetaalde mensen bij het bedrijf dat deze persoon interviewt.

Mijn huidige bedrijf heeft het goed gedaan, en dit is de weg die ik zou inslaan in jouw positie. Geef ze een kleine taak die misschien maar 90-120 minuten zou moeten duren, en vertel ze in het commentaar te verantwoorden waarom ze voor die manier van oplossen van het probleem hebben gekozen. Dit is iets dat kan worden gedaan in een nacht, en zal u inzicht geven in hun denken.

Ik kan u nu al vertellen dat als ik een project krijg dat 8+ uur duurt om te doen, ik hen bedank, maar ik ben niet geïnteresseerd. Ik heb een goede baan en een leven. Als een manager dat als een probleem ziet, zegt me dat ze zich niet zouden bekommeren om mijn work/life balance op het werk (vooral als ze er niet om geven voor ik het heb). Geen enkel bedrijf, behalve misschien Google, Apple of Facebook, kan daar mee wegkomen.

In mijn ervaring, wieden de meeneemprojecten geen slechte codeurs uit, en zorgen ze er waarschijnlijk voor dat goede codeurs een baan vinden waarbij ze niet door een hoepel hoeven te springen om met de inhuurmanager te praten.

Denk er maar eens over na. Een goede codeur kan gemakkelijk telefoon- en persoonlijke interviews krijgen. Elke extra hoepel die ze moeten doorprikken betekent dat ze de makkelijkere weg nemen en een sollicitatiegesprek (en een sollicitatiegesprek) krijgen met iemand anders die net zo veel betaalt. Als je mensen door hoepels laat springen, zorg er dan voor dat ze zien dat het de moeite waard is vanaf de get-go.

Een slechte ontwikkelaar kan zo lang duren als ze willen. Je zult niet zien dat ze er 4x zo lang over doen; je zult gewoon de voltooide test zien. Je ziet ze ook niet naar Google of hun maatje gaan voor hulp met een if-verklaring.

Mijn laatste bedrijf deed dit, en de overgrote meerderheid van de mensen die we binnenbrachten voor een persoonlijk interview faalde Fizz buzz (ongeveer 65%). Ik denk dat dit is gebeurd omdat we per ongeluk goede, drukke mensen die geen behoefte hadden aan een interview met een ander bedrijf, en op hetzelfde moment, bungelend een eenvoudig interview in het bijzijn van slechte programmeurs.

Wat ik denk dat we in plaats daarvan hadden moeten doen

In plaats van mensen een take-home opdracht te geven die 15-20 minuten duurde om te beoordelen, hadden we een 15-20 minuten durend Skype-interview moeten doen waarin we vragen als Fizz buzz stelden. Dit zou evenveel tijd hebben gekost, maar ik zou waarschijnlijk de slechte programmeurs hebben uitgeschakeld voor een twee uur durend persoonlijk interview.

FYI -> Hier is een zeer gedetailleerd artikel over Fizz-buzz en algemene interviewpraktijken.

Een contrasterende kijk, van iemand in de loopgraven aan beide kanten van deze vraag. Ik vermoed dat dit antwoord een negatieve invloed zal hebben op de stemming, maar het is een goed geïnformeerde mening, die in de loop van enkele tientallen jaren in deze business is ontwikkeld. Omdat ik dat graag doe, schrijf ik nog steeds elke dag code voor de kost en als hobby in mijn “overvloedige vrije tijd”, maar ik ben ook de uiteindelijke beslisser geweest over het inhuren van een paar dozijn programmeurs, en heb geholpen bij het interviewen en adviseren over het inhuren van een vrij groot aantal meer.

Lawrence heeft gelijk: inhuren is jammerlijk onnauwkeurig. Maar we worden er na verloop van tijd beter in. Meer dan face-to-face chats, meer dan trivia vragen, korte on-site programmeeruitdagingen zijn daar een steeds essentiëler onderdeel van: niet alleen voor de vaardigheid, maar ook voor de houding.

Merk op dat ik zei “kort ”. We geven kandidaten een laptop met een goed geïnstalleerde Eclipse (de door ons gekozen IDE) als ze binnenkomen voor het interview. Een goede opstelling betekent dat ze toegang hebben tot de jdk-bron, maar die heeft geen internet en er wordt gevraagd om geen mobiele telefoons te gebruiken tijdens de test. Ze krijgen een uur de tijd om problemen op te lossen, van nul tot vijf, beginnend bij “FizzBuzz”, en gaandeweg in complexiteit tot iets in de volgorde van een eenvoudig multi-threaded producer/multiple-consumer systeem.

Niemand heeft ooit alle vijf in een uur opgelost, en ik verwacht niet dat iemand dat ooit zal doen (ik kan oplossingen voor vijf in comfortabel minder dan een uur schrijven, maar natuurlijk heb ik de problemen al eerder gezien en opgelost, dus ik ben geen eerlijke test).

Overigens hebben we schijnbaar ervaren programmeurs fail gehad om FizzBuzz in orde te krijgen. Laat ik dat nog eens zeggen: we hebben een handvol kandidaten gehad die FizzBuzz niet goed hebben ingevuld. Meestal door geen aanwijzingen te volgen, maar het lezen van de specificaties is een essentieel onderdeel van het zijn van een ontwikkelaar.

We laten ze code schrijven terwijl ze hier op locatie zijn in plaats van ze huiswerk te geven om verschillende redenen, deels om het risico van bedrog, en deels om elke kandidaat een gelijke kans te geven om de problemen aan te pakken. Ook rouleren we problemen in en uit de gestelde uitdaging, en bespreken we achteraf oplossingen met kandidaten.

Ik voel me hier zeer sterk bij betrokken. Ik heb nog nooit gezien dat een kandidaat een functie weigerde of uit het sollicitatieproces stapte vanwege onze programmeertest. Maar dat kan worden beïnvloed door het feit dat we de recruiters die ons bedienen vertellen dat het proces ook het programmeren op locatie omvat. Het kan dus zijn dat we de kandidaten die denken dat het schrijven van een uur code “onbetaald werk” is, gewoon niet zien. Als dat zo is, dan is het goed om te weten. Als ze denken dat een uur codering meer lijkt op “werk” dan op het beantwoorden van triviavragen, of dat hun antwoorden op testproblemen iets nuttigs kunnen opleveren, dan heb ik hun houding niet nodig.

We hebben ooit een kandidaat laten klagen over de test, omdat hij dacht dat hij te oud was om zichzelf te moeten bewijzen (dat is geen speculatie - dat zei hij wel). En hij deed het goed op de uitdagingen, en hij had alle ervaring die we wilden. Maar hij was een verschrikkelijke werknemer: hij vond blijkbaar ook dat hij te senior was om richting te geven of te leren, en uiteindelijk moesten we hem laten gaan.

Een van de dingen die ik in de loop der jaren heb besloten, is dat elk bedrijf dat geen test doet, minder kans heeft om mij als werknemer te pakken te krijgen. Zoals hun antwoorden op vragen als wat ze gebruiken voor broncontrole etc., of een bedrijf dat test vertelt me veel over hoe goed ze zijn in de business van softwareontwikkeling.

Zo, wat moet je doen? ** Je moet doen wat werkt voor je organisatie, maar mijn advies is om de tests voort te zetten, maar doe ze wel ter plaatse, als onderdeel van het interview. Vertel hen op voorhand dat dat deel uitmaakt van het proces, en doe het voordat ze het hoger management ontmoeten (maar je moet ze eerst ontmoeten om ze op hun gemak te stellen). En echt: sla het interview met het hoger management over als het niet lukt. Maak je geen zorgen over de populariteit van kandidaten of posters op het internet. **De kosten van een slechte aanwerving zijn veel erger dan de kosten van het uitstellen van een goede aanwerving.

Waarom geen thuistests?

Zelfs als we de mogelijkheid van valsspelen negeren, en de omgekeerde filter die ervoor zorgt dat goede en eerlijke kandidaten bedrijven met thuiscoderingstests vermijden, is de waarde van thuiscoderingstests beperkt.

Als het gaat om een senior positie , zal een senior ontwikkelaar met mensenvaardigheden binnen minder dan 10 minuten kunnen zien of de senior ontwikkelaar aan de andere kant van de telefoon een goed is, of gewoon dingen aan het verzinnen is. We zullen niet precies weten hoe goed, maar we zullen net zoveel weten als elke denkbare thuiscoderingstest ons vertelt.

Als het voor een junior positie is, verwachten we niet veel op het gebied van technische expertise. We zijn op zoek naar enthousiasme, leergierigheid en talent - geen van allen gespot uit een thuiscoderingstest. Er zijn te veel dingen waar junioren zich niet bewust van mogen zijn. Als we ze aannemen, moeten we ze toch opleiden.

Hoe te testen?

Als filter, geef ze gewoon 10 minuten de tijd om een FizzBuzz variatie ter plaatse op te lossen tijdens de eerste interviewronde of, als je overspoeld wordt met goede CV’s en nog een filter nodig hebt, doe het dan via Skype voor de eerste echte interviewronde.

Als ze eenmaal door de filters heen zijn, moet je meer weten over de codeervermogen van je kandidaten. Ik raad aan om 30 minuten tot maximaal 2 uur te besteden aan het programmeren van paren of aan code reviews - echt werk, in plaats van een oefening. Herhaal dit 1-2 keer met verschillende partners. Het voordeel van pair programming en code reviews is dat de ontwikkelaar al voldoende kennis heeft om bij te dragen.

Maak je geen zorgen over het feit dat de test bij elke aanwerving anders is - het doel van het aannameproces is niet om de persoon te vinden die het beste scoort in een paar meetbare en herhaalbare testen. Het doel is om één persoon aan te nemen die het werk goed doet.

Hier is een ander punt dat ik niet behandeld zie in de bestaande antwoorden (die volgens mij het onderwerp in het algemeen goed behandelen). Ik zou eens goed en serieus kijken naar hoe lang het eigenlijk duurt om het te voltooien. Ik heb vier sollicitatiegesprekken gehad, waarbij ik een programmering heb moeten maken, die elk op een andere manier is uitgevoerd (en die elk hun eigen voor- en nadelen hebben). Twee van de vier (de nummers 3 en 4 hieronder) deden er veel langer over dan ze zeiden dat het moest, en beide heb ik uiteindelijk opgegeven vanwege het moeilijke niveau dat ermee gemoeid was. Ik heb ze hieronder beschreven en ze van het beste naar het slechtste gerangschikt vanuit mijn perspectief.

1. Tijdens het technische interview hebben ze me bij een computer gezeten die een uitgeklede versie van hun codebasis had en hebben ze me drie relatief korte problemen laten oplossen (een bug vinden en repareren die ze doelbewust hadden toegevoegd, een nieuw veld toevoegen aan een infotabel, etc.). Ze gaven me precies een uur om het te doen, en na een uur gingen ze over mijn oplossing en hoe ik de problemen benaderde. Dit gaf hen meer inzicht in mij als programmeur, met respect voor mijn tijd door het kort en bondig te houden.
2. 2. Tijdens het technische interview lieten ze me een probleem dat ze tijdens de ontwikkeling hadden ondervonden op een whiteboard doornemen, terwijl ze ideeën van hen af konden stoten. Dit was de kortste optie, terwijl ze toch de kans kregen om te zien hoe ik door problemen heen werk en hoeveel ik daadwerkelijk de benodigde klus kan klaren.
3. Tijdens het technische interview (voor een junior Ruby on Rails Web Development functie) gaven ze mij de opdracht om een webapplicatie te bouwen vanaf nul, die zou navigeren naar een website, meerdere formulieren zou invullen zoals ze werden gepresenteerd, gegevens zou schrapen van de resulterende pagina, en die zou presenteren aan de gebruiker. Ze zeiden dat dit een snelle oefening moest zijn, en het kan voor een senior level webontwikkelaar zijn geweest, maar omdat ik op dat moment nog maar een jaar professionele ervaring had, heb ik vier uur geprobeerd om het allemaal aan het werk te krijgen voordat ik het opgaf en naar huis ging (alle interviewers waren al uren eerder vertrokken omdat het een middaginterview was, ze zeiden dat ik gewoon het afgewerkte programma moest opslaan als ik klaar was). Dit is een belachelijke opdracht voor de genoemde functie, gaf hen geen idee van mijn coderingsmogelijkheden, en leek me alsof ze gewoon probeerden om vrij werk te krijgen van de deal. Onnodig te zeggen dat ik de baan niet eens wilde tegen de tijd dat ik die dag vertrok.
4. Voordat ik zelfs maar een technisch interview had, gaven ze me een opdracht om een webapplicatie te maken die gebruik zou maken van een API die hun bedrijf gebruikte om “iets interessants te doen”. Dit was precies zo breed als het klinkt. Dit vereiste dat ik het volgende moest doen voordat ik zelfs maar een poging deed om de applicatie te maken: maak een ontwikkelaarsaccount voor de API, download de API-ontwikkelingskit, maak een publiek toegankelijke webapplicatie (met een ander ontwikkelaarsaccount), leer de API kennen, en maak een data repository aan om toegang te krijgen met de API. Dit duurde natuurlijk vele uren om te beginnen, en kort na de start van de webapplicatie zelf, kreeg ik een ander sollicitatiegesprek en kort daarna een vacature, dus ik stopte met het werk aan de opdracht. Dit is een gekke zaak om te hebben als onderdeel van een sollicitatieproces, want wie wil al die tijd en moeite steken in het ontwikkelen van een programma alleen maar om een kleine kans te hebben om verder te gaan in het sollicitatieproces?

Dus om je vraag directer te kunnen beantwoorden, moet je een programmeeroefening hebben? Ja, maar zorg ervoor dat het op maat gemaakt is om te testen waar je daadwerkelijk om geeft, en geen tonnen van buitenaf werk voor de geïnterviewde nodig hebt. Wil je weten wat hun algoritmisch denken is? Geef ze een algoritme probleem. Wil je iets weten over hun codeerstijl? Geef ze een coderingsprobleem. Wil je weten over hun ontwikkelingsproces? Bespreek hun proces met hen terwijl ze door een probleem heen werken.

Laat ik beginnen met:

• Ik heb thuis testen gekregen die varieerden van 15 minuten tot 10 uur.
• Ik heb online testen gekregen om door te nemen.
• Ik heb de opdracht gekregen om het antwoord op FizzBuzz en andere modieuze internet testen op whiteboards uit te schrijven.
• Ik ben gevraagd naar de vierkante versus ronde mangatdeksels.

Kortom, ik heb zo'n beetje alle verschillende manieren waarop ontwikkelaars graag met interviews omgaan, behandeld. Om eerlijk te zijn - ik betwijfel ten zeerste of de overgrote meerderheid van de mensen die mij interviewen wel begrijpen wat de mogelijke uitkomsten van elk van die tests waren en uiteindelijk alleen maar mensen hebben ingehuurd op het al dan niet “leuk” vinden ervan.

Voordat je zelfs maar een vacaturelijst opstelt, moet je gaan zitten en precies doornemen wat je probeert in te huren en “ontwikkelaar” is geen antwoord, althans, het is geen fatsoenlijk antwoord. Een goed antwoord hierop zou zoiets zijn als “hypotheek domein expert”.

Iemand vinden die een beetje code kan schrijven of google kan zoeken voor het toepassen van een bepaald patroon is triviaal vergeleken met het vinden van iemand die in de business zit waar je in zit en die die kennis kan gebruiken. Met andere woorden, als ik voor een hypothecaire documentatiebedrijf zou huren, zou ik iemand nemen die kan praten over het verschil tussen 15 jaar vast en en ARM lening over iemand die een bubble sort algoritme kan schrijven in 2 minuten. De reden hiervoor is dat “normale” zakenmensen allerlei vreemde eisen stellen en dat domeinexperts gemakkelijker tot de kern kunnen komen van wat nodig is, terwijl iemand die niets weet graag dingen toevoegen die nutteloos zijn of de app echt slecht maken.

Terug naar de vragen, alleen vragen stellen / geen vragen stellen.

Is het kritisch dat de persoon je het verschil kan vertellen tussen een virtuele en een abstracte methode? Misschien wel, meestal niet. Ik zou wedden dat een groot deel van de ontwikkelaars nauwelijks weet wanneer ze die sleutelwoorden moeten gebruiken, maar ze zijn niet je supersterren, ze zijn de rang en het bestand die geen code kunnen gebruiken zonder de visuele ontwerpers.

Is het kritisch om te zien wanneer een query open is voor sql-injectie? Voor een Sr positie - absoluut; voor een Jr. positie nee. Dit is iets dat gemakkelijk te trainen is en behandeld kan worden via code review. Vandaar dat je wilt dat de sr. het van binnen en van buiten weet - zodat ze de junioren kunnen trainen.

Is het kritisch dat ze de exacte maximale waarde van een Int32 datatype weten? Normaal gesproken niet - dat niveau van triviale kennis is waar google voor is; maar misschien is uw eis voor het coderen op geheugenbeperkte apparaten - in dat geval: absoluut.

Ik interview en huur ontwikkelaars in. Ik stuur geen tests naar huis - het is te gemakkelijk om hulp van een vriend te krijgen. Ik gebruik geen online testsites - gezien de manier waarop het scoren moet worden geautomatiseerd is het triviaal om te spelen. Ik vraag kandidaten niet om het antwoord op fizzbuzz uit te schrijven - zowat iedereen heeft die test gezien en zou het antwoord uit het hoofd moeten kennen; alle anderen hebben het afgelopen jaar het veld betreden en zijn sowieso jr.‘s. Ik stel ook geen trivia vragen - als je het antwoord kunt reciteren, betekent dit meestal dat je de vraag al eerder hebt gehoord.

Wat ik doe om mensen te interviewen:

• Ik vraag hen om een of twee eerdere projecten te beschrijven. Het enige waar ik op dit moment om geef is om ze op hun gemak te stellen en ze aan het praten te krijgen. Dit is een go/no go want als ik niet kan begrijpen wat ze zeggen dan kan ik niet met ze werken.

• Ik stel ze een paar specifieke vragen in de technologie die ik nodig heb om ze te gebruiken. Als het SQL server is, zal ik vragen over het updaten van een join. Als het HTML is, geef ik ze een 10 regelig html bestand met een paar css-klassen en vraag ze wat de output is. Dit zijn triviale vragen aan mensen met ervaring in die gebieden en snel onkruidverdelgers.

• Als ik op zoek ben naar een Sr. dev dan zal ik domeinkennis vragen stellen. Geen randzaken, maar kernprincipes. Als ik je nodig heb om een project te leiden op een boekhoudkundige backend dan kun je beter een greep hebben op de basis boekhoudprincipes.

• Als ik op zoek ben naar een Jr. dev dan zal ik vragen stellen over huisdierprojecten. het enige wat ik wil weten is het type technologie dat gebruikt wordt. Dit zou je moeten aanwijzen wat ze echt willen doen. Met andere woorden, een C# ontwikkelaar doet waarschijnlijk geen huisdierprojecten in php. Ik verwacht eerlijk gezegd niet te veel van een jr dev, behalve dat het trainbaar is. Als ze actief bezig zijn met een huisdierproject dan kan ik ze trainen. Als ze het type zijn dat mensen nodig heeft om hen te vertellen wat ze moeten doen zijn er veel grotere bedrijven waar deze jongens kunnen werken.

Ik verzin deze vragen niet van tevoren, de mogelijke antwoorden worden van tevoren overwogen en passen in een go/no go patroon. Als een vraag daar niet bij past dan is het niet relevant. Ik vraag ook elke kandidaat dezelfde, tenzij ik er 100% van overtuigd ben dat ik hem of haar niet in dienst neem.

Als u om een of andere reden nog steeds aandringt op het naar huis sturen van een test - zorg ervoor dat de vaardigheden die nodig zijn om die test met succes af te ronden in een redelijke hoeveelheid tijd zijn eigenlijk vaardigheden waar je om geeft.

Ik had een bedrijf dat me een take home test gaf die het schrijven van een aangepaste cryptografische service provider inhield. Ik heb de test gedaan omdat het wat interessant was; ze hebben me ingehuurd. Op geen enkel moment in mijn tijd heb ik iets gedaan dat ook maar in de verste verte te maken heeft met beveiliging, cryptografie of zelfs wiskunde, behalve het toevoegen van een paar getallen. Ik vraag me af hoeveel mensen ze met die test zijn weggereden?

Vroeger geloofde ik heilig in coderingstests en whiteboard codering, maar ik ben me gaan realiseren dat ze zo goed als nutteloos zijn, want

Wat ben je eigenlijk aan het testen?

Een whiteboard test, of korte programmeertest geeft je wel wat inzicht in het individu, maar echt niet zo veel. Tenzij je van plan bent om iemand zijn tijd te laten besteden aan het schrijven van code op een whiteboard of FizzBuzz stijl code.

Wat wil je wil?

Je wilt iemand die:

• gepassioneerd
• bereid is om te leren
• in staat is om problemen op te lossen*
• resonerend technisch
• je team gaat helpen verbeteren

*Note, de meeste ontwikkelaars lossen hun problemen op door te weten naar welke termen je moet zoeken in Google.

Het laatste ding dat je wilt inhuren is iemand die niet goed past bij je team omdat ze het naar beneden zullen slepen.

How Can You Test For These?

• Vraag ze naar een project dat ze leuk vonden. Als ze er niet graag over willen praten, probeer dan voorzichtig ongeloof te uiten, bijvoorbeeld: “Je kunt geen X doen, toch?” Als het iets is waar ze gepassioneerd over zijn, zullen ze je corrigeren. Dit zal je ook helpen om te leren of ze technisch zijn of niet.
• Vraag ze naar dingen die ze recentelijk hebben geleerd. Of wat ze hebben geleerd van het project waar ze van hebben genoten.
• Vraag ze naar de laatste keer (of een keer) dat ze wat kennis hebben gemist. Hoe kwamen ze aan de informatie die ze nodig hadden? Gingen ze naar een teamgenoot? Hebben ze op het internet gezocht?
• Vraag hen of er iets is wat ze verbeterd willen zien in hun huidige/laatste team. Hadden ze betere berichten nodig? Meer code reviews? Meer testen? Meer automatisering?
• Vraag hen welke technologie hen prikkelt en waarom.

Als je iemand hebt die technisch gezien competent is in dit gesprek zal het het makkelijkste zijn om te vertellen of deze persoon het ergste zal zijn. Een voorbeeld: we hebben een kind laten komen en interviewen - hij zei dat op een schaal van 1-10, zijn Java vaardigheden als een 7-8 waren. Ik denk dat hij niet eens wist dat Java was gecompileerd tot een pot file die later door de JVM werd gecompileerd tot machinetaal. Ik zou mezelf misschien een 2 of een 3 rangschikken en I dat weten.

Hij werd eigenlijk dezelfde vraag gesteld door onze CTO in een interview de vorige dag, en onze CTO belde hem op en legde uit dat er geen manier was dat hij een 7-8 was.

Onze CTO vroeg hem ook naar zijn favoriete project, dat te maken had met handscanners. Maar hij kon niets uitleggen over hoe ze werkten, of het feit dat ze peilingen gebruikten om busy-waits te voorkomen. Hij kon geen enkel technisch ding uitleggen.

Die kerel werd niet aangenomen.

Zoek uit wat voor soort attributen je zoekt, en zoek dan uit hoe je moet testen voor die

Maar ik heb _echt nodig om te zien hoe ze codeert!

Oké, dat is prima - maar tenzij ze gaat coderen in een silo, zal het beste zijn om haar in te huren als aannemer voor een klein, welomschreven project. Misschien voeg je de mogelijkheid toe om wat bestanden van een FTP te downloaden en ze dan in je database te dumpen. Iets simpels, dat niet veel/geen domeinkennis vereist.

Laat uw kandidaten werken met een bestaande medewerker of twee, en betaal ze voor hun tijd. U krijgt precies te zien hoe ze werken, en hoe goed ze met het team werken. Communiceren ze goed? Raken ze gemakkelijk gefrustreerd? Zijn ze volhardend?

Er zijn zijn dingen die je kunt doen om betere medewerkers aan te nemen… maar een programmeerwedstrijd hoort daar waarschijnlijk niet bij.

Vanuit het standpunt van een werkzoekende vermijd ik over het algemeen plaatsen die meer dan 1 uur nodig hebben om te coderen. Een keer ging ik naar deze plaats die een bijna 3 dagen durende java-codering nodig had. Ik deed het allemaal en de man was er zelfs van onder de indruk, maar ze vertelden me dat ze iemand anders hadden ingehuurd na de tweede fase van het sollicitatiegesprek. Dus als ik daarna naar een bedrijf zou komen, zou ik elk project dat meer dan een paar uur nodig heeft om te voltooien, negeren/passen. Mijn tijd is net zo waardevol als die van hen en ik verspil die liever niet aan dingen die me nergens toe leiden.

Met dat gezegd hebbende, als je coderingsoefening te lang is, zijn mensen misschien niet bereid om er tijd in te steken. Ik zou proberen het zo te verminderen dat het hooguit een uur duurt, maar tegelijkertijd toont het begrip van de codering aan en misschien is het zetten van een deadline als, “Gelieve in te vullen door COB morgen” of iets dergelijks. Ze kunnen nog steeds iets online “kopiëren en plakken” maar maken het moeilijk door specifiek te zijn in plaats van iets wat je online leest.

Zoals anderen hebben opgemerkt, kunnen sommige ontwikkelaars worden afgeschrikt door een 1-2 uur durende programmeeroefening om te solliciteren naar een baan. Wat misschien beter werkt is het hebben van een white-boarding sessie, waarbij de kandidaat een probleem op een whiteboard oplost tijdens het interview. Dit geeft je de mogelijkheid om een persoonlijk gesprek te hebben en er tegelijkertijd voor te zorgen dat ze technische karweitjes hebben.

Deze problemen zouden niet extreem moeilijk moeten zijn, of ontworpen om een ontwikkelaar te laten struikelen. Een klassiek voorbeeld is FizzBuzz . Zo kun je zien hoe ze denken, en weet je ook dat ze in ieder geval kunnen programmeren en niet hoeven te googelen hoe ze een loop moeten doen.

Naar mijn mening is het probleem dat u hier heeft niet noodzakelijkerwijs de programmeertoets. Eerst heb je het telefonische technische interview en dan een werk van thuis uit test voor een face to face interview. Het klinkt alsof u uw kandidaten op afstand houdt en het tot de laatste minuut voor de ontmoeting met hen laat rusten. Op welk moment verwacht u dat kandidaten besluiten dat ze ** voor u willen werken ?

Ik ga ervan uit dat uw rekruteringsadvertentie vergelijkbaar is met de meeste en dus gericht is op locatie, salaris en een (wensen)lijst van vaardigheden. Kandidaten weten niet echt waar ze aan zouden werken, iets over de omgeving of over de mensen met wie ze zouden moeten omgaan. Je hebt de baan nog niet aan hen verkocht hier vraag je hen om hun technische capaciteiten twee keer te bewijzen voordat ze een enkele vraag krijgen over het werk.

Ik stel voor dat je probeert het formaat van het technische telefooninterview te veranderen in een 30-45 minuten durende babbel over de baan inclusief voldoende mogelijkheden voor vragen van de kandidaten, dan 15 minuten technische vragen als scherm zodat je nog steeds een kans krijgt om de betere kandidaten te kiezen zonder het te belastend te maken.

Ik zou ook overwegen om de programmeeruitdaging te verplaatsen naar ter plaatse te doen voorafgaand aan de interviews. Het lijkt me meer haalbaar voor de kandidaten, geef ze een stimulans om op de hoogte te blijven van het proces en je zou het voordeel krijgen van het observeren van de werkelijke tijd die aan de uitdaging wordt besteed (ik denk dat je verbaasd zou kunnen zijn).

Wil je programmeurs inhuren die niet kunnen programmeren?

Ik waag het erop dat je dat niet doet.

Het inhuren van programmeurs die geen problemen kunnen oplossen en geen code kunnen schrijven is een goede manier om een technisch bedrijf te ruïneren. En je gaat niet effectief zijn in het wieden van de programmeurs die niet echt kunnen programmeren (en er zijn een heleboel die er zijn) als uw huurproces niet een soort van programmeringstest omvat.

*Wil je bereid om je normen te verlagen omdat iedereen probeert programmeurs in te huren? *

Misschien ben je dat wel, maar ik denk niet dat je dat zou moeten zijn. Zoals in de commentaren en antwoorden is opgemerkt, zijn er kandidaten die niet de moeite nemen om programmeeroefeningen te doen als onderdeel van een sollicitatieproces omdat ze dat gewoon niet nodig hebben om een baan te krijgen_.

Maar zijn dat echt de mensen die je toch wilt aannemen? Degenen die het pad van de minste weerstand volgen, doen wat voor hen het meest gunstig is op de korte termijn, en geven niet echt genoeg om uw bedrijf om een eenvoudige programmeeroefening te voltooien? Die lijken geen positieve eigenschappen te hebben, en ze geven niet veel vertrouwen om die kandidaten op lange termijn te kunnen behouden (wat ook belangrijk is voor een technisch bedrijf, omdat de leercurves vaak steil zijn en de kosten voor het vervangen van bestaand personeel erg hoog zijn).

Laat die andere bedrijven dus de programmeurs hebben die niet eens gestoord kunnen worden. Je wilt ze toch niet inhuren. In tegenstelling tot hen heb je een plan. Een plan dat niet gebaseerd is op de “een programmeur is een programmeur”-fout. Je moet je richten op kwaliteit en duurzaamheid, niet op bodycount.

*Schrikt kandidaten af van een probleem? *

Over het algemeen niet, zolang ze maar met een goede reden worden afgeschrikt. Je wilt geen mensen aannemen die niet in staat zijn om te presteren. En sommige mensen die zeggen dat ze “geen moeite kunnen doen” vanwege de grote vraag, gebruiken dat misschien wel als excuus om een “niet zo goed programmeerwerk” situatie te verdoezelen.

Het is goed om die kandidaten af te schrikken. Je wilt de capabele, gemotiveerde kandidaten aannemen. Zolang je die niet ook afschrikt, ben je goed.

Elke kandidaat die je niet afschrikt, moet je proberen te evalueren. En dat kan moeilijk zijn als u uw technische kandidaten geen technische oefeningen geeft om te evalueren.

*Hoe kan ik ons rekruteringsproces verbeteren? *

Controleer de inhoud van uw programmeeroefening. Is het redelijk en geschikt voor een sollicitatiegesprek?

U wilt niet dat iets wat dagen (of zelfs uren) gaat duren. Wat je wilt is iets eenvoudigs om de mensen die gewoon niet kunnen programmeren uit te wieden, idealiter met voldoende ruimte voor nuance dat de mensen die gewoon goed kunnen programmeren zich kunnen onderscheiden. Houd in gedachten wat u probeert te bereiken (het wieden van ongeschoolde en niet-serieuze kandidaten), en zorg ervoor dat uw inhoud op dat doel is afgestemd. Ga niet te ver.

Als je al wat technisch personeel hebt, kun je die gebruiken om je oefening te saneren (en/of te helpen ontwerpen).

En denk ook na over de manier waarop je de oefening uitvoert. Als je ze gewoon wat documentatie geeft en zegt “hier, doe dit de komende week en e-mail het naar mij”, dan is dat waarschijnlijk maar minimaal effectief.

kan beter zijn als je de oefening via een webportaal kunt laten lopen, waar kandidaten kunnen inchecken en de oefening kunnen starten, en als ze eenmaal beginnen met een timer begint af te tellen vanaf 1 uur. Dan dienen ze binnen dat uur iets in, of niet. Dat is minder open, houdt de aandacht van de kandidaat beter vast en zorgt voor een duidelijke deadline/timebox, zodat 1) je niet de hele week hoeft te wachten op een resultaat dat nooit gaat komen, en 2) ongekwalificeerde kandidaten niet een week van hun tijd weggooien om je programmeeroefening af te ronden. Ze krijgen 1 uur, ze lossen het probleem op of ze doen het niet, en je weet meteen de uitkomst.

En nog beter zou zijn om ze binnen te halen voor een interview op locatie. Stel ze voor aan een lid van je ontwikkelingsteam. Sluit ze op in een kamer samen met een werkplek. Laat je ontwikkelaar beginnen met wat algemene/zachte interviewvragen, en dan kunnen ze met de kandidaat pair-programmeren om de programmeeroefening op te lossen. Zo weet u niet alleen of de kandidaat kan coderen, maar ook hoe goed hij of zij met uw team kan werken. Uw ontwikkelaar zou ook in staat moeten zijn om veel aanvullende informatie te verzamelen die u niet krijgt door te kijken naar een hoop code die een kandidaat heeft geschreven en vervolgens naar u heeft gemaild.

Bottom line

Nee, u wilt niet van uw programmeeroefening af. Maar je wilt het misschien wel beoordelen op de juiste inhoud, ervoor zorgen dat het niet te lang duurt om het op te lossen, en ook kijken hoe je het in je overkoepelende interviewproces inpast.

Een zelf-georiënteerde thuishaaloefening is waarschijnlijk niet de beste aanpak. Maar de oplossing daarvoor is niet om de oefening helemaal te schrappen. Niet tenzij je het in ieder geval goed vindt om rotzooi programmeurs in te huren.

Beter om veel slechte kandidaten en een handvol goede te verjagen dan om de sluizen open te zetten en een paar slechte in te huren.

Eén ding lijkt niemand te hebben vermeld; zelfs als de test niet jouw probleem is, moet je op zoek gaan naar andere manieren om talent aan te trekken.

Als je op zoek bent naar goede mensen op basis van hun bestaande gepubliceerde werk, hoef je de test niet op hen uit te voeren.

Als je alleen maar mensen via recruiters en filtering wordt gestuurd, ben je kwetsbaar voor het feit dat je behoeften en de behoeften van de recruiters niet perfect op elkaar zijn afgestemd. Ze willen iemand bij u plaatsen. Je wilt een ingenieur van topniveau. Als ze een top level engineer kunnen vinden die geweldig is omdat je bij hen terugkomt, maar als ze dat niet kunnen (en top level engineers hebben de neiging om dingen te doen die weinig tijd laten voor het interviewen), dan nemen ze genoegen met het plaatsen van een gematigde engineer met een mooi pak. Het verlies voor hen is een beetje een lange termijn reputatie, maar dat is minder belangrijk dan het missen van hun doelwitten. Als dit in jouw geval niet waar is, blijf dan bij die recruiter en laat ze nooit meer gaan. Werknemers die een lange-termijn relatie voorrang geven op doelen zijn kostbare diamanten in een oceaan van steenkool. Hunt through StackOverflow en GitHub voor top ingenieurs (ik hoor dat StackOverflow een tool heeft om te helpen met deze ), check voor technisch interessante bedrijven die goede software hebben geproduceerd, maar die hun financiën of monetarisatie hebben verknald, en net 10 top ingenieurs hebben ontslagen. Breng tijd door op universiteiten om te assisteren bij afstudeerprojecten. Identificeer goede potentiële kandidaten en raak bevriend met hen, bij voorkeur in persoon, of op afstand; zelfs als ze aanbiedingen hebben, hangen goede ingenieurs rond met goede ingenieurs. Ook kunnen ze je vertellen hoe zij zich voelen over je aannameproces.

Klinkt dit als veel werk? Het zou moeten. Een van de redenen dat aannemen zo “moeilijk” lijkt, is omdat je het zo efficiënt mogelijk probeert te doen. Hoe meer tijd, denkkracht en middelen je er aan besteedt, hoe makkelijker het is. Of die middelen beter besteed kunnen worden aan het verzenden van producten is de eeuwige managementvraag. Maar als je veel tijd besteedt aan “crap programmer filtratie”, dan is dat verbranding geld. De hierboven beschreven stappen hebben tenminste een inherente waarde buiten het inhuurproces.

: Hell, hire them.

Ik hou niet van take-home tests als onderdeel van interviews, om veel van de redenen die mensen al hebben genoemd - verlengt het aannameproces, devalueert de tijd van de sollicitant, krijgt misschien toch geen telefoontje terug, etc.

Mijn belangrijkste punt is dat het onrealistisch is om te zien hoe het team daadwerkelijk werkt en maakt het interviewproces eenzijdig. Een sollicitant wil of deze plek goed bij hem past, inclusief de cultuur, hoe het team problemen benadert en oplost. Je bent vooral ook op zoek naar fit, inclusief hoe ze werken en of ze de juiste vaardigheden hebben. Een take home test biedt een sollicitant geen gelegenheid om de zachte kwaliteiten van een werkplek te evalueren, en werkgevers leren niet hoe de sollicitant het probleem benaderd heeft.

Een betere oplossing zou kunnen zijn om de sollicitant een meer open-ended probleem te geven dat op elke vorm van creatieve manier kan worden opgelost. Je zou het zelfs kunnen beperken tot X-taal. In plaats van het te e-mailen, nodig je ze uit om het aan jezelf en het hoger management te presenteren. Het geeft hen autonomie en stimulans om het goed te doen, want het belooft nog een interview en laat zien dat je er belang aan hecht om te weten wat ze denken.

Als je een test moet gebruiken om te screenen welke kandidaten het maken om te interviewen met het hoger management, zou ik de test opnemen in het interview, zodat je hun denkproces samen kunt bespreken.

Ik denk dat je je vraag een beetje verkeerd hebt geformuleerd, maar de manier waarop je het hebt geformuleerd weerspiegelt een veel voorkomende misvatting over het inhuren van programmeurs. Worden de kandidaten “afgeschrikt” door de programmeeropdracht, of filteren ze je bedrijf uit eigenbelang vanwege de opdracht?

Een anekdote om mijn punt te demonstreren: tijdens de banenjacht niet zo lang geleden zag ik een positie voor een bedrijf dat gemiddeld leek. De manier waarop ze hun programmeerproces beschreven klonk vrij goed, maar er waren weinig details, dus ik was sceptisch. Misschien waren ze een goede plek om te werken, misschien ook niet. Maar ik dacht dat ik zou zien dat ik naar een telefoonscherm kon gaan, zodat ik de details kon achterhalen en kon zien of ze zo goed waren als ze leken.

Ik klikte op de vacature, en werd meteen gevraagd om een sollicitatiebrief te schrijven. Ugh. Ik denk dat elke kandidaat een hekel heeft aan sollicitatiebrieven. Ik kende dit bedrijf niet en gebruik hun producten niet, dus wat kon ik er over zeggen? Ik googelde hen, las hun website en productaanbod door, zocht uit waar ik waarschijnlijk in hun org orgaangrafiek zou passen als ik werd aangenomen, en kwam zelf met een paar alinea’s “verkopen”.

Vervolgens gaf ik mijn cv en toegang tot mijn LinkedIn - maar onmiddellijk daarna vroegen ze me om mijn relevante werkervaring in te vullen met datums en beschrijvingen. Deze informatie staat zowel op mijn LinkedIn als op mijn CV, het was belachelijk om 3 keer dezelfde informatie te moeten geven. Ik sloot de browser tab. 5 minuten later solliciteerde ik bij een ander bedrijf dat een aantal echt coole voordelen bood die de eerste niet had. Ik kon eigenlijk sneller solliciteren bij een ander bedrijf met betere voordelen dan dat ik door de hoepels kon springen die het eerste bedrijf van mij wilde.

Je moet er zeker van zijn dat je kandidaten geïnvesteerd zijn in uw bedrijf in het bijzonder voordat je ze een hoepel voorstelt om door te springen, anders springen ze niet. Doet u dit?

Voorbeelden van kwaliteitsvoordelen die ik vaak zie bij technische bedrijven:

1. 1. Werken op afstand.
2. 2. Gratis computers/monitoren als tekenbonus.
3. Gratis computers/monitoren als tekenbonus. 4. Bedrijf draagt bij aan gerespecteerde open-source projecten.
4. Vergoeding voor professionele training en/of conferenties.
5. Lunches met cateringbedrijf.
6. 6. Flexibele uren.
7. Mogelijkheid om te werken met nieuwe of onbekende technologieën.
8. “Startup cultuur” - ook wel gebrek aan politiek/bureaucratie.
9. De mogelijkheid om te werken met nieuwe of onbekende technologieën. 10. Naamsbekendheid: uw bedrijf of product is bekend. Kandidaten vermelden graag waar ze werken en horen mensen reageren met “Oh, netjes! Ik hou van hun producten.”
10. 11. Liefdadigheid of revolutionaire bedrijfsdoelen/visie. Mensen houden ervan om code te schrijven die het leven van mensen beter maakt.
11. 12. Bovengemiddelde beloning. Geld dekt een veelvoud aan organisatorische zonden.
12. 13. Jaarlijks bedrijf trekt zich terug naar koele plaatsen.

Deze lijst is niet uitgebreid, maar als uw bedrijf niet één of meer dingen aanbiedt zoals de items op die lijst, dan kan elk obstakel in uw rekruteringsproces een kandidaat sturen die dat wel doet.

Dus laten we zeggen dat, om welke reden dan ook, u niet of niet kan bieden prikkels zoals de bovenstaande voor uw kandidaten om hen te overtuigen om code te schrijven voor u gratis te spenderen. Wat kunt u dan wel doen? Ik heb twee alternatieven die de meeste kandidaten zullen verkiezen boven drukke programmeertaken:

Alternatief #1 - Betaal hen een uurtarief om uw programmeertaak uit te voeren alsof ze een aannemer zijn. Dit moedigt hen aan om het serieus te nemen, zowel om professionele redenen als omdat… ze betaald worden. Dit kost je geld, maar dat geldt ook voor elke vorm van rekrutering. Als je echt goed bent kun je zelfs een manier vinden om een diagnose te stellen en een echte bug in je code te repareren, in welk geval je iets nuttigs voor je geld krijgt.

Alternatief #2 - Ze hebben waarschijnlijk al gratis code geschreven die ze je zullen laten zien als je het maar vraagt. De meeste programmeurs hebben code op Github, Bitbucket, V&A websites zoals Stack Overflow, of kunnen je wat code geven die ze nog niet hebben gepubliceerd.

Waarom zou je ze code laten schrijven waar ze niet om geven als je ze in plaats daarvan een passieproject met je zou kunnen laten delen? Het is gegarandeerd minder saai dan het lezen van weer een andere oplossing voor hetzelfde generieke probleem voor de 100ste keer. En omdat de code al geschreven is, bespaart het zowel u als uw kandidaat tijd. Bovendien krijgt u inzicht in wat voor soort code ze graag schrijven, wat inzicht geeft in hun persoonlijkheid en hoe goed ze passen bij uw bedrijfscultuur.

Als direct antwoord op Bobo’s antwoord (dat is het geaccepteerde antwoord omdat de man het zelf schreef en accepteerde, wat ik eerlijk gezegd een beetje zielig vind):

Je komt uit een totaal verkeerde premisse. Ik wil niet voor je werken. Waar haal je dat idee vandaan dat iemand wilt werken voor jou? Je bent gewoon een van de vele bedrijven die een baan aanbieden. Ik wil niet voor je werken. Ik wil je bedrijf evalueren, en als je boven op alle anderen komt, dan wil ik voor je werken.

Er zijn een dozijn bedrijven waar ik kan werken, je staat gewoon ergens in de rij. Ik kijk eerst wat voor bedrijven er zijn, stuur ze mijn CV, ze kunnen het lezen en al dan niet onder de indruk zijn, dan heb je meestal een snel telefoongesprek waarbij ze me laten zien dat ze een interessante baan hebben en ik laat zien dat ik de vaardigheden heb, en een eventuele coderingstest might komt helemaal aan het einde.

Je take home test zet je helemaal aan het einde van de wachtrij. Om dit te compenseren moet je een salarisbereik van 10.000 pond hoger plaatsen dan anderen. Het vinden van een baan is sowieso tijdrovend; iemand die het tien keer zo tijdrovend maakt staat aan het eind van de lijst. Als ik de keuze heb tussen het sturen van een CV en een telefonisch interview met tien bedrijven, en het maken van huiswerk voor jou, raad eens wat ik ga doen.

Dus wat er gebeurt is dat je kandidaten vindt die voor jou willen werken _ omdat ze elders geen baan krijgen_.

Ik denk echt dat het kan helpen om vast te stellen wie de talen die op hun cv staan echt kent.

Als dat echt je doel is, zou ik een andere aanpak overwegen. Zoals andere antwoorden al aangaf, JA, moet je altijd een coderingsvraag hebben, maar coderingsvragen komen zelden in details van de taal. Enkele vragen die ik heb gezien en die nuttig zijn om dit te testen:

1. 1. Vergelijk Java en C (of wat voor twee talen dan ook relevant zijn, staan op het cv van de kandidaat, etc.). )

2. Welke functies denk je dat er aan de taal moeten worden toegevoegd (of beter nog, wat vind je van deze specifieke voorgestelde/recentieve verandering van de taal?)

Engineers die een of twee dingen hebben gezien weten vrij gemakkelijk deze vragen te beantwoorden, en in slechts een paar minuten.

Wat is uw zakelijke probleem?

Als u alle argumenten voor of tegen bepaalde tests buiten beschouwing laat, komt het allemaal neer op een afweging - meer filters zullen sommige goede kandidaten afschrikken, minder filters zullen slechte kandidaten doorlaten die u misschien snel na de aanwerving moet vervangen.

Het komt allemaal neer op het kijken naar uw zakelijke situatie in plaats van algemene praktijken.

Heeft u op dit moment een probleem waarbij u geen gekwalificeerde kandidaten heeft en niet in staat bent om zo snel als u nodig heeft uw zakelijke doelstellingen te bereiken? U dient deze eerste programmeeropdracht te dumpen.

Heeft u op dit moment een probleem waarbij u niet tevreden bent over de kwaliteit van uw recente aanwervingen? Dan moet u meer van dit soort filters implementeren.

Heeft u beide van deze problemen, en zijn ze allebei even pijnlijk? Gefeliciteerd, je hebt de juiste balans gevonden voor deze afweging.

IMHO er is bijna 0% kans dat een pas afgestudeerde een zware programmeercode op instapniveau zou kunnen doen. Als uw coderingstest een week tijd in beslag neemt om te voltooien dan moet u duidelijk vermelden in uw eis dat u mensen op zoek zijn naar programmeurs met ten minste 2+ jaar ervaring, omdat ik denk dat er veel ervaring nodig is voor het voltooien van een code werk dat een week nodig heeft om te voltooien. En ik denk dat als je op zoek bent naar pas afgestudeerden, ontwerp dan je test dienovereenkomstig en je kunt veel ideeen vinden op het internet of anders kun je senior programmeurs die voor je werken vragen om een geschikte test voor pas afgestudeerden te ontwerpen.

Ik dacht dat ik deze vraag zou beantwoorden, het is al een jaar geleden dat het is gepost, en we hebben ons eraan gehouden.

FINDINGS

Positieven van aanpak

1) Neem de gedemotiveerde kandidaten mee naar huis, en vervang ze door kandidaten die echt voor u willen werken. Dat alleen al maakt het de moeite waard, want gemotiveerde mensen = productieve medewerkers. Als ze niet de moeite nemen om een opdracht van 1 uur te doen dan zegt dat veel over hun houding ten opzichte van het krijgen van de baan.

2) Ik ben het met anderen eens, dat de take home test niet langer dan een uur mag duren - de mijne is heel simpel. Ik heb de volgende resultaten gehad door het toe te voegen aan het rekruteringsproces-

a) Sommige kandidaten voltooien het niet. Niet de moeite waard om aan te nemen.

b) Sommige kandidaten proberen het, maar voltooien het slecht. Niet de moeite waard om aan te nemen.

c) Sommige kandidaten spelen vals, waarbij het de moeite waard is om vervolgvragen te stellen over hun opdracht. We hebben dit gedaan met een recente kandidaat die toen niet de moeite nam om te reageren op onze e-mail over de opdracht. Niet de moeite waard om in te huren.

d) Sommige kandidaten die horen dat er een technische opdracht is, trekken plotseling hun sollicitatie in, waar ze eerder veel belangstelling voor hadden. Waarschijnlijk een kogel ontweken.

e) Sommige kandidaten doen het buitengewoon goed, geven commentaar op hun code en verstrekken in één of twee keer documentatie. Waardetoevoeging.

Negatieven van aanpak

1) Sollicitatie-uitval van kandidaten die worden afgeschrikt door de meeneemopdracht maakt het langer om iemand te vinden die geschikt is. Maar aan de andere kant is het positief voor het bedrijf omdat het de kans op een slechte aanwerving die gevaarlijk is verkleint.

2) Kan niet altijd zien of iemand heeft valsgespeeld, maar wordt daarom vaak ondersteund met een technisch telefoongesprek.

Outcome of this approach

Een van onze medewerkers die ik met deze aanpak heb aangenomen is een sterwerknemer gebleken. Hij werkt nog steeds voor ons na meer dan een jaar. Hij is betrouwbaar en technisch getalenteerd.

Onbekende muis of onverwachte toetsenbordindeling (vooral Mac vs. PC), of verschillende IDE’s kunnen de prestaties dramatisch vertragen zonder enig verschil in competentie. Ook vereist een complete applicatie vaak veel ketelplaatcode die een ontwikkelaar misschien niet genoeg tijd heeft om in te typen of zelfs niet meer weet. Het starten van een nieuwe app volledig vanaf nul is eigenlijk een zeer zeldzame taak; het meeste werk concentreert zich op het uitbreiden of verbeteren van de bestaande code.

Daarom stel ik voor om slechts zeer korte en meer zorgvuldig voorbereide taken te geven tijdens het interview. Het beste is om het schrijven van een functie te vragen die bepaalde parameters moet nemen en het verklaarde resultaat terug te geven en ik zou adviseren om dat op papier te doen, waarbij ik de computer helemaal niet hoefde te gebruiken.

Ik zou ze naar een online quiz sturen waar je mensen kunt filteren die geen idee hebben. Je zou in ieder geval een gevoel hebben of ze weten waar ze het over hebben.

Vroeg in mijn carrière zeiden de headhunters me “dat je het opneemt tegen mensen die het vakje lezen en een sollicitatie op hun cv zetten”. Ik neem aan dat dit nog steeds kan gebeuren met de jongeren en de naïevelingen, maar als je eenmaal in een paar interviews vernield bent, leer je dat dit een slecht advies is…

Ik heb recentelijk een take home test gekregen. Het was een volwaardige applicatie die verbinding moest maken met een socket server die een trage feed moest simuleren. De klant had een dynamische update, kon de feed annuleren, en schreef en las XML.

Ik wil sowieso sockets leren omdat ik erover denk om ze te gebruiken voor een pokerserver die ik aan het schrijven ben.

Ik wilde XML-reader en XML-schrijver leren.

In eerste instantie dacht ik dat ik het vergeten was. Maar toen zag ik het als een kans om te bewijzen wat ik kan. Ik heb geen CS-diploma, dus ik mis wat theoretische dingen. Ze vroegen wat de 3 pijlers van OOP zijn en wilden zeggen who cares.

Mijn boodschap is dat mensen die de baan willen, de test moeten afmaken.