FAQ |
Kalender |
![]() |
#11 | ||
|
|||
Flitig postare
|
Citat:
|
||
![]() |
![]() |
![]() |
#12 | ||
|
|||
Bara ett inlägg till!
|
Citat:
|
||
![]() |
![]() |
![]() |
#13 | ||
|
|||
Medlem
|
De gånger vi anställt folk har vi alltid kört trial-by-fire... Jag skulle inte lita på kod som de lämnar över som de gjort sedan tidigare. Finns inget som övertygar mig om att de är deras egen kod då. Inte för att jag inte litar på folk, men rent generellt finns det på tok för många jeppar...
Vi kör principen att när vi har hittat någon som verkligen verkar intressant så får han/hon köra par-programmering med någon i teamet under en dag. På så sätt märks det ganska snabbt hur personen jobbar och hur den är att jobba tillsammans med vilket är mycket viktigt eftersom det inte är en individuell programmerare man vill ha utan en som passar bra i teamet. När de har klarat av det "testet" så får de ett trail-by-fire-test då de får en svår och komplex uppgift som skall lösas på allt för kort tid för att se hur de agerar under press.... Principen är att uppgiften egentligen inte skall gå att lösa på den tiden som är utstakad. Vår samlade erfarenhet av detta tillvägagångssätt har fallit mycket väl ut i 20 fall av 21. I det fallet då det inte var så lyckat var det inte personen det hängde på utan vår problemställning. Vi gav personen ett problem som personen omdefinierade till ett mycket enklare problem, men som fortfarande uppfyllde de kraven vi hade dokumenterat på det. |
||
![]() |
![]() |
![]() |
#14 | ||
|
|||
Supermoderator
|
Citat:
__________________
Full-stack developer, free for smaller assignments |
||
![]() |
![]() |
![]() |
#15 | |||
|
||||
Flitig postare
|
Citat:
|
|||
![]() |
![]() |
![]() |
#16 | ||
|
|||
Klarade millennium-buggen
|
Vad har programmeraren gjort tidigare, är det en person med många uppdrag bakom sig så bör de kunna lösa problem som de aldrig gjort tidigare.
Man kan ju provanställa som någon mer föreslog och du märker på de två första veckorna hur de funkar med personkemin. Parprogrammering håller jag med om att det är en bra idé att köra med. Men det är viktigt att personen får en fair chans att göra ett bra jobb. Parprogrammering brukar anses som ksotsamt men enligt min egen erfarenhet så gör två personer som fungerar bra ihop tre mans jobb på samma tid. Dessutom är det mer kompetensutvecklande för de enskilda individerna än någon annan arbetsform jag testat (inkluderat lärarledd utbildning). Ett stort problem i alla projekt är kontinuerlig kompetensöverföring mellan individer. Det kan man oftast lösa med just parprogrammering. Dessutom höjs kvaliten och buggar minskar. Är det en nybörjare så kan man aldrig använda stresstest för att testa dem, då måste de ha betydligt längre tid på sig typ 6 månader. Men då är oxo kraven man kan ställa betydligt lägre, det är ju en newbie, alla har varit newbie en gång i tiden. Generellt är stresstester för att testa programmerare väldigt felriktade. En programmerare ska vara en lugn och sansad person som verkligen sätter av tid för att fundera på att ta fram en bra lösning. Det är totalt kontraproduktivt att göra stresstester på den typen av kompetens. Man riskerar tvärtom att få slarvputtar som klarar detta men som inte klarar att lösa komplexa problem. Bättre anser jag det är att använda en kravspec som är realistisk från ett tidigare litet projekt med funktionella krav (dvs verksamhetskrav) och se hur programmeraren lägger upp sitt arbete och hur programmeraren lägger upp en metod för att lösa problemet. En programmerare som självständigt klarar att lägga upp en tillförlitlig metodik för hur han ska lösa ett problem är det sannolikt mycket högre chans att de kan lösa komplexa problem i framtiden. Det är mycket kontraproduktivt att testa befintliga kunskaper i ett specifikt programspråk. Pogramspråken kommer och går, de växlar hela tiden men arbetsmetodiken för att lösa problem är mer generisk och tidlös. Det är viktigt att programmeraren har en analytisk och kreativ inställning (ja det är en paradox) och att man är unlyssnande till beställarens krav. |
||
![]() |
![]() |
![]() |
#17 | ||
|
|||
Mycket flitig postare
|
Att utgå ifrån att alla programmerare har en "portfölj" att visa upp är nog iofs sant. Den programmerare som inte kan visa upp något litet hobbyprojekt har sällan en riktig passion för jobbet. Alla riktigt duktiga utvecklare jag känner kodar på fritiden för att lära sig nya saker. Sedan finns det en hel del hyfsat bra utvecklare som inte har några hobbyprojekt också och även dessa skulle jag anställa.
Dock faller hela "portfölj"-tanken påen annan sak... En duktig utvecklare utvecklas hela tiden. personligen skulle jag (efter mer än 10 år i branchen) inte vilja visa uppden kod jag skrev för ett år sedan. Knappt ens 6 månader sedan. Den koden är inte representativ för hur jag arbetar idag. Därför tror jag ett färskt arbetsprov måste till. Jag håller med om att "trial under fire" som någon skrev ofta säger mer än att lösa en enkeluppgift. Och appropåparprogrammering läste jag någonstans om en amerikan som genomförde sina intervjuer genom att säga "OK, kom och sätt dig bredvid mig så parprogrammerar vi en timme". På så sätt lärde han sig mycket om hur killen tänkte och arbetade samtidigt som han hela tiden kunde styra lösningen i rätt riktning för att verifiera tekniska detaljer. |
||
![]() |
![]() |
![]() |
#18 | ||
|
|||
Klarade millennium-buggen
|
Citat:
Jag har i alla mina kundavtal en klausul om NDA så jag kan aldrig visa upp kundkod för en ny kund. Nya kunder får ta mitt ord på att jag kan lösa problem. Kunden kan ju alltid avsluta kontraktet när de vill i alla fall så det är inget problem i realitetetn. Den kod jag skriver är ju helt och hållet individuellt anpassad efter varje specifik kunds önskemål, ofta har de krav på att man ska följa en mall de använt sedan tidigare och det har hittils aldrig hänt att det har varit "den ultimata koden" utan det har ofta varit snabbhack som gjorts av personer som testar-hur-det-funkar, trist men så är det oftast. Det skulle mao ord vara totalt missvisande att visa upp denna typ av kod för en ny kund. Jag gör ju oxo så att jag alltid anpassar mitt arbetssätt till det projekt jag jobbar med. Även då blir gamla arbetsprov totalt missvisande. Jag kan omöjligt i förväg veta vilken kodningsstandard som används hos varje enskild kund. Det finns inga generella kodningsregler som används fullt ut hos någon kund eller arbetsgivare jag någonsin jobbat med. Alla kodare utvecklas ju mer man kodar och jag skulle inte heller anse att kod jag skrev för ens 6 månader sedan representerar hur jag skriver koden idag, det kommer alltid nya influenser som är bättre än det man gjort tidigare. Ju mer man programmerar/parprogrammerar desto snabbare ökar takten på stegvis förfining. |
||
![]() |
![]() |
![]() |
#19 | |||
|
||||
Mycket flitig postare
|
Är det inte det man har provanställning till?
|
|||
![]() |
![]() |
![]() |
#20 | ||
|
|||
Medlem
|
Citat:
Således får jag ut den där utvecklningsbiten på arbetet och känner att jag inte vill sitta framför datorn 24/7 som vissa andra gör, ett liv bortom datorn är inte en så dum grej. På så vis orkar jag koncentera mig bra mycket bättre på arbetstid. Man blir ju less på saker och ting ifall man kontinuerligt gör det. |
||
![]() |
![]() |
Svara |
|
|