Prueba las instrucciones del ejercicio de código antes de contratar

Para probar las instrucciones de un ejercicio para hacer en casa, pide a alguien que no conozca el enunciado que siga los pasos de preparación y entrega que recibirá cada candidato. Observa cuándo necesita ayuda, anota los obstáculos imprevistos, revisa el material y repite con otra persona. Ten presentes durante toda la prueba las competencias que quieres evaluar.

El 11 de octubre, Terence Eden contó cómo había pagado a varias personas para que intentaran seguir su README. Ofreció 25 € por una hora, observó cómo compartían la pantalla y pensaban en voz alta, y revisó el documento entre sesiones. Según indicó, gastó unos 150 € en total. El experimento descubrió un enlace de demostración incorrecto, operaciones con archivos confusas, términos sin explicar y apartados ordenados de forma poco útil.

La conversación en Hacker News trata sobre documentación de software. Eden no estudió procesos de selección. Un equipo de contratación puede aprovechar la idea para ensayar sus propias instrucciones antes de usar el trabajo de los candidatos como prueba de sus competencias. Un enunciado bien redactado todavía puede ocultar un permiso que falta o un último paso sin definir.

¿Qué evalúan realmente las instrucciones del ejercicio?

Escribe qué competencia quieres evaluar antes de organizar el ensayo. Necesitas esa referencia para decidir si una dificultad forma parte de la evaluación o procede de un defecto evitable en su organización.

Imagina un ejercicio de backend: añadir un filtro a una API pequeña y proteger el comportamiento existente mediante pruebas. Podrías evaluar cómo entiende el candidato el código, cómo elige el cambio, cómo aborda los casos límite y cómo explica una decisión. Son objetivos razonables si se parecen al trabajo que exige el puesto.

La Oficina de Gestión de Personal de Estados Unidos describe las muestras de trabajo y simulaciones como tareas parecidas a las actividades reales del puesto. Sus orientaciones también distinguen las competencias necesarias al incorporarse de aquellas que la empresa prevé enseñar. Eso te permite hacer una pregunta útil sobre cada requisito previo: ¿es necesario para desempeñar el puesto desde el primer día?

Leer código desconocido puede serlo. Conocer la configuración de la base de datos de tu empresa, si no está documentada, no se deduce de ese objetivo. Depurar también puede formar parte de la evaluación, pero debes decidir si arreglar un entorno inicial que falla es la tarea de depuración. Un fallo oculto cambia lo que los candidatos deben demostrar.

Escribe tu respuesta junto a los criterios de revisión. Para el ejercicio ficticio de la API, podrías decir: «Revisamos la corrección, la conservación del comportamiento existente, las pruebas pertinentes y tu explicación de las decisiones y sus contrapartidas». Si interpretar una petición poco definida es parte del ejercicio, explica cómo valorarás los supuestos que adopten los candidatos.

El ensayo comprueba si el material permite realizar la evaluación prevista. Que alguien complete todos los pasos no demuestra que el ejercicio prediga su rendimiento laboral. Para diseñar la tarea en su conjunto, consulta la guía de cómo estructurar ejercicios de código.

Entrega el material real a alguien que no lo conozca

Ensaya conjuntamente la invitación, el acceso, las instrucciones y la entrega. Enviar a un compañero solo el repositorio deja fuera las transiciones en las que un candidato puede perder de vista qué viene después.

Elige a alguien que tenga las competencias iniciales esperadas y que no haya redactado ni revisado la tarea. Puede servir un desarrollador de otro proyecto. Una persona que acaba de empezar a programar podría detectar un problema de redacción, pero su dificultad para instalar el entorno de ejecución requeriría otra interpretación si el puesto es para un ingeniero sénior.

Explica el propósito antes de empezar: estás probando el material del ejercicio. Si buscas a alguien específicamente para la sesión, acordad el trabajo y la remuneración. El presupuesto de Eden describe su experimento; no es una tarifa estándar ni una recomendación sobre el número de participantes. No conviertas a un candidato en un probador de usabilidad sin remunerar y sin avisarle.

Entrega a esa persona los mismos materiales y permisos que piensas proporcionar a los candidatos:

• El mensaje de invitación y las instrucciones de preparación.
• El resumen de la tarea, las instrucciones detalladas y los criterios de revisión.
• El acceso al repositorio, los datos proporcionados y las credenciales necesarias.
• La dedicación prevista, la fecha límite y el evento que inicia el plazo.
• Las reglas sobre documentación, búsquedas, colaboración y ayuda de IA.
• La vía real de entrega y un contacto para las dudas.

