Inledning

En av de MÅNGA LinkedIn aspekter som buggar mig är "hur man intervjuar utvecklare" inlägg. Det finns ett ton av dem och de är i tre läger:

I detta sammanhang är det viktigt att se till att "Hur skulle du flytta Mount Fuji?" närma sig med logiska pussel och hjärnan retas.
Den "Låt oss se hur mycket du kan minnas från din datavetenskap examen" strategi med algoritmiska frågor.
Den "titta på dig medan du skriver kod" tillvägagångssätt med kodning övningar.

Under årens lopp har jag intervjuat dussintals gånger och hyrt hundratals utvecklare för olika företag från Microsoft till Dell till små startups. Jag har också märkligt nog varit en forskningspsykolog som specialiserat sig på psykometri (vetenskapen att mäta mental kapacitet) och en programvaruutvecklare. Så jag har sett processen från alla håll.

Problemet

Kodning är ofta inte en social aktivitet. Visst "mjuka färdigheter" är mycket viktigt men de är ofta ortogonala till praxis att skriva kod för att lösa användarproblem. Så hur intervjuar man någon för ett jobb som mest handlar om att skriva kod?

Vårt yrke är också fullt av impostorsyndrom. Jag har sett det i mig själv och i många andra. Det är på riktigt. Så hur intervjuar man någon som redan känner sig som en bedragare?

Vårt yrke är spänt med det socialt besvärliga (och ja som mig själv lite autistisk); en intervju som är både stressig och kräver social interaktion samtidigt som man löser kodproblem är ett recept på katastrof. Så hur intervjuar man någon som är socialt obekväm?

Lösningen

Läs först deras CV; prata inte ens med dem om deras CV inte gör det klart att de har erfarenhet tillräckligt för jobbet du anställer för. Detta är inte bara respekt för deras tid utan också din.

För det andra bör intervjun (eller intervjuerna) vara så stressfri som möjligt för deltagarna. Detta innebär följande:

Ge tillräckligt med varsel. Gör inte en intervju om någon med 24 timmars varsel (eller värre samma dag).
Gör klart för dig vilket intervjuformat som kommer att vara, vem som kommer att vara där för förväntade resultat (är det den slutliga, en teknisk skärm etc).
Läs upp personens liv. Jag kan inte betona det här tillräckligt. Om du intervjuar någon borde du veta deras CV ut och in. Detta är inte bara respektfullt utan det ger dig också en chans att ställa frågor om deras erfarenhet.
Se till att du har detaljerna I MAILEN; om det är Teams / Zoom se till att de har länken. Om det är personligen se till att de vet vart de ska gå.

Intervjun

VAR MED PÅ TIDEN; ingenting gör en person mer orolig än att vänta på att en intervju skall börja. Om du är sen börjar du redan på fel fot. Om de är sena ge dem några minuter; de förmodligen inte har varit tillbaka till tillbaka möten så deras inställning kan vara skruvad.

Verkar de vara någon som skulle passa med laget i fråga om temperament; är de en bra passform för laget? Detta är viktigt; du kan ha den bästa kodaren i världen men om de är en idiot de är inte värt det.

Ett tips jag har kommit på (efter år av Fibonacci sekvens frågor, vända arrayer, länkade listor etc) är.

Drönare gillar att prata om kod de vet

Detta innebär att om du gör en teknisk bedömning personen som gör intervjun måste kunna prata om koden de ser. Om det är ett ramverk du inte vet (som att jag intervjuar Angular Devs) oroa dig inte för mycket.

Så innan intervjun med tillräckligt varsel (5 dagar är i allmänhet bra) berätta för dem att du kommer att be dem att prata om en kod de har skrivit. Jag frågar inte generellt efter en GitHub länk (många människor på även äldre nivåer kanske inte har detta; Jag har arbetat med många projekt som är egenutvecklade och kan inte delas).

Gör det klart att du inte ber om ett stort projekt / några fantastiska innovativa kod. Det är bara en kod de kan prata om. MÅNGA människor har dessa "familj" saker, chansen är att de inte har varit en 365 dagars strimma bidragsgivare till ett stort Open Source projekt.

Du anställer inte baserat på hur mycket fritid någon har

Varför?

Så varför föredrar jag detta tillvägagångssätt? Varför tycker jag att detta är ett bättre sätt att intervjua utvecklare?

Det är mindre stressigt. Personen som intervjuas talar om något de vet. De försöker inte lösa ett problem som de aldrig har sett förut; egentligen för det mesta när du kodar är du orolig för hur de skriver kod när de ges tid att skriva det. De flesta av oss piska inte upp galna algoritmer för att göra saker som vårt ramverk av val redan gör för oss.
Du kan bedöma om de ljuger om sin erfarenhet. Om de inte kan prata om en kod de har skrivit så skrev de nog inte den.
Du kan gräva i koden på mer naturliga sätt; varför de valde detta tillvägagångssätt kontra en annan, varför de inte använde ett bibliotek etc.
Du ser koden de vill visa dig. Det här är stort. Om du ber dem att skriva kod på plats du ser kod de skriver under press. Om du ber dem att prata om kod de har skrivit ser du kod de har skrivit när de inte är under press. Återigen om inte din arbetsplats är en korg fall för det mesta du inte skriver kod under tryck.

Undantag från regeln

Så det finns undantag här, super junior kodare ibland behöver lite kodning övning, men ta det långsamt. Att be dem att tolka och refaktor / fixa några enorma kodbas är bara grymt. För dem kan du fråga om grundläggande begrepp som loopar, villkor etc (hålla det fokuserat på det jobb du anställer för). Mönster? Jag har sett många som inte kan namnge ett mönster men som kan berätta när de har använt det. Så häng inte upp dig för mycket på det här.

Logiska pussel? Jag har aldrig sett poängen med de här. Jag har aldrig sett ett jobb där du behöver flytta Mount Fuji. Jag har aldrig sett ett jobb där du behöver veta hur många golfbollar som passar i en 747. Jag har aldrig sett ett jobb där du behöver veta hur många pianostämmare det finns i New York.

Uppföljning

Efter intervjun se till att du följer upp med kandidaten. Om de inte fick jobbet berätta varför (du visade mig inte tillräckligt av din erfarenhet, du var inte tydlig när du förklarade din kod etc). Detta är inte bara respektfullt utan det hjälper dem också att förbättra sig inför nästa intervju. Om de fick jobbet, se till att de vet vad som väntar härnäst.