Cómo diseñar ejercicios de código que los candidatos no odien

Un ejercicio de código bien estructurado es un ejercicio de programación realista, acotado en el tiempo, que predice el rendimiento laboral mejor que las entrevistas de pizarra y respeta el tiempo del candidato. Las pruebas de muestra de trabajo (work sample tests) tienen un coeficiente de validez de 0,33 con el éxito profesional, según el metaanálisis de 1998 de Schmidt y Hunter publicado en el Journal of Applied Psychology. Cuando se combinan con una entrevista de seguimiento estructurada, esa validez sube a 0,63. La diferencia entre un ejercicio de código que los candidatos respetan y uno que destrozan públicamente en Reddit se reduce a siete decisiones de diseño.

Por qué las entrevistas de pizarra perdieron

Las entrevistas de live coding tradicionales reducen el rendimiento cognitivo de un candidato simplemente por el estrés de ser observado, según un estudio de 2020 de la North Carolina State University publicado en el Journal of Systems and Software. El candidato resuelve un puzzle algorítmico artificial en una pizarra, con un entrevistador vigilando cada pulsación de tecla y un reloj en cuenta atrás. Esto mide tolerancia a la ansiedad, no habilidad como ingeniero.

La industria lo reconoció. El DevSkiller 2023 Technical Hiring Report concluyó que las pruebas de código para llevar a casa se habían convertido en el formato de evaluación técnica dominante, superando al live coding. Las encuestas del sector muestran de forma consistente que la mayoría de los desarrolladores prefiere las pruebas para llevar a casa frente a las entrevistas de pizarra.

Pero el cambio trajo nuevos problemas. Las empresas reemplazaron un formato roto por otro igual de roto. Cambiaron tests de ansiedad de 45 minutos por maratones de trabajo no remunerado de 20 horas. La herramienta cambió; la falta de respeto siguió igual.

Qué odian realmente los candidatos de los ejercicios de código

El rechazo hacia los ejercicios de código no va sobre el concepto, sino sobre la ejecución. En Hacker News, Reddit r/ExperiencedDevs y las redes sociales de ingeniería, las quejas se agrupan en tres fallos concretos.

Estimaciones de tiempo engañosas

La queja más común: pruebas anunciadas como de “2-3 horas” que en realidad requieren 8-10. CodeSubmit informa de que los ejercicios bien acotados alcanzan tasas de finalización de hasta el 92 %. Pero cuando las empresas piden construir aplicaciones full-stack desde cero, las tasas de abandono se disparan. La brecha entre el tiempo anunciado y el real destruye la confianza al instante.

La carrera armamentista del over-engineering

Cuando las instrucciones son vagas, los candidatos se sienten obligados a sobredimensionar la solución. Añaden suites de tests exhaustivas, configuraciones de Docker y documentación pulida porque no tienen idea de qué valora la rúbrica. Los enunciados abiertos convierten un ejercicio de código en una carrera armamentista donde gana quien más tiempo libre tenga.

Silencio después de la entrega

Los candidatos invierten horas de trabajo no remunerado, envían su código y no reciben respuesta. Ni feedback. Ni email de rechazo. Solo silencio. En las comunidades de ingeniería, hacer ghosting después de una prueba de código se considera una de las mayores faltas de respeto por parte de una empresa. Algunos candidatos incluso han revocado el acceso a sus repositorios de GitHub tras ser ignorados, una señal clara de que la relación se rompió.

A quién excluyen las pruebas mal acotadas

Las pruebas para llevar a casa sin límite claro crean un problema de diversidad que la mayoría de los equipos de selección nunca abordan. El candidato que puede dedicar un fin de semana entero a un proyecto no remunerado es, estadísticamente, más probable que sea joven, sin pareja y sin responsabilidades de cuidado.

Los padres trabajadores, las personas que cuidan de familiares y los candidatos con varios empleos no tienen el lujo de dedicar un fin de semana a una candidatura especulativa. Un proceso de selección que exige tiempo extenso no remunerado excluye sistemáticamente a esa bolsa de talento.

Los candidatos neurodivergentes y los candidatos con discapacidades enfrentan barreras adicionales. Los entornos de presión con tiempo limitado pueden disparar la ansiedad de rendimiento. Los tests de código rígidos y con vigilancia intensiva suelen carecer de diseño accesible. Una prueba para llevar a casa mal acotada no es solo un cuello de botella operativo: es un filtro que descarta talento diverso mientras selecciona un perfil demográfico muy estrecho.

