Utviklere protesterer mot urealistiske jobbintervjuer. Innrømmer at de googler hele tiden

[KANE2009]

Og det var også poenget mitt, ergo hvorfor jeg syntes det faktisk var et relevant spørsmål og ble lettere irritert når en annen kommer og forteller meg hva jeg kan og ikke kan trekke inn i diskusjonen. Du forklarte det vel egentlig ganske greit i posten din

[Tastaturskriver]

Ikke galt å nevne utdanning. Universitetene bruker jo akkurat samme metode som disse inkompetente intervjuerne. Dette er kanskje litt av grunnen til at mange med mastergrad i IT stryker på en ekte programmeringstest der man har tilgang til hjelpemidler og faktisk skal løse et reelt problem.

Har ikke inntrykk av at "mange med mastergrad i IT" har problemer i en reell jobbsituasjon. Tvert i mot opplever jeg at karakterer gir et ganske klart bilde av hvor godt en kandidat klarer å tilegne seg kunnskap.

[quantum]

 

Ikke galt å nevne utdanning. Universitetene bruker jo akkurat samme metode som disse inkompetente intervjuerne. Dette er kanskje litt av grunnen til at mange med mastergrad i IT stryker på en ekte programmeringstest der man har tilgang til hjelpemidler og faktisk skal løse et reelt problem.

Har ikke inntrykk av at "mange med mastergrad i IT" har problemer i en reell jobbsituasjon. Tvert i mot opplever jeg at karakterer gir et ganske klart bilde av hvor godt en kandidat klarer å tilegne seg kunnskap.

nå stod det ikke "reell jobbsituasjon" men "ekte programmeringstest", noe som da åpenbart ikke kan være et krav for å oppnå en mastergrad...

 

når det gjelder tema her tror jeg slik tavleprogrammering kun kan brukes til å avsløre de som ikke kan et eneste kvekk, eller man kan kvasi-kode algoritmer som man så kan diskutere videre. evt. kan man få en indikasjon på hvor effektivt noenvil klare seg uten noen form for ide til hjelp, men hvor nyttig er dét?

 

kjennskap til rammeverk, arkitektur, verktøy osv. man skal bruke i jobben er mer relevant. og hvis man har god domeneforståelse bør arbeidsgiver absolutt spisse ører.

[Markedsfundamentalisten]

 

Ikke galt å nevne utdanning. Universitetene bruker jo akkurat samme metode som disse inkompetente intervjuerne. Dette er kanskje litt av grunnen til at mange med mastergrad i IT stryker på en ekte programmeringstest der man har tilgang til hjelpemidler og faktisk skal løse et reelt problem.

Har ikke inntrykk av at "mange med mastergrad i IT" har problemer i en reell jobbsituasjon. Tvert i mot opplever jeg at karakterer gir et ganske klart bilde av hvor godt en kandidat klarer å tilegne seg kunnskap.

 

Vel, man kan ha E i alle fag og likevel få en mastergrad. Jeg ser null korrelasjon mellom hvilken grad noen har og hvilken reell kompetanse de har. Rart at arbeidsgivere i det hele tatt ser på papirer. De burde heller

 

1. Se på kode personen har skrevet (da finner man også hvem som er interessert i programmering og siler vekk de som aldri programmerer på fritida)

2. Gi en ekte programmeringstest der det er lov å bruke hjelpemidler

3. Gi et testprosjekt (med betaling) og se hvordan personen er å jobbe sammen med

Endret 5. mars 2017 av Markedsfundamentalisten

[Gavekort]

Moderatormelding

2 innlegg forsvant pga. Off-topic. Tilbakemelding tas på PM

[MegaMann2]

Noe bra, mye rare og drøye forslag her.

 

 

1. Se på kode personen har skrevet (da finner man også hvem som er interessert i programmering og siler vekk de som aldri programmerer på fritida)

