¿Cuán larga debe ser una asignación take-home de coding?
La respuesta corta
Etapa de cribado: 60-90 minutos, hard cap. Etapa onsite: 2-3 horas si debes usar take-home; sino prefiere formatos en vivo. Etapa final: nunca. Las candidatas senior no deberían hacer take-homes de 4 horas para final.
Estos números asumen que la candidata sigue el time cap. En la práctica muchas gastan 1.5-2× el tiempo declarado. Diseña la tarea asumiendo el cap declarado, y confía en la rúbrica para manejar varianza.
Por qué bajo 90 minutos para etapa de cribado
Tres razones:
- Ancho del pipeline. Cada 30 minutos adicionales de tiempo de take-home baja tu tasa de conversión de invitación a sumisión por aproximadamente 5-10 puntos porcentuales, con drops mayores en el high end.
- Varianza en tiempo gastado. Take-homes más largos tienen mayor varianza en tiempo real, lo que significa que estás midiendo disponibilidad tanto como skill.
- Señal marginal. Un test bien diseñado de 90 min produce 80% de la señal de un test de 4 horas. El 20% restante no vale el coste para candidata.
Cuándo más largo es apropiado
- Asignaciones onsite-stage pagadas. Un proyecto scopeado de 4-8 horas, pagado a tarifa justa, tarde en el loop, opcional. Algunos equipos lo usan para roles senior+ para reemplazar un onsite de medio día. Aceptable si pagado y opcional.
- Trial weeks. Categoría distinta. Razonable para hires senior con notice periods, roles ejecutivos o arreglos contract-to-hire.
- Roles que genuinamente requieren artefacto. Algunos roles (technical writing, design) necesitan portfolio en cribado. Aún así, scope a 3 horas max.
Qué fitar en 60-90 minutos
Una tarea scopeada con un deliverable claro:
- Añadir feature a codebase provisto
- Arreglar tres bugs documentados
- Analizar dataset provisto y producir writeup de 1 página
- Refactorear módulo desordenado provisto con goal declarado
Evita scope abierto ("construye una app pequeña que haga X"). La varianza en interpretación matará tu rúbrica.
Qué hacer con el time cap
Pide a las candidatas trackear y autoreportar tiempo gastado. Créeles, pero rubric-ánclate: una candidata que reporta 90 min y produce 4 horas de trabajo polido ha gastado efectivamente 4 horas. La rúbrica debería recompensar la cantidad correcta de completion para el tiempo declarado.
ClarityHire timestampea sesiones de evaluación y saca a la luz el tiempo elapsed real junto al self-report. La discrepancia es señal: no en sentido punitivo, sino como contexto para el revisor.
Qué nunca hacer
- "Esperamos 4-8 horas de trabajo." Esto es mentira piadosa. La candidata o lo gasta (y la pierdes a competidores más rápidos) o no (y has miscalibrado).
- "Open-ended, toma lo que necesites." Worst possible framing.
- "Evaluaremos basado en calidad, no velocidad." Significa que la candidata optimiza por polish sobre señal.
La alternativa estructural
Si te encuentras queriendo take-homes más largos, la necesidad subyacente suele ser "quiero ver juicio de ingeniería real, no solo un fix pequeño." La respuesta correcta rara vez es "hazlo más largo." Suele ser "añade una entrevista walk-through."
Un take-home de 90 min + walk-through de 30 min produce dramáticamente más señal que un take-home de 4 horas solo. El walk-through testea el razonamiento de la candidata sobre su propio trabajo — que es lo que el take-home más largo intentaba implícitamente medir. Llega ahí directo.