Mange programmerere misliker tavleintervjuer. Men fungerer de?

BLINDERN (digi.no): For knapt to uker siden skrev digi.no om at en rekke utviklere protesterte på Twitter mot urealistiske jobberintervjuer, og da spesielt det å måtte demonstrere sine programmeringsferdigheter på en tavle.

I den anledning har vi intervjuet Gunnar Bergersen, som har to deltids førsteamanuensisstillinger ved Universitetet i Oslo, Institutt for informatikk (Ifi). Han har de siste tolv årene forsket på måling av programmeringsferdigheter, både ved Simula Research Laboratory og ved universitetet. Bergersen skrev sin doktorgrad om temaet i 2015.

Det korte svaret er at det avhenger veldig av personene, både kandidat og intervjuer, men også av oppgavene som velges. Men som vi kommer tilbake til – Bergersen er skeptisk til vidunderkurer som lover veldig mye.

I den ene stillingen ved Ifi er Bergersen tilknyttet avdelingen Programming and Software Engineering, hvor man forsker på de som jobber profesjonelt i programvareindustrien og hvordan ting gjøres der.

I den andre stillingen er han tilknyttet Studielabben ved Ifi, hvor det spesielt fokuseres på førsteårs informatikkstudenter. Bergersen har også etablert et selskap basert på forskningsresultatene sammen med andre.

Hva kjennetegner en dyktig programmerer?

I sin forskning ser Bergersen derfor på hele løpet fra man begynner med koding, via alle stegene man skal gjennom underveis, fram til man kommer til programvareindustrien og det som gjøres der.

– Fra et studentperspektiv minner koding på tavle om muntlig eksamen. Men det er ikke sikkert at det man ønsker å måle i en universitetssammenheng, ofte kunnskap, er det samme som man ønsker å måle i en arbeidssituasjon, sier Bergersen til digi.no.

For å innlede, spurte vi Bergersen hva som kjennetegner en dyktig programmerer.

– En dyktig programmerer, eller en ekspert innen programmering, kan defineres på mange forskjellige måter. Det vi er spesielt interessert i, er hva eksperter gjør og i hvilken grad de klarer å levere ting på et høyt kvalitetsnivå på en stabil måte, sier han.

Register med strategier

– Stikkordene for dyktige programmerere er dybde og bredde. De har også et stort repertoar av strategier som man kan bruke for å løse et gitt problem. De kan hoppe mellom disse ulike strategiene, avhengig av begrensninger ved oppgaven eller hvordan oppgaven er formulert. Når en nybegynner innen programmering skal løse et problem for første gang, lærer man seg en måte å løse det på. Da har man lett for å anvende denne metoden på alle problemer man ser.

Han legger til at nybegynnere ofte hefter seg ved overflatestrukturen til programmeringsoppgaver, mens ekspertene klarer å se den dype strukturen ved et problem. De dyktige programmererne klarer også å hoppe mellom ulike kvalitetskrav, slik som lesbarhet, vedlikeholdbarhet, effektivitet og portabilitet, avhengig av situasjonen.

– En annen ting som er viktig, er at ekspertene har en «forståstrategi» framfor en «prøve og feile»-strategi. Det er mange ting man tilsynelatende kan løse ved å flytte litt rundt på variabler eller tilordninger, for å se om man får riktig output. Alle som programmerer har gjort dette på et tidspunkt i karrieren, men det skaper problemer når du tre måneder senere ikke skjønner hvorfor en feil oppstår, fordi du egentlig ikke løste problemet fra starten av. Forståelse går på det at du først prøver å skjønne hva det er som ligger bak.

Lesbarhet

Det kjennetegner også eksperter at de har evne til å løse vanlige problemstillinger på en rask, god og gjerne konvensjonell måte.

– Det er ikke alltid man skal «finne opp kruttet». Dersom det er andre som skal lese koden din, er det jo et poeng at du ikke har valgt en veldig alternativ måte å gjøre det på, sier Bergersen.

– Noen kan jo skrive kode nesten som en god tekst. Den er lesbar som den fremstår.

Et siste kjennetegn er at eksperter er i stand til å forstå rekkevidden av handlinger.

– Et programmeringsproblem kan ofte løses på mange måter, men det er ikke sikkert at man skjønner hva det kommer til å påvirke. I tavleintervjuer er det av praktiske årsaker vanlig å se på noen som ser på veldig små biter av kode, gjerne algoritmer. Men i en industriell sammenheng er det ofte ikke en enkelt algoritme som utgjør kompleksiteten. Derimot er det totalsystemet, hvor forskjellige teknologistacker skal snakke sammen, og hvor det er hundretusenvis av kodelinjer som må fungere i samspill. Her kommer viktigheten av å forstå rekkevidden av egne handlinger inn, når noe feiler og resultatet av feilen kommer ut på et helt annet sted, mener Bergersen.

Relative sammenligninger

Tilbake til tavleintervjuer. Hva forsøker egentlig arbeidsgiverne å oppnå med dette?

