Topp 7 sätt att snabbt kontrollera IT-specialisters kompetenser före intervju

Att hyra IT-specialister är en utmanande uppgift. För det första råder det just nu brist på erfarna kandidater, och de är medvetna om det. Kandidater är ofta inte villiga att spendera mycket tid på "urvalsprocesser" om de inte först blir intresserade. Den tidigare populära metoden med "ett test på över 8 timmar" fungerar inte längre. För att göra en första bedömning av kunskaper och filtrera bort kandidater innan en fullständig teknisk intervju, måste man använda andra, snabbare metoder. För det andra, för att bedöma kunskaper och färdigheter av hög kvalitet, behöver man själv ha sådana färdigheter eller involvera en kollega som har dem. Dessa utmaningar kan lösas med hjälp av metoder som jag kommer att berätta om i denna artikel. Jag använder själv dessa metoder och har sammanställt en sorts ranking.

Så, mina topp-7 metoder för snabb bedömning av IT-specialisters kompetens före intervjun:

7. Granska portföljer, kodexempel och öppna repositoryn hos kandidaten.

6. Kort testuppgift på tid (utförd på 30-60 minuter).

5. Kort expressintervju om färdigheter via telefon/Skype (som en frågeenkät, men online och med röst).

4. Live-Doing (Kodning) - vi löser en enkel uppgift i realtid med delad skärm.

3. Enkäter med öppna frågor om erfarenhet.

2. Korta tester med flervalsfrågor, begränsade i tid.

1. Flertrins testuppgift, där första steget görs före intervjun.

Jag kommer nu att gå in på djupet om dessa metoder, deras fördelar och nackdelar samt situationer där jag använder respektive metod för snabb bedömning av programmerares kompetens.

I den föregående artikeln om rekryteringsprocessens trattform habr.com/ru/post/447826 gör jag en undersökning bland läsarna om metoder för snabb bedömning av IT-specialisters färdigheter. I denna artikel berättar jag om de metoder som jag personligen gillar, varför jag gillar dem och hur jag tillämpar dem. Jag börjar med första plats och avslutar med den sjunde.

1. Flertrins testuppgift, där första steget görs före intervjun.

Jag anser att det här sättet att bedöma utvecklares kompetenser är det bästa. Till skillnad från traditionella testuppgifter, där man säger "här är uppgiften, gå och gör den", delas min variant av testuppgiften upp i steg – diskutera och förstå uppgiften, designa en lösning och bedöma de resurser som krävs, flera steg för att genomföra lösningen, dokumentera och överlämna/lämna in lösningen. Detta tillvägagångssätt ligger närmare en normal och modern programvaruutvecklingsteknik än bara "ta och gör". Mer detaljer följer nedan.

När använder jag detta tillvägagångssätt

För mina projekt anställer jag vanligtvis frilansare som utvecklar en separat, avskild och relativt oberoende del av projektet. Detta minskar behovet av kommunikation mellan medarbetarna, vilket ofta är nära noll. Medarbetarna kommunicerar inte med varandra, utan med projektledaren. Därför är det viktigt för mig att direkt kunna bedöma personens förmåga att snabbt förstå uppgiften, ställa klargörande frågor, självständigt utveckla en handlingsplan för att lösa uppgiften, samt bedöma de nödvändiga resurserna och tiden. Detta underlättas mycket av den flerfasiga testuppgiften.

Hur man genomför

Vi definierar och formulerar en självständig och originell uppgift relaterad till projektet som utvecklaren ska arbeta med. Jag beskriver vanligtvis som uppgift en förenklad prototyp av huvuduppgiften eller den framtida produkten, för vars genomförande utvecklaren kommer att behöva konfronteras med de centrala problemen och teknologierna i projektet.

Det första steget i testuppgiften är att bekanta sig med uppgiften, klargöra det som är oklart, designa en lösning, planera stegen för att lösa uppgiften och bedöma tiden för att genomföra varje steg samt hela testuppgiften. I slutändan förväntar jag mig ett dokument på 1-2 sidor där utvecklarens handlingsplan och tidsbedömning beskrivs. Jag ber också kandidater att ange vilket av stegen de skulle vilja genomföra helt för att bekräfta sina färdigheter i praktiken. Det behöver inte programmeras någonting just nu.