Ja, det er ofte positivt med folk som også koder på fritiden og spesielt de som er med i open-source prosjekter, men det er noe drøyt å skulle sile vekk de som aldri programmerer på fritiden.

 

 

2. Gi en ekte programmeringstest der det er lov å bruke hjelpemidler

Jepp, dette er også vanelig og gi mellom intervju nr. 1 og intervju nr. 2.

 

3. Gi et testprosjekt (med betaling) og se hvordan personen er å jobbe sammen med

Også kjent som prøvetid?

[quantum]

 

 

Ikke galt å nevne utdanning. Universitetene bruker jo akkurat samme metode som disse inkompetente intervjuerne. Dette er kanskje litt av grunnen til at mange med mastergrad i IT stryker på en ekte programmeringstest der man har tilgang til hjelpemidler og faktisk skal løse et reelt problem.

Har ikke inntrykk av at "mange med mastergrad i IT" har problemer i en reell jobbsituasjon. Tvert i mot opplever jeg at karakterer gir et ganske klart bilde av hvor godt en kandidat klarer å tilegne seg kunnskap.

Vel, man kan ha E i alle fag og likevel få en mastergrad. Jeg ser null korrelasjon mellom hvilken grad noen har og hvilken reell kompetanse de har. Rart at arbeidsgivere i det hele tatt ser på papirer. De burde heller

 

1. Se på kode personen har skrevet (da finner man også hvem som er interessert i programmering og siler vekk de som aldri programmerer på fritida)

2. Gi en ekte programmeringstest der det er lov å bruke hjelpemidler

3. Gi et testprosjekt (med betaling) og se hvordan personen er å jobbe sammen med

hvorfor skal man programmere på fritida? hvis det ikke er mulighet til å utvikle kompetansen i arbeidstiden; se etter en annen jobb.

[Markedsfundamentalisten]

Noe bra, mye rare og drøye forslag her.

 

 

 

3. Gi et testprosjekt (med betaling) og se hvordan personen er å jobbe sammen med

Også kjent som prøvetid?

 

Problemet er at det i Norge er ganske vanskelig for en arbeidsgiver å si opp noen, selv i prøvetiden. Det er også mye verre for en person å bli sagt enn å bare faile et prøveprosjekt som han gjør på fritida mens han jobber et annet sted.

[K S]

Ærlig talt, så burde programmerere flest klare å skrive bubble sort og insertion sort på ei tavle - forutsatt at de kan selve algoritmen. Egentlig burde programmerere klare å skrive de fleste algoritmer på ei tavle i det språket de er vant med, så lenge de forstår algoritmen i utgangspunktet.

 

Det man googler er det man ikke kan, for eksempel argumentene til en bestemt funksjon. Men algoritmer handler stort sett om å flytte på variabler og sjonglere pekere.

 

"Skrive de fleste algoritmer på ei tavle". Nå har nok verden beveget seg litt for langt framover til at det finnes mennesker som har oversikt over 'de fleste algoritmer '. Enkle algoritmer som bubble sort og quicksort har man knapt bruk for i sitt virke som programvareutvikler, og blir meningsløse å huske...

[Leorand]

Skjønner ingenting, dette er jo formler som de burde kunne...

 

Og husker de ikke ENKLE formler for å hente ut data og standar referanser, så er det noe galt her.

 

Dette skal man jo kunne etter man er ferdig på ntnu... kan man ikke kodinga, så kan man jo ikke forbedre på noe, man ender jo opp med å nermest kopiere en løsning som kansje ikke er optimal for det man skal gjøre... å skjønner man ikke det sikkerhetsmessige i dette, så kan man ende opp med å lage store problemer senere...

 

NÅ må jeg nesten spørre, kan man i dag få seg jobb i store it selskaper uten å kunne det grunnleggende for yrket de søker på... dette er jo store selskaper også, ikke bare It ola normann as som skal lage seg ett enkelt program :x

...tror ikke helt du forstår problemstillingen.  Men jeg kan forsøke å illustrere det med en analogi...

 

