Hvordan kan jeg bestemme, om en kodningsopgave er for hård for en interviewkandidat?

Dit spørgsmål er tvetydigt. Lad mig prøve at sprænge det op. Jeg tror, ​​hvad du virkelig beder om er:

Vi har en proces til at opnå et signal fra kandidater om deres fitness . Hvis processen producerer et "no hire" -signal for kandidater, der faktisk er egnede, kan den tekniske spørgsmålsdel af processen muligvis være for vanskelig. Hvordan kan jeg afgøre, om et spørgsmål er for svært?

Det er let; som andre har sagt, sæt dine kolleger, der er kendt for at være fit gennem processen; hvis processen konsekvent afviser dem, så er der noget galt med processen.

Men det er ikke det problem, du har . Dette er et spørgsmål og svar-websted, og du har stillet det forkerte spørgsmål.

Det problem, du faktisk har, er en betydelig del af kandidaterne er klart uegnede , og dette spilder tid, kræfter og penge, der bedre kan bruges andre steder.

Du har et pipeline-problem, ikke et kodningsspørgsmålsproblem. Noget i din kandidatrørledning producerer en stor brøkdel af klart uegnede kandidater. Som det er kendt, har en lang række ansøgere til programmeringsjob ingen evner overhovedet til at skrive selv enkle programmer : https://blog.codinghorror.com/why-cant-programmers-program/

Spørg rundt og se om andre interviewere har lignende problemer. Hvis de er det, skal du skubbe tilbage til ledelse og rekruttering for at se, om de kan finde ud af, hvad der tilskynder rekruttering til fortsat at sende dig ukvalificerede kandidater.

Hvordan kan jeg bestemme, om en kodningsopgave, der bliver spurgt i interviewet, er for hård?

Synes, at de svigtende kandidater er bevis for, at din kodningsopgave kan være mere udfordrende end du tænker.

Empirisk kan du afgøre, om fremtidige kodningsopgaver er "for hårde", hvis du ser flere kandidater mislykkes eller tager for meget tid på at gøre dem.

Du kan også få dig selv eller nogle tekniske kolleger til at prøve at udføre kodningsopgaverne, tage dig tid til at gøre det og derefter sammenligne dine resultater med uanset dine forventninger til de særlige opgaver. Du kan derefter afgøre, om det har brug for en vis forenkling for at kunne gennemføre i et almindeligt kodningssamtale.

Husk, at kodningssamtaler eller tests normalt ikke bør være for lange . Ellers vil du ikke faktisk evaluere viden om sagen, men i stedet bare se, hvem der er bedre til at foregive at kende et programmeringssprog (om 2 timer kan alle søge og blive en "ekspert" på ethvert Stack Overflow-tag). Normalt er enkle og ligetil spørgsmål eller opgaver mere effektive til at måle sprogkundskabet såvel som noget kreativitet og improvisation.

Jeg foreslår også, at du kigger på dette spørgsmål, hvor der gives flere svar, der kan hjælpe med at beslutte, om en bestemt opgave skal fjernes eller ej.

Jeg havde lignende problemer med meget enkle kodningsspørgsmål. Det ser ud til, at mange mennesker er, hvad vi kaldte "troldmandens lærlinge" efter IDE-kodegeneratorguiden og Micky Mouse-tegneserien. De tror, ​​de kender C ++, men har virkelig ingen idé om, hvordan man skriver en klasse, endda en enkel.

Her er den første. Jeg læser det altid for at give nøjagtig den samme ordlyd til alle, men fra hukommelsen nu: "Skriv en klasse, hvis konstruktør tager to integrerede argumenter og har medlemmer til at returnere deres sum og forskel."

Jeg forventede for at se forskellige niveauer af, hvor godt de undersøgte specifikationerne for at sømme tingene ned, inden de startede, og folk, der brugte skabeloner i stedet for at vælge en bestemt type osv.

Hvad jeg fik var et overraskende antal mennesker, der kunne ikke skriv en klasse, punktum.

for eksempel at finde det næststørste tal i en matrix

Som jeg sagde, søm ting ned før kodning:

• Kan jeg ændre arrayet?
• Mente du det andet element i sorteret rækkefølge, eller mener du den næststørste unikke værdi ([1,2, 2,3,3,3] er svaret 3 eller 2?)?
• Skal det behandle arrays, der har færre end 2 elementer (eller unikke elementer, afhængigt af svaret til forrige)? Kast undtagelse, planlæg for valgfri returværdi, eller hvad?

Skal jeg afklare specifikationerne (og blive underskrevet på den) og derefter skrive kritiske testsager som i "det virkelige liv"?

Dine angivne mål er i modstrid med den uklare specifikation. Som nævnt skal du virkelig teste engineering færdigheder først og derefter kodningsfærdigheder. Og vil du virkelig ansætte nogen, der vil smide et ulæseligt alt for klogt uvedligeholdeligt rod? Jeg sætter spørgsmålstegn ved klogheden i ikke at bekymre sig om syntaksen.

Hvis du bare vil vide, om de kan nærme sig problemet, skal du gøre oraler snarere end en kodningsopgave. Få ham til at forklare, hvordan han ville gøre det: f.eks. Jeg kender til standardalgoritmen, så duh. Hvis det gør, hvad du virkelig ønskede. Bliv imponeret over, at jeg har nyttige referencer, der er bogmærket og altid er åben, og skal ikke bekymre dig om det sidste trin i at skrive et prøveprogram, der indeholder en linje, der kalder denne funktion.

Så jeg stiller spørgsmålstegn ved, om din test virkelig er klar til, at nogen bare koder, eller hvis de problemer, jeg påpegede, ville lamme den kandidat, der får at vide, at dette er en komplet specifikation klar til kodning?

