Jobbintervju innen IT. Hva kan jeg forvente?

14. mars 2018

Hei!

Jeg er til sommeren ferdig utdannet med en Bachelor innen Informatikk, og jeg har for en stund siden begynt å søke på jobber. Dette er første gang jeg skal inn på intervjuer innenfor IT-bransjen, og jeg lurer dermed på hva jeg kan forvente meg, sammenlignet med det man kanskje er vant med innen andre yrker.

Jeg har en del erfaring med programmering gjennom studiene mine, men jeg er ikke "super". Det jeg er mest nervøs for er at jeg har hørt at man ofte på intervjuer kan få beskjed om å kode noe. Og det er her jeg tenker at jeg kan komme til å slite litt...

Så derfor håper jeg at det finnes noen innen utviklerbransjen som kan kaste litt lys på hva jeg kan forvente meg, og hva jeg kan gjøre for å forberede meg.

Freddy_fred5

I failed unit tests

5.209 1.014

14. mars 2018

Om du er skremt for sånne små tasks du kan bli bedt om å gjøre ville jeg anbefalt deg å begynne med "daily programming challenges" (eg. På reddit.) God trening generelt, men ikke ille for sånne ting

Markonan

Mattoholiker

130 49

14. mars 2018

Her er det stor forskjell på en frontend gui master og en dev.ops backend hardcore hacker. Hvilke jobber søker du på ? ^^

Strangerest

Trådstarter

2 0

14. mars 2018

Ah, beklager. Er snakk om systemutvikler- og konsulentstillinger innen .NET i hovedsak. Klar over at konsulentstillingene nok er litt over mitt nivå, men søker på det som virker interessant.

dggr

970 258

14. mars 2018

Ofte første intervju er mest for å sjekke at du er en person de kan tenke å ansette. Dvs du passer som type til stillingen de søker folk til, og til selskapet generelt.
Mer teknisk blir det kanskje hvis du går videre, har ikke opplevd ofte å måtte kode noe på intervju. Oftere det å beskrive hvordan jeg ville gått fram for å løse en problem.

Moff

Limited edition

1.201 950

14. mars 2018

Ingen jeg kjenner har blitt bedt om å programmere noe på intervju. Det virker for meg litt useriøst fordi intervjuet er en veldig stressende situasjon, og ingen klarer å yte sitt beste der. Det er ingen god målestokk for hva man kan og ikke kan gjøre. Kanskje det kan brukes for å se om du for eksempel bruker LINQ eller ikke og hvordan du strukturerer ting.

Mitt beste tips er å lære deg "buzzwords". Du vil bli spurt om hva du kan om X og hva du foretrekker av A og B. Det er veldig kjipt om de bruker ett eller annet uttrykk som du ikke er kjent med. Det er selvsagt lov å spørre, men du bør i alle fall kunne mesteparten av utrykkene som man bruker innenfor området ditt. Det kan være navn på rammeverk, navn på tankemåter, navn på programmeringsspråk, programmer, navn på produsenter av hardware og så videre og videre.

Hvilke ord og uttrykk som er relevant er selvsagt helt avhengig av hva slags type jobb dette er. Det forrige intervjuet jeg var på dreide seg om fullstack-utvikling i C# på Windows (IIS), og da er det mange rammeverk og metoder som er veldig spesifikke for denne platformen, som det er kjekt å ha et forhold til. Jeg fikk også sjansen til å vise frem noe tidligere arbeid som jeg hadde publisert på nett, men det er sjelden at en slik sjanse byr seg i en intervjusituasjon (men kanskje du kan forbrede noe just in case?).

Bea

Big Bad Wolf

311 120

14. mars 2018

De fleste jobber jeg har intervjuet for har hatt en kode-del, gjerne som runde to eller tre av intervjuer. Det varierer veldig hvordan disse blir utført, men kan gjerne være at du blir satt ved en PC og får 1-2 timer på å løse en del oppgaver.

Som nevnt tidligere er det ikke nødvendigvis den beste måte å finne ut hva du kan, og du må ikke nødvendigvis svare "riktig" på alle spørsmål. Det viktigste er å vise hvordan du tenker, og at du ikke er helt på jordet når det kommer til programmering. Du får også ofte mulighet til å diskutere koden din, og dette er en veldig god mulighet til å forklare hvorfor du gjorde det slik du gjorde, og forklare tankegangen din.