La solución es estructural: imponer límites de tiempo, ofrecer formatos de evaluación alternativos e integrar los flujos de adaptaciones en el proceso desde el principio, en vez de tratarlos como excepciones.

Las siete reglas para ejercicios de código que funcionan

Estas reglas se basan en las mejores prácticas de evaluación promovidas por interviewing.io, Karat y Hired, combinadas con datos de CodeSubmit y DevSkiller. Aplica las siete juntas; saltarse una socava el resto.

1. Imponer un límite estricto de 2 a 4 horas

Diseña la prueba para que pueda completarse de verdad en una sola tarde. No confíes en el sistema de honor. Usa una plataforma que registre cuándo empieza el candidato y envíe automáticamente su trabajo cuando se acabe el tiempo. Esto evita la carrera armamentista y crea condiciones equitativas.

Un límite de tiempo firme también te protege legalmente. Cuando todos los candidatos tienen la misma ventana, eliminas la ventaja de quienes disponen de más tiempo libre.

2. Proporcionar un template de inicio completo

No evalúes la capacidad de un candidato para configurar Webpack o montar un esquema de base de datos. Proporciona un repositorio preconfigurado con scaffolding, dependencias, esquemas y frameworks de testing ya listos. El candidato debería abrir el repo y empezar a escribir lógica de negocio en cuestión de minutos.

Esto refleja cómo funciona el trabajo de ingeniería en la práctica. Nadie arranca un proyecto greenfield desde cero en cada sprint. Se trabaja dentro de bases de código, convenciones y arquitectura ya existentes.

3. Alinear las tareas con el trabajo real

Pide al candidato que construya una funcionalidad pequeña, corrija un bug existente o integre una API concreta. Evita puzzles algorítmicos abstractos, ejercicios artificiales de estructuras de datos o cualquier cosa que parezca un examen universitario.

Las mejores pruebas se sienten como una tarea realista de la primera semana. “Aquí está nuestra API. Añade un endpoint que haga X y escribe tests para ello.” Eso te dice exactamente cómo rendirá el candidato desde el primer día.

4. Publicar tu rúbrica de evaluación

Dile a los candidatos exactamente qué van a evaluar los revisores antes de que empiecen. Una rúbrica transparente debería cubrir:

• Legibilidad del código y convenciones de nomenclatura
• Manejo de errores y cobertura de edge cases
• Calidad de los tests (no cantidad)
• Decisiones de arquitectura y separación de responsabilidades
• Higiene de Git (mensajes de commit, commits lógicos)

Cuando los candidatos conocen los criterios, dejan de adivinar y empiezan a demostrar sus habilidades reales. Tú obtienes señal; ellos obtienen claridad.

5. Garantizar feedback humano

Comprométete a dar feedback constructivo en cada entrega, sin importar el resultado del proceso. Esto es innegociable.

El feedback no necesita ser una code review completa. Tres o cuatro observaciones concretas sobre qué funcionó bien y qué podría mejorar le lleva a un revisor 10 minutos. Esa inversión de 10 minutos evita que el candidato publique una reseña demoledora en Glassdoor sobre tu proceso.

6. Ofrecer formatos de evaluación alternativos

No todos los buenos ingenieros rinden mejor en formato take-home. Da a los candidatos la opción de:

• Presentar una contribución open-source que ya hayan realizado
• Hacer una sesión de pair-programming en vivo con un problema similar
• Recorrer un proyecto de portfolio anterior y comentar las decisiones de arquitectura

La flexibilidad transmite respeto. También amplía tu bolsa de talento para incluir candidatos que podrían ser excelentes ingenieros pero que tienen limitaciones que dificultan una prueba para llevar a casa.

7. Remunerar los proyectos extensos

Si tu evaluación requiere genuinamente más de cuatro horas, paga al candidato. Contrata por horas a una tarifa justa y trátalo como una prueba remunerada.

Automattic paga $25/hora por proyectos de prueba de 5 a 40 horas. Linear realiza pruebas remuneradas de 2 a 5 días donde los candidatos construyen funcionalidades reales. Pagar por el tiempo de un candidato no es solo ético: señala que tu empresa valora el trabajo que la gente produce.

