I Alv har vi relativt mange som søker jobb hos oss. En del av disse blir kalt inn til førstegangsintervju, og vi gjennomfører i snitt flere intervjuer i uka. Etter en vurdering på om personen passer inn og kommer til å trives i Alv, samt en rekke andre kriterier, går noen videre til andre runde, hvor vi har et såkalt teknisk intervju. Her faller dessverre urovekkende mange gjennom. 

I denne bloggposten vil vi forklare nettopp hvorfor vi syns det er så viktig å gjennomføre gode tekniske intervjuer, hva som sjekkes i disse intervjuene og hvorfor så mange feiler på dem. Dette innlegget er skrevet av Håkon Halvorsen og Pål Bøckmann. Håkon er ansvarlig for data og analyse i Alv, og Pål er en senior utvikler i Alv. Begge har lang erfaring med gjennomføring av tekniske intervjuer.

Hvorfor er tekniske intervjuer viktig?

La oss starte med hvorfor vi synes at tekniske intervjuer er viktige. En av grunnene, kanskje hovedgrunnen, er at det er ekstremt dyrt og bortkastet med feilansettelse rent teknisk. Dette gjelder både for den som blir ansatt, men også for Alv. Hvis vi har et kundebehov som ikke blir fylt godt nok gjennom ansettelsesprosessen, blir det naturlig å gi avslag, når vi ikke kan stå inne for å dekke behovet ovenfor kundene våre. De tekniske intervjuene går ofte hånd i hånd med kompetansen som blir etterspurt i markedet. 

I tillegg til å dekke kundenes behov, ønsker vi også å sende et signal til markedet om at Alv har dyktige konsulenter. For å kunne oppnå dette, må vi prioritere kvalitet foran kvantitet. Ved å unngå å senke kravene til ansettelser, holder vi oss på et høyt nivå, som forhåpentligvis vil gi oss god verdi på lang sikt. 

En siste grunn til at det tekniske intervjuet er viktig, er at vi bryr oss om folkene, med hele sin personlighet, kommunikasjon og væremåte i en arbeidssituasjon. Vi kaller det helhetskonsulenten. Dette er ikke noe vi klarer å oppdage kun gjennom å se gjennom en CV, eller gjennom en generell prat. Når vi derimot koder sammen med kandidatene, oppdager vi i mye større grad hvordan samspillet fungerer, selv om en teknisk test selvsagt aldri vil bli helt lik som en normal arbeidssituasjon. 

Hvordan gjennomfører vi tekniske intervjuer

Mange har nok opplevd å gå på teknisk intervju og bli servert en oppgave som på ingen måte ligner noe de har jobbet med før eller er sannsynlig å møte i et oppdrag. En eller annen komplisert LeetCode-oppgave hvor man skal traversere et binært tre, eller for eksempel optimalisere søk av en linket liste. Dette er oppgaver som er langt unna det man vanligvis møter i hverdagen og ikke minst problemstillinger som er svært vanskelige å sette seg inn i i en stressende intervjusituasjon. Her får man sjeldent testet kandidaten på en god måte. 

Vi mener en bedre måte er å la kandidaten forklare noen grunnleggende konsepter i deres foretrukne programmeringsspråk, gjerne basert på egne prosjekterfaringer, hvor vi følger opp med litt dypere spørsmål og begynner samtaler om disse temaene. Da får vi raskt en god følelse av hvor kandidaten ligger teknisk og om de har en solid forståelse av både programmeringsspråk og systemutvikling generelt. 

Videre er det nyttig å se kandidaten skrive noen linjer kode. Det trenger ikke være kompliserte greier, men om du har skrevet på CV-en din at man har programmert C# i 5 år, bør du klare å skrive litt kode av et grunnleggende program. Her ser vi også ganske raskt om kandidaten har programmering i fingrene, eller om de kun har en mer overfladisk teknisk forståelse. Begge deler er viktig.

I Alv ønsker vi å spille kandidaten god. Det er ikke vårt mål å sette deg ut eller gjøre det vanskelig for deg. Vårt mål er jo tross alt å gi deg et jobbtilbud og at du skal ha lyst til å takke ja til det tilbudet! Nettopp derfor legger vi opp til et litt mer åpent teknisk intervju hvor vi heller kan fokusere på de tingene kandidaten føler seg trygg på, tilpasset etter deres CV. Kandidaten har også mulighet til å bruke internett og Google under intervjuet, slik at det skal minne mer om en vanlig arbeidssituasjon. Ellers så har vi selvfølgelig våre krav og forventninger til hva kandidaten bør kunne, men det er ikke gøy for noen, og heller ikke særlig informativt, om kandidaten kontinuerlig stanger hodet i veggen gjennom intervjuet.

I Alv ønsker vi å spille kandidaten god. Det er ikke vårt mål å sette deg ut eller gjøre det vanskelig for deg.

Når vi gjennomfører teknisk intervju for utviklere, ønsker vi alltid å teste et par ting. For det første vil vi se om kandidatens egenskaper er omtrent der vi forventer og trenger at de skal være. Er du en senior utvikler med 5+ års erfaring bør du kunne forklare både grunnleggende og avanserte konsepter, argumentere for forskjellige arkitekturvalg og løse enkle programmeringsoppgaver du får på intervjuet. Jeg har selv opplevd utviklere med over fem års erfaring som ikke en gang har klart å opprette et nytt prosjekt i Visual Studio. Det er nettopp slike tilfeller det er så viktig å avdekke, for tro det eller ei: pynting på CV er svært vanlig.

Siden vi er så heldige å få inn såpass mange kandidater, er det også naturlig at flere av dem er på juniornivå. Vi har sett fra flere intervjuer med juniorer at de kan gjøre det godt teknisk – selv om de har lite prosjekterfaring med koding, og kanskje kommer rett fra skolebenken. Kanskje har de kodet mye gjennom studiene og fritiden, og er derfor godt rustet for arbeidslivet. Disse kandidatene er ofte også høyt motiverte, og gjør gjerne det lille ekstra for å prestere på et intervju. I disse intervjuene ser vi uansett mer etter motivasjon og et ønske om å utvikle seg videre, slik at de passer til konsulentrollen, enn harde tekniske ferdigheter. Vi ser også her ekstra mye etter om kandidaten greier å ta til seg informasjonen vi gir gjennom intervjuet. Dette gir en god pekepinn på hvor lærevillig denne forhåpentligvis fremtidige juniorkonsulenten er. 

Utover det faglige og tekniske ønsker vi også å teste evnen din til å sette deg inn i nye problemstillinger og domener. Som konsulent vil du bli plassert i mange ulike oppdrag og situasjoner hvor det er avgjørende å raskt kunne komme i gang med problemløsingen. Du vil ofte bli sett på som en kostbar ressurs som konsulent, og med det følger det gjerne høye forventninger til å kunne levere.

Utover det faglige og tekniske ønsker vi også å teste evnen din til å sette deg inn i nye problemstillinger og domener.

Teknisk intervju gir oss også muligheten til å bli bedre kjent med kandidaten fra et sosialt perspektiv, i tillegg til at flere enn de som gjennomfører førstegangsintervju får gjort en vurdering av kandidaten. Dette gjør oss tryggere på at vi tar rett valg om kandidaten som person. Ikke minst så er det en god mulighet for kandidaten å bli bedre kjent med selskapet gjennom å snakke med konsulenter og ikke bare administrasjonen. Man bør ikke glemme denne muligheten som kandidat, og også være nysgjerrig og interessert i de som vurderer deg. Vi er her for å finne ut om du og Alv er en god match på alle plan.

Til slutt har vi lyst til å sjekke kommunikasjonsegenskapene dine gjennom hvordan du svarer på spørsmål og forklarer løsningen din til intervjuoppgaven. Jeg vil argumentere for at som konsulent er det viktigere å ha gode (eller hvert fall ok pluss) sosiale ferdigheter, enn det er som fast ansatt, generelt sett. Man kommer tross alt inn som en outsider hos ulike kunder, og må raskt bygge tillit som konsulent.

Hvor går det galt

Som nevnt tidligere faller veldig mange kandidater gjennom på teknisk intervju. Vår erfaring er at det er noen tendenser som går igjen til hvorfor dette skjer.

Først og fremst er det viktig å påpeke at om du føler at du gjør det dårlig fordi du er nervøs, så er det helt vanlig. Vi har god trening på å se gjennom nervøsiteten og vurdere ferdighetene som ligger bak. Det er ytterst sjelden at dette er grunnen til at intervjuet ikke ender i tilbud. 

Den vanligste grunnen til at noen feiler et teknisk intervju, er nok at de ikke er godt nok forberedt. På mange kandidater virker det som at de er litt rustne og sliter med å komme ordentlig i gang. En oppfriskning rundt grunnleggende konsepter og litt koding på egenhånd i forkant av intervjuet, gjør ofte underverker.  

Hvis kandidaten sliter på det tekniske under intervjuet, og setter seg ofte fast i forskjellige oppgaver, setter vi enda mer pris på kommunikasjonsegenskaper. Hvis kandidaten sitter i stillhet og koder for seg selv, er det vanskelig for oss å få innblikk i hvordan kandidaten tilnærmer seg problemet og dermed vanskelig å vurdere hvor godt de skjønner oppgaven. Hvis en skulle stå fast, har man lov til å benytte seg av internett, som en vanlig arbeidssituasjon – men da ønsker vi gjerne at de resonnerer hvordan de tenker. Det blir vanskelig for oss å hjelpe kandidaten hvis de ikke kommuniserer godt når de setter seg fast!

Til slutt har vi de kandidatene som rett og slett ikke når opp til kravene av ulike grunner. Kandidater som har pyntet på CV-en sin finner vi ofte her. De som har flere års erfaring med C#, men den erfaringen er innenfor et eller annet smalt område, hvor de egentlig bare har brukt et spesielt nisjeprogram skrevet i C# for 15 år siden, eller for eksempel kun har drevet med enkel feilretting, og sjeldent drevet med mer avansert koding. I et mindre selskap som Alv ser vi ofte etter litt bredere kompetanse slik at kandidatene kan ta på seg flere hatter, men også eksperter innenfor et attraktivt område - som .NET eller kunstig intelligens. 

Oppsummering

Teknisk intervju er kanskje det viktigste verktøyet vi har for å sikre riktige ansettelser. For et lite til mellomstort selskap er det svært dyrt med feilansettelser og grundig testing er essensielt for å ikke gå i den fella. De aller fleste hører ordene teknisk intervju og får kaldsvette oppover ryggen, men ved å legge opp intervjuet på en god måte, er det etter vår mening mulig å gjøre det til en mye mindre skummel opplevelse for alle parter, der kandidaten får vist seg frem fra sin beste side og selskapet gjør seg selv attraktivt som en potensiell arbeidsplass. Vi vet at en del selskaper ikke gjennomfører teknisk test med koding, men heller gjennomfører en teknisk kaffeprat. Vi snakker også ofte teknisk i deler av førstegangsintervjuet vårt, men vi opplever stadig at kandidater vi har trodd har vært svært stødige teknisk etter slike prater, faller gjennom når vi kommer til den faktiske kodingen.