Jeg har intervjuet godt over hundre utviklere gjennom teknisk intervju. Flesteparten av dem har vært i fulltidsjobb som utvikler allerede. Folk reagerer ulikt på å bli testet teknisk. De fleste synes det er skummelt. Noen gir opp og mister all selvtillit. Andre blir fornærmet for å måtte (be)vise sin kompetanse etter flere år i jobb allerede, mens andre igjen blir både giret og ivrige.

Dette har fått meg til å tenke mye på hvorfor vi egentlig gjennomfører teknisk test og hvordan man gjør det best mulig.

Er det i helet tatt nødvendig å teste kandidater med praktisk oppgave? 

Jeg mener det er et veldig tydelig JAAAA, som svar på det spørsmålet. Det er absolutt noe man bør gjennomføre på alle kandidater. En annen ting jeg har funnet ut er at det er mange fellestrekk på hva folk gjør feil i intervjuer og feilene de gjør ellers i arbeidslivet. Derfor vil jeg i denne bloggposten ta for meg noen av det jeg synes skiller en GOD og en OK utvikler og hvordan vi tester kandidater i Alv for å finne de riktige folkene.

Minner om IQ-test og eksamen

Som med både IQ-test og eksamen må man ha en del grunnleggende evner til å begynne med for å gjøre det godt på en teknisk case. Samtidig kan øvelse hjelpe deg langt på vei mot målet. En nettside der man tester seg litt på små tankeoppgaver som ofte blir brukt i intervjuer, er denne https://projecteuler.net/archives. Der finnes det mye å bryne seg på og kan være smart for back-end utviklere. For både front-end og back-end kan det være smart å ha litt erfaring med oppsett av prosjekter helt fra bunn og gjerne kunne vise fullstack ved å sy disse sammen med en front-end eller back-end. 

GJØR DEG NOEN TANKER OM NÅR DU BURDE BRUKE HVA, HVORFOR DU GJØR DE TINGENE DU GJØR OG HVORFOR DU VELGER DE LØSNINGENE DU PLEIER Å GÅ FOR.

For å gjøre deg klar til intervjuet bør du øve deg på problemløsning, og øve på mer enn bare CRUD endepunkter. Tenk gjerne gjennom hva du selv ville testet en kandidat i, dersom du var den som holdt intervjuet. Prøv å utvid horisonten litt og lek deg med forskjellige måter å lagre elementer, annet enn bare array eller list. Gjør deg noen tanker om når du burde bruke hva, hvorfor du gjør de tingene du gjør og hvorfor du velger de løsningene du pleier å gå for. Det er i denne delen av intervjuet du viser at du er en kompetent utvikler som bryr deg om håndverket du utfører. De aller fleste klare å løse en teknisk test, men bare flinke utviklere klare å løse den på en måte som er; 

1. Lett å lese

2. Lett å forstå

3. Lett å utvide

4. Lett å vedlikeholde

5. Lett å teste/verifisere

6. Lett å forklare

De beste utviklerne skiller seg blant annet ut på hvor raskt de klarer å forstå nye oppgaver og sette seg inn i dem. De bruker tidligere erfaringer på nye og effektive måter og klarer ofte å forklare hva de har lyst å få til på et overordnet nivå allerede etter de første 5-10 minuttene av intervjuet. Denne typen utviklere trenger som regel ikke å få oppgaver repetert i det uendelige, men tar heller til seg informasjon så fort du gir den til dem. Dette betyr ikke at de detaljplanlegger alt før de begynner, men heller at de har en tanke om hvor de vil og en følelse om hvordan sluttproduktet kommer til å se ut.

Bryt ned oppgaven

Uerfarne utviklere prøver som regel å løse hele problemet i hodet, for så å skrive ut alt fra topp til bunn. Selv om dette av og til lar seg gjøre, pleier det nesten alltid å være en dårlig måte å angripe utfordringen på. 

ERFARNE UTVIKLERE STARTER OFTE PROGRAMMET MED EN «HELLO WORLD», BARE FOR Å SJEKKE AT MILJØET ER SATT OPP RIKTIG, FØR DE SKRIVER FØRSTE RELEVANTE LINJE KODE.

I arbeidslivet vil slike personer starte store brukerhistorier som det fort blir umulig for andre å hjelpe til på, siden alt bare er i hodet til «tenkeren». På intervjuer kjenner vi ofte igjen disse ved at de ikke kjører/tester programmet en eneste gang, før over 50% av intervjuet er ferdig. De setter seg veldig ofte fast i at de ikke klarer å forholde seg til alle «corner cases» samtidig, allerede før de har begynt å kode. 

