skip to Main Content
Hoe NIET Een Software Engineer In Te Huren

Hoe NIET een software engineer in te huren

Ik ben geen expert in het inhuren van software engineers voor grote techbedrijven, maar ik heb veel ervaring met kleine bedrijven en ik heb een beetje een gezond verstand. Sinds 2006 heb ik ervaring met het aannemen van (internationale) technisch en niet-technisch personeel, zowel in loondienst als freelancers.

Dat alles geeft me het vertrouwen om kritiek te leveren op de praktijken die internetgiganten tot op de dag van vandaag gebruiken om engineers in te huren.

Niet streven naar de beste oplossing

Wanneer je bij het interview aankomt, zal de interviewer jou een probleem geven en van jou een oplossing binnen twee minuten verwachten. Als je er langer over doet, beginnen ze zich echt zorgen te maken en vragen ze je om tenminste iets op te schrijven.

Ik begrijp dat ze maar 45 minuten hebben en er zijn veel dingen die ze met je willen bespreken.

Wat ik echter niet begrijp is dat je beoordeeld wordt op de kwaliteit van de oplossing die je binnen twee minuten hebt gevonden. Want zo werkt de menselijke creativiteit niet. Het is gemakkelijk om met veel ideeën te komen, maar het is vreemd om te verwachten dat de beste oplossing altijd de eerste zal zijn die bij je opkomt. Zelfs genieën kunnen niet op een voorspelbare manier met de beste antwoorden binnen een beperkte tijd komen.

Creativiteit is immers het vermogen om de stroom aan ideeën die je bedenkt te evalueren en te filteren. Als je daar echt in geïnteresseerd bent, waarom vraag je de sollicitant dan niet om meerdere ideeën te vergelijken en te evalueren? Controleer of de persoon de eigenschappen van de voorgestelde oplossing kan beoordelen? En of hij of zij duidelijk alle voor- en nadelen ziet?

En als je vraagt om in twee minuten met de best mogelijke oplossing te komen, dan test je het geluk, meer niet. Huur jij mensen in die mazzel hebben? Of die capabel zijn?

Vraag niet om raadsels op te lossen

Hoe kan ik controleren of een linked list een loop heeft? Past een N-dimensionale doos in een andere N-dimensionale doos? Kun je twee variabelen met elkaar verwisselen zonder een derde? Hoe vind ik de kortste afstand tussen twee bewegende schepen? Vind alle permutaties van N elementen vinden die alleen N-1 swaps doen?

Dit soort puzzels zijn leuk om erover te praten en de oplossingen kunnen zeer inzichtelijk zijn. Vroeger vond ik het leuk om als kind  Mathematical Recreations and Essays te lezen. Begrijp me niet verkeerd, ze zijn echt leuk.

Maar hoe leuk ze ook zijn, het zijn slechts anekdotes. Het kenmerk van een raadsel is dat je het antwoord erop weet of je weet of niet. Het vertelt je verder niets. Het heeft niets te maken met toekomstige prestaties, slim zijn, capabel of iets anders. Het kennen van een bepaald antwoord betekent niet dat je de eigenschap hebt om echte problemen op een generieke en voorspelbare manier op te lossen. Het enige wat het je vertelt is dat de kandidaat zich ooit in een situatie heeft bevonden waarin iemand een oplossing met hem of haar deelde. Niets meer en niets minder. Stop er alsjeblieft gewoon mee.

Sta open voor alternatieven

Dit is een beetje te verwachten, maar grote bedrijven lijken nog steeds  op dit punt te falen. Als de sollicitant een alternatieve oplossing voorstelt, is het een kans voor jou als interviewer om iets ervan te leren. Het is ook een goede kans voor een diepgaande discussie als de voorgestelde oplossing onmogelijk of op de een of andere manier niet goed blijkt te zijn.

Ik  heb wel eens meegemaakt dat een van onze kandidaten een alternatieve oplossing van dezelfde complexiteit had voorgesteld (haar werd de les gelezen “er is één echte manier om dit probleem aan te pakken”). De interviewer negeerde maar al te graag wat de kandidaat over haar oplossing te vertellen had en wilde met haar alleen maar bespreken wat hij als een oplossing voor het probleem zag, waarbij hij later zei dat hij “niet onder de indruk” van haar was.

Niemand is in staat om alles te weten. Wees open. Luister. Denk erover na. Ja, zelfs als je iemand interviewt.

Wees verdraagzaam voor imperfecties

Off-by-one errors worden in het algemeen geaccepteerd als een van de moeilijkste problemen in softwareontwikkeling. Om een reden – iedereen maakt ze. Fouten maken deel uit van het leven van de ontwikkelaar, niet iets waar je van af kunt komen. Een goede ontwikkelaar weet gewoon wat hij of zij moet doen. De kwaliteit van een ontwikkelaar wordt NIET bepaald door het aantal fouten dat hij of zij maakt.

Welnu, als je alleen mensen selecteert die tijdens het interview geen fouten hebben gemaakt, krijg je niet op een magische wijze een groep ontwikkelaars die altijd perfecte code schrijven. Je weet gewoon niet hoe ze zich zullen gedragen wanneer ze onvermijdelijk hun fouten zullen maken.

Fouten zijn dus eigenlijk goed omdat je leert hoe die persoon ze corrigeert. Beoordeel de fouten niet, maar beoordeel hoe de geïnterviewde ermee omgaat:

  • eenvoudige code,
  • divide and conquer,
  • self-checks,
  • invariants,
  • asserts,
  • compiling en running,
  • testing.

