Intervjuspørsmål for senior utvikler

Senior utvikler-intervjuer er en annen sjanger

Hvis du har vært gjennom intervjuer som junior og mid-level, vet du hva du har vært gjennom: kode-tester, FizzBuzz-aktige oppgaver, kanskje en algoritme i fokus. Senior-intervjuer er fundamentalt annerledes. Selskaper kjøper ikke en god koder, de kjøper en som kan ta tekniske beslutninger og påvirke et team.

Denne guiden er for utviklere med 7+ års erfaring som søker senior, lead eller staff-roller i norske selskaper. Mange av tipsene gjelder også for tilsvarende roller utenfor utvikling: senior data engineer, senior PM, lead UX.

Hvilke selskap som faktisk rekrutterer seniors

I norsk tech finnes det noen ulike kategorier:

Etablerte tech-selskap (over 200 ansatte)

Schibsted, Cognite, Telenor, FINN, Vipps, Storebrand, DNB digital. Disse har strukturerte intervju-prosesser, ofte 3-5 runder, og de leter etter folk som kan bli teknisk leder eller arkitekt over tid.

Scale-ups (50-200 ansatte)

Otovo, Tise, Boost, Findable, Foreldre.no. Senior-rollen er ofte mer hands-on og praktisk. Du forventes å skrive kode samtidig som du tar tekniske beslutninger og mentorer junior-er.

Konsulent-selskap

Bekk, Knowit, Bouvet, Kantega, Sopra Steria. Senior-rollen er ofte fokusert på kunde-leveranser og rådgivning. Mindre dyp teknisk arkitektur, mer pragmatisk problemløsning.

Offentlig sektor og digitaliserings-team

Skatteetaten, NAV, Difi/Digdir, Helsedirektoratet. Senior-rollen er ofte fokusert på arkitektur, sikkerhet, og samarbeid med saksbehandlere og forretnings-eiere.

Hver kategori har sine egne intervju-mønstre. Tilpass forberedelsen.

De fire vanligste rundene

Runde 1: Innledende telefon med rekrutterer

15-30 minutter. Snakker om bakgrunnen din, hvorfor du søker, og hva du forventer i lønn (forsøker å filtrere). Ingen teknisk dybde her.

Forberedelse: 30-sekunders pitch om karriere, klar lønnsforventning eller intervall, og spørsmål om selskap-kulturen.

Runde 2: Teknisk dybde med utvikler eller tech lead

60-90 minutter. Dette er den teknisk tunge runden. Forvent kombinasjon av:

• Dypdykk i tidligere prosjekter: "Forklar arkitekturen til X-systemet du bygde."
• System-design: "Hvordan ville du designe en søkemotor?", "Hvordan ville du bygd betalings-modul som håndterer 10 000 transaksjoner per minutt?".
• Trade-off-diskusjon: "Hvorfor valgte dere Postgres fremfor MongoDB?", "Hvordan vurderer du synkron versus asynkron kommunikasjon?".

Forberedelse: ha to-tre prosjekter klart der du kan tegne arkitekturen på whiteboardet (eller delt skjerm) og forklare hvilke trade-offs du gjorde.

Runde 3: Praktisk kode-oppgave

Ofte hjemme-oppgave, noen ganger live. Senior-rollen tester sjelden algoritmer (du har bevist det med erfaring), men oftere:

• Pair-programming på en realistisk oppgave: Fikse en bug i en eksisterende kode-base, eller legge til en feature.
• Code review: Du leser en pull request og kommenterer.
• Live-debugging: Et system som ikke fungerer, og du må finne ut hvorfor.

Forberedelse: vær komfortabel med å kommentere kode du ikke har skrevet, og å tenke høyt mens du jobber.

Runde 4: Ledelse og samarbeid

Ofte med tech lead eller engineering manager. Tester:

• Mentor-erfaring: "Fortell om en gang du hjalp en mindre senior utvikler."
• Konflikt-håndtering: "Hvordan håndterer du uenighet i tekniske valg?"
• Påvirknings-arbeid: "Hvordan får du andre med på en endring?"

Forberedelse: ha tre konkrete eksempler på mentoring, en på konflikt, og en på å drive endring.

Eventuell runde 5: Møte med leder eller stakeholder

20-30 minutter. Mer kulturell match enn teknisk. Spørsmål om hva du vil oppnå, hvordan du jobber med ikke-tekniske, og om dere passer sammen.

De 12 mest sannsynlige spørsmålene

Etter mange intervjuer for senior-roller i norsk tech, går disse spørsmålene igjen. Forbered ærlige svar med konkrete eksempler.

1. Fortell om et komplisert teknisk problem du løste. Velg noe der du måtte balansere flere bekymringer. Ikke bare teknisk, men også team-dynamikk eller stakeholder-press.

2. Hva er den verste tekniske beslutningen du har vært med på? Ærlighet teller. Vis at du har lært, ikke bare at du tar feil.