Hvordan kan jeg bestemme, om en kodningsopgave, der bliver spurgt i interviewet, er for hård?

Der er forskellige måder. Langt det nemmeste er at finde et samfund af mennesker, som du vil ansætte, og spørge dem.

Dette kan være en gruppe med møder. Dette kan være interne mennesker. Måske online fora. For programmører får du tons feedback, fordi de fleste programmører kan let blive nørdede med "hej, kan du hjælpe mig med at se, hvor lang tid dette programmeringsspørgsmål tager?"

Find også ud af standard introduktion til dine spørgsmål, så alle får de samme oplysninger. Måske et diskussionsark til problemets introduktion. Interview kan være stressende for begge parter.

Så snart du har tid til opgaven, gang du den med mindst 1,5 for at redegøre for nervøsitet, der er forbundet med interviews og bam, har du et gæstestimat for tiden det skulle tage. Hvis de fleste af dine interne medarbejdere giver dig et svar på 20 minutter, er det urimeligt for nogen under et meget højere og mere akavet pres fra et interview at konsekvent gøre det også.

For det andet er det nyttigt at give folk nogle . Fortæl dem på forhånd om det værktøj, du vil bruge i din tilmelding til interviewet. Fortæl kandidater, hvilket sprog de kan / ikke kan bruge (jeg kan programmere meget bedre i Python end at sige Java, så jeg kan løse problemer i 10% af tiden i Python end Java). Sørg for, at de ved, hvad de kan forvente. Værktøjet kan være meget akavet i starten, og du ønsker ikke rigtig at afvise folk på grund af dette.

Og sidst, når du taler igennem problemerne, opfordrer kandidaterne til at tale højt med deres tanker. Dette vil gøre en række ting:

• Identificer, hvad der er uklart ved problemet, så det kan afklares
• Separat mennesker, der er nervøse og laver syntaksfejl, som de kender konceptuelt fra mennesker, der ikke er clueless
• Giv dig flere oplysninger om deres færdigheder end bare koden

Da jeg har interviewet et par dusin kandidater ved hjælp af en kodningsopgave, tror jeg, at jeg måske har en vis indsigt:

For at vurdere den virkelige verdens programmeringsfærdighed skal testen gennemføres i et virkeligt verdensmiljø. Det betyder en IDE, ikke en tavle. Det betyder adgang til google og et stille arbejdsmiljø, ikke konstant afbrydes af spørgsmål eller råd fra en interviewer.

At bestå testen burde ikke kræve et perfekt program, fordi programmer i den virkelige verden normalt ikke er perfekte ved første forsøg. Jeg er tilfreds med at se gode fremskridt hen imod en fungerende løsning. Hvis der forbliver fejl, bekræfter jeg, at kandidaten er i stand til at genkende fejlen efter anmodning og kan beskrive en rimelig løsning.

For at vurdere testens vanskelighed skal du gøre det selv eller give det til nogle kolleger (spejling af samtaleforhold så tæt som praktisk). Se også på de kandidater, du endte med at ansætte på trods af en marginal kodningstest. Forudsagte testen deres faktiske arbejdsindsats?

Når det er sagt, selvom din test er perfekt, er det helt normalt at møde en lejlighedsvis kandidat, der ikke kan programmere sig ud af en papirpose. Jeg tror ikke, jeg nogensinde vil glemme kandidaten, der erklærede sig Java-ekspert, men på en eller anden måde ikke kunne nå nogen steder i kodningsøvelsen. Mærkeligt for en så dårlig præstation forblev deres browservindue uberørt - men de havde glemt at rydde browserhistorikken, som afslørede google-søgninger som "hvordan man erklærer en klasse i Java". Han fik ikke jobbet, men jeg var nødt til at gentage mig selv 4 gange, før ansættelseslederen troede mig, at kandidaten, der havde talt så fortroligt om hans store erfaring faktisk ikke havde nogen anelse.

Hvis du får mange dårlige kandidater, er det også muligt, at den indledende screening er utilstrækkelig. En total mangel på kvalificerede ansøgere kan også betyde, at din jobfortegnelse er vildledende eller utilstrækkeligt annonceret - eller måske er der simpelthen ikke nok kodere på udkig efter et job i dit område.

Når jeg plejede at udvælge kandidater, der skulle ansættes, lavede jeg nogle live kodningstest. En ting, jeg plejede at sige var: "Brug gjerne Google, hvis du har brug for at søge efter inspiration". Hvad jeg ledte efter, mere end evnen til at huske alle biblioteker med et bestemt sprog udenad, det var evnen til at "fokusere problemet, bygge en idé om, hvordan man løser det, se efter en måde at implementere det på" Jeg var virkelig interesseret i at teste. Jeg har ikke noget imod det, hvis de vil se efter en lignende tilgang i Stack Overflow. Med denne tilgang var jeg ligeglad med, hvor meget problemet kunne være mere eller mindre (altid overvejer jeg selvfølgelig, at udfordringen skulle udføres på en rimelig tid) ...

IMO, skabeloner og skeletter, der skal udfyldes, er mere forvirrende end simpel opgave fra bunden, især når vi taler om 3-4 linjers løsning. Hvad med trin-for-trin algoritmebeskrivelsesopgave? Alle i branchen kan gøre det, hvis han kan kalde sig programmør. Og hvis kandidaten kan skrive algoritme, kan han implementere den.

Måske tror de, at du prøver at lokke det brugbare arbejde ud af dem under foregivelse af testopgave.

Hvis du holder opgaven kort og enkel uden tilsyneladende forbindelse til faktisk brugbarhed, skal du ikke have problemer.