En av de många saker som stör mig på LinkedIn är "hur man intervjuar utvecklare" inlägg. Det finns massor av dem, och de nästan alla faller i tre läger:
Under årens lopp har jag intervjuat dussintals gånger och hyrt Hundratals av utvecklare för olika företag - från Microsoft och Dell till små startups. Jag hade också ett tidigare liv som en forskningspsykolog specialiserad på psykometri (vetenskapen att mäta mentala kapaciteter). Så jag har sett processen från var och en av dessa På sidan.
Skriva kod är ofta inte en social aktivitet. Visst - mjuka färdigheter spelar roll. Men de är ofta ortogonal till den faktiska praxis att skriva kod för att lösa verkliga användarproblem.
Så hur intervjuar man någon för ett jobb som är mestadels Om att skriva kod?
Vårt yrke är också fullt av Impostorsyndrom Jag har sett det i mig själv och otaliga andra. redan Känns det som en bluff?
Och vi är ofta en socialt besvärliga gäng En intervju som båda är påfrestande. och kräver levande problemlösning är ett recept för katastrof.
Så hur intervjuar man någon som är nervös, pinsam eller redan tvivlar på sig själv?
Inte ens starta Om inte deras erfarenhet stämmer, så respekterar det deras tid. och Ditt.
Gör processen tydlig och mänsklig.
Var i tid. Ångest spikar medan väntar. Om de är sena, ge dem några minuter - chanserna är att de inte är i back-to-back möten som du är.
Fråga dig själv: Skulle de passa laget temperamentsfullt? En lysande kodare som är en idiot är en nettoförlust.
Efter år av fibonacci-frågor och länkade listmaraton lärde jag mig en kärnsanning:
Kodare älskar att prata om kod de känner till.
Det är hemligheten. Och det fungerar bara om intervjuaren faktiskt förstår vad som visas. Om du inte känner till ramverket (Angular, React, vad som helst) - fortfarande bra. Fokusera på struktur, tydlighet, namngivning, avsikt.
Så berätta för dem. i förväg (5 dagar är rättvist) som du vill diskutera kod de har skrivit. Ingen press. Inget trick. Bara: Visa mig nåt du kan prata om.
De kanske inte har GitHub – det är ok. En personlig eller arbete sippet är bra. Målet är inte att hitta geni. Det är att hitta ägarskap.
Du anställer inte baserat på hur mycket fritid någon har.
I Personligen lämna kodning intervjuer nu för tiden. Det gör mig MASSIVT orolig - även om jag har byggt hundratals system. Det är UNNECESSARY.
Därför är detta tillvägagångssätt bättre:
Juniorkandidater kan De behöver ett litet praktiskt test - men behåll det humant. Låt dem inte återskapa en 4000-radig äldre fil.
Fråga om loopar, villkor och grunderna i verkligheten.
Design mönster? Många människor använder dem dagligen utan att veta namnet. Bli inte upphängda på etiketter.
Logic pussel? Aldrig en gång behövde dem i verkliga arbete. Aldrig en gång sett en verklig användning för att veta hur många pianostämmare finns i New York.
Om kandidaten får rollen eller inte - uppföljning.
Om de inte fick det: Förklara varför. Ge dem något användbart att ta ifrån dem.
Om de fick det: Berätta för dem vad som väntar härnäst. Låt dem andas.
För i slutändan:
En intervju bör avslöja förmåga - inte skydda ego. Det bör tillföra mervärde - även när svaret är nej.
Den mest exakta intervjun jag någonsin hittat är enkel: Låt kandidaterna tala om kod de är stolta över. För att i kod, visar ärlighet. Trycket döljer det.
När folk lämnar din intervju känner sig respekterad även om de avvisas, Du har redan byggt något som är värt att gå med i.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.
