Rekrytera utvecklare utan teknisk bakgrund: guide för rekryterare

Kort svar: när du ska rekrytera utvecklare utan teknisk bakgrund behöver du inte bedöma om koden är bra. Du kan bedöma hur kandidaten pratar om sitt eget arbete. Be personen berätta om något hen faktiskt har byggt, ställ följdfrågor och lyssna efter konkreta exempel, avvägningar och ärlighet om misstag. Den som har skrivit koden kan förklara den i detalj. Den som inte har det kan sällan det.

Guiden vänder sig till rekryterare utan ingenjörsbakgrund och till grundare som ska anställa sin första utvecklare. Du behöver inte kunna något programmeringsspråk.

Varför generiska intervjufrågor inte räcker

Listor med "50 intervjufrågor till utvecklare" har två problem. Du kan inte avgöra om ett svar är tekniskt rätt, så ett självsäkert felaktigt svar låter lika bra som ett riktigt. Och kandidaterna har läst samma listor och kommer med färdiga svar.

Frågor om kandidatens eget arbete löser båda problemen. Kandidaten är expert på sitt eget projekt, så du behöver bara bedöma hur förklaringen håller ihop. Och det finns inga inövade svar på kod som ingen annan har skrivit.

Förberedelse när du rekryterar utvecklare utan teknisk bakgrund (10 minuter)

1. Be kandidaten nämna ett projekt hen är stolt över, eller titta på hens publika arbete på GitHub.
2. Gå till fliken Pull requests och filtrera på Merged. En pull request är ett förslag på en kodändring som andra läser igenom. En "merged" ändring har godkänts och lagts in i projektet.
3. Leta efter ändringar i projekt som kandidaten inte äger själv. Där har någon annan sagt ja.
4. Läs beskrivningen och kommentarerna, inte koden.
5. Skriv ner tre frågor om just de ändringarna.

Mer om vad du ska titta på finns i så bedömer du en utvecklares GitHub-profil (på engelska).

DevEval gör det här automatiskt. Verktyget läser bara kod som kandidaten själv har skrivit och föreslår intervjufrågor om den. Privat arbete syns inte, och rapporten säger det öppet. Har kandidaten inget publikt arbete, be om en beskrivning av ett projekt från ett tidigare jobb och använd samma frågor.

Upplägg för en intervju på 45 minuter

Tid	Del	Syfte
5 min	Roll och sammanhang	Berätta om jobbet, teamet och produkten
15 min	Berätta om något du har byggt	Förstå djup och eget ansvar
10 min	Problem och avvägningar	Se hur kandidaten tänker när något gick fel
10 min	Samarbete	Hur kandidaten tar emot feedback
5 min	Kandidatens frågor	Bra kandidater ställer bra frågor

Tio frågor att ställa

Om något de har byggt

1. "Berätta om ett projekt du är stolt över. Vad gör det och vem använder det?"
2. "Vad var din del, och vad gjorde andra?"
3. "Vad var svårast? Hur bestämde du hur det skulle lösas?"
4. "Vad skulle du göra annorlunda i dag?"

Om avvägningar och misstag

5. "Berätta om en bugg som hamnade i produktion. Hur hittade du den, och vad ändrade du efteråt?"
6. "När valde du en snabb lösning framför en snygg? Varför?"
7. "Har någon som granskade din kod bett dig ändra något du inte höll med om? Hur gick det?"

Om samarbete

8. "Hur förklarar du ett tekniskt problem för någon som inte är teknisk?" (Det är du. Märk om hen lyckas.)
9. "Berätta om en oenighet med en kollega om hur något skulle byggas."
10. "Vad vill du lära dig i nästa jobb?"

Så bedömer du svaren utan teknisk kunskap

Lyssna efter fyra saker.

Konkreta detaljer. Namn, siffror, riktiga händelser. "Sidan var långsam, jag såg att databasen anropades 200 gånger per sidladdning och ändrade det till ett anrop" säger mer än "jag optimerade prestandan".