Por qué importa la integración con GitHub

El medio de entrega importa tanto como el contenido. Los sandboxes de código en el navegador impiden que los candidatos usen su IDE preferido, limitan el acceso a herramientas de debugging y abstraen por completo el control de versiones. Eliminan exactamente las señales que quieres medir.

Los ejercicios de código integrados con GitHub resuelven esto. El candidato clona un repositorio, trabaja en su entorno local, crea branches, escribe commits y envía mediante Pull Request. Esto refleja cómo trabajará realmente en el día a día.

Para los revisores, los beneficios se multiplican. Puedes examinar el historial de commits del candidato para entender cómo desglosó el problema. Puedes leer sus mensajes de commit para evaluar la calidad de comunicación. Y revisar un Pull Request es algo que todo equipo de ingeniería ya hace a diario, así que el proceso de evaluación resulta natural en vez de artificial.

El metaanálisis de Schmidt y Hunter estableció que combinar muestras de trabajo (validez de 0,33) con entrevistas estructuradas (validez de 0,51) produce las predicciones compuestas más sólidas del rendimiento laboral. Un ejercicio de código entregado como Pull Request, seguido de una discusión de code review en vivo, es exactamente esa combinación llevada a la práctica.

Coeficientes de validez del metaanálisis de 1998 de Schmidt y Hunter en el Journal of Applied Psychology.

Cómo evaluar entregas sin sesgo

Una prueba de código estructurada es solo la mitad de la ecuación. Sin un marco de evaluación disciplinado, el sesgo de los revisores contamina los resultados.

Evitar la puntuación tipo “reseña de Yelp”

El fallo más habitual es dejar que los revisores emitan un veredicto subjetivo de “contratar/no contratar” basado en la intuición. Este enfoque es muy susceptible al sesgo de afinidad: los revisores favorecen inconscientemente a candidatos cuyo estilo de código se parece al suyo. Un desarrollador de React podría penalizar a un candidato que prefiere vanilla JavaScript, no porque la solución sea peor, sino porque le resulta poco familiar.

Anclar las revisiones a la rúbrica

Cada revisor debería puntuar conforme a la rúbrica publicada, documentando observaciones concretas. No “la calidad del código es buena”, sino “el candidato sanitizó correctamente las entradas del usuario en el handler de API en la línea 47”. No “la arquitectura es mala”, sino “la lógica de negocio está mezclada con la capa de presentación en el UserController”.

Las observaciones concretas se pueden debatir. Las corazonadas, no.

Usar revisiones de Pull Request

Cuando el código se envía como Pull Request de GitHub, los revisores pueden dejar comentarios inline sobre líneas específicas. Esto replica la comunicación asíncrona que el candidato experimentará en el puesto. Además, crea un registro permanente de la evaluación al que varios miembros del equipo pueden recurrir.

Continuar con una discusión en vivo

La señal más predictiva viene de pedir al candidato que recorra su propio código. ¿Por qué eligió esta biblioteca? ¿Cómo manejaría 100x más tráfico? ¿Qué refactorizaría si tuviera más tiempo?

Esta conversación revela habilidades de comunicación, adaptabilidad y profundidad técnica que el código por sí solo no puede mostrar. También es la oportunidad del candidato para explicar los compromisos que hizo dentro de la restricción de tiempo.

Qué hacen diferente las empresas líderes

Las mejores organizaciones de ingeniería han ido más allá de la simple prueba para llevar a casa. Cada una ha adaptado el formato de evaluación a su entorno de trabajo real.

Pruebas de trabajo remuneradas

Automattic (WordPress) realiza proyectos de prueba remunerados obligatorios, de 5 a 40 horas a $25/hora. Los candidatos trabajan en tareas reales, se comunican por Slack y GitHub, y demuestran cómo operan en un entorno completamente distribuido. Linear hace pruebas remuneradas de 2 a 5 días donde los candidatos asisten a reuniones de arranque, construyen funcionalidades y presentan entregables. Para extender una oferta se requiere un “strong yes” casi unánime del panel.

Ejercicios prácticos en vivo

Stripe se salta las pruebas para llevar a casa por completo. Su loop de entrevistas incluye un “Integration Round” donde los candidatos navegan por una base de código desconocida para integrar una nueva API, y un “Bug Bash” centrado en depurar problemas reales de GitHub. Estos ejercicios evalúan cómo funciona un desarrollador bajo restricciones realistas, no artificiales.

