kim tiedemann bloghoved

Den svære rekruttering

Jeg har igennem tiden været med til at ansætte en del udviklere og arkitekter. Vi vil jo alle gerne have de teknisk bedste hoveder, men hvordan søren er det lige, at vi finder dem?

Hos Schultz har vi lige været igennem et rekrutteringsforløb, hvor vi skulle bruge to seniorudviklere, hvilket fik mig til at reflektere over spørgsmålet.

Vi har diskuteret hvordan vi i jobsamtalen kan finde de bedste kandidater:

Brainteasers

En metode er "brainteasers", som fx "hvor mange tankstationer er der på sjælland". Ideen bag spørgsmålet er, at se hvordan kandidaten ræsonnerer sig frem til svaret. Metoden er brugt en del i Silicon Valley, som det kan ses på Glassdoor, hvor folk har lagt erfaringer fra deres jobinterviews op.

Google har været ivrig bruger af disse brainteasers, men er efterhånden holdt op med at bruge dem, da de ikke giver værdi.

Jeg har ikke selv prøvet at bruge brainteasers i de samtaler, som jeg har afholdt. Jeg har svært ved at se værdien af dem, da det jo ikke er repræsentativt for de opgaver, som udviklere møder i hverdagen.

Pair coding

Ideen bag pair coding er, at se om kandidaten er "god til at kode". Altså stille en konkret opgave, åbne Visual Studio og så er det bare at gå i gang. Det viser om kandidaten er hjemme i sit IDE og kan løse en simpel opgave.

Jeg har tidligere prøvet at bruge denne metode til at vurdere de tekniske kompetencer, men det gav ikke det ønskede resultat. For at det kunne lade sig gøre, blev opgaven alt for simpel og kandidaterne var oftest nervøse, hvilket er meget forståeligt. Det var simpelthen ikke relevant at se, om en udvikler kunne implementere fx en fibonacci metode.

Snak om forretningsforståelse

En vigtig egenskab ved en udvikler/arkitekt er, om man kan forstå og ikke mindst kan videreformidle et komplekst forretningsområde. Hos Schultz udvikler vi blandt andet produkter til kommunernes jobcentre, og der er tale om et meget kompleks område, som er underlagt en del lovgivning. Derfor er det vigtigt, at man har en god forståelse for området og kan udfordre Product Owner i forhold til den bedste implementering af noget funktionalitet. Det er svært at udfordre en user story, hvis man ikke har den underliggende forretningsforståelse eller ikke interesserer sig for andet end teknik.

Det er derfor rart at se, om en kandidat kan fortælle om et tidigere projekt og kan formidle noget om forretningsdomænet og hvilke forretningsmål, som projektet var sat i verden for at løse.

Snak om arkitektur

En anden vigtig egenskab er, om kandidaten kan videreformidle en arkitektur for et system, som hun tidligere har været med til at implementere. Forstår kandidaten systemlandskabet for systemet? Integrationer med andre systemer? Komponentopdelingen i systemet? Hvorfor valg om arkitekturen er truffet?

Det er vigtigt at man som udvikler kan overskue og forstå en arkitekur. Det giver mulighed for, at man kan indgå i diskussioner i et Scrum team om arkitekturen for et system og være med til at finde de bedste løsninger.

Snak om vores fag

Endeligt har vi haft succes med at tage en snak om faget. Det er mange teknologier og mange buzz-words derude i dag. For mig er det mindre vigtigt, om der er et præcist match mellem kandidatens kompetencer indenfor de teknologier, som vi bruger. Det er klart, at jeg kigger efter C# udviklere, da vi er et Microsoft hus, men det er vigtigere, at der er en grundlæggende forståelse for faget og hvorfor vi gør, som vi gør. Når fundamentet er til stede, så vil det være meget nemmere at springe fra en teknologi til en anden, når og hvis der er behov for det.

Vi starter ud med at tale lidt om objekt-orienteret programmering. Er der styr på de grundlæggende koncepter indenfor OO?

Herefter taler vi relationelle databaser, og hvordan man mapper fra en OO verden til en relationel verden.

Så putter vi et sprog ovenpå - i vores tilfælde C#. Forstår kandidaten de forskellige grundlæggende koncepter i sproget? Hvad med de mere avancerede? Her er masser at tage fat på...

Endeligt taler vi om det som vi kalder craftmanship - det kan være en samtale som fører vidt omkring afhængigt af kandidatens erfaring og kan fx indeholde en snak om design patterns, dependency injections, sikkerhed og så videre.

Mennesket bag

Vi kigger selvfølgelig også på mennesket bag teknikken. Det er vigtigt, at man er selvkørende, kan fungere i Scrum teams, har lyst til at udfordre autoriteter og normer, samt har en lyst til at blive bedre til sit fag. Men det er vist et blogindlæg i sig selv :-)

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jn Madsen

Til gengæld er der mange vildspor.

Jeg havde for en del år siden en chef, der havde en eller andet evne ...

Der var det obligatoriske CV og hej med dig,- der hvor han var genial, det var hans evne til at "læse" folk.
Han sad i en times tid og sludrede med kandidaten, grinede lidt og drak kaffe.

Men jeg så aldrig et fejlskud fra ham,- han fandt altid helt perfekte profiler til en stilling. Helt uden personlighedstests, konsulentbureauer og HR-folk ....

Til gengæld har jeg andre steder set horrible fejl-ansættelser, selv om alle de "fine" og rigtige værktøjer var taget i brug.

Kvalifikationer - eller mangel på samme kan være hos ansøgeren, men så sandeligt også hos den der skal udvælge.

  • 10
  • 0
Log ind eller Opret konto for at kommentere