Kan HackerRank upptäcka klipp-och-klistra?

HackerRanks övervakningssystem registrerar inklistringshändelser i kodredigeraren. Kandidatrapporten visar att en inklistring skedde och var i sessionen det hände.

Det posten inte innehåller är ursprunget. Redigeraren är en webbsida; den tar emot vilken text operativsystemet än ger den och har inget sätt att fråga varifrån den texten kopierades. Din egen anteckningsfil, ett dokumentationsexempel och ett chattbotssvar kommer alla in som samma händelse.

Två konsekvenser följer av detta. Att klistra in ett utdrag du själv skrev fem minuter tidigare i ett annat fönster loggas exakt som att klistra in en färdig lösning. Och en ren inklistringslogg bevisar inte att du arbetade utan hjälp, eftersom skrivande inte spåras som bevis på författarskap.

Klustret om upptäckbarhet (detectability) tar upp samma fråga för andra bedömningsplattformar.

De flesta hamnar i den här frågan i efterhand, efter att ha klistrat in något under ett test och undrar hur illa det ser ut. Det här avsnittet beskriver vad en granskare ser. Det korta svaret är att formen på en inklistring bär betydligt mer betydelse än att den överhuvudtaget existerar.

En handfull små inklistringar utspridda över en lång session läses som normalt arbetsbeteende. Ingen skriver om en URL eller ett block med testdata för hand. En enda inklistring som fyller en tom redigerare med en fullständig, korrekt lösning läses annorlunda, eftersom det visar att svaret kom i sin helhet i stället för att utvecklas.

Tidpunkten förstärker detta. En inklistring under första minuten av ett problem, direkt följd av en inlämning, berättar en annan historia än en inklistring som kommer efter synlig iteration. Tänk dig en kandidat som gör ett data engineering-screeningtest och håller en personlig utdragsfil öppen: flera små inklistringar dyker upp, koden ändras sedan upprepade gånger, och rapporten läses som normalt arbete. Inget i den loggen behöver försvaras.

Det här är två oberoende system, och att blanda ihop dem orsakar mycket onödig oro.

• Inklistringsloggning är en beteendesignal som fångas live i redigeraren. Den säger att en handling inträffade.
• Kodlikhetspoängsättning körs på den inlämnade koden och jämför den med andra kandidaters inlämningar och kända källor. Den säger att resultatet liknar något annat.

Du kan utlösa den ena utan den andra. Att skriva om en kopierad lösning för hand ger ingen inklistringshändelse och poängsätts ändå som likartad. Att klistra in ditt eget originalarbete ger en inklistringshändelse och poängsätts inte alls som likartad.

En granskare ser båda på samma rapport och läser dem tillsammans. Det är också därför en enda flagga sällan avslutar något: det vanliga nästa steget är en livesession där du förklarar ditt tillvägagångssätt, vilket löser oklarheten snabbare än vilken logg som helst.

SubcueAI hjälper till vid live muntliga intervjuer. Skrivbordsappen på macOS och Windows fångar systemljud och din mikrofon och visar förslag på ett lokalt overlay; webbläsartillägget Side Panel gör samma sak för ett samtal som körs i en Chromium-flik, och fångar bara den flikens ljud, vilket betyder intervjuarens röst och inte din. Ingen bot ansluter till mötet och inget injiceras i mötessidan.

En HackerRank-kodningsbedömning är inte den situationen. Ingen talar, så det finns inget att transkribera, och att ta in extern hjälp i en bedömning bryter mot villkoren du accepterade när du påbörjade den. Vi hävdar inte att något verktyg är odetekterbart där. Skärmdelning, skärminspelning, övervakade sessioner och företagsstyrda laptoppar ligger alla utanför vad ett lokalt overlay kan påverka.

Där en assistent verkligen hjälper till med HackerRank är före och efter. Att öva med övningsintervjuer (mock interview) bygger upp vanan att förklara kod högt, vilket är precis vad en genomgång efter bedömningen ber dig om. Detaljer om inspelning och latens finns i klustret om hur det fungerar (how it works).