Avvägningar. Starka utvecklare säger "vi kunde göra A eller B, jag valde A eftersom ...". Svaga svar beskriver en enda väg som självklar.

Ärlighet om egna gränser. "Det visste jag inte, så jag läste dokumentationen och frågade Maria" är ett gott tecken. Den som aldrig har haft fel är inte bättre, bara mindre ärlig.

Konsekvens. Ställ samma fråga med andra ord tio minuter senare. En riktig historia klarar det. En inövad ändrar sig ofta.

Följdfrågor som alltid fungerar

• "Kan du ge ett exempel?"
• "Vad hände sedan?"
• "Vilket var alternativet, och varför valde du bort det?"
• "Hur visste du att det fungerade?"
• "Vad skulle en kollega säga om det beslutet?"

Varje följdfråga tar kandidaten från ett påstående till ett minne, och minnen är svåra att fabricera.

Gröna och röda flaggor

Gröna flaggor

• Förklarar något komplicerat på enkel svenska utan att bli ombedd
• Nämner kollegor vid namn
• Berättar om misstag utan att försvara sig
• Ställer frågor om produkten, användarna och teamet
• Vet vad hen skulle ändra i sitt eget arbete

Röda flaggor

• Kan inte förklara vad ett projekt i det egna CV:t gör
• Säger "vi" om allt och kan inte säga vad hen själv gjorde
• Ger samma sorts svar oavsett exempel
• Skyller på andra i varje berättelse
• Blir irriterad av följdfrågor

En röd flagga är en anledning att ställa en fråga till, inte att avfärda någon. Nervositet är vanligt, så ge kandidaten chansen att reda ut det.

Hoppa inte över den tekniska bedömningen

Din intervju är ett första filter. Inför ett erbjudande bör en ingenjör ha pratat med kandidaten. Saknar ni egen utvecklare kan du låna en i en timme: en konsult, en rådgivare eller en bekant i branschen. Ge hen kandidatens egna ändringar och dina anteckningar, så kan samtalet gå på djupet på 30 minuter. Jämförelsen mellan olika metoder finns i take-home, live coding och GitHub-granskning (på engelska). Vill du hoppa över kodtest helt, läs teknisk screening utan kodtest.

Så behandlar du kandidaten rättvist

• Berätta i förväg hur intervjun går till och att du kan titta på publik kod.
• Fråga om arbete som kandidaten kan dela. Många utvecklare har privat kod som inte får visas, så en tunn GitHub-profil betyder inte en svag kandidat.
• Använd samma upplägg för alla kandidater.
• Se varje rapport, även från DevEval, som ett underlag. Det är en människa som fattar beslutet. Läs vad som mäts och inte mäts på metodsidan.
• Du behandlar personuppgifter om kandidaten. Informera om det enligt GDPR och kontrollera vad som gäller hos er.

Checklista

• Tittade på 1 eller 2 delar av kandidatens riktiga arbete
• Skrev tre frågor om dem
• Berättade för kandidaten hur processen ser ut
• Frågade "vad var din del?"
• Frågade om ett misstag och vad som ändrades efteråt
• Ställde minst tre följdfrågor
• Noterade detaljer, avvägningar, ärlighet och konsekvens
• Ordnade en teknisk bedömning av en ingenjör före erbjudande

Vanliga frågor

Kan jag verkligen bedöma en utvecklare utan att kunna kod? Du kan bedöma hur kandidaten förklarar, tar ansvar och reflekterar över sitt arbete. Du kan inte avgöra om koden är tekniskt korrekt. Låt en ingenjör titta innan du erbjuder tjänsten.

Vad gör jag om kandidaten saknar GitHub? Fråga om ett tidigare projekt och använd samma frågor. Be om ett exempel som hen får visa.

Behöver jag ett kodtest också? Ibland. Läs om när det passar i teknisk screening utan kodtest.