Hoe lang moet een take-home codering opdracht zijn?

het korte antwoord

screen fase: 60–90 minuten, hard cap. onsite fase: 2–3 uren als je een take-home moet gebruiken; anders liever live formaten op deze fase. uiteindelijke fase: nooit. senior kandidaten moeten 4-uur take-homes niet doen voor finale-ronde.

deze nummers veronderstellen de kandidaat volgt het tijd cap. in praktijk vele kandidaten besteden 1.5–2× het gesteld tijd. ontwerp je taak veronderstelling de gesteld cap, en vertrouw de rubric naar omgang variantie.

waarom onder 90 minuten voor screen fase

drie redenen:

1. pijplijn breedte. elke bijkomend 30 minuten take-home tijd daalt je conversie percentage van uitnodiging naar indiening ongeveer 5–10 percentage punten, met groter daalt op de hoge einde.
2. variantie in tijd besteed. langer take-homes hebben hoger variantie in werkelijk time besteed, wat betekent je meet beschikbaarheid zoveel als vaardigheid.
3. marginaal signaal. een welontworpen 90-minuten test produces 80% van het signaal een 4-uur test zou. het overblijvende 20% is niet kandidaat kosten waard.

wanneer langer passend is

• onsite-fase betaald opdrachten. een 4–8 uur scoped project, betaald op een eerlijk percentage, laat in de lus, optioneel. sommige teams gebruiken dit voor senior+ rollen naar vervangen een half-dag onsite. acceptabel als betaald en optioneel.
• proef weken. anders categorie. redelijk voor senior aangenomen met kennisgeving perioden, leidinggevend rollen of contract-naar-huurafspraken.
• rollen die eigenlijk een artefact vereisen. sommige rollen (technisch schrijven, ontwerp) hebben een portefeuille-stijl artefact op screen fase. zelfs dan, reikwijdte naar 3 uren max.

wat te passen in 60–90 minuten

een scoped taak met één duidelijk geleverd:

• voeg een kenmerk toe aan een verleende codebase
• repareer drie documented bugs
• analyseer een verleende dataset en produce een 1-pagina writeup
• refactor een verleende rommelig module met een gesteld doel

vermijd open-eindige reikwijdte ("bouw klein app naar doen X"). variantie in reikwijdte interpretatie zal je doden rubric.

wat naar doen over het tijd cap

vraag kandidaten naar volgen en zelf-rapport time besteed. geloof hen, maar rubric-anker: een kandidaat die zelf-rapport 90 minuten en produce 4 uren pool werk heeft effectief 4 uren besteed. de rubric moet belonen het juiste hoeveelheid voltooiing voor de gesteld tijd.

ClarityHire timestamps beoordeling sessies en oppervlak het werkelijk verstreken time naast kandidaat's zelf-rapport. het verschil is signaal: niet in de punitieve zin, maar als context voor reviewer.

wat nooit naar doen

• "we verwachten 4–8 uren van werk." dit is een beleefd leugen. de kandidaat ofwel besteden het (en je verliest hen naar sneller concurrenten) of niet (en je hebt miscalibrated).
• "open-eindige, neem zoveel tijd je nodig." ergste mogelijke framing — stimuleert meest betrokken kandidaten naar overspend.
• "we zullen evalueren op basis van kwaliteit, niet snelheid." betekent kandidaat optimizeert voor pool over signaal, wat de verkeerde prikkel is.

de structuur alternatief

als je jezelf vindt wilt langer take-homes, de onderliggende noodzaak is meestal "ik wil zien echte engineering oordeel, niet gewoon klein reparatie." het juist antwoord is zelden "maak het langer." het is meestal "voeg een doorloop interview."

een 90-minuten take-home + 30-minuten doorloop produce dramatisch meer signaal dan een 4-uur take-home alleen. de doorloop tests kandidaat's redenering over hun eigen werk — wat de langer take-home was impliciet probeert naar meten. krijgen daar direct.