Code review asíncrono

GitLab envía a los candidatos un Merge Request hasta 24 horas antes de la entrevista. El candidato revisa el MR de forma asíncrona, dejando comentarios y críticas arquitectónicas. Esto sirve de base para una discusión en vivo de 90 minutos y una sesión de pair-programming. El formato encaja perfectamente con la cultura remota y asíncrona de GitLab.

Cribado conversacional

Basecamp (37signals) evita por completo los puzzles lógicos. Evalúan a los candidatos con entregas de código prácticas y ponen gran énfasis en la carta de presentación y la comunicación escrita. La entrevista técnica es una conversación colaborativa, no un interrogatorio.

El hilo conductor: cada empresa alinea su formato de evaluación con la forma en que su equipo trabaja de verdad. Si eres un equipo remote-first y asíncrono, evalúa habilidades async. Si hacéis pair-programming a diario, evalúa con pair-programming. La evaluación debería ser un anticipo del puesto.

Cómo gestiona Kit los ejercicios de código

La función de ejercicio de código de Kit está diseñada en torno a las siete reglas anteriores. Cada decisión del flujo de trabajo aborda un fallo concreto que genera rechazo en los candidatos.

Creación automática de repositorios en GitHub

Cuando un candidato llega a la etapa de ejercicio de código, Kit crea automáticamente un repositorio privado en GitHub clonado desde tu template. El template incluye todo el scaffolding, las instrucciones y las suites de tests que el candidato necesita. Clona el repo, lo abre en su IDE preferido y empieza a escribir código de inmediato. Sin sandbox. Sin editor desconocido. Sin configuración de entorno.

Control de plazos con adaptaciones integradas

Kit registra el momento exacto en que el candidato inicia la prueba e impone un límite de tiempo configurable. Cuando se cumple el plazo, el sistema asegura automáticamente el repositorio y envía el estado actual del código. Esto evita que los candidatos dediquen 20 horas no remuneradas a una prueba de 3 horas.

Kit incluye un flujo integrado para extensiones de tiempo. Los reclutadores pueden otorgar tiempo adicional a candidatos que soliciten adaptaciones por responsabilidades de cuidado, discapacidades u otras circunstancias. Las adaptaciones forman parte del proceso, no son un añadido de última hora.

Revisión del equipo mediante Pull Requests

Una vez enviada la prueba, Kit otorga automáticamente acceso al repositorio al panel de revisión designado y les notifica que el Pull Request está listo. Los revisores usan las funcionalidades nativas de GitHub para dejar comentarios inline directamente sobre el código.

El historial completo de commits del candidato queda visible, mostrando cómo iteró sobre el problema. ¿Planificó la arquitectura de antemano? ¿Refactorizó sobre la marcha? ¿Sus mensajes de commit son descriptivos? Estas señales son invisibles en un sandbox de navegador, pero evidentes en un flujo de trabajo real con Git.

Integración completa con el pipeline

La etapa de ejercicio de código se conecta con el pipeline de contratación completo de Kit. Las puntuaciones y el feedback de los revisores fluyen al perfil del candidato. La siguiente etapa (normalmente una sesión de code review en vivo) se activa automáticamente. Nada se pierde porque todo el proceso vive en un solo sistema.

Construye tu ejercicio de código hoy

La brecha entre empresas que atraen a los mejores ingenieros y las que los ahuyentan suele reducirse al diseño de la evaluación. La investigación de Schmidt y Hunter es clara: las muestras de trabajo combinadas con entrevistas estructuradas producen las predicciones más sólidas del rendimiento laboral. Pero el formato solo funciona cuando respetas el tiempo del candidato, publicas tus criterios y das feedback.

Empieza con las siete reglas. Impón un límite de tiempo. Proporciona un template de inicio. Publica tu rúbrica. Da feedback. Ofrece alternativas. Paga por el trabajo extenso. Usa un entorno de desarrollo real en lugar de un sandbox.

Kit automatiza la carga operativa para que puedas centrarte en diseñar grandes evaluaciones en vez de gestionar repositorios y plazos. Empieza tu prueba gratuita y configura tu primer ejercicio de código en menos de 10 minutos.