Ram plet med kodningstest i naturlige omgivelser [case study]

Udgivet: Sidst opdateret:

Efter at vi havde offentliggjort et indlæg om de mest almindelige råd til at ansætte programmører, modtog vi en række spørgsmål om programmeringsopgaver og den måde, hvorpå vi bør kontrollere kodningsevnerne.

Fra min langvarige erhvervserfaring har jeg en masse konsulentpraksis inden for rekruttering af programmører i nogle af de største it-virksomheder, der hovedsageligt er baseret i Central- og Østeuropa.

Vi har skrevet meget om tekniske interviews. Tjek Den ultimative guide til den tekniske samtale.

Udfordringer ved at interviewe udviklere

Da jeg begyndte at interviewe udviklere, var der ikke tid til aktiv programmering og kodning af tests. Vi havde mange kandidater, så vi var nødt til at holde os til en time for hvert enkelt spørgsmål - blød og teknisk vurdering samt økonomiske forhandlinger. Til sidst ansatte vi omkring 5% af de oprindelige kandidater. Efter prøveperioden fortsatte ca. 90% af dem med at arbejde. Det var en ganske god konverteringsrate.

Det er ret...

Men efter at have beregnet de omkostninger, der var forårsaget af uhensigtsmæssige ansættelsesbeslutninger, indså vi, at vi spildte en masse penge. Løn, HR, kontor, notesbøger, tid til kick-start af seniorudviklere osv. Udgifter ud over lønnen var i gennemsnit næsten en fordobling af de endelige omkostninger.

Der var tre hovedårsager til, at udviklere ikke blev ansat efter prøveperioden:

  1. de var ikke i stand til at arbejde på holdet,
  2. de havde kun teoretisk viden,
  3. de arbejdede meget langsommere end forventet.

Grunden til, at vi ikke var i stand til at finde ud af alle disse ulemper, var, at vi sprang over aktive kodningstests under interviewet. At ansætte softwareudviklere uden at kontrollere, om de virkelig kan kode hurtigt og smart, svarer til at købe en bil uden at kontrollere, om motoren virker.

Så hvordan kunne vi kontrollere alle disse svagheder på bare 60 minutter?

Svaret er enkelt - det kunne vi ikke! Vi var nødt til at forlænge interviewprocessen med mindst to timer. Men før vi kunne gøre det, var vi tvunget til at begrænse antallet af kandidater i første omgang. Vi besluttede at lave en 15 minutters telefonisk screening ved at stille 10-15 tekniske spørgsmål og få kendskab til deres lønforventninger. På det grundlag inviterer vi kandidaten igen eller ej. Screeningprocessen gjorde det muligt for os at reducere antallet af næste nødvendige møder med næsten 40%, hvilket var et dårligere resultat end forventet, men godt nok til at forlænge tiden for hvert enkelt interview.

Vi har forsøgt at finde en løsning til at kontrollere, om hver enkelt kandidat er på samme bølgelængde som teamet, og om de kan bruge de programmeringssprog, vi normalt bruger til daglig. Uafhængigt af de nødvendige kodningsfærdigheder på programmørernes arbejde lægger vi vægt på den måde, de tænker på, især da det påvirker deres evne til at kommunikere med andre.

Er parprogrammering en løsning?

Ideen var at lave parprogrammering! Cool - vi får det bedste fra begge verdener. Antagelsen var rigtig for ca. 70% af vores kandidater. Som følge heraf var en times kodningssession tilstrækkelig til at se, hvordan en person vil opføre sig i vores krævende og specifikke miljø - både med hensyn til at bruge den viden, han/hun havde i praksis, bruge evnen til hurtig informationsbehandling, fleksibilitet og også som en teamworker, der nogle gange er tvunget til at indgå kompromiser for at nå virksomhedens mål.

Samtidig gav det os også mulighed for at se, hvordan de bruger værktøjerne, men først og fremmest - hvordan de kan bruge SOLID-principperne i praksis osv. Men hvad med de andre 30%? Det var faktisk folk, der slet ikke kan programmere i par. Det var helt unaturligt for dem. Er det et stort problem? Når man indser at man i praksis brugte 5-10% af tiden på parprogrammering må man tænke sig om, om man kan leve med sådanne medarbejdere på den stilling man besætter 🙂 .

Hvordan kan vi kontrollere deres kodningsevner? Vi lader dem bare fortsætte den opgave, vi har påbegyndt. Men alene. Uden at interviewerne kigger dem over skulderen og kommenterer hver eneste linje i koden.

Det er også vigtigt, at vi genskaber naturlige forhold for alle udviklere - favorit IDE installeret, adgang til StackOverflow.com, dokumentation osv. Hvis kandidaten spørger om at bruge sin egen notebook - bør svaret altid være: "Du er velkommen. Gør alt, hvad du har brug for, for at du kan føle dig tryg ved kodning". Naturlige omgivelser er et absolut must for alle former for test til kontrol af kodningsevner, både i parprogrammering og i individuelle interviews.

Del indlæg

Få mere at vide om ansættelse af teknologiske medarbejdere

Tilmeld dig vores Learning Hub for at få nyttig viden direkte i din indbakke.

Kontroller og udvikl kodningsevner uden problemer.

Se DevSkiller-produkterne i aktion.

Sikkerhedscertificeringer og overholdelse. Vi sørger for, at dine data er sikre og beskyttede.

DevSkiller-logo TalentBoost-logo TalentScore-logo