Usa una cuenta de ensayo y datos adecuados para la sesión. Si el ejercicio requiere un entorno concreto, proporciónalo expresamente. Si los candidatos pueden usar sus propios equipos, prueba los pasos documentados en un entorno permitido que no tenga ya instaladas las dependencias de tu equipo.

Pide a la persona que explique qué cree que debe entregar antes de continuar. Anota esa explicación como una observación. Una interpretación distinta puede revelar un requisito poco claro o ser una decisión profesional razonable dentro de la libertad que querías conceder.

En un ejercicio de programación, pide que avance lo suficiente para ejecutar las pruebas iniciales, hacer un pequeño cambio válido y completar la entrega. Acordad antes ese alcance. Necesitas observar los pasos operativos sin exigir, de forma encubierta, una solución completa sin remunerar.

Observa dónde dejan de funcionar las instrucciones

Anota lo ocurrido antes de explicar lo que querías decir. Puede ser necesario dar una pista, pero el hecho de que haga falta forma parte de la información que buscabas recoger.

Pide a la persona que piense en voz alta mientras trabaja: qué instrucción sigue, qué espera que haga un comando y dónde busca la siguiente acción. Evita explicarle la página de antemano. Si se detiene, deja que explique la pausa antes de decidir que hay un problema.

Una pausa para pensar en el comportamiento del filtro puede mostrar un razonamiento útil. Una pausa porque el enlace dice «repositorio inicial» pero abre una página a la que no tiene acceso indica un problema de organización. Distingue estas observaciones en tus notas en vez de reducirlas a un único tiempo de finalización.

Lleva un registro breve de obstáculos. Las siguientes entradas son ejemplos inventados para el ejercicio de la API; no son resultados de un estudio real sobre contratación:

Añade el comando, el error o la frase necesarios para reproducir el problema. Una nota como «La preparación era confusa» cuesta convertirla en una acción concreta. «El comando de preparación requiere un nombre de base de datos que falta en el ejemplo del entorno» da al responsable un punto de partida.

Si intervienes, anota la ayuda que has dado. De lo contrario, el resultado final puede hacer que el material parezca utilizable cuando la sesión dependió de tu explicación. Trata las observaciones en voz alta como información para diagnosticar problemas: sentirse observado y hablar puede cambiar la forma de trabajar. Esas observaciones no permiten estimar el rendimiento habitual de los candidatos.

Corrige el enunciado y prueba los cambios

Corrige el problema más concreto que puedas identificar y prueba los pasos revisados con alguien que no conozca tu solución provisional. La primera persona ya sabe detalles que el siguiente candidato desconocerá.

En el ejercicio ficticio de la API, el material original dice: «Ejecuta la aplicación, añade filtros y envía tu solución». Una versión revisada podría incluir un entorno de ejecución compatible, comandos exactos de instalación, un comando para ejecutar las pruebas iniciales, datos de ejemplo y el comportamiento esperado del filtro. También indicaría dónde entregar la solución y los criterios de revisión.

Vincula esas correcciones a lo observado. Si la persona no puede instalar las dependencias, añadir un párrafo sobre la cultura de empresa no resuelve el problema. Si las pruebas pasan, pero no encuentra la acción de entrega, la corrección debe hacerse en esa transición.

Comprueba los comandos por tu cuenta antes de otra sesión de observación. Sigue la secuencia desde una copia limpia del repositorio con el entorno documentado. Elimina cualquier dependencia accidental de tus credenciales locales, datos en caché o configuración sin publicar. Las comprobaciones automáticas pueden detectar enlaces y comandos que fallan; no pueden decirte cómo interpreta una persona «envía tu solución».

Define una pregunta concreta para la siguiente ronda. Por ejemplo: ¿puede esta persona ejecutar las pruebas iniciales con solo el material y explicar en qué momento queda formalmente entregado el trabajo? Anota lo observado en el mismo registro en vez de dar todo el ejercicio por «validado».

Vuelve a probar el recorrido completo después de corregir un obstáculo que impedía llegar a los pasos posteriores. Una invitación al repositorio corregida puede revelar un problema de preparación que la primera persona nunca llegó a encontrar. Termina cuando tengas información suficiente para resolver los obstáculos concretos detectados, sin perder de vista los límites de los entornos y las personas que has observado.

Mantén unas condiciones y aclaraciones uniformes para los candidatos

Cierra el material antes de invitar a un grupo y comunica por igual las correcciones relevantes. Cambiar requisitos sin avisar puede llevar a los revisores a comparar trabajos realizados en condiciones distintas.

Guarda la invitación, las instrucciones, la versión inicial del código y los criterios de evaluación juntos en el documento o repositorio que ya utilice tu equipo. Registra qué versión recibió cada candidato. Esta es una propuesta para organizar la evaluación; no implica que guardar versiones baste para hacerla justa.

