I løpet av min karriere til nå har jeg byttet arbeidsgiver et par ganger, og har dermed vært gjennom en hel del tekniske intervjuer.
Man skulle tro de fleste selskaper brukte lignende modeller, men her finnes det flere varianter - alle med sine fordeler og ulemper.
La oss dele disse inn i noen kategorier:
- Hjemmeoppgave: En case blir gitt til den potensielle kandidaten, som får en liten uke på seg til å løse den etter beste evne
- Live-koding: Kandidaten løser en mindre oppgave under intervjuet
- Teknisk fagprat: Kandidaten blir presentert kode, case, eller begge deler, og har en åpen diskusjon rundt dette
Hva er så fordelene og utfordringene med hvert av disse formatene?
Hjemmeoppgaven
Hjemmeoppgaven gir kandidaten frie tøyler, og hen kan benytte seg av alle hjelpemidler, inklusive Google og ChatGPT.
Denne modellen er nok den som er mest tilsvarende en normal arbeidssituasjon for en utvikler, og tester i hovedsak om hen kan levere et produkt som fungerer i henhold til beskrivelsen.
Oppgaven kan være relativt åpen, eller veldig tilspisset, og kan dekke alt fra back-end og front-end, til arkitektur, testing, og pipelines.
Jobbi lar deg anmelde jobben din – helt anonymt
- 👍 Hovedfordelen med denne modellen er at kandidaten får mulighet til å vise frem alle ferdigheter hen besitter, og kan bli godt testet på sin forståelse og fremstillingsevne. Under selve intervjuet er kandidaten klar for å presentere sitt produkt, sin metode, struktur, og kanskje til og med kreativitet?
- 👎 Utfordringen med hjemmeoppgaver er omfanget; hvor stor kan man gjøre oppgaven før kandidaten bestemmer seg for at hen ikke gidder? Og, i motsatt ende finner vi oppgaver som rett og slett er for små til å alene kunne gjenspeile kandidatens egenskaper.
Live-koding
Live-koding: Å løse en kata fra scratch mens noen puster deg i nakken. Neida, det er ikke så ille (håper jeg), men man blir fort litt svett når man skal implementere et red-black-tre med dobbellinket liste.
I dette formatet får kandidaten en veldig liten, men gjerne litt kompleks oppgave. Færre hjelpemidler er tillatt, man får for eksempel ikke benytte seg av eksisterende biblioteker som løser selve oppgaven bare ved å implementeres, men ofte er det tillatt å google litt, under oppsyn selvfølgelig.
Formatet minner nok mest om parprogrammering mellom en senior som sitter på svaret, og en junior som ikke aner hva hen begir seg ut på.
Her får man virkelig testet om kandidaten har logisk resonnement, og hvordan hen presterer under press og stress. Som regel blir man bedt om å tenke høyt, og forklare valgene man tar underveis.
Variant med reprise fra 2024 – trekker jobbtilbud til nyutdanna
- 👍 Fordelen med dette er at man fort finner ut hvordan kandidaten tenker, men dersom kandidaten allerede har løst en lignende oppgave ved å trene på kata-oppgaver på f.eks codewars, handler dette plutselig ikke om å tenke seg frem til svaret lenger, men heller å huske hvordan man løste oppgaven forrige gang.
- 👎 Utfordringen her er at en kandidat under stress kan rote seg litt vekk, og man får ikke testet de tekniske ferdighetene på samme bredde som i hjemmeoppgaven, men man får likevel testet hvor mye “is i magen” kandidaten har, som er nyttig dersom man trenger en nyansatt som er fryktløs og tar ting på strak arm.
Teknisk fagprat
Teknisk fagprat handler mer om forståelsen av fagområdet, og her finnes det varianter som kan inkludere kodeeksempler og noen ganger hele repoer.
Dette formatet minner mest om en “code-review” situasjon, der man f.eks må avdekke sikkerhetshull, optimalisere, refaktorere, og vise at man kan sette seg inn i nye domener.
Diskusjonen forgrener seg gjerne ut til spesifikke use-cases, og kandidaten får mulighet til å vise frem sine sterkeste sider, være dette ren kodeforståelse, arkitektur, eller forklaringsevne.
Vi lengter tilbake: Se jobbintervjuer i 2021 vs. 2025
- 👍 Fordelen med den tekniske fagpraten er at man kan la kandidaten ta litt av styringen, og får målt teamwork-egenskapene hen besitter.
- 👎 Utfordringen er at man ikke får sjekket kandidatens evne til å faktisk levere produsert materiale, som gjør at dette formatet kanskje er best egnet for kandidater som søker på rådgiver-roller.
Hva bør man velge?
Det finnes nok varianter jeg ikke har gått gjennom her, og de fleste tekniske intervjuer inneholder flere enn én av disse formatene. Til syvende og sist handler det om å finne riktig kandidat til rollen, og jeg vil ikke si at det ene er bedre enn det andre.
Så hva bør du velge? Det avhenger av rollen.
- Konsulenter bør gjerne testes på formidlingsevne, domeneforståelse og samarbeid, og dette er noe en fagprat eller live-koding kan avdekke.
- For in-house utviklere, hvor kvalitet over tid og arbeidsvaner er viktig, kan en hjemmeoppgave være mer aktuell.
Men i praksis er ofte en kombinasjon det beste. De fleste utviklerroller krever både samarbeid, struktur og tekniske ferdigheter, og da bør intervjuprosessen gjenspeile nettopp det.
Uansett format, sørg for at intervjuet ikke bare tester kandidaten, men også gir et godt inntrykk av hvordan en arbeidshverdag er hos dere.