Erfarne utviklere starter ofte programmet med en «hello world», bare for å sjekke at miljøet er satt opp riktig, før de skriver første relevante linje kode. De bryter ned oppgaven i komponenter som kan testes og klarer derfor lett å delegere til andre, eller til seg selv i fremtiden. Man hører dem oftere si ting som «her kommer jeg til å få problemer med IndexOutOfBounds, men det kommenterer jeg bare nå og fikser det heller etterpå». På denne måten ser man at de klarer å fullføre de komponentene, eller naive førsteversjonsimplementasjonene som skal til for at man videre kan utvikle noe som kjører steg for steg. 

Dette gjør det også mye lettere å følge utviklingen for oss som er med på den tekniske testen. Ett annet aspekt er at vi ute hos kunder ofte utvikler ved hjelp av parprogrammering. Da er denne typen gradvis oppbygging utrolig mye bedre for å sikre kvalitet og forenkle samarbeid.

Vær kvalitetsbevisst

Som konsulent vet vi at vi ikke skal jobbe på et prosjekt for alltid og det stilles derfor ekstra strenge krav til oss når det kommer til kvalitet, verifisering og sporbarhet, selv om dette egentlig er krav som gjelder alle, konsulent eller ikke. Et av de verktøyene vi ofte bruker for å sikre dette, er å skrive gode tester som både dokumenterer og verifiserer de vanskelige delene av koden vår. I en parprogrammering- eller intervjusetting er dette en glimrende mulighet til å vise at du klarer å tenke fremover og jobbe basert på krav. Ved å skrive tester for koden slipper du selv å tenke på disse kravene, men overlater det heller til datamaskinen å sikre at kravene er oppfylt etterhvert som kompleksiteten øker. Dette gjør det mye lettere for intervjueren å følge hva du prøver å få til, følge logikken og tankerekken din i feilsøkingen og ikke minst sikre at det du gjør ikke brekker andre deler av koden din. 

Overkill

Noen utviklere prøver alltid litt for hardt å vise alt de kan, både på intervju og i prosjekt. De ender som oftest opp med å lage et uleselig makkverk av kode, som kun de selv forstår, i beste fall. Hvis du skal lage FizzBuzz trenger du kanskje ikke 32 forskjellige klasser med arv, interface og object factory. De som skyter spurv med kanoner i prosjekt kan være noe av det verre å bekjempe, da de ikke gjør noe direkte feil, men heller skakkjører et prosjekt på sikt, med overkompliserte løsninger det er umulig å vedlikeholde. Det kan være vanskelig å oppdage disse typene da koden kjører og gjør jobben den er designet for, men leselig er den absolutt ikke. En slik person i team ditt kan bety en sakte død for all produktivitet i teamet, da vedkommende alltid øker kompleksiteten for å gjøre løsningene supergeneriske, så kort som mulig, eller har optimal ytelse.

BYGG SYSTEMET DITT MER ETTER SAMTALE MED BRUKEREN (INTERVJUEREN) OG DE DIREKTE KRAVENE SOM STILLES TIL LØSNINGEN.

Mitt tips dersom du er redd for at du er en slik person, er å fokusere mer på rett mengde kompleksitet til rett sted og tid og heller strebe etter kode de fleste utviklere klarer å lese, fremfor det akademisk peneste. Spør for eksempel gjerne intervjueren om inputen til oppgaven skal være en konstant, eller om dette kanskje blir konfigurerbart i fremtiden, før du implementerer et helt bibliotek for input. Bygg systemet ditt mer etter samtale med brukeren(intervjueren) og de direkte kravene som stilles til løsningen. Dersom ytelse ikke er viktig så ikke bruk for mye tid på det. 

Jobb som vanlig

Det å være god til å google er en undervurdert egenskap, og det er stor forskjell på gode og dårlige utviklere når det kommer til googling. Dårlige utviklere bruker ofte feil søkeord, eller blander inn ting som er spesifikt for akkurat denne oppgaven, i stedet for å søke etter det generelle problemet de egentlig lurer på. Dette tyder på at kandidaten ikke har et godt ordforråd som utvikler og vil da ofte ende opp med nybegynnerløsninger på nybegynnerspørsmål. En god googler klarer raskt å finne riktige treff og klarer å bruke selv de dårligste resultatene til å komme videre i oppgaven. Det å drive copy-paste-utvikling fra Stack Overflow, kan være en risikosport når man ikke har peiling hva man kopierer.

Vær strukturert

Gode utviklere tegner opp eller noterer oppgaven og kommer med oppfølgingsspørsmål, for å være sikker på at de har forstått oppgaven riktig. Dette er en utrolig viktig egenskap ute i arbeidslivet også. Som arbeidsgiver er man interessert i å ansette folk som tar ansvar og klarer å være med på å drive utvikling og prosess videre. Dette er umulig å gjøre uten at man forstår hverandre og klarer å ta til seg informasjon på en god og strukturert måte. 