Las orientaciones de la EEOC estadounidense sobre pruebas de empleo y procedimientos de selección abordan el propósito adecuado, la administración, la puntuación y la validación. El ensayo con una persona que no conozca el material es una comprobación operativa. No cubre todas esas responsabilidades ni demuestra el cumplimiento de la legislación.

Supón que un candidato avisa de que no puede cargar los datos proporcionados. Confirma el problema, informa a los demás candidatos afectados de lo que ha cambiado y valora si debes ajustar sus plazos. Si el defecto impidió que alguien demostrara sus competencias, examina su efecto antes de interpretar el resultado que falta como una carencia de conocimientos.

Distingue las aclaraciones logísticas de la ayuda para resolver el ejercicio. «Esta es la página donde debes subir el archivo» puede comunicarse a todos. Una conversación que aporta una forma de abordar el problema central cambia la ayuda recibida y debe quedar registrada para los revisores.

Tras la entrega, conserva la relación entre el material que recibió cada candidato y la evaluación. El revisor debe conocer los criterios comunicados, incluida cualquier ambigüedad intencionada. Las preguntas de entrevista posteriores sobre una solución que supera las pruebas pertenecen a otra etapa; consulta la entrevista después de que la solución supere las pruebas.

Haz que el material sea accesible para quien lo lee

Incluye en el ensayo cómo se lee y cómo se recorre el material. Un comando correcto sigue siendo difícil de usar si solo aparece en una captura de pantalla o bajo un encabezado que no corresponde.

El tutorial de encabezados de W3C WAI explica cómo una estructura de encabezados con sentido facilita la navegación y la comprensión. En un ejercicio, encabezados como «Preparación», «Comportamiento requerido» y «Entrega» ofrecen destinos útiles. Comprueba el documento tal como se muestra, incluidos los PDF o las páginas del repositorio que vayas a distribuir.

Proporciona comandos en texto que se puedan seleccionar y copiar. Pon a los enlaces nombres que identifiquen su destino. Comprueba que las instrucciones importantes sigan siendo legibles en los dispositivos y formatos de documento que admites. Si la página de entrega utiliza controles, incluye su manejo con el teclado en el ensayo en vez de suponer que leer el enunciado cubre toda la experiencia.

Ofrece una vía de contacto antes de empezar el ejercicio. En sus orientaciones estadounidenses sobre candidatos a un empleo y la ADA, la EEOC explica que las empresas pueden describir el proceso de selección y preguntar si los candidatos necesitan una adaptación para participar en él. Gestiona las solicitudes por un canal privado adecuado y mantén los datos médicos de diagnóstico fuera de las notas de evaluación compartidas.

Probar el recorrido con una persona cubre la experiencia de esa persona. No demuestra la accesibilidad para todos los usuarios ni el cumplimiento íntegro de las WCAG. En cuanto a la redacción, la guía anterior sobre instrucciones claras para candidatos trata las expectativas de la tarea, los plazos y los comprobantes de entrega. Este ensayo aporta información sobre si alguien puede seguir realmente el recorrido configurado.

Guarda las instrucciones probadas junto al ejercicio de Kit

Sigue el recorrido real del candidato en el último ensayo. Los campos y las vistas previas ayudan a preparar el material; seguir el recorrido muestra qué significan esos ajustes en la práctica.

En Kit Hiring, un ejercicio de código puede usar un repositorio privado de GitHub creado a partir de tu plantilla. Su configuración incluye instrucciones, dedicación estimada y ajustes de tiempo. El candidato conecta GitHub y recibe una invitación al repositorio. Al aceptar esa invitación, empieza a contar el plazo del ejercicio. La página del candidato muestra entonces las instrucciones y la acción de entrega; una fecha límite posterior e improrrogable cierra el plazo mediante la entrega automática.

Una prueba práctica empieza de otra manera. El candidato puede leer primero el resumen y después pulsar Empezar tarea para ver el enunciado privado y empezar el plazo. Sube el resultado y recibe un comprobante de entrega. Explica estas diferencias al ensayar tu propia tarea; la documentación de la experiencia del candidato describe ambos recorridos.

Kit proporciona el flujo del ejercicio. Tu equipo organiza la sesión con una persona que no conozca el material, registra los obstáculos y decide qué correcciones preservan la evaluación. Entrega a esa persona la invitación que piensas enviar, observa la preparación y la entrega, y después revisa y vuelve a probar los obstáculos que puedas reproducir. Hazlo antes de que el primer candidato tenga que descubrirlos por ti.