random105675

Gjest

n/a 0

14. mars 2018

En systemutvikler som er nervøs for å skrive kode?

Om de spør deg om det så er det ikke for å se på kvaliteten på arbeidet ditt men hvordan du presterer under press. Det er litt som vandrehistoriene hvor man blir bedt om å regne ut hvor mange 10-kroninger man må stable for å nå opp til etasjen man sitter på.
Poenget er ikke at svaret skal være riktig men om du i det hele tatt prøver.

Dyret

1.914 1.750

14. mars 2018

På jobben jeg har nå, som var myntet på en direkte fra universitetet, så var intervjuet på ca. 2-3 timer. Mye av det var for meg å fortelle om meg og mine ferdigheter, og for bedriften å introdusere sine visjoner og verdier, men det var også en kodesesjon på rundt en time. Dette var svært uformelt, og ikke noe som skulle kompileres eller noe sånt. "Skriv en funksjon som reverserer en tekst-streng." etterfulgt av "Kan du modifisere den til å ikke bruke ekstra minne?". Alt i form av pseudokode på whiteboard, og tankeprosessen din er alfa og omega. Svært enkle oppgaver, som hvem som helst som kan programmere burde kunne løse under press.

Skal sies at i etterkant har vi omstrukturert prosessen litt, slik at det er mer oppdelt. Screening først, så sjekking av referanser og telefonintervju, før vi holder et teknisk intervju. Dette kan også gjøres over Internett i form av par-programmering eller via en slags "hjemmelekse" med forholdsvis lang frist.

Det er dessverre veldig mange som ikke kan å kode i det hele tatt som søker jobber som programmerere, og disse kaster bort ganske mye tid for bedriftene. Hvis du søker deg inn et sted hvor de forventer programmeringserfaring, så vil jeg si at det er svært sannsynlig for at du blir "utsatt" for noe slikt som FizzBuzz. Men for de som ikke forventer så mye erfaring, så kan det hende de heller spør deg mer om teoretiske ting relatert til studiet ditt.

Xasma

dumstein

2.156 2.023

14. mars 2018

Samtlige intervjuer jeg har hatt, har inneholdt en eller flere kodedeler. Har gjerne fått servert et stykke kode på papir som er både ineffektiv og på randen til uleselig(tenk variabelnavn som v1, v2, l1, l2 osv). Deretter skal jeg forklare hva koden gjør, for så å gjøre den både mer leselig og effektiv, mens jeg hele tiden forklarer hva jeg tenker og hvorfor, så de får et innblikk i min angrepsmetode på problemer. Har også hatt et intervju hvor jeg fikk en problemstilling med ca. 5 problemer, hvor jeg skulle løse flest mulig på 75 minutter, hvor hvert problem gjorde koden mer kompleks. Så jeg kunne f.eks fint løse problem 1 og 2 raskt, men da ble koden lite fleksibel for problem 3, 4 og 5, så man måtte planlegge koden og disponere tiden godt.

Har også typisk vært deler av intervjuet der man snakker om arbeidserfaring, hva man lærte ved å jobbe der og fritidsinteresser. Der ser de gjerne etter noen som passer inn i bedriftskulturen, og man har ingen rette eller gale svar; enten så passer man inn, eller så gjør man ikke.

Om du ikke er så vant til intervjuer og prosessene rundt, kan det være lurt å se på det hele som øvelse til intervjuet for drømmejobben. Gjør så godt du kan, men ikke forvent jobben, og skriv ned hva som ble spurt om, og hvordan du gjorde det. Om du får avslag, spør gjerne om hva de følte at du kom til kort på, slik at du blir klar over egne feil og kan forbedre til neste gang. HR-folkene har ikke alltid rett, men de er overraskende like, så du kan lære veldig mye av et intervju for en jobb du ikke fikk.

nso

popålol

Administrator

6.157 5.582

14. mars 2018

Sitat av Dyret