Oh, sorry voor de laatste twee. Ik was vergeten dat je ze hun programma’s niet hebt laten draaien. Nou, wat had je dan verwacht?

Laat me testen!

Serieus, wat is het probleem met het schrijven van code op een whiteboard?

Ik bedoel, ik vind het prima om daarop algoritmes te bespreken – abstracte dingen op die manier bespreken werkt efficiënter.

Maar het schrijven van code, echte programma’s, op een notitieblok? Zonder ze zelfs maar uit te voeren? Wat wil je ermee bereiken? Het eerste concept van de code is nauwelijks een tiende van het hele proces, gevolgd door het compileren, controleren, tunen, testen, beoordelen, enz. Wie houden we voor de gek? Dat zijn de essentiële onderdelen van de workflow van elke ontwikkelaar. Een code is pas goed om naar te kijken wanneer het het hele proces heeft doorlopen, en niet eerder.

Het is alsof je een kunstenaar vraagt om een schilderij van een paard te schilderen, en haar dan halverwege de allereerste schets tegen te houden, net als je vier verticale lijnen voor de benen kunt zien en vervolgens dat te gaan beoordelen. Hoeveel leer je dan over haar?

Diep gaan

Vijf korte interviews? Of twee lange interviews?

Met vijf krijg je vijf onafhankelijke meningen, wat beter is dan twee. Maar hoe diep kun je in 45 minuten gaan? De praktijk leert dat het nauwelijks genoeg is om 20-30 regels code te schrijven en een paar heel eenvoudige vragen te stellen (wat is de complexiteit, hoe test je het?).

De volgende interviewer herhaalt eenvoudigweg hetzelfde proces, en gaat net zo ver als de vorige. Wat niet ver is. Helemaal niet ver.

Waarom maak je er geen twee interviews van, en dan echt diepte-interviews? Bijvoorbeeld één voor de lunch en één erna? Drie uur is ook niet veel, maar je krijgt in ieder geval de kans om te zien hoe iemand de code test, hoe men de code verandert, hoe men met de eisen omgaat – dit alles binnen een reeds vastgestelde context, en niet elke 45 minuten steeds vanaf nul te beginnen.

Met zoveel tijd kun je de sollicitant zelfs vragen om de code te schrijven alsof het een deel van een systeem is, en niet alleen een abstracte algoritmische taak in een vacuüm – en nog een paar andere dingen te leren over haar werkelijke prestaties.

En als je toch meer meningen wilt? Zet meerdere interviewers in de kamer en laat ze daarna de kandidaat bespreken.

Leer de achtergrond

Ik heb ooit een kandidaat gehad met veertien jaar ervaring als softwareontwikkelaar. Hij praat graag over functioneel programmeren, gedistribueerde systemen, consensus, replicatie, tekstbewerking door meerdere gebruikers tegelijkertijd, CRDT’s, parallelle architecturen, UI-frameworks, teamprocessen, productontwerp, gebruikerservaring. Deze persoon heeft praktische en onderzoekservaring op al die gebieden. Ze zijn allemaal in directe belang voor min of meer alle internetreuzen door wie hij is geïnterviewd.

Hebben ze hem ooit ernaar gevraagd? Nee.

Wat die bedrijven vragen is “Stel je voor dat je een functie in je code hebt die een lijst neemt en….”, vijf keer op rij. Vijf problemen op schoolniveau worden verondersteld je een goede indruk te geven van… wat precies? Hoe grondig de kandidaat Cormen et al heeft gelezen? Om eerlijk te zijn, hier vragen ze je ook nooit naar.

Stel in plaats daarvan het interview af op de ervaring van de kandidaat. Praat over waar hij of zij goed in is. Jij krijgt de kans om diepgaande vragen te stellen en veel meer te weten te komen over het ervaringsniveau en de voordelen die de kandidaat voor jouw bedrijf kan opleveren.

Maak het proces naadloos

Verkeerde routebeschrijving? Een vragenlijst die de installatie van de originele Adobe Reader specifiek vereist? Een goedkope ultrabook met een onbekend toetsenbord lay-out en een slechte web-based editor met geen enkele snelkoppeling die zelfs op een lokale machine traag is? Sorry, maar ik ben toch in het kantoor van het meest capabele IT-bedrijf ter wereld, nietwaar?

Je zou kunnen denken dat dat niet uitmaakt. Nou, dat hangt ervan af. Ja, het is een makkelijke fout om te maken, maar het is ook een makkelijke fout om te herstellen. Het maakt niet uit dat het maar voor één dag is, als je de moeite hebt genomen, doe het dan goed.

Ja, ik geloof dat iedereen het beter kan.

Tot slot

Als jouw werk het inhuren van softwareontwikkelaars inhoudt, dan gaan de praktijken van de grote techbedrijven niet voor jou werken, vrees ik. Gezond verstand, eerlijkheid, tolerantie, echte interesse en openheid echter wel.

Success met het inhuren!

Heeft u op de afdeling softwareontwikkeling een uitdaging met personeel en zoekt u tijdelijke, gekwalificeerde junior developers die direct operationeel zijn? Team X is een detacheringsbureau dat u kan helpen. Neem vrijblijvend contact op met Anthony Carter voor onze tarieven. Of lees meer over onze dienstverlening op de site.

Telefoon : 023-2052070

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Back To Top