Du kan lese og skrive, samt formulere meninger ved hjelp av ord. Med andre ord, du kan kommunisere. Men det er mer enn ett språk, du skal kanskje formidle et budskap på engelsk, spansk, tysk, arabisk og japansk... I dag trenger du ikke lære disse språkene 100%, nettopp fordi du kan google det frem til hvordan du skal formulere enkel budskap.  Men jo mer du jobber med ett av språkene, jo bedre blir du i akkurat det språket. Men hvor god du er i ett språk, sier lite om hvor dyktig du er til å kommunisere... 

 

Programmering blir litt likt dette (selv om jeg også ser mange hull i denne analogien). Selv er jeg ikke anser meg som en programmerer, må ofte løse enkle problemer i flere språk. Og da googler jeg meg ofte frem til syntaks ("skal sortere liste med tall, hvilke innebygde funksjoner kan jeg bruke i dette språket?").

 

Og dette gjelder ikke bare programmering. Det er en hel mengde ting jeg til stadig googler fordi jeg ikke går rundt å husker det.

 

Har selv intervjuet veldig mange teknikere. De dyktigste er de som både forstår de grunnleggende prinsippene og som har en genuin interesse for faget. Hvorvidt de husker alle intrikate detaljer, er uvesentlig. Det viktigste på et intervju er å teste den grunnleggende forståelsen - den man ikke googler seg til, men får gjennom erfaring.

[Leorand]

Etter veldig mange intervjuer, kan jeg ikke se at det er en sammenheng mellom karakterer og reell kunnskap om faget. Dessverre, for det ville gjort ting veldig mye enklere.  Derimot er det veldig stor korrelasjon mellom interesse for faget og kunnskap.

[GOAXT8WU]

Hvem bli utvikler i dag? Meget sterk konkurranse fra lavkostland og krav til oppdatering. Bli heller byråkrat, eller "bestiller" eller en som lever på forretningssiden.

[NightlyDev]

Men én ting er iallfall sikkert - de flinkeste programmererne vet at den beste måten å sortere på er å bruke språkets innebyggede implementasjon av quicksort, og prøver ikke å lage noe selv.

Det er helt feil. Gode utviklere vet at det ikke finnes noen algoritme for sortering som alltid er best - det er sikkert.

[_dundun_]

Jeg satte det på spissen. Poenget er at de flinkeste folka ikke prøver å finne opp hjulet på nytt og vet at 80%-løsninger stort sett er langt bedre enn 100%-løsninger fordi de koster 10% av prisen.

Endret 6. mars 2017 av Audun_K

[VABZJDTR]

Jeg satte det på spissen. Poenget er at de flinkeste folka ikke prøver å finne opp hjulet på nytt og vet at 80%-løsninger stort sett er langt bedre enn 100%-løsninger fordi de koster 10% av prisen.

 

Bingo!

[koffeld]

Hos oss gir vi kandidater en hjemmetest de får ettermiddagen/kvelden på å løse. En helt reell problemstilling en av oss kom over i et kundeprosjekt som er relativt enkel å beskrive men litt kinkig å få løst bra. De bruker selvfølgelig det de trenger av hjelpemidler. Besvarelsen tester vi så mot en referansebesvarelse og måler avvik, kjøretid osv osv. Og sjekker selvfølgelig lesbarheten. Dette mener jeg gir et bra bilde på hvor god den enkelte er til å kode - vi får testet om de faktisk klarer å forstå problemstillingen og fokusere på det som er viktig i oppgaven, vi ser selvfølgelig om de faktisk løser problemet og regner riktig, vi ser om de er effektive nok og levere GOD NOK kode på den tiden de har til rådighet. Når vi lever av å leie ut kompetansen vår på timesbasis må vi vite at kundene våre faktisk får verdi for de midlene de legger igjen hos oss.

 

Spennet på besvarelsene er utrolig stort. Fra pene 100-linjers besvarelser som regner 100%-rett til andre på tusenvis av linjer som knapt kompilerer (selvfølgelig etter å ha bedt om ekstra tid et par ganger). Og vi har mange med gode bakgrunner som har levert besvarelser som ikke regner et eneste case riktig, selv ikke eksempelcasene vi har lagt med.

[Tor Thorbergsen]

Har forsøkt dette, med godt hell. Nøkkelen er å forstå hva du er ute etter. I vårt tilfelle var vi ute etter å avsløre samarbeidsevner, evne til å tåle litt press, tro på egne ferdigheter, og aller sist, at du faktisk er i stand til å programmere litt.

 

Vi gav en enkel oppgave (snu en streng på valgfritt språk), og presiserte at syntaks ikke var viktig, ei heller om resultatet virket perfekt med en gang.

 

Det var svært avslørende. En av kandidatene som omtrent ble avskrevet da han kom inn døren, han var litt kjepphøy, avslørte seg som en virkelig fantastisk utvikler, med noen mindre issues på samarbeidfronten. Han ble ansatt, og jeg kan rapportere at inntrykket stemte 100%.

 

Det er veldig vanskelig å ansette folk. Å bommer du på det kan du omtrent bare legge ned.

Jeg ser at denne metoden har svakheter, men hva er alternativet? Ansette på "magefølelse" og karakterer?

 

Nei, spør om de har noen "skuffeprosjekter", noen hjemmeprosjekter de er sånn litt halvveis med. Det viser interesse for faget, og evne til å følge med fremover. Om de i tillegg har klart å gjennomføre et høyskole/universitetsstudium så vet du at de har evne til å tilegne seg kunnskap også. Da er den siste tingen du trenger pliktfølelse, men det er ikke så vrient å spotte.

[_dundun_]

Jepp. Ingenting er bedre om man vil ha jobb enn å kunne vise til reelle hobbyprosjekter. Folk uten noe som helst på Github stiller med et enormt handicap ift folk som har publiserte prosjekter.

Endret 6. mars 2017 av Audun_K

[quantum]

Jepp. Ingenting er bedre om man vil ha jobb enn å kunne vise til reelle hobbyprosjekter. Folk uten noe som helst på Github stiller med et enormt handicap ift folk som har publiserte prosjekter.

 

 

Den viktigste erfaringen man har - i de fleste tilfeller - er den man har opparbeidet 8 timer hver dag på jobb. Intet i veien for å kode litt på fritida også, men dersom det er et viktig kriterie ville jeg stille meg ganske undrende ... medmindre man mangler arbeidserfaring fordi man er nyutdannet, da. Og så kan det være en grei sak å ta med et prosjekt å vise til på f.eks. andregangsintervju, så man har noe å snakke om. Men bottom line - hvis det forutsettes at man koder på fritida, er det fordi det mangler noe på arbeidsplassen.  

[_dundun_]

Å ansette noen er en stor risk å ta, og referanser kan man ikke nødvendigvis stole på. Å kunne verifisere at en person har interesse for faget samt å kunne se kode personen har laget på eget initiativ uten å kunne skylde på noen andre for evt. svakheter er gull verdt.

 

Det er selvsagt ikke noen forutsetning, men om man har to kandidater som ellers stiller ganske likt der den ene har noe å vise til og den andre ikke er det et veldig enkelt valg å ta. Det kan også gjøre opp for manglende erfaring og svakere karakterer. Heller den ivrige som bidrar på konferanser og open source-prosjekter på fritida enn programmereren som kun gjør det han blir bedt om men som har masse erfaring og knall karakterer.

 

Selvsagt er erfaringa fra jobben den viktigste, men den er det vanskelig å verifisere skikkelig om ikke man har inside-info på personen. Som man forsåvidt ofte har. Om man som arbeidsgiver kjenner en kollega eller tidligere sjef for en person og kan sjekke litt uformelle referanser er det en enorm fordel for søkeren det også (om det man hører er bra, såklart).

Endret 7. mars 2017 av Audun_K