3. Hvordan ville du designe X? Lær Boris Cherny sitt SDS-rammeverk: "Functional, Non-functional, Architecture, Trade-offs". Bruk 5 minutter på å forstå problemet før du begynner å tegne.

4. Hvorfor valgte du teknologi X? Aldri svar med "fordi det er moderne". Trade-offs, kontekst, alternativer du vurderte.

5. Hvordan håndterer du uenighet med andre utviklere? Konkret eksempel. Ideelt en der du tapte argumentet og lærte noe.

6. Hvordan har du mentorert junior-utviklere? Konkret. To eller tre eksempler. Hva de lærte, hvor de er nå.

7. Hvordan påvirker du tekniske beslutninger uten at du har formell makt? Senior-rollen handler ofte om dette. RFC-dokumenter, code reviews, parring, demoer.

8. Hva gjør du hvis ikke-tekniske krever noe du tror er en dårlig idé? Forklarer trade-offs. Foreslår alternativer. Aksepterer beslutningen hvis det er deres beslutning, men dokumenterer.

9. Hvordan holder du deg oppdatert teknisk? Konkrete kilder. Bøker, podcasts, communities, eksperimenter.

10. Fortell om et prosjekt som ikke gikk som planlagt. Vis modenhet. Ikke skyld på andre. Forklar hva du gjorde annerledes etter.

11. Hva slags kode-kvalitet er du komfortabel med? Vær realistisk. Perfeksjonist-svar er en rød flagg. "Fungerer i produksjon med rimelig vedlikehold" er bedre enn "100 prosent test-dekning".

12. Hvor ser du deg selv om 3 år? Ærlighet, men koblet til hva selskapet kan tilby. Hvis du sier "starter eget selskap", får du sjelden offer.

Det de ikke sier eksplisitt

Det finnes ting senior-utviklere lett feiler på, men som ikke alltid blir sagt høyt:

Du skal være pragmatisk, ikke ideologisk

Hvis du sier "Jeg vil aldri jobbe med JavaScript igjen, kun TypeScript", lukker du dører. Hvis du sier "Vi prøvde TypeScript på prosjekt X, men droppet det fordi team-størrelsen var for liten til å rettferdiggjøre overgangen", høres du senior ut.

Test-coverage er ikke alltid svaret

Aggressiv "alt skal ha 95 prosent test-coverage" er en junior-holdning. Senior-svar: "Vi tester der det matter mest, kjerne-business-logikk og APIer ut av tjenesten. UI-tester selektivt der bug-er har stor kostnad."

Du skal kunne velge ikke å bygge

"Ikke alt trenger en mikrotjeneste. Vi løste det med en cron-job og en Slack-integrasjon i to dager." Senior-svar.

Du skal kunne erkjenne hva du ikke vet

"Jeg har ikke jobbet med Kafka i produksjon, men kan nevne hvilke trade-offs jeg ville vurdert" er bedre enn å bløffe.

Lønnsforhandling for senior

Senior-roller i Norge har som regel 100 til 250 000 forhandlings-rom over utlysningens utgangspunkt. For å forhandle riktig:

Få et tall først

Når de spør "hva forventer du", svar "hva er rammene dere har for stillingen?". Hvis de gir et tall, la dem ha det førstesteget.

Bruk markeds-data

LinkedIn salary insights, glassdoor (mindre nøyaktig i Norge), og samtaler med tidligere kolleger gir referanse. SSB sin lønnsstatistikk er konservativ, men gyldig som baseline.

Forhandl pakke, ikke bare grunnlønn

Pensjon, aksjer, hjemmekontor, fleksibel arbeidstid, kurs-budsjett, ferie. Senior-roller har ofte flere variable enn junior-er.

Vit hvilke knapper du kan trykke

Hvis selskapet er offentlig finansiert eller scale-up med begrenset cashflow, kan grunnlønn være låst. Forhandle aksjer, opsjoner eller bonus.

Gi dem en vei ut

Ikke ultimatum. "Jeg vil gjerne se på dette og kommer tilbake" er bedre enn "Jeg trenger 1.1 millioner eller jeg går".

Etter offer

Når du får offer:

1. Be om 2-3 dager til å vurdere. Aldri aksepter på telefon umiddelbart.
2. Sjekk om du har andre prosesser i gang og ranger dem ærlig.
3. Vurder ikke bare lønn, men også team, prosjekt, vekst-muligheter.
4. Forhandle pakka én gang, ikke iterativt over flere uker.
5. Få det skriftlig før du sier opp eksisterende jobb.

Det vanskeligste er å si nei

Hvis tilbudet ikke føles riktig, lønn er for lavt, eller team-dynamikken kjente seg av i intervjuet, si nei. Senior-utviklere har bedre alternativer enn de fleste, og en feil ansettelse koster deg 1-2 år.

Hold styr på alle parallelle prosesser i en pipeline, så du faktisk vet hva du sammenligner.