Som regel vet ikke de som bestiller et program hva de faktisk vil ha. Derfor er det å forstå brukere og det underliggende behovet, ofte en undervurdert egenskap. Dette avdekkes ofte når oppgaven blir litt kompleks. Uerfarne utviklere starter kodingen uten egentlig å ha forstått hva man skal lage. 

Dette kan kanskje føles som en konflikt med punktet om det å bryte ned oppgaven, men det å forstå hele oppgaven er ikke det samme som å løse alt på de første 5 minuttene. Man kan avdekke de funksjonelle kravene, for så å notere seg at dette må man løse senere og velge å starte med kjernefunksjonaliteten. Hvis man skal lage en racerbil kan man gjerne samle inn alle kravene, men første POC bør kanskje bare være versjon «0.1» av motoren eller noe annet «lite» man kan bygge videre på. Det er likevel viktig å tidlig avdekke om det skal bygges en racerbil eller en familiebil, før man begynner på noe teknisk.

Vær hyggelig å samarbeide med

Et godt teknisk intervju er som tidligere nevnt, litt som parprogrammering. Man kommer nesten alltid til en situasjon der intervjueren kommer med et hint eller tips eller spørsmål. I slike situasjoner reagerer kandidater ganske forskjellig. Noen reagerer ved å overse input, andre blir forvirret og noen får nytt mot og ser løsninger. Disse situasjonene viser godt forskjeller i personlighet og skiller hvem som er hyggelig å jobbe med, er lærevillig, tar input positivt og spiller videre på hverandres ide-er. Personer som er gode i slike situasjoner gjør at man får et enda bedre resultat og skaper supereffektive team.

Dette er helt essensielt for våre ansatte, og krever at man ikke har spisse albuer og ikke ser på det som et nederlag å ta input fra andre. Jeg har tidligere med vilje lagt inn feil i oppgavetekster eller tekstdata for å se hvordan kandidaten håndtere slikt, og da kan det fort skinne gjennom hos noen en «er du helt idiot!»-holdning som kan være veldig ødeleggende for et eventuelt fremtidig samarbeid. 

PASS DERFOR PÅ Å JOBBE AKTIVT MED Å BLI EN HYGGELIG TEAMARBEIDER I HVERDAGEN.

Denne egenskapen kjenner vi også igjen ute i prosjekt da noen skyter ned forslag fra andre, kritiserer ukonstruktivt og leter etter skyldige når ting går galt. Pass derfor på å jobbe aktivt med å bli en hyggelig teamarbeider i hverdagen. Da kommer dette til å bli helt naturlig også på intervjuer. 

Eksamen er ikke for alle

Ved å kjøre teknisk intervju kan man dessverre gå glipp av noen veldig gode potensielle ansatte. Jeg har møtt noen få utviklere som er utrolig flinke, men som dessverre fryser helt på intervjuer og da spesielt teknisk testing. Dette gjelder heldigvis bare et fåtall. Selv om tekniske tester kan gjøre at vi går glipp av noen svært dyktige utviklere, er situasjonen med teknisk test og håndteringen av den, en viktig egenskap i seg selv. Som konsulent må man ofte dra på oppdragsintervju for å vinne de kuleste oppdragene. Derfor er dette noe man bare må være god på. 

JEG HUSKER GODT AT JEG VAR MYE MER NERVØS PÅ MITT FØRSTE INTERVJU SOM INTERVJUER ENN JEG VAR PÅ MITT FØRSTE INTERVJU SOM KANDIDAT.

Tips til de som sliter med dette er å øve og gjerne dra på et par ekstra intervjuer for å bli mer vant til situasjonen. Prøv å senke skuldrene og tenk på at det bare er vanlige folk som sitter på andre siden av bordet. Folk som så inderlig vil at du skal gjøre det bra, så de kan få fylt stillingen de har som oppgave å fylle. Jeg husker godt at jeg var mye mer nervøs på mitt første intervju som intervjuer enn jeg var på mitt første intervju som kandidat. Situasjonen er jo et intervju begge veier og det er også en god anledning for å få testet om personene i selskapet du potensielt skal jobbe i er hyggelige å jobbe sammen med.

Tanker på tampen

Det viktigste med intervjuet er at du får frem at du er en hyggelig person å jobbe med og en som kan tingene sine. Som junior er det mye viktigere å få frem at du er engasjert, ivrig, lærevillig og greier å ta til deg hint og forslag, enn at du har all syntax i fingretuppene.

Prøv gjerne å få frem hvorfor nettopp du bør ansettes til stillingen en gang i løpet av intervjuet. Det er viktig at du finner en fin balanse mellom å vise deg frem og det å være en jovial og trivelig person. 

Dersom du mener du har det som skal til eller bare har lyst til å teste dine egenskaper så ta gjerne kontakt med oss på hei@alv.no .