Denna uppgift (den samma) delas ut till flera kandidater. Det förväntas att svaren från kandidaterna kommer att komma in nästa dag. Därefter, efter 2-3 dagar, när alla svar har samlats in, analyserar vi vad vi fått från kandidaterna och vilka avklarande frågor de ställt innan de började utföra uppgiften. Utifrån denna information kan vi bjuda in det antal kandidater ni behöver till nästa steg.

Nästa steg är en kort intervju. Vi har redan något att prata om. Kandidaten har en ungefärlig förståelse för ämnesområdet för det projekt som hen kommer att arbeta med. Huvudsyftet med denna intervju är att svara på tekniska frågor från kandidaten och motivera hen för att genomföra det huvudsakliga testuppdraget – programmeringen av den del av uppgiften som hen själv valt. Eller den del vars genomförande ni vill se.

Det är alltid mycket intressant att se vilken del av uppgiften utvecklaren vill genomföra. Vissa föredrar att strukturera projektet, bryta ner lösningen i moduler och klasser, vilket innebär att de arbetar uppifrån och ner. Andra – lyfter fram en specifik deluppgift som de anser vara viktigast, utan att beskriva hela lösningen. De arbetar alltså nedifrån och upp – från den mest komplexa deluppgiften till hela lösningen.

Fördelar

Vi kan se kandidatens beläsenhet, tillämpbarhet av hens kunskaper på vårt projekt och utveckling av kommunikationsförmågor. Dessutom kan vi enkelt jämföra kandidater sinsemellan. Vanligtvis avfärdar jag de kandidater som ger alltför optimistiska och alltför pessimistiska tidsuppskattningar för uppgiften. Självklart har jag en egen tidsuppskattning. En låg uppskattning från kandidaten tyder förmodligen på att personen inte har förstått uppgiften ordentligt och har genomfört testet ytligt. En alltför hög tidsuppskattning antyder vanligtvis att kandidaten har en dålig förståelse för ämnesområdet och saknar erfarenhet inom de ämnen jag behöver. Jag avfärdar inte kandidater direkt baserat på deras uppskattning, utan ber dem motivera sin uppskattning om den inte redan har motiverats tillräckligt.

För vissa kan denna metod verka komplicerad och tidskrävande. Min uppskattning av arbetsinsatsen för att tillämpa denna metod är följande – det tar 30-60 minuter att formulera testuppgiften och sedan 15-20 minuter för att kontrollera svaret från varje kandidat. Kandidaterna brukar spendera högst 1-2 timmar på att utföra en sådan testuppgift, och på så sätt kommer de i kontakt med de uppgifter som de kommer att behöva lösa framöver. Redan i detta skede kan kandidaten tappa intresset och avbryta kommunikationen med er efter att ha slösat lite tid.

Nackdelar

För det första måste man komma på en original, isolerad och koncis testuppgift, vilket inte alltid är möjligt. För det andra förstår inte alla kandidater från början att de inte behöver programmera i det första steget. Vissa börjar omedelbart programmera och försvinner i flera dagar, för att sedan skicka in en helt genomförd testuppgift. Formellt sett har de inte klarat av denna testuppgift eftersom de gjorde något annat än vad som krävdes. Men samtidigt kan man också säga att de har klarat det, om de skickade in en adekvat lösning på hela testuppgiften. För att undvika sådana missöden brukar jag vanligtvis ringa alla kandidater som fått uppgiften efter 2 dagar för att höra hur det går för dem.

2. Kortare tester med alternativ och tidsbegränsad genomförande

Jag använder sällan denna metod, även om jag verkligen gillar den och anser att det är en av de bästa metoderna för snabb kompetenskontroll. Jag kommer att skriva en separat artikel om denna metod inom kort. Sådana tester används flitigt inom olika kunskapsområden. Det mest tydliga och typiska exemplet är det teoretiska provet för att få körkort. I Ryssland innehåller detta prov 20 frågor som måste besvaras på 20 minuter. En felaktig svar är tillåten. Vid två fel måste man svara korrekt på 10 ytterligare frågor utan misstag. Denna metod går utmärkt att automatisera.

Tyvärr har jag inte stött på några bra implementationer av sådana tester för programmerare. Om du känner till bra färdiga implementationer av sådana tester för programmerare, vänligen skriv i kommentarerna.

