Å ansette IT-spesialister er ikke en lett oppgave. For det første er det for tiden mangel på erfarent personell i markedet, de forstår dette. Kandidater er ofte ikke villige til å bruke mye tid på en arbeidsgivers "utvelgelsesarrangementer" hvis de ikke først er interessert. Den tidligere populære praksisen med "vi gir deg en test i 8+ timer" fungerer ikke lenger. For førstegangsvurdering av kunnskap og screening av kandidater før gjennomføring av et fullskala teknisk intervju, er det nødvendig å bruke andre, raskere metoder. For det andre, for en høykvalitets vurdering av kunnskap og ferdigheter, må du ha slike ferdigheter selv eller tiltrekke deg en kollega som har slike ferdigheter. Disse vanskelighetene kan løses ved hjelp av metodene som jeg vil diskutere i denne artikkelen. Selv bruker jeg disse metodene og har satt sammen en slags vurdering for meg selv.
Så, mine topp 7 måter å raskt teste kompetansen til IT-spesialister før et intervju:
7. Studer kandidatens portefølje, kodeeksempler og åpne depoter.
6. En kort tidsbestemt testoppgave (fullført på 30-60 minutter).
5. Et kort ekspressintervju om ferdigheter på telefon/Skype (som et spørreskjema, kun på nett og med tale).
4. Live-Doing (Coding) – vi løser et enkelt problem i sanntid med en delt skjerm.
3. Spørreskjemaer med åpne spørsmål om erfaring.
2. Korte flervalgstester med begrenset tid å gjennomføre.
1. Flertrinns testoppgave, første trinn gjennomføres før intervjuet.
Deretter vurderer jeg i detalj disse metodene, deres fordeler og ulemper, og situasjonene der jeg bruker en eller annen metode for raskt å teste kompetansen til programmerere.
I forrige artikkel om ansettelsestrakten Jeg gjennomførte en undersøkelse blant lesere om måter å raskt teste ferdighetene til IT-spesialister. I denne artikkelen snakker jeg om metodene jeg personlig liker, hvorfor jeg liker dem og hvordan jeg bruker dem. Jeg starter på førsteplass og ender på sjuende.
1. Flertrinns testoppgave, første trinn gjennomføres før intervjuet
Jeg anser denne metoden for å teste utviklerkompetanse som den beste. I motsetning til en tradisjonell testoppgave, når du sier "ta oppgaven og gå og gjør den," i min versjon, er prosessen med å fullføre testoppgaven delt inn i stadier - diskusjon og forståelse av oppgaven, utforming av en løsning og vurdering av nødvendige ressurser , flere stadier av implementering av løsningen, dokumentere og sende inn aksept av vedtaket. Denne tilnærmingen er nærmere normal moderne programvareutviklingsteknologi enn bare "ta det og gjøre det." Detaljer nedenfor.
I hvilke tilfeller bruker jeg denne metoden?
Til mine prosjekter ansetter jeg vanligvis fjernarbeidere som utvikler en egen, separat og relativt selvstendig del av prosjektet. Dette reduserer behovet for kommunikasjon mellom ansatte, ofte til null. Ansatte kommuniserer ikke med hverandre, men med prosjektleder. Derfor er det viktig for meg å umiddelbart vurdere en persons evne til raskt å forstå et problem, stille oppklarende spørsmål, selvstendig utvikle en handlingsplan for å løse problemet og estimere nødvendige ressurser og tid. En flertrinns testoppgave hjelper meg godt med dette.
Hvordan implementere
Vi identifiserer og formulerer en selvstendig og original oppgave knyttet til prosjektet som utbygger skal jobbe med. Jeg beskriver vanligvis som en oppgave en forenklet prototype av hovedoppgaven eller fremtidig produkt, for implementeringen som utvikleren må møte hovedproblemene og teknologiene til prosjektet.
Den første fasen av testoppgaven er å gjøre seg kjent med problemet, avklaring av hva som er uklart, designe en løsning, planlegge trinn for å løse problemet og estimere tiden for å fullføre enkelttrinn og hele testoppgaven. Ved utgangen forventer jeg et 1-2 siders dokument som skisserer utviklerens handlingsplan og tidsestimat. Jeg ber også kandidatene om å angi hvilke av trinnene de ønsker å implementere fullt ut for å bekrefte ferdighetene sine i praksis. Det er ikke nødvendig å programmere noe ennå.
Denne oppgaven (den samme) gis til flere kandidater. Svar fra kandidater forventes neste dag. Deretter, etter 2-3 dager, når alle svarene er mottatt, analyserer vi hva kandidatene sendte oss og hvilke oppklarende spørsmål de stilte før oppgaven startet. Basert på denne informasjonen kan du invitere et hvilket som helst antall kandidater du trenger til neste trinn.
Neste trinn er et kort intervju. Vi har allerede noe å snakke om. Kandidaten har allerede en grov ide om fagområdet for prosjektet han skal jobbe med. Hovedmålet med dette intervjuet er å svare på kandidatens tekniske spørsmål og motivere ham til å fullføre hovedtestoppgaven - programmere den delen av oppgaven han selv har valgt. Eller den delen du vil se implementert.
Det er alltid veldig interessant å se hvilken del av oppgaven utvikleren ønsker å gjennomføre. Noen mennesker foretrekker å pakke ut prosjektstrukturen, dekomponere løsningen i moduler og klasser, det vil si at de beveger seg fra topp til bunn. Noen trekker frem en egen deloppgave, den viktigste etter deres mening, uten å foreskrive løsningen som helhet. Det vil si at de går fra bunnen og opp – fra den mest komplekse deloppgaven til hele løsningen.
Fordeler
Vi kan se kandidatens lærdom, anvendeligheten av hans kunnskap til prosjektet vårt, og utviklingen av kommunikasjonsevner. Det er også enkelt for oss å sammenligne kandidater med hverandre. Jeg avviser vanligvis kandidater som gir for optimistiske eller for pessimistiske anslag på hvor lang tid det vil ta å fullføre en oppgave. Jeg har selvfølgelig mitt eget tidsanslag. En kandidats lave poengsum indikerer mest sannsynlig at personen ikke forsto oppgaven ordentlig og fullførte denne testen overfladisk. For mye tidsestimering indikerer vanligvis at kandidaten har dårlig forståelse av fagområdet og ikke har erfaring i de temaene jeg trenger. Jeg avviser ikke umiddelbart kandidater basert på deres poengsum, men ber dem heller begrunne vurderingen dersom vurderingen ikke allerede er tilstrekkelig motivert.
For noen kan denne metoden virke komplisert og dyr. Min vurdering av arbeidsintensiteten ved å bruke denne metoden er som følger: det tar 30-60 minutter å beskrive testoppgaven og deretter 15-20 minutter å sjekke hver kandidats svar. For kandidater tar det vanligvis ikke mer enn 1-2 timer å fullføre en slik testoppgave, mens de er fordypet i essensen av problemene de må løse i fremtiden. Allerede på dette stadiet kan kandidaten bli uinteressert, og han nekter å kommunisere med deg etter å ha kastet bort litt tid.
Begrensninger
For det første må du komme opp med en original, isolert og romslig testoppgave; dette er ikke alltid mulig. For det andre forstår ikke alle kandidater umiddelbart at programmering ikke er nødvendig i det første trinnet. Noen begynner å programmere med en gang og forsvinner i noen dager, for så å sende dem en fullført testoppgave. Formelt klarte de ikke denne testoppgaven fordi de ikke gjorde det som ble krevd av dem. Men samtidig lyktes de dersom de sendte en adekvat løsning på hele testoppgaven. For å eliminere slike hendelser pleier jeg å ringe alle kandidater som fikk oppgaven 2 dager etter at oppgaven er gitt og høre hvordan de har det.
2. Korte flervalgstester med tidsbegrensninger
Jeg bruker ikke denne metoden ofte, selv om jeg virkelig liker den og synes den er en av de beste måtene å raskt teste kompetanser. Jeg vil skrive en egen artikkel om denne metoden i nær fremtid. Slike tester er mye brukt i ulike kunnskapsfelt. Det mest slående og typiske eksemplet er den teoretiske eksamen for å få førerkort. I Russland inneholder denne eksamenen 20 spørsmål som må besvares på 20 minutter. Én feil er tillatt. Hvis du gjør to feil, må du svare riktig på 10 tilleggsspørsmål. Denne metoden er svært automatisert.
Dessverre har jeg ikke sett gode implementeringer av slike tester for programmerere. Hvis du kjenner til gode ferdige implementeringer av slike tester for programmerere, vennligst skriv i kommentarfeltet.
Hvordan implementere
Jeg har jobbet med egenimplementering av lignende tester av arbeidsgivere ved utførelse av bestillinger som outsourcet rekrutterer. Det er fullt mulig å gjennomføre en slik test. For eksempel ved å bruke Google Forms. Hovedproblemet er å komponere spørsmål og svaralternativer. Vanligvis er arbeidsgivernes fantasi nok til 10 spørsmål. Dessverre, i Google Forms er det umulig å implementere rotasjon av spørsmål fra bassenget og tidsbegrensninger. Hvis du kjenner et godt nettverktøy for å lage dine egne tester, hvor du kan begrense tiden for å ta testen og organisere utvalget av forskjellige spørsmål for forskjellige kandidater, så skriv om slike tjenester i kommentarfeltet.
I hvilke tilfeller bruker jeg denne metoden?
Nå bruker jeg denne metoden på forespørsel fra arbeidsgivere dersom de har ferdige tester som kan gis til kandidater. Det er også mulig å kombinere slike tester med den fjerde metoden fra min vurdering – vi ber kandidaten dele skjermen sin og ta testen. Samtidig kan du diskutere spørsmål og svaralternativer med ham.
Fordeler
Hvis den implementeres godt, er denne metoden autonom. Kandidaten kan velge et tidspunkt som passer for ham for å ta testen, og du trenger ikke å kaste bort mye av tiden din.
Begrensninger
Implementering av høy kvalitet av denne metoden er ganske dyr, og det er ikke veldig praktisk for et lite selskap som av og til ansetter nye ansatte.
3. Spørreskjemaer med åpne spørsmål om erfaring
Dette er et sett med åpne spørsmål som inviterer kandidaten til å reflektere over sin erfaring. Vi tilbyr imidlertid ikke svaralternativer. Åpne spørsmål er de som ikke kan besvares enkelt og monosyllabically. Husk for eksempel det vanskeligste problemet du løste ved å bruke et slikt og et slikt rammeverk? Hva var den største vanskeligheten for deg? Slike spørsmål kan ikke besvares med enstavelser. Mer presist er det eneste enkle svaret at jeg ikke har slik erfaring, jeg har ikke jobbet med dette verktøyet.
Hvordan implementere
Enkelt implementert ved hjelp av Google Forms. Det viktigste er å komme med spørsmål. Jeg bruker flere standard design.
Fortell oss om det siste prosjektet du gjorde ved hjelp av XXX, hva var det vanskeligste for deg i dette prosjektet?
Hva er de viktigste fordelene med XXX-teknologi for deg, gi eksempler fra din erfaring?
Etter å ha valgt XXX-teknologi, hvilke andre alternativer vurderte du og hvorfor valgte du XXX?I hvilke situasjoner ville du valgt AAA-teknologi fremfor BBB?
Fortell oss om det vanskeligste problemet du løste med XXX, hva var hovedproblemet?
Følgelig kan disse konstruksjonene brukes på mange teknologier i arbeidsstabelen din. Det er ikke lett å svare på slike spørsmål med malfraser fra Internett, siden de er personlige og om personlig erfaring. Når kandidaten svarer på disse spørsmålene, har kandidaten vanligvis tanken om at ved intervjuet kan et hvilket som helst av svarene hans utvikles i form av tilleggsspørsmål. Derfor, hvis det ikke er noen erfaring, trekker kandidatene seg ofte tilbake, og innser at videre samtale kan være meningsløs.
I hvilke tilfeller bruker jeg denne metoden?
Når jeg jobber med bestillinger for valg av spesialister, hvis kunden ikke har foreslått sin egen metode for primær kompetansetesting, bruker jeg denne metoden. Jeg har allerede utarbeidet spørreskjemaer om en rekke emner og det koster meg ingenting å bruke denne metoden for en ny kunde.
Fordeler
Enkel å implementere ved hjelp av Google Forms. Dessuten kan en ny undersøkelse gjøres basert på den forrige, og erstatte navnene på teknologier og verktøy med andre. For eksempel vil en undersøkelse om erfaring med React ikke være mye forskjellig fra en undersøkelse om erfaring med Angular.
Å lage et slikt spørreskjema tar 15-20 minutter, og kandidatene bruker vanligvis 15-30 minutter på å svare. Tidsinvesteringen er liten, men vi mottar informasjon om kandidatens personlige erfaring, som vi kan bygge ut fra og gjøre hvert intervju med kandidater unikt og mer interessant. Vanligvis er varigheten av intervjuet etter et slikt spørreskjema kortere, siden du ikke trenger å stille enkle, lignende spørsmål.
Begrensninger
For å skille en kandidats eget svar fra et "Googlet" svar, må du forstå emnet. Men dette kommer fort med erfaring. Etter å ha sett 10-20 svar vil du lære å skille kandidatenes egne originale svar fra de som finnes på Internett.
4. Live-Doing (Coding) – løse et enkelt problem i sanntid med en delt skjerm
Essensen av denne metoden er å be kandidaten om å løse et enkelt problem og observere prosessen. Kandidaten kan bruke hva som helst, det er ingen forbud mot å søke etter informasjon på Internett. Kandidaten kan oppleve stress ved å bli observert på jobb. Ikke alle kandidater godtar dette alternativet for å vurdere ferdighetene deres. Men på den annen side lar denne metoden deg se hvilken kunnskap en person har i hodet, hva han kan bruke selv i en stressende situasjon, og hvilken informasjon han vil gå til en søkemotor for. Nivået på kandidaten merkes nesten umiddelbart. Nybegynnere bruker de mest grunnleggende, til og med primitive funksjonene i språket, og begynner ofte å implementere funksjonaliteten til grunnleggende biblioteker manuelt. Mer erfarne kandidater er godt kjent med grunnleggende klasser, metoder, funksjoner og kan raskt løse et enkelt problem - 2-3 ganger raskere enn nybegynnere, ved å bruke funksjonaliteten til det grunnleggende språkbiblioteket som er kjent for dem. Enda mer erfarne kandidater starter vanligvis med å snakke om ulike tilnærminger til å løse et problem og presentere flere løsningsalternativer, og spørre hvilket alternativ jeg ønsker å se implementert. Alt kandidaten gjør kan diskuteres. Selv basert på samme oppgave, viser intervjuene seg å være svært forskjellige, det samme er kandidatenes løsninger.
Som en variant av denne metoden kan du be kandidaten om å ta en test for å teste faglig kompetanse, som rettferdiggjør valget av ett eller annet av svaralternativene. I motsetning til vanlig testing vil du finne ut hvor rimelig valg av svar var. Du kan komme opp med dine egne varianter av denne metoden, med tanke på egenskapene til ledig stilling.
Hvordan implementere
Denne metoden implementeres enkelt ved hjelp av Skype eller et annet lignende videokommunikasjonssystem som lar deg dele skjermen. Du kan komme opp med problemer selv eller bruke nettsteder som Code Wars og en rekke ferdige tester.
I hvilke tilfeller bruker jeg denne metoden?
Når jeg velger ut programmerere og det ikke helt klart fremgår av CV-en hvilket kunnskapsnivå kandidaten har, tilbyr jeg kandidatene et intervju i dette formatet. Min erfaring er at omtrent 90 % av utviklerne ikke har noe imot det. De er glade for at fra det aller første intervjuet begynner kommunikasjon om programmering, og ikke dumme spørsmål som "hvor ser du deg selv om 5 år."
Fordeler
Til tross for stress og angst hos kandidaten, er det generelle ferdighetsnivået til kandidaten umiddelbart og tydelig synlig. Kandidatens kommunikasjonsevner blir også tydelig synlige – hvordan han resonnerer, hvordan han forklarer og motiverer sin beslutning. Hvis du har behov for å diskutere en kandidat med kolleger, er det enkelt å lage et videoopptak av skjermen din og deretter vise intervjuet til andre.
Begrensninger
Kommunikasjonen kan bli avbrutt. På grunn av angst kan kandidaten begynne å bli dum. I denne situasjonen kan du ta en pause og gi ham tid til å tenke på oppgaven alene, ringe tilbake etter 10 minutter og fortsett. Hvis kandidaten etter dette oppfører seg merkelig, er det verdt å prøve en annen måte å vurdere ferdigheter på.
5. Kort ekspressintervju om ferdigheter på telefon/Skype
Dette er rett og slett en talesamtale over telefon, Skype eller et annet talekommunikasjonssystem. Samtidig kan vi vurdere kandidatens kommunikasjonsevner, hans lærdom og syn. Du kan bruke et spørreskjema som en samtaleplan. Alternativt kan du diskutere mer detaljert med kandidaten hans svar på spørreskjemaet ditt.
Hvordan implementere
Vi avtaler en samtale med kandidaten og ringer. Vi stiller spørsmål og registrerer svarene.
I hvilke tilfeller bruker jeg denne metoden?
Jeg bruker vanligvis denne metoden sammen med et spørreskjema når kandidatens svar virket originale eller ikke overbevisende nok for meg. Jeg snakker med kandidaten om spørsmålene fra spørreskjemaet og finner ut hans mening mer detaljert. Jeg anser en slik samtale som obligatorisk når kandidatens kommunikasjonsevner og evnen til å formulere sine tanker enkelt og tydelig er viktig.
Fordeler
Uten å snakke med en stemme om faglige emner, er det vanligvis umulig å fastslå hvor godt en kandidat kan uttrykke sine tanker.
Begrensninger
Den største ulempen er den ekstra tidsbruken. Derfor bruker jeg denne metoden i tillegg til andre, om nødvendig. I tillegg kommer kandidater som snakker godt om faglige temaer, men har lite praktisk kunnskap. Hvis du trenger en programmerer som konsekvent og effektivt løser problemer, er det bedre å velge en annen metode for primær kompetansetesting. Hvis du trenger en leder eller en analytiker, det vil si en spesialist som oversetter fra menneskelig språk til "programmerer" og tilbake, vil denne metoden for å teste kompetanse være veldig nyttig.
6. Testoppgave med kort tid (fullført på 30–60 minutter)
For en rekke yrker er det viktig for en spesialist å raskt kunne finne en løsning på et problem. Som regel er problemer ikke vanskelige å løse, men tiden det tar å løse problemet er viktig.
Hvordan implementere
Vi avtaler med kandidaten tidspunkt for gjennomføring av prøveoppgaven. Til avtalt tid sender vi kandidaten vilkårene for oppgaven og finner ut om han forstår hva som kreves av ham. Vi registrerer tiden kandidaten bruker på å løse problemet. Vi analyserer løsningen og tiden.
I hvilke tilfeller bruker jeg denne metoden?
I min praksis ble denne metoden brukt til å teste kompetansen til tekniske støttespesialister, SQL-programmerere og testere (QA). Oppgavene var som "finne problemområder og finne ut hvordan du fikser problemet", "optimalisere SQL-spørringen slik at den fungerer 3 ganger raskere", etc. Selvfølgelig kan du finne på dine egne oppgaver. For begynnende utviklere kan denne metoden også brukes.
Fordeler
Vi bruker tiden vår kun på å utarbeide og sjekke oppgaven. Kandidaten kan velge et tidspunkt som passer for ham for å fullføre oppgaven.
Begrensninger
Den største ulempen er at løsninger på dine problemer eller lignende kan bli lagt ut på Internett, så du må ha en rekke alternativer og med jevne mellomrom komme med nye oppgaver. Hvis du trenger å teste reaksjonshastigheten og horisonten din, velger jeg personlig tidsbestemte tester (metode nr. 2).
7. Studer kandidatens portefølje, kodeeksempler, åpne arkiver
Dette er kanskje den enkleste måten å teste kompetanser på, forutsatt at kandidatene dine har en portefølje og du har spesialister i utvalgsteamet som kan vurdere porteføljen.
Hvordan implementere
Vi studerer kandidatenes CV. Finner vi lenker til mappen studerer vi dem. Hvis det ikke er indikasjon på en portefølje i CV-en, ber vi om en portefølje fra kandidaten.
I hvilke tilfeller bruker jeg denne metoden?
I min praksis ble denne metoden brukt svært sjelden. Det er ikke ofte at en kandidats portefølje inneholder arbeid med ønsket emne. Erfarne kandidater foretrekker ofte denne metoden i stedet for en typisk og uinteressant testoppgave. De sier, "se på rappen min, det er dusinvis av eksempler på mine løsninger på forskjellige problemer, du vil se hvordan jeg skriver kode."
Fordeler
Kandidatenes tid er spart. Hvis fagfolkene i teamet ditt har tid, er det mulig å raskt og uten kommunikasjon med kandidater luke ut uegnede. Mens rekruttereren ser etter kandidater, vurderer hans kollega porteføljen. Resultatet er ganske raskt og parallelt arbeid.
Begrensninger
Denne metoden kan ikke brukes for alle IT-yrker. For å vurdere en portefølje, må du ha utviklet ferdigheter selv. Hvis du ikke er en spesialist, vil du ikke være i stand til å kvalitativt vurdere porteføljen.
Kolleger, jeg inviterer dere til å diskutere det dere har lest i kommentarene. Fortell oss, hvilke andre metoder for å raskt teste kompetanser bruker du?
Kilde: www.habr.com