– Testen tar utgangspunktet i det som kalles for en relativ vurdering hvor de som har søkt på stillingen kan rangeres i forhold til hverandre. Man har situasjoner hvor man har absolutte vurderinger, hvor man vet hvor godt man presterer – også sammenlignet med dem som ikke søker på stillingen. Men med tavleintervjuer gjør man relative sammenligninger, for å finne den beste kandidaten blant dem som søker på stillingen, sier Bergersen.

Han forteller at vi mennesker er ganske gode på slike relative sammenligninger, som grunnprinsipp.

– Uten å måtte bruke målebånd kan man for eksempel se hvem som er høyest av to personer. Eller når man ber folk om å rangere seg internt i en bedrift, så finner vi en ganske klar konsensus om at det er noen som utpeker seg som de sterkeste. Mens andre kanskje er svakere, men samtidig kanskje er bedre på annen ting. Det utgangspunktet ligger også til grunn for tavleintervjuer, sier Bergersen.

(artikkelen fortsetter under)

Arbeidsgiverens mål

Det er flere ting en arbeidsgiver ofte ønsker å få ut av slike intervjuer.

– En ting er at man kan produsere kode som fungerer. Men hvorfor må man gjøre det på en tavle og ikke slik man skrive kode vanligvis? Det kan være at arbeidsgiveren ønsker å vite hvordan kandidaten tenker rundt og snakker høyt om kode. En annen ting kan være håndtering av press, sier Bergersen.

Han nevner også at arbeidsgiveren kan være interessert i å vite hva kandidaten husker eller har memorert av ting.

– Det er også naturlig å trekke fram «Hvordan presterer du foran et publikum?». Man kan jo tenke seg at dette kan være et poeng for eksempel i konsulentbransjen. Ikke nødvendigvis for koden som produseres, men at man klarer å få solgt inn ideene.

– I det hele tatt putter folk mye rart inn i det. Som forsker er det da interessant å se på hva det er bra for og hva er det problematisk for. En ting er forskjellen på det å snakke om noe, og det å gjøre noe. Det går an å si ting på en overbevisende måte, men når det kommer til de konkrete detaljene, hvordan implementere i praksis, så feiler man fullstendig, sier Bergersen.

– Datamaskinen bryr seg ikke om intensjonen til en utvikler, men gjør det som er beskrevet i koden.

Avgjørende faktorer

Han mener at tavleintervjuer kan gjøres på en brukbar måte. Men det avhenger også av hvem som gjør vurderingen av prestasjonene. Også blant disse personene kan det være eksperter og noviser innen det aktuelle feltet, og forskning viser at disse fokuserer på ulike deler av presentasjonen.

– Uheldigvis kan de som ikke er eksperter på et felt, gjerne henge seg opp i de uvesentlige tingene og vektlegge disse som en del av det hele. Dersom du ikke er så god til å fortolke det som en ekspert sier, kan du få en dårlig match, hvor du hekter deg opp i det som virker overbevisende, framfor det som er viktig for en jobb, forteller Bergersen.

Et annet moment er hvilke oppgaver det er man bør velge.

– Det er ganske avgjørende, både for den som blir spurt og den som gjør evalueringen, sier Bergersen.

Innen forskningen på dette området kan man for eksempel se på hva det betyr å bytte evaluator, hvor man lar mange mennesker vurdere det samme tavleintervjuet som har blitt tatt opp på video.

– Man bør også spørre seg selv hvor avhengig resultater i intervjuet er av oppgavevalg. Dersom rangeringen av kandidater til en stilling hopper og spretter som et resultat av hvilken oppgave man velger, hvor god er da testen?

– Ideelt sett bør man ha oppgaver som alle måler det samme, hvis man ønsker å måle et begrep, da dette gjør at man kan slå sammen resultatene fra flere prestasjoner.

Vidunderkur?

Bergersen er også generelt skeptisk til vidunderkurer som skal løse alt og er trivielle å gjennomføre.

– Dersom måten å få den beste utvikleren på er slik at du bare kan velge en tilfeldig algoritme, intervjue alle personene om denne, og vips så har du funnet den beste utvikleren – da er det jo ganske enkelt (og kostnadsfritt hvis man ikke regner med tidsforbruk). Dessverre er verden slik at det er en del detaljer som det er viktig å få med seg, sier han.

– Vi har bygd programvare rundt dette i mange år. Presisjon får du over tid når du får jobbet inn alle smådetaljene.

Tid og presisjon henger sammen

I forbindelse med doktorgraden til Bergersen sammenlignet forskerne ulike metoder. Man kan for eksempel spørre kandidatene hvor gode de selv mener de er, eller se på erfaring fra CV-en. Dette er fort gjort, men gir dårlig presisjon. Ifølge Bergersen er det spesielt to faktorer som innvirker på selvoppfattelsen – erfaring og intelligens.

– De med lang erfaring sier at de er eksperter uansett om de presterer godt eller dårlig. Men de med høy intelligens vurderer seg gjerne lavere igjen. Dette er i samsvar med hva som er kjent som «Kruger og Dunning»-effekten.

Med kunnskaps- og intelligenstester som tar en time å utføre, får man ifølge Bergersen bedre presisjon.