Hur man genomför

Jag har arbetat med självständiga implementationer av liknande tester som arbetsgivare använder när de genomför uppdrag som rekryteringsoutsourcer. Det är fullt möjligt att genomföra sådana tester. Till exempel med hjälp av Google Forms. Huvudproblemet är att formulera frågor och svarsalternativ. Vanligtvis har arbetsgivare tillräcklig fantasi för 10 frågor. Tyvärr är det inte möjligt i Google Forms att rotera frågor från en pool och att sätta tidsbegränsningar. Om du känner till ett bra onlineverktyg för att skapa egna tester där man kan sätta en tidsbegränsning och organisera olika frågor för olika kandidater, vänligen skriv om sådana tjänster i kommentarerna.

När använder jag detta tillvägagångssätt

Just nu använder jag detta sätt på begäran av arbetsgivare, om de har färdiga tester som kan ges till kandidater. Det är också möjligt att kombinera sådana tester med den fjärde metoden från min ranking – vi ber kandidaten att dela sin skärm och genomföra testet. Under tiden kan ni diskutera frågorna och svarsalternativen.

Fördelar

Med en bra implementering är denna metod autonom. Kandidaten kan välja en lämplig tid för att genomföra testet och du behöver inte spendera mycket tid.

Nackdelar

Kvalitativ implementering av denna metod är ganska kostsam och det är inte särskilt praktiskt för ett litet företag som sällan anställer nya medarbetare.

3. Enkäter med öppna frågor om erfarenhet

Detta är en uppsättning öppna frågor som erbjuder kandidaten att reflektera baserat på sin erfarenhet. Här erbjuder vi inte svarsalternativ. Öppna frågor är sådana som inte kan besvaras enkelt och entydigt. Till exempel, kom ihåg den svåraste uppgiften du har löst med hjälp av ett visst ramverk? Vad var den största svårigheten för dig? För sådana frågor kan man inte ge ett kort svar. Den enda enkla svaret är att jag har ingen sådan erfarenhet, har inte arbetat med det här verktyget.

Hur man genomför

Lätt att implementera med hjälp av Google Forms. Det viktigaste är att tänka ut frågorna. Jag använder några standardkonstruktioner.

Berätta om det senaste projektet du arbetade med genom XXX, vad var det svåraste för dig i detta projekt?

Vilka är de viktigaste fördelarna med teknologin XXX för dig, ge exempel från din erfarenhet?
När du valde teknologin XXX, vilka andra alternativ övervägde du och varför valde du just XXX?

I vilka situationer skulle du föredra teknologi AAA framför BBB?
Berätta om den mest utmanande uppgiften du löste med hjälp av XXX, vad var den huvudsakliga svårigheten?

Därför kan dessa konstruktioner tillämpas på många teknologier i din arbetsstack. Det är inte lätt att svara på sådana frågor med generiska fraser från nätet, eftersom de är personliga och handlar om personlig erfarenhet. När kandidater svarar på dessa frågor, håller de oftast i åtanke att under intervjun kan varje av deras svar leda till följdfrågor. Så om det inte finns någon erfarenhet, tenderar kandidater att dra sig tillbaka, med förståelsen att fortsatt samtal kan bli meningslöst.

När använder jag detta tillvägagångssätt

Vid arbete med beställningar om att hitta specialister, om beställaren inte har föreslagit sitt sätt för initial utvärdering av kompetenser, använder jag denna metod. Jag har redan färdiga enkäter för ett antal ämnen och det kostar mig inget att använda denna metod för en ny beställare.

Fördelar

Det är enkelt att genomföra med hjälp av Google Forms. Dessutom kan en ny enkät göras baserat på den tidigare, genom att byta ut namnen på teknologier och verktyg mot andra. Till exempel kommer en enkät om erfarenhet med React knappast att skilja sig från en enkät om erfarenhet med Angular.

Att sammanställa en sådan enkät tar 15-20 minuter, och kandidaterna brukar spendera 15-30 minuter på att svara. Tidskostnaden är liten, men vi får information om kandidatens personliga erfarenhet, som vi kan utgå ifrån och göra varje intervju med kandidater unik och mer intressant. Vanligtvis blir intervjutiden efter en sådan enkät kortare, eftersom vi slipper ställa enkla standardfrågor.

Nackdelar

För att särskilja kandidatens egna svar från de som har "googlats" måste man förstå ämnet. Men detta kommer snabbt med erfarenhet. Efter att ha granskat 10-20 svar kommer du att lära dig att skilja mellan kandidaternas egna originella svar och de som hittats på nätet.

4. Live-Doing (Kodning) – vi löser en enkel uppgift i realtid med delad skärm

Syftet med denna metod är att be kandidaten lösa en enkel uppgift och observera processen. Kandidaten får använda vad som helst, det finns ingen begränsning för att söka information på nätet. Kandidater kan känna stress av att deras arbete observeras. Inte alla kandidater går med på denna typ av bedömning av sina färdigheter. Men å andra sidan, ger denna metod möjlighet att se vilken kunskap personen har i huvudet, vad de kan använda även under stressiga situationer och vilken information de går till sökmotorn för. Nivån på kandidaten syns nästan omedelbart. Nybörjare använder de mest grundläggande, till och med primitiva funktionerna av språket, ofta börjar de implementera funktionaliteten för grundläggande bibliotek manuellt. Mer erfarna kandidater är bra på att navigera i grundläggande klasser, metoder, funktioner och kan snabbt lösa en enkel uppgift – 2-3 gånger snabbare än nybörjare, med hjälp av de funktioner som de är bekanta med i språket. Ännu mer erfarna kandidater börjar vanligtvis med att resonera om olika angreppssätt för att lösa uppgiften och berättar flera lösningar, de frågar vilken av alternativen jag vill se implementerad. Allt som kandidaten gör kan diskuteras. Även baserat på samma uppgift kan intervjuerna bli väldigt olika, liksom kandidaternas lösningar.

Som en variant av denna metod kan du be kandidaten att genomföra ett test för att kontrollera professionella kompetenser, motivera valet av svarsalternativ. Till skillnad från vanlig testning får du reda på hur väl grundat valet av svar var. Du kan komma på dina egna varianter av denna metod med hänsyn till egenskaperna hos din lediga tjänst.

Hur man genomför

Denna metod kan enkelt genomföras med hjälp av Skype eller ett annat liknande videosamtalssystem som gör det möjligt att demonstrera skärmen. Uppgifter kan skapas självständigt eller utnyttja plattformar som Code Wars, samt olika färdiga tester.

När använder jag detta tillvägagångssätt

När jag rekryterar programmerare och det inte framgår tydligt vilken kunskapsnivå kandidaten har utifrån CV:t, erbjuder jag en intervju i det formatet. Enligt min erfarenhet motsätter sig cirka 90% av utvecklarna inte det. De uppskattar att vi direkt börjar diskutera programmering istället för att ställa dumma frågor som "hur ser du dig själv om 5 år".

Fördelar

Trots kandidatens stress och nervositet är kandidatens allmänna färdighetsnivå genast tydlig. Kommunikationsförmåg blir också uppenbar – hur de resonerar, hur de förklarar och motiverar sina beslut. Om det behövs kan man enkelt göra en videoinspelning av sin skärm och visa intervjun för andra personer senare.

Nackdelar

Kommunikationen kan brytas. På grund av nervositet kan kandidaten börja tveka. I denna situation kan man avbryta och ge dem tid att tänka på uppgiften i ensamhet, ringa tillbaka om 10 minuter och fortsätta. Om kandidaten fortfarande beter sig konstigt efter det, bör man pröva en annan metod för att utvärdera färdigheterna.

5. Kort expressintervju om färdigheter via telefon/Skype

Det är helt enkelt en samtal via telefon, Skype eller något annat röstkommunikationssystem. På så sätt kan vi bedöma kandidatens kommunikationsförmåga, deras allmänbildning och syn på världen. Man kan använda en enkät som samtalsplan. Som alternativ kan vi diskutera kandidatens svar på enkäten mer detaljerat.

Hur man genomför

Vi kommer överens med kandidaten om ett samtal och ringer. Vi ställer frågor och antecknar svaren.

När använder jag detta tillvägagångssätt

