Häromveckan gjorde jag ett programmeringstest på nätet. Visste inte vad jag skulle förvänta mig och det var ett tag sedan jag jobbade med Java. Efter lite strul med syntaxen löste det sig någorlunda. Det som jag tyckte var lite roligt var att det fick mig att tänka på många utmaningar som ett utvecklingsprojekt står inför.
Tiden man har på sig för denna demotest är 30 minuter och klockan tickar utan möjlighet att pausa. Känns som ett bra upplägg för att simulera en normal projektmiljö med konstant tidspress. Bara att ta in kravställningen och få rätt på syntaxen gjorde att tiden rann iväg snabbt och jag hann bara en bit på 23 minuter men mitt programmet fungerar för de vanliga fallen. Ville ha något fungerande när jag skulle ”leverera” varför jag stannade innan tiden gick ut. Insåg förstås att det fanns en hel del randfall men det hade tagit mig bra mycket mer tid än 30 minuter att lösa. Bara att komma på testfallen tar tid. Här är det förstås lätt att stressa och inte läsa kraven och förstå dem utan börja programmeringen direkt. Någon som minns något projekt där det blivit så?
Det finns möjlighet att lägga till fler egna testfall för att se hur programmet klarar sig i andra fall än det som bifogas övningen. Tyvärr ”hann” jag inte det… Detta var bra i detta testet för det gav en spegling av vad jag förväntar mig att utvecklingarna skall kunna göra. Det var också lätt att lägga till testfallen vilket är en förutsättning för att man skall ta sig tid att skriva testfallen då dessa ofta plötsligt dyker om i huvudet när man håller på med att göra andra saker. Då är det viktigt att snabbt kunna få dem nedtecknade.
Att jag inte hann skriva fler testfall berodde förstås på tidspressen, jag prioriterade inte testfallen. Detta åskådliggör mycket bra hur det brukar fungera i många projekt. Man kör normalfallet och går sedan vidare då man känner sig stressade i stället för att testa igenom varje komponent, vilket brukar straffa sig längre fram i projektet när man upptäcker att man har “glömt” en hel del fall som måste tas om hand. Det går bra att demonstrera applikationen men när man sätter igång och testa lite noggrannare i verifierings och valideringsfasen så bubblar problemen upp.
I mitt fall ser man att min implementation inte tar hand om flera gränsfall som stora tal, stora negativa tal, fall med overflow samt beräkningstider när det är många tal. Det står om vissa av dessa krav i beskrivningen medan andra krav är underförstådda. Det fanns alltså förutsättningar för att man skulle kunnat hitta testfallen och implementera lösningar för det.
Man inser också att tiden för att hantera dessa fallen kommer att bli mycket längre än det tog att implementera normalfallet. Dessutom växer komplexiteten på koden och testfallen är inte helt lätta att skriva och verifiera att testfallet är korrekt implementerat. Jag känner att detta är typiskt för hur det brukar se ut i projekt, att det går snabbt i början och så börjar det efter ett tag upptäckas saker som är struliga. Jag hade en kollega på ett tidigare jobb som brukade kalla det nyckelhålseffekten. När man ser genom nyckelhålet på avstånd ser man inte så mycket och det ser lätt ut att implementera, men ju närmare man kommer ser man mer och till sist så vidgar sig världen bakom dörren.
Jag gjorde också ett lättare test men det var för lätt. Det blev 100% rätt enligt systemet och gick på ca 20 minuter när man hade 60 minuter på sig. Det hade gått att göra ännu snabbare men det blev en hel del funderingar kring om det var något jag missat.
Ger dessa typer av tester en bra bild av om man kan programmera?
Det ger definitivt en bild av om man kan läsa en text och förstå vad som efterfrågas. Man behöver kunna lite matte och i detta fallet en del programmering.
Det som inte framgår av testet är att det i dagens programmering ofta är stora komplexa system som man måste kunna bilda sig en uppfattning om. Att skaffa sig denna överblick och förstå komplexa samband är ofta viktigare än att på kort tid lyckas skriva koden för detta fallet. Men man bör nog lyckas skriva det ungefär så långt som jag nådde vad gäller detta exemplet för att ha några möjligheter att klara sig i ett verkligt projekt. Men om man klarar testet är det, enligt min mening, inte mycket till hjälp vid en anställningsintervju. Det är mer att man kan sålla bort agnarna från vetet vilket förstås är ett bra första steg.
[…] första gången den programeringstesttjänst som Codility erbjuder vid en rekrytering. Som jag skrev för ett drygt år sedan såg jag en del fördelar med att använda denna möjlighet vid rekrytering […]