– En kunnskapstest på en time skiller godt mellom dem som kan et programmeringsspråk og ikke. Men den skiller ikke mellom de gjennomsnittlige og de som er veldig gode til å programmere. Etter det er det andre faktorer som blir viktige. Det er ikke slik at den som svarer riktig på 30 av 30 spørsmål, er den programmereren som leverer best kode. Har man over et visst nivå, kanskje 80 prosent riktig på en kunnskapstest, er det andre faktorer som er viktigere, sier Bergersen.

– Vi bygget også et måleinstrument hvor du sitter og programmerer i en dag. Tiden du bruker og variasjonen av oppgavene betyr noe for målepresisjonen. Det skal mye til å få gode resultater på kort tid. I disse dager kan vi bruke en snau halv dag på å få samme kvalitet på resultater som vi før trengte en dag på ved bruk av en algoritme for automatisk oppgavevalg («computer adaptive testing»), sier han.

Realisme

Bergersen mener at også økt realisme har betydning for presisjonen.

– For studenter er det jo gjerne kodeproblemer slik at man starter med blanke ark, men i den virkelige verden starter man inne i et større system. Du har tilgang til et IDE med «autocomplete», og du har tilgang til Google hvor du kan søke opp alt det du ellers ville måtte huske under tavleintervjuet, sier Bergersen.

Professor Magne Jørgensen ved Simula har også sett nærmere på det som kalles for «trial sourcing», hvor man sammenligner flere programmeringsteam ved å gi dem tilgang til å gjøre noe i et reelt system, kanskje over en uke, mot betaling og kanskje sammenlignet med team man kjenner fra innad i bedriften.

– Da begynner vi å snakke om realisme, med ordentlig kode og hvor de kan jobbe sammen. I en studie publisert i IEEE Software fant Magne Jørgensen at risikoen for at et prosjekt feilet var kun en femtedel når man kunne benytte informasjon om hvordan de hadde gjort det i andre prosjekter, forteller Bergersen.

Noen lykkes

Bergersen sier likevel at han kjenner personer han stoler veldig på, som forteller at de har gode resultater av tavleintervjuer.

– Men jeg vet ikke om det er fordi det er disse som er gode intervjuere og velger gode oppgaver, eller om det er metoden som sådan som er god. Som forsker er det ofte gjennomsnittsverdier man må si noe om.

– Kanskje tavleintervjuer er bra dersom du er ekspert på algoritmen og algoritmen er relevant for den jobbsituasjonen du holder på med. Men man må ha en bra match mellom det kandidatene blir evaluert på og det de faktisk skal gjøre, sier Bergersen.

Hvilke kandidater som fort blir utelukket når de må gjennom slike tavleintervjuer, avhenger ifølge Bergersen av kriteriene for evaluering som benyttes. Men han trekker spesielt fram seniorer som en gang har lært seg algoritmer, men som kanskje ikke har brukt dem på 20 år.

– Man får tak i bøker om hvordan man kan lykkes i jobbintervjuer. Men hvem er det som har tid til å lese disse bøkene? Er det en høyt etterspurt, industriell programmerer, eller er det en student? Det er langt fra sikkert at det er de aller beste utviklerne som føler at det er god tidsbruk. Det er skummelt dersom det man må fokusere på før intervjuet, er noe som er helt irrelevant for arbeidsoppgaven, mener Bergersen.

Norske forhold

På spørsmål om hvor vanlig det er med slike tavleintervjuer i forbindelse med programmererstillinger i Norge, svarer Bergersen at han ikke kjenner til god, systematisk forskning på dette. Men man har utført studier hvor dette indirekte blir tatt opp.

– I 2011 spurte vi folk på Reddit om de har skrevet kode som en del av et intervju. Svarprosenten for Norge var lav fordi det ikke er så mange fra Norge som er på Reddit til enhver tid, men omtrent en av tre bruker praksisen der de jobbet. Områdene som brukte det mest, var i techsenterne Silicon Valley og rundt Seattle, hvor to av tre brukte praksisen.

– Rent analytisk kan størrelsen på industrien være en forklaring. Vi kjenner for eksempel ganske mange utviklere i Oslo, og dersom ansettelsene går via bekjente som har jobbet sammen tidligere, så er det naturlig at bruken av tavleintervjuer går ned. Men har du noen hundre tusen indere som utdannes hvert år, så har du ikke mulighet til å kjøre alt via anbefalinger. Da må de gjerne testes på en eller annen måte.

Referanser:

• Gunnar Rye Bergersen, Jan-Eric Gustafsson: Programming Skill,Knowledge, and Working Memory Among Professional Software Developers from an Investment Theory Perspective. Journal of Individual Differences 2011; Vol. 32(4):201–209
• Magne Jørgensen: Better Selection of Software Providers through Trialsourcing.IEEE Software September/october 2016:48-53
• Justin Kruger, David Dunning: Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments.Journal of Personality and Social Psychology 1999, Vol. 77, No. 6. ] 121-1134

Du finner enda flere spennende Digi Ekstra-saker i arkivet »