Denna metod tillämpar jag vanligtvis tillsammans med enkäten när kandidatens svar verkar originala eller otillräckligt övertygande. Jag samtalar med kandidaten om frågorna från enkäten och utforskar deras åsikter mer detaljerat. Jag anser att sådana samtal är obligatoriska när kommunikationsförmåga är viktig, så att kandidaten kan formulera sina tankar enkelt och tydligt.

Fördelar

Utan en röstkonversation om professionella ämnen är det vanligtvis omöjligt att avgöra hur bra kandidaten kan uttrycka sina tankar.

Nackdelar

Den största nackdelen är den extra tidsåtgången. Därför använder jag denna metod som ett komplement till andra metoder när det behövs. Dessutom finns det kandidater som pratar utmärkt om professionella ämnen, men som i praktiken har begränsad kompetens. Om du behöver en programmerare som konsekvent och kvalitativt löser problem, är det bättre att välja en annan metod för att först kontrollera kompetenser. Om du behöver en manager eller analytiker, det vill säga en specialist som översätter från mänskligt språk till 'programmerarens språk' och tillbaka, då är denna metod för att kontrollera kompetenser mycket användbar.

6. Kort testuppgift under tid (utförs på 30-60 minuter)

För ett antal yrken är det viktigt att specialisten snabbt kan hitta lösningen på en uppgift. Vanligtvis är uppgifterna inte så komplicerade, men tidsåtgången för att lösa uppgiften är avgörande.

Hur man genomför

Vi kommer överens med kandidaten om tid för att utföra testuppgiften. Vid den avtalade tiden skickar vi kriterierna för uppgiften till kandidaten och ser om de förstått vad som krävs. Vi mäter tiden som kandidaten lägger på att lösa uppgiften. Vi analyserar lösningen och den tid。

När använder jag detta tillvägagångssätt

I min praktik har denna metod använts för att kontrollera kompetenser hos teknisk supportpersonal, SQL-programmerare och testare (QA). Uppgifterna har varit av typen 'hitta problemområden och föreslå lösningar', 'optimera SQL-frågan för att få den att fungera tre gånger snabbare', och så vidare. Självklart kan du skapa dina egna uppgifter. Denna metod kan också användas för juniora utvecklare.

Fördelar

Vi lägger endast vår tid på att utarbeta och verifiera uppgiften. Kandidaten kan välja en lämplig tid för att genomföra uppgiften.

Nackdelar

Den största nackdelen är att det kan finnas lösningar på dina uppgifter eller liknande på nätet, så det är viktigt att ha flera alternativ och sporadiskt komma på nya uppgifter. Om du behöver testa reaktionsförmåga och allmänna kunskaper, väljer jag personligen tidstester (metod nr 2).

7. Granska portföljer, kodexempel, öppna repositorier från kandidaten.

Detta är förmodligen det mest begripliga sättet att kontrollera kompetenser, förutsatt att dina kandidater har portföljer och att ditt rekryteringsteam har specialister som kan bedöma portföljer.

Hur man genomför

Vi granskar kandidaters CV. Om vi hittar länkar till portföljer, granskar vi dem. Om det inte finns några hänvisningar till portföljer i CV:t, ber vi kandidaten om deras portfölj.

När använder jag detta tillvägagångssätt

I min erfarenhet har denna metod använts mycket sällan. Det är inte ofta man kan hitta arbeten inom rätt ämne i kandidaters portföljer. Erfarna kandidater föredrar ofta denna metod framför ett standardiserat och ointressant testuppdrag. De säger: "titta på mitt repo, där finns tiotals exempel på mina lösningar av olika problem, ni får se hur jag skriver kod."

Fördelar

Det sparar kandidaternas tid. Om det finns tid bland proffsen i ert team kan man snabbt och utan kommunikation med kandidaterna sortera bort de olämpliga. Medan rekryteraren letar efter kandidater, utvärderar en kollega portföljer. Det leder till en ganska snabb och parallell arbetsprocess.

Nackdelar

Denna metod kan inte tillämpas för alla IT-professioner. För att utvärdera en portfölj måste man själv ha utvecklade färdigheter. Om du inte är specialist kan du inte kvalitativt bedöma en portfölj.

Kollegor, jag bjuder in er att diskutera det lästa i kommentarerna. Berätta gärna vilka andra sätt för snabb kontroll av kompetenser ni använder?

Källa: habr.com