mboost-dp1
Svingdørsansættelser i it-branchen
Det skal nok passe er et problem, vi har haft stor succes med at bede folk om at sende et kodeeksempel som er de er stolt af og så tage den derfra.
Og så kører vi efter en tese om gruppedynamik, så tekniske egenskaber bliver oplært, det vigtigste er at gruppen funger med den nye type person.
Og så kører vi efter en tese om gruppedynamik, så tekniske egenskaber bliver oplært, det vigtigste er at gruppen funger med den nye type person.
Kodeeksempler er en god procedure. Ikke blot fordi det hjælper arbejdsgiveren, men det giver også udvikleren en måde at præsentere sig selv på en teknisk måde, hvilket for de gode udviklere, føles rigtig godt.
Mine GitHub og Stack Overflow accounts er også på første side af mit CV, da jeg anser det som en vigtig detalje.
Problemet er bare den typiske tilgang til ansættelser i Danmark. Man kigger for meget på personen, og for lidt på de tekniske kompetancer.
Men på den anden side, er det jo også svært at lave et præcist CV som programmør.
Jeg kunne f.eks. skrive jeg kan kode i Ruby og Python. Fordi jeg kan forstå koden, og i løbet af 2 uger blive up2speed med sproget. Men jeg ville ikke være ekspert fra dag 1.
Ligeledes kan man have godt kendskab til en teknologi specifik ting, men hvis man ikke bruger den i hverdagen, hvad skriver man så? Jeg er WPF programmør til dagligt, og Windows Phone er min hobby. Begge dele er XAML, men det ved HR afdelingen sku ikke.
Jeg skriver også jeg har kendskab til Extreme Programming og SCRUM, fordi jeg har arbejdet med begge på mit studie, og været til konferencer sessioner om emnet (JAOO/GOTO i Århus). Men jeg har aldrig brugt det i praksis. Fordi mange virksomheder som "bruger" SCRUM, gør det jo alligevel ikke.
Sådanne tekniske problemstillinger gør jo at et CV for en softwareudvikler vel er mere kompliceret end en gadefejer.
Og derfor er det jo nok svært at præcisere sit CV. Enten skriver man for lidt, eller for meget.
... og intet af overstående er garenti for at folk faktisk kan kode.
Jeg har ihvertfald rettet nok legacy code i min tid, til at kunne konkludere at nogen folk ikke er blevet ansat med de rigtige kvalifikationer.
Mine GitHub og Stack Overflow accounts er også på første side af mit CV, da jeg anser det som en vigtig detalje.
Problemet er bare den typiske tilgang til ansættelser i Danmark. Man kigger for meget på personen, og for lidt på de tekniske kompetancer.
Men på den anden side, er det jo også svært at lave et præcist CV som programmør.
Jeg kunne f.eks. skrive jeg kan kode i Ruby og Python. Fordi jeg kan forstå koden, og i løbet af 2 uger blive up2speed med sproget. Men jeg ville ikke være ekspert fra dag 1.
Ligeledes kan man have godt kendskab til en teknologi specifik ting, men hvis man ikke bruger den i hverdagen, hvad skriver man så? Jeg er WPF programmør til dagligt, og Windows Phone er min hobby. Begge dele er XAML, men det ved HR afdelingen sku ikke.
Jeg skriver også jeg har kendskab til Extreme Programming og SCRUM, fordi jeg har arbejdet med begge på mit studie, og været til konferencer sessioner om emnet (JAOO/GOTO i Århus). Men jeg har aldrig brugt det i praksis. Fordi mange virksomheder som "bruger" SCRUM, gør det jo alligevel ikke.
Sådanne tekniske problemstillinger gør jo at et CV for en softwareudvikler vel er mere kompliceret end en gadefejer.
Og derfor er det jo nok svært at præcisere sit CV. Enten skriver man for lidt, eller for meget.
... og intet af overstående er garenti for at folk faktisk kan kode.
Jeg har ihvertfald rettet nok legacy code i min tid, til at kunne konkludere at nogen folk ikke er blevet ansat med de rigtige kvalifikationer.
Jeg har selv oplevet meget stor variation i hvor meget vægt der lægges på faglig kunnen i jobsamtaler. I den ene ende af spektret er der virksomheder hvor jeg har været til samtale, og da jeg et stykke inde i anden samtale med virksomheden bliver spurgt om jeg selv har nogen spørgsmål er mit eneste spørgsmål hvorfor jeg endnu ikke er blevet stillet spørgsmål omkring mine faglige evner.
I den anden ende af spektret har vi Google, hvor jeg var gennem syv samtaler af hver 45 minutters varighed, som bestod af ca. 95% faglige spørgsmål.
Det vil sige at jeg ville være noget mere begrænset i mit udvalg. Hvis jeg skulle finde kode som jeg stadig havde adgang til, og som ikke var fortrolig, ville det måske ikke være et stykke kode der var lagt lige så stor indsats i, og dermed kunne det måske ikke være på højde med det bedste jeg havde udviklet.
Hvis man ikke har mulighed for at vælge et stykke kode fra et tidligere ansættelsesforhold er man måske nødt til at vælge noget man har udviklet for sig selv. Hvis det er noget man har udviklet for sig selv har det næppe været gennem et peer review. Og min erfaring siger mig, at kode der har været gennem et peer review er af væsentligt bedre kvalitet end kode der ikke har. Det tror jeg gør sig gældende uanset hvem der har skrevet det, og hvem der har reviewet det.
I den anden ende af spektret har vi Google, hvor jeg var gennem syv samtaler af hver 45 minutters varighed, som bestod af ca. 95% faglige spørgsmål.
Det ville jeg have et problem med. Noget af den kode jeg er mest stolt af udviklede jeg for en tidligere arbejdsgiver og har derfor ikke længere adgang til. Og selv hvis jeg stadigvæk arbejdede der, ville det være i strid med min kontrakt at udlevere det.lorenzen (2) skrev:vi har haft stor succes med at bede folk om at sende et kodeeksempel som er de er stolt af og så tage den derfra.
Det vil sige at jeg ville være noget mere begrænset i mit udvalg. Hvis jeg skulle finde kode som jeg stadig havde adgang til, og som ikke var fortrolig, ville det måske ikke være et stykke kode der var lagt lige så stor indsats i, og dermed kunne det måske ikke være på højde med det bedste jeg havde udviklet.
Hvis man ikke har mulighed for at vælge et stykke kode fra et tidligere ansættelsesforhold er man måske nødt til at vælge noget man har udviklet for sig selv. Hvis det er noget man har udviklet for sig selv har det næppe været gennem et peer review. Og min erfaring siger mig, at kode der har været gennem et peer review er af væsentligt bedre kvalitet end kode der ikke har. Det tror jeg gør sig gældende uanset hvem der har skrevet det, og hvem der har reviewet det.
#4
Hvis man ikke har noget at udlevere, så har man jo ikke noget at udlevere. Men jeg tror nu også du overfortolker lidt, du må meget gerne komme med noget kode som ikke er perfekt og hellere end gerne noget der har været reviewet, ideen at vi tager noget kode med en hvis kvalitet og så en snak udfra.
Vi havde en kandidat som havde et kodeeksempel han ikke selv havde lavet, men tilgengæld havde han en holdning til mange af tingene og udfra det kan man have en god dialog omkring arbejdsmetoder, fokusområder og stilarter.
Det er absolut ikke det eneste værktøj vi bruger til at vurdere folk på, men det er en god måde at få folk til rent faktisk at snakke om deres håndværk og ikke bare få dem til at sige alt det rigtige.
Hvis man ikke har noget at udlevere, så har man jo ikke noget at udlevere. Men jeg tror nu også du overfortolker lidt, du må meget gerne komme med noget kode som ikke er perfekt og hellere end gerne noget der har været reviewet, ideen at vi tager noget kode med en hvis kvalitet og så en snak udfra.
Vi havde en kandidat som havde et kodeeksempel han ikke selv havde lavet, men tilgengæld havde han en holdning til mange af tingene og udfra det kan man have en god dialog omkring arbejdsmetoder, fokusområder og stilarter.
Det er absolut ikke det eneste værktøj vi bruger til at vurdere folk på, men det er en god måde at få folk til rent faktisk at snakke om deres håndværk og ikke bare få dem til at sige alt det rigtige.
I stil med #5.
Selv hvis det er noget kode af en lavere kvalitet, grundet manglen på peer-review, så kan du jo stadig tage noget gammel kode med, og tale om hvad du ville have gjort anderledes i dag. Det er jo et miljø som udvikler sig med store skridt. Ting bliver hele tiden gjort nemmere og sikrere.
Og hvis der er kodere til stede ved samtalen, så kan man hurtigt få en konstruktiv dialog igang.
Jeg ville næsten hellere kunne argumentere for en ny og bedre måde at udføre en gammel hobby/solo-opgave på, end jeg ville fremvise et stykke peer-reviewed kode.
Selv hvis det er noget kode af en lavere kvalitet, grundet manglen på peer-review, så kan du jo stadig tage noget gammel kode med, og tale om hvad du ville have gjort anderledes i dag. Det er jo et miljø som udvikler sig med store skridt. Ting bliver hele tiden gjort nemmere og sikrere.
Og hvis der er kodere til stede ved samtalen, så kan man hurtigt få en konstruktiv dialog igang.
Jeg ville næsten hellere kunne argumentere for en ny og bedre måde at udføre en gammel hobby/solo-opgave på, end jeg ville fremvise et stykke peer-reviewed kode.
#kode til job samtale
Jeg har et lidt ambivalent forhold til det.
Det er helt klart relevant til en job samtale at få klarlagt de faktiske tekniske kompetancer. Flinke mennesker der ikke rigtigt kan noget duer ikke. Et projekt har til formål at producere software ikke hygge.
Og papir/email er taknemligt - hvem som helst kan skrive at de er ekspert i XYZ. Det er ikke ualmindeligt for virksomheder efter ansættelse at opdage at det halve CV var løgn. Og det skal naturligvis afsløres til job samtale.
Og diskussion af små kode eksempler kan sagtens indgå i dette. Men der er et par små detaljer man skal være opmærksom på.
Der er forskel på små kode stumper som gør noget i sig selv i demo kvalitet og små kode stumper som passer ind i et stort system i produktions kvalitet. Evnerne til at producere de to er ikke uafhængige men er heller ikke ikke identiske. Og med stor sandsynlighed skal firmaet bruge det sidste mens ansøgeren kun kan vise det første.
Der er også stor forskel op hvilken type job man skal besætte. Er det en nyuddannet/junior udvikler, så kan dte jo være helt fint at checke vedkommendes evne til at skrive kode i sprog XYZ. Men er det en erfaren/senior udvikler er evnen til at skrive kode i sprog XYZ en ret lille del af de kvalifikationer man ønsker. Nytteværdien af at diskutere kode er faldende med det erfaringsniveau man søger efter.
Jeg har et lidt ambivalent forhold til det.
Det er helt klart relevant til en job samtale at få klarlagt de faktiske tekniske kompetancer. Flinke mennesker der ikke rigtigt kan noget duer ikke. Et projekt har til formål at producere software ikke hygge.
Og papir/email er taknemligt - hvem som helst kan skrive at de er ekspert i XYZ. Det er ikke ualmindeligt for virksomheder efter ansættelse at opdage at det halve CV var løgn. Og det skal naturligvis afsløres til job samtale.
Og diskussion af små kode eksempler kan sagtens indgå i dette. Men der er et par små detaljer man skal være opmærksom på.
Der er forskel på små kode stumper som gør noget i sig selv i demo kvalitet og små kode stumper som passer ind i et stort system i produktions kvalitet. Evnerne til at producere de to er ikke uafhængige men er heller ikke ikke identiske. Og med stor sandsynlighed skal firmaet bruge det sidste mens ansøgeren kun kan vise det første.
Der er også stor forskel op hvilken type job man skal besætte. Er det en nyuddannet/junior udvikler, så kan dte jo være helt fint at checke vedkommendes evne til at skrive kode i sprog XYZ. Men er det en erfaren/senior udvikler er evnen til at skrive kode i sprog XYZ en ret lille del af de kvalifikationer man ønsker. Nytteværdien af at diskutere kode er faldende med det erfaringsniveau man søger efter.
Det kan man ikke være uenig i, men jeg vil sige at evnen til at producere kode til hver af de to er så kraftigt korreleret at hvis man kan måle om en ansøger kan producere et lille stykke kode til at løse en specifik opgave, så er det en væsentlig indikation af om de er velegnet til jobbet.arne_v (7) skrev:Der er forskel på små kode stumper som gør noget i sig selv i demo kvalitet og små kode stumper som passer ind i et stort system i produktions kvalitet. Evnerne til at producere de to er ikke uafhængige men er heller ikke ikke identiske. Og med stor sandsynlighed skal firmaet bruge det sidste mens ansøgeren kun kan vise det første.
Det er ikke en perfekt indikation, men den er bedre end de fleste andre indikatorer man kunne kigge på. Selvfølgelig skal man kigge på mange indikatorer, tilsammen give de et bedre billede end de ville hver for sig.
På hvilken side har du da siddet?arne_v (8) skrev:Jeg har iøvrigt aldrig selv måttet vise eller diskuteret kode når jeg har været til til job samtale.
Personligt har jeg nok været til omkring 20 samtaler hvor jeg selv var jobsøgende, til gengæld har jeg haft over 100 samtaler, hvor jeg sad på den anden side og skulle vurdere ansøgeres evner.
Jeg er aldrig blevet bedt om at vise kode jeg selv har skrevet tidligere. Og når jeg selv har interviewet ansøgere har jeg heller aldrig set kode de har skrevet tidligere. Nogle af dem har dog været ophavsmænd til opensource software, som jeg kunne have kigget på. Men de tilfælde hvor jeg har haft kendskab til opensource software som ansøgeren har skrevet, har det har det dog ikke været relevant for mig at kigge på det.
Hvad jeg til gengæld har oplevet til en samtale er at blive præsenteret for et stykke kode og skulle forholde mig til det. Jeg har også selv prøvet at præsentere ansøgere for et stykke kode og bedt dem forholde sig til det. Det var ikke kode fra et faktisk system, men blot små stykker beregnet til brug i samtalerne. Og det kan være meget afslørende.
Hvad jeg også mange gange har prøvet er at bede en ansøger om at skrive kode til at løse en specifik opgave. Ansøgeren har fået en meget løst specificeret opgave. Det har så været ansøgerens eget ansvar at tage stilling til hvad der ville være en god løsning på de punkter der ikke var præciseret i specifikationen. Og de har fra start fået at vide at de skal kunne skrive koden på 30 minutter.
Nogle ansøgere bryder sig ikke om den løse specifikation. Disse ansøgere spørger indtil præcist hvad der kræves, og kan ikke forholde sig til at de får lov til selv at træffe et valg, som de naturligvis efterfølgende får lov til at argumentere for.
Andre ansøgere ser straks at de med et meget simpelt stykke kode kan opfylde kravspecifikationen. Nogle indser at en løsning der kun lige netop opfylder den kravspecifikation jeg har givet dem aldrig vil virke i praksis, andre skal have en del ledende spørgsmål før de indser det.
De bedste kandidater starter med at skitsere forskellige løsningsmuligheder og kan vurdere hvor god en løsning de kan nå at producere indenfor tidsrammen.
Men det er svært at skrive et interessant stykke kode indenfor den tid man har til en samtale. Nogen gange kan det være bedre at enten give ansøgeren en fuldstændig firkantet formulering af hvordan opgaven skal løses og så lade dem skrive koden, eller give dem en løs beskrivelse af et problem og lade dem selv udtænke en algoritme. Man skal bare være opmærksom på hvad det er for evner man har testet, og hvad det er man er gået udenom.
Men tidligere kollegaer har som regel en langt bedre vurdering af en persons evner end man nogensinde kan danne sig ved en samtale. Derfor er referencer også relevante. Det største problem med referencer er nok muligheden for interessekonflikter.
Jeg havde ikke hørt den specifikke opgave før.Windcape (10) skrev:Jeg skrev en fizzbuzz til mit tekniske interview :p
Min første tanke er at hvis man "spilder" tid på et så simpelt spørgsmål, så har man ikke tid til de mere interessante spørgsmål. På den anden side, hvis det kan skrives hurtigt nok er det ikke ret meget tid man har spildt, og hvis det tager for lang tid, så har man allerede en idé om at det nok ikke er den ansøger man skal ansætte.
Så jeg prøvede hvor lang tid det tog for mig selv at skrive koden til at løse den opgave. Det tog mig 3 minutter og 7 sekunder at skrive koden på et stykke papir, og bagefter tastede jeg den ind for at checke om jeg havde gjort det korrekt.
Desværre kommer der nok til at gå lang tid før jeg får lejlighed til at afprøve spørgsmålet i praksis.
Det var mest for sjov, tror jeg.kasperd (11) skrev:Min første tanke er at hvis man "spilder" tid på et så simpelt spørgsmål, så har man ikke tid til de mere interessante spørgsmål.
Der var mere teknisk kode først (som handlede mere om API design).
Når man har løst den før (hvilket jeg havde), tager det ikke mange sekunder at løse den.kasperd (11) skrev:Det tog mig 3 minutter og 7 sekunder at skrive koden på et stykke papir,
Modolus er et glemt begreb i den danske folkeskole :o
Jeg havde ikke løst den før. De tog mig kun ganske få sekunder at udtænke en løsning. Resten af tiden gik med at skrive den ned.Windcape (12) skrev:Når man har løst den før (hvilket jeg havde), tager det ikke mange sekunder at løse den.
Det er det vist. Det var min mor der lærte mig om begrebet. Det har vist været da jeg gik i 5. klasse. Jeg kom til at stifte mere bekendtskab med det, da jeg begyndte at programmere. Hvis ikke jeg havde deltaget i Georg Mohr seminariet da jeg gik i gymnasiet tror jeg ikke jeg ville være stødt på det i undervisningssystemet før jeg kom på universitetet.Windcape (12) skrev:Modolus er et glemt begreb i den danske folkeskole
Windcape (12) skrev:Modolus er et glemt begreb i den danske folkeskole :o
Hvis jeg lige tager matematik-flueknepper-hatten på et øjeblik, kan jeg lige indskyde at du nok mener restmodulus i stedet for modulus. Indrømmet, begerberne er tæt beslægtede, så det er ikke så mærkeligt, at alle i programmeringsverdenen kalder restmodulus for modulus. :-)
kasperd (9) skrev:Det kan man ikke være uenig i, men jeg vil sige at evnen til at producere kode til hver af de to er så kraftigt korreleret at hvis man kan måle om en ansøger kan producere et lille stykke kode til at løse en specifik opgave, så er det en væsentlig indikation af om de er velegnet til jobbet.
kasperd (9) skrev:Det er ikke en perfekt indikation, men den er bedre end de fleste andre indikatorer man kunne kigge på. Selvfølgelig skal man kigge på mange indikatorer, tilsammen give de et bedre billede end de ville hver for sig.
Problemet er "jeg ved bedst - det er forkert at bruge XYZ - jeg omskriver det hele til ZYX" typerne.
Deres eget lille standalone projekt ser sikkert perfekt ud.
Men lukket ind i et stort projekt kan det blive en katastrofe.
Jeg er aldrig rendt ind i individer af den type. Men det hjælper måske også at jeg det meste af min karriere har arbejdet i en virksomhed med så omfattende jobsamtaler, at alvorlige tilfælde vil blive opdaget før de bliver ansat. Det har nok også hjulpet at tingene har været sat i system, og der har været interne retningslinier som i mange tilfælde dokumenterer hvordan ting skal gøres, men frem for alt har det hjulpet at der har været kodereview på alt. Krav om kodereview kræver at man som minimum skal kunne overbevise en anden person om at den ændring man er ved at lave tjener et formål.arne_v (17) skrev:Problemet er "jeg ved bedst - det er forkert at bruge XYZ - jeg omskriver det hele til ZYX" typerne.
Hvor jeg ikke har oplevet individer med ovenstående problem har jeg oplevet at arbejde sammen med et team der i fællesskab var i stand til at udvise den adfærd du beskriver. Vi havde et system der var blevet for stort til at driften kunne varetages fra en tidszone, så der blev samlet et nyt team i en anden tidszone, som skulle hjælpe med driften. Det nye team bestod til dels af eksisterende medarbejdere, der flyttede fra andre funktioner til vores projekt og til dels af nyansatte.
Det nye team ville straks have lavet ting om allerede før de havde sat sig ind i det system de skulle til at arbejde med. De fik gennemtrumfet en meningsløs ændring som senere måtte ændres tilbage. I teorien burde denne ændring intet have gjort, men i praksis gjorde den systemet ustabilt.
#18
Den slags typer findes der relativt mange af blandt nyuddannede.
Check bl.a. skråsikkerheden hos flere newz.dk brugere som indicie.
Code review bør fange det, men det er meget sent.
Design review kan fange det tidligere.
Men det er stadigvæk bedre at undgå problemet end at fange det.
En vis portion ydmyghed er en god ballast for nyuddannede udviklere.
Selvom noget ved første blik virker forkert, så kan der jo godt være en grund til at det er sådan.
Den slags typer findes der relativt mange af blandt nyuddannede.
Check bl.a. skråsikkerheden hos flere newz.dk brugere som indicie.
Code review bør fange det, men det er meget sent.
Design review kan fange det tidligere.
Men det er stadigvæk bedre at undgå problemet end at fange det.
En vis portion ydmyghed er en god ballast for nyuddannede udviklere.
Selvom noget ved første blik virker forkert, så kan der jo godt være en grund til at det er sådan.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund