Näin luot koodaustestin

What you'll need

• SkillCort-työtila (tai esittely)
• Todellinen esimerkki koodista jota tiimisi kirjoittaa — bugi, pieni ominaisuus, refaktorointi
• Kokenut ohjelmistokehittäjä määrittelemään tehtävän ja arviointimatriisin
• Päätös siitä mitkä kielet hyväksytte

Step 1: Valitse realistinen tehtävä algoritmipulman sijaan

Katso viime kuukauden pull requesteja ja poimi tehtävä, joka on samanmuotoinen kuin toistuvat: korjaa bugi annetun vikakäyttäytymisen perusteella, laajenna pientä funktiota käsittelemään uusi tapaus, refaktoroi sotkuinen lohko tai kirjoita datamuunnos. Nämä ennakoivat päivittäistä suoriutumista paljon paremmin kuin binääripuun kääntäminen.

Mitoita se 30–45 minuutin keskittyneeseen työhön pätevälle rekrytoinnille. Pulma palkitsee sen joka on harjoitellut sitä; realistinen pieni tehtävä palkitsee sen joka osaa lukea olemassa olevaa tarkoitusta, tehdä järkevän muutoksen ja pitää koodin ymmärrettävänä — mikä on se mihin rekrytoit.

Riisu kehys- ja yrityskohtainen tieto pois, ellei rooli aidosti vaadi sitä, ja anna kaikki tehtävän tarvitsema konteksti itse toimeksiannon sisällä. Vahvan kehittäjän, joka ei ole koskaan koskenut teknologiapinoasi, tulisi silti pystyä näyttämään sinulle järkevää harkintaa. Testaa taitoa, älä koodikantasi nippelitiedon tuntemusta.

• Toistuu todellisessa koodikannassasi, ei haastatteluvalmennuskirjoissa
• Sillä on useampi kuin yksi järkevä ratkaisu
• Mahtuu 30–45 minuuttiin ilman sankaritekoja
• Arvioija pystyy lukemaan sen alle kymmenessä minuutissa

Step 2: Luo koodin tehtävä tehtäväpankkiin

Tee roolille kansio — vaikkapa Backend-kehittäjä — tageineen taitoalueelle ja vaikeudelle, ja luo sitten tehtävä käyttäen koodin tehtävätyyppiä. Hakijat kirjoittavat ja muokkaavat koodia suoraan vastausalueella, ja arvioijat tarkastavat sen myöhemmin paikan päällä.

Siemennä tehtävä aloituskoodilla tyhjän editorin sijaan. Lyhyt funktio kuvattuine bugeineen, tai tynkä selkeine sopimuksineen, ankkuroi jokaisen hakijan samaan lähtökohtaan ja tekee heidän muutoksistaan suoraan vertailukelpoisia. Todellinen työ ei lähes koskaan ala tyhjästä tiedostosta, eikä testinkään pitäisi.

Step 3: Kirjoita toimeksianto editorin viereen

Käytä rinnakkaista ärsykeasettelua: toimeksianto, vaatimukset sekä esimerkkisyötteet ja -tulosteet toisella puolella, koodieditori sen vieressä. Hakijan ei tarvitse koskaan vierittää pois määrittelystä kirjoittaakseen ratkaisun — sama muoto kuin tiketistä työskentely kehitysympäristössä.

Kirjoita toimeksianto niin kuin hyvä tiketti lukeutuu: nykyinen käyttäytyminen, odotettu käyttäytyminen, rajoitteet ja kaksi tai kolme konkreettista esimerkkiä. Ilmaise nimenomaisesti mistä välität — „toimiva koodi ensin; luemme myös selkeyttä” — jotta hakijat optimoivat sen mukaan mitä tosiasiassa pisteytät. Monitulkintaisuus toimeksiannossa muuttuu kohinaksi tuloksissa.

Step 4: Rakenna arviointimatriisi, joka pisteyttää muutakin kuin oikeellisuutta

Oikea tuloste on välttämätön, ei riittävä. Rakenna tasopohjainen matriisiarviointimatriisi kolmella tai neljällä kriteerillä — tyypillisesti oikeellisuus, luettavuus ja lähestymistapa, valinnaisesti reunatapausten käsittely — joista kullakin on ankkuroidut kuvaukset siitä miltä vahva, hyväksyttävä ja heikko koodi näyttää. „Nimet paljastavat tarkoituksen, ei kuollutta koodia” on pisteytettävissä; „siisti koodi” ei ole.

