Inleiding

Een van de vele LinkedIn-aspecten die me dwarszit is de 'hoe te interviewen ontwikkelaars' berichten. Er is een TON van hen en ze zijn in 3 kampen:

1. De 'Hoe zou je Mount Fuji verplaatsen?' aanpak met logische puzzels en hersenteasers.
2. De 'Laten we eens kijken hoeveel je je kunt herinneren van je Computer Science degree' benadering met algoritmische vragen.
3. De 'watch you while you write code' benadering met coderingsoefeningen.

Door de jaren heen heb ik tientallen keren geïnterviewd en honderden ontwikkelaars ingehuurd voor verschillende bedrijven van Microsoft tot Dell tot kleine startups. Ik ben ook vreemd genoeg een Research Psycholoog die gespecialiseerd is in psychometrie (de wetenschap van het meten van mentale capaciteiten) en een Software Developer. Dus ik heb het proces van alle kanten gezien.

Het probleem

Coderen is vaak geen sociale activiteit. Zeker 'zachte vaardigheden' zijn van vitaal belang, maar ze zijn vaak orthogonaal aan de praktijk van het schrijven van code om gebruikersproblemen op te lossen. Hoe interview je iemand voor een baan die voornamelijk over het schrijven van code gaat?

Ons beroep is ook vol met bedriegerssyndroom. Ik heb het gezien in mezelf en in vele anderen. Het is echt. Hoe interview je iemand die zich al een bedrieger voelt?

Ons beroep zit vol met het sociaal onhandige (en ja zoals ikzelf enigszins autistisch); een interview dat zowel stressvol is als sociale interactie vereist terwijl het oplossen van coderingsproblemen een recept is voor een ramp. Hoe interview je iemand die sociaal ongemakkelijk is?

De oplossing

Lees eerst hun CV; praat zelfs niet met hen als hun CV niet duidelijk maakt dat ze voldoende ervaring hebben voor de baan waarvoor je inhuurt. Dit is niet alleen respectvol van hun tijd, maar ook van jullie.

Ten tweede moet het opzetten van het interview (of interviews) zo stressvrij mogelijk zijn voor de deelnemers. Dit betekent:

1. Geef een passende waarschuwing. Verstuur geen interview met iemand met een opzegtermijn van 24 uur (of slechter op dezelfde dag).
2. Maak duidelijk wat het interview formaat zal zijn, wie er zal zijn en verwachte resultaten (is het de finale, een technisch scherm etc).
3. Lees het resume van de persoon. Ik kan dit niet genoeg benadrukken. Als je iemand interviewt, moet je hun CV binnenstebuiten kennen. Dit is niet alleen respectvol, maar het geeft je ook een kans om vragen te stellen over hun ervaring.
4. Zorg ervoor dat je de details IN DE MAIL hebt; als het Teams / Zoom is, zorg er dan voor dat ze de link hebben. Als het persoonlijk is, zorg dan dat ze weten waar ze heen moeten.

Het interview

BE OP DE TIJD; niets maakt een persoon angstiger dan wachten tot een interview begint. Als je te laat bent, begin je al op de verkeerde voet. Als ze te laat zijn, geven ze ze een paar minuten; ze zijn waarschijnlijk niet achterin geweest om afspraken te maken, zodat hun setup misschien gestoord is.

Lijken ze op iemand die bij het team past in termen van temperament; zijn ze goed geschikt voor het team? Dit is belangrijk; je kunt de beste programmeur ter wereld hebben, maar als ze een eikel zijn, zijn ze het niet waard.

Een tip die ik heb bedacht (na jaren van Fibonacci sequence vragen, omkeren arrays, gekoppelde lijsten etc) is.

CODERS, zoals praten over code die ze kennen.

Dit betekent dat als je een technische beoordeling doet de persoon die het interview doet in staat moet zijn om te praten over de code die ze zien. Als het een kader dat je niet weet (zoals ik interviewen Angular devs) maak je geen zorgen te veel.

Dus voordat het interview met genoeg kennisgeving (5 dagen is over het algemeen goed) vertel hen dat je hen zal vragen om te praten over een stuk code die ze hebben geschreven. Ik vraag over het algemeen niet om een GitHub link (veel mensen op zelfs hogere niveaus hebben dit misschien niet; ik heb gewerkt aan veel projecten die eigendom zijn en niet gedeeld kunnen worden).

Maak duidelijk dat je niet vraagt om een groot project / een aantal geweldige innovatieve code. Het is gewoon code waar ze over kunnen praten. Veel mensen hebben deze 'familie' dingen, de kans is groot dat ze geen 365 dagen durende bijdrage hebben geleverd aan een groot Open Source project.

Je neemt geen mensen aan op basis van hoeveel vrije tijd iemand heeft.

Waarom?

Waarom geef ik dan de voorkeur aan deze aanpak? Waarom denk ik dat dit een betere manier is om ontwikkelaars te interviewen?

1. Het is minder stressvol. De persoon die wordt geïnterviewd heeft het over iets wat ze weten. Ze proberen niet een probleem op te lossen dat ze nog nooit eerder hebben gezien; echt het grootste deel van de tijd wanneer coderen je je zorgen maakt over hoe ze code schrijven wanneer ze tijd krijgen om het te schrijven. De meesten van ons slaan geen gekke algoritmen op om dingen te doen die ons keuzekader al voor ons doet.
2. Je kunt meten of ze liegen over hun ervaring. Als ze niet kunnen praten over een stuk code dat ze geschreven hebben... dan hebben ze het waarschijnlijk niet geschreven.
3. Je kunt in de code graven op meer natuurlijke manieren; waarom ze die aanpak kozen versus een andere, waarom ze geen bibliotheek gebruikten etc.
4. Je ziet de code die ze je willen laten zien. Dit is een grote. Als je ze vraagt om code te schrijven op de plek waar je code ziet die ze onder druk schrijven. Als je ze vraagt om over code te praten die ze geschreven hebben zie je code die ze geschreven hebben als ze niet onder druk staan. Opnieuw tenzij uw werkplek is een mand geval meestal je niet het schrijven van code onder druk.

Uitzonderingen op het Reglement

Er zijn hier uitzonderingen, super junior codeurs hebben soms een beetje codering nodig, maar doe het rustig aan. Het vragen van hen om te ontleden en refactor / repareren van een enorme codebase is gewoon wreed. Voor hen kun je vragen naar basisconcepten zoals loops, conditions etc (houd het gericht op de job waarvoor je inhuurt). Patronen? Ik heb veel mensen gezien die geen patroon kunnen noemen, maar je kunnen vertellen wanneer ze het gebruikt hebben. Dus hou je er niet te veel mee bezig.

Logische puzzels? Ik heb hier nooit het nut van gezien. Ik heb nog nooit een baan gezien waar je Mount Fuji moet verplaatsen. Ik heb nog nooit een baan gezien waar je moet weten hoeveel golfballen er in een 747 passen. Ik heb nog nooit een baan gezien waar je moet weten hoeveel pianotuners er zijn in New York.

Follow-up

Zorg er na het interview voor dat je de kandidaat opvolgt. Als ze de baan niet kregen vertel ze waarom (je liet me niet genoeg van je ervaring zien, je was niet duidelijk bij het uitleggen van je code etc). Dit is niet alleen respectvol, maar het helpt hen ook verbeteren voor het volgende interview. Als ze de baan kregen, zorg er dan voor dat ze weten wat ze nu kunnen verwachten.