Det er dessverre veldig mange som ikke kan å kode i det hele tatt som søker jobber som programmerere, og disse kaster bort ganske mye tid for bedriftene. Hvis du søker deg inn et sted hvor de forventer programmeringserfaring, så vil jeg si at det er svært sannsynlig for at du blir "utsatt" for noe slikt som FizzBuzz. Men for de som ikke forventer så mye erfaring, så kan det hende de heller spør deg mer om teoretiske ting relatert til studiet ditt.

Vis hele sitatet...

Intervjuet en gang en kar til å hjelpe oss å designe, sette opp og drifte et datasenter for noen tusen servere. Etter mye frem og tilbake viste det seg at erfaringen hans kunne summeres opp til "er veldig glad i dataspill, kan ingenting om nettverk og servere og slik men er veldig villig til å lære".

Det var dagen jeg innså at pre-screening er viktig. 3 arbeidere * ~halv dag sløst bort.

On topic så begynner jeg om noen uker hyringsprosessen for utviklere til å hjelpe meg med produktet jeg lager. Tror det eneste jeg gjør av kodetest blir å skrive noen simple algoritmer for å screene ut over-engineers. Mye fordi jeg ikke syntes man kan ekstrapulere alt for mye ut av testene, og litt fordi jeg sikkert hadde strøket på en slik test selv. Kodetest frafaller dog hvis de har tidligere arbeid å vise til.

Jeg er mer interessert i å se tidligere arbeid hvis tilgjengelig, og å kjøre en åpen diskusjon hvor jeg ber dem forklare meg litt om koden. Hvis ikke tilgjengelig (proprietært tidligere arbeid) så blir det å vise kodesnutter eller design patterns fra mitt system og å kjøre lignende diskusjon om dem. Man merker raskt hvem som har kontroll på hva de snakker om og hvem som brenner for faget.

Viktigste for meg blir å luke vekk dem som over-engineer ting og de som ikke har evne til å se det store bildet i det man bygger samtidig som man bygger på smådelene.

Det er kanskje litt enklere å lete etter senior full-stack developers siden man raskt oppdager om man snakker med noen som forstår hva de snakker om fra tak til bunn vs. de som bare har jokket litt rundt i PHP.

Sist endret av nso; 14. mars 2018 kl. 19:33.

robhol

NOOOOOOOOOOOOOOOOOO-

6.424 5.658

15. mars 2018

På alle intervjuer jeg har hatt, har jeg blitt bedt om å gjøre noe koderelatert. I mitt tilfelle har det meste av dette vært "hjemmelekser", dvs. små oppgaver man bruker litt tid på hjemme, og så kan snakke om på intervjuet. Det er sjelden første intervju, men kan bli et tema på andre.

Et eksempel på oppgaver jeg har fått er noe liknende å lage en klasse som representerer en heisvogn, å refaktorisere en "brusautomat" og gjøre koden bedre, å lage en datamodell, populere den med gitt data og gjøre noe enkel behandling på denne, osv.

Det er sjelden ekstremt kompliserte greier - øv deg på å løse småoppgaver og du klarer deg helt fint.

PS: kan anbefale ting som å sjekke ut http://codewars.com, http://adventofcode.com (oppgavene er tilgjengelige selv om det ikke er jul

) og https://www.reddit.com/r/dailyprogrammer/

Sist endret av robhol; 15. mars 2018 kl. 12:28.

Ozma

55535 HP

3.680 1.125

15. mars 2018

Helt anekdotisk så jeg fikk ingen kodespørsmål i intervjuene til jobben min (IT-konsulent, nyutdannet fra NTNU, gjennomsnittlige karakterer).

Konsulentbransjen ansetter som bare det, så bare søk på alle jobbene du finner. At de krever at du har mastergrad er ofte bullshit. For den rette søkeren nøyer de seg med en bachelor, spesielt om du kan Java/C# og JavaScript.

Synderen

sindre@puse.cat:~$

1.097 396

15. mars 2018

Fikk heller ikke noen kodespørsmål under intervju, men det ene sted der jeg fikk et tilbud så ble jeg spurt om å presentere et privat prosjekt. Hadde heller ingen erfaring med språket som ble hovedsaklig brukte i det firmaet, så ikke la vær å søke på en jobb bare fordi du ikke er kjent med språket de bruker. De ser gjerne litt igjennom øynene på det når man kommer rett fra skolen.