Painota oikeellisuutta raskaimmin, mutta pidä muut kriteerit todellisina: hädin tuskin toimiva ratkaisu jota kukaan ei voi ylläpitää ei ole vahva rekrytointisignaali. Kun liität arviointimatriisin, se jäätyy tilannekuvaksi, joten jokainen ajon hakija tarkastetaan identtistä mittapuuta vasten vaikka pankin versio kehittyisi myöhemmin.

Step 5: Kokoa ja aikarajaa rakentimessa

Luo arviointi osioina, sivuina ja lohkoina ja tuo koodin tehtävä sisään valitsimella. Monet tiimit lisäävät lyhyen ensimmäisen osion nopeita harkintakysymyksiä — diffin lukemista, bugin bongaamista katkelmasta, pikaliitettynä monivalintana — ja laittavat koodaustehtävän omaan osioonsa.

Aseta kokonaisaikaraja väljyydellä lukemiselle ja ajattelulle, ja käytä sivukohtaista rajaa koodaussivulla, jottei tehtävä voi niellä koko suorituskertaa. Painota koodausosiota raskaimmin (esimerkiksi ×3), jotta roolisopivuus Decision Boardilla heijastaa työtä eikä lämmittelyä. Kirjoita ohjeet, jotka nimeävät sallitut kielet ja sen mitä tapahtuu jos aika loppuu.

Step 6: Esikatsele, käy tarkistuslista läpi ja julkaise

Käytä Esikatsele hakijana -toimintoa ja yritä tehtävää itse, tai vielä parempaa, anna sellaisen kehittäjän yrittää sitä kylmiltään joka ei kirjoittanut sitä. Jos hän saa sen valmiiksi kymmenessä minuutissa, se on liian helppo; jos hän ei saa sitä valmiiksi rajan sisällä, löysää laajuutta tai kelloa. Korjaa toimeksianto kaikkialta missä hän epäröi.

Täytä sitten julkaisun tarkistuslista — se estää julkaisun kunnes pisteytys, ajoitus ja ohjeet ovat valmiit. Koodaustesti, jolta puuttuu arviointimatriisi tai jonka aikarajaa ei ole testattu, ei saisi koskaan tavoittaa hakijaa, ja tarkistuslista varmistaa ettei se voi.

Step 7: Aseta luotettavuuskontrollit oikeasuhtaisiksi panoksiin

Luo toteutus nimineen ja aikaikkunoineen, ja valitse sitten turvallisuuskytkimet harkitusti. Tavallisessa rekrytointiseulonnassa kopioinnin ja liittämisen esto sekä koko näytön lockdown järkevällä rikkomusrajalla riittävät yleensä. Verkkokameran tallennus, näytön tallennus, lisänäytön tunnistus ja henkilöllisyyden tarkistukset ovat olemassa aidosti korkean panoksen ajoja varten — sertifiointiin, loppukierroksiin — eivät oletuksiksi.

Kaikki mitä otat käyttöön kerrotaan suostumus- ja esitarkistusportilla ennen kuin hakija aloittaa. Luotettavuussignaalit ovat merkintöjä ihmisen tarkastettavaksi kontekstissaan, eivät koskaan peruste automaattiselle hylkäykselle — koko näytön tilasta poistuminen voi olla ilmoitus, ei petos. Oikeasuhtaisuus estää vahvoja hakijoita kävelemästä pois valvontahaavin edestä.

Step 8: Tarkasta koodi arviointimatriisilla, tekoäly tukena

Arvioijat tarkastavat kunkin palautuksen yhteistä arviointimatriisia vasten klikkaamalla sitä tasokorttia joka vastaa koodia kussakin kriteerissä — oikeellisuus, luettavuus, lähestymistapa. Kahden tarkastajan asettaminen rajatapauksiin tai korkean panoksen tapauksiin pitää mittapuun rehellisenä, ja koska kaikki pisteyttävät samaa jäädytettyä arviointimatriisin tilannekuvaa vasten, erimielisyydet nousevat esiin täsmällisinä kriteerikuiluina eivätkä epämääräisinä tuntumaeroina.

Tekoäly voi luonnostella yhteenvedon palautuksesta ja ehdottaa kriteeritason pisteitä — aidosti hyödyllinen ensimmäinen kierros koodissa, malli ja versio kirjattuina. Mutta nimetty kehittäjä vahvistaa tai ohittaa jokaisen pistemäärän. Tekoäly on täällä päätöksen tukea, ei koskaan päätöksentekijä: vastuullinen harkinta hakijan koodista on aina ihmisen.