Cómo crear una prueba de programación

What you'll need

• Un espacio de trabajo de SkillCort (o una demostración)
• Un ejemplo real del código que escribe su equipo — un error, una funcionalidad pequeña, una refactorización
• Un ingeniero sénior que defina la tarea y la rúbrica
• Una decisión sobre qué lenguajes aceptará

Step 1: Elija una tarea realista antes que un acertijo de algoritmos

Mire el último mes de pull requests y elija una tarea con la forma de las que se repiten: corregir un error a partir de un comportamiento defectuoso, ampliar una función pequeña para que atienda un caso nuevo, refactorizar un bloque desordenado o escribir una transformación de datos. Estas anticipan el desempeño diario mucho mejor que invertir un árbol binario.

Dimensiónela para 30–45 minutos de trabajo concentrado de una persona competente. Un acertijo premia a quien lo ha ensayado; una tarea pequeña y realista premia a quien sabe leer la intención existente, hacer un cambio sólido y mantener el código comprensible — que es justo lo que usted contrata.

Elimine el conocimiento propio de un framework o de la empresa salvo que el puesto lo exija de verdad, y aporte dentro del propio enunciado el contexto que la tarea necesite. Un buen ingeniero que nunca ha tocado su stack debería poder mostrarle igualmente un criterio sólido. Evalúe la habilidad, no la familiaridad con los detalles menores de su base de código.

• Se repite en su base de código real, no en los libros de preparación de entrevistas
• Tiene más de una solución razonable
• Cabe en 30–45 minutos sin heroicidades
• Un evaluador puede leerla en menos de diez minutos

Step 2: Cree el ítem de código en la biblioteca de ítems

Cree una carpeta para el puesto — Ingeniero de backend, por ejemplo — con etiquetas de área de habilidad y de dificultad, y cree después un ítem con el tipo de ítem de código. Los candidatos escriben y editan el código directamente en el área de respuesta, y los evaluadores lo revisan después ahí mismo.

Prepare el ítem con código de partida en lugar de un editor en blanco. Una función corta con un error descrito, o un esqueleto con un contrato claro, ancla a todos los candidatos al mismo punto de partida y hace directamente comparables sus cambios. El trabajo real casi nunca empieza en un archivo vacío, y la prueba tampoco debería.

Step 3: Escriba el enunciado junto al editor

Use la disposición de estímulo en paralelo: el enunciado, los requisitos y los ejemplos de entradas y salidas a un lado, y el editor de código al otro. El candidato no se aleja nunca de la especificación para escribir la solución — la misma forma que trabajar a partir de un ticket en un IDE.

Escriba el enunciado como se lee un buen ticket: comportamiento actual, comportamiento esperado, restricciones y dos o tres ejemplos concretos. Diga explícitamente qué le importa — «primero que el código funcione; también lo leemos buscando claridad» — para que los candidatos optimicen aquello que usted va a puntuar realmente. La ambigüedad en el enunciado se convierte en ruido en los resultados.

Step 4: Construya una rúbrica que puntúe algo más que la corrección

Que la salida sea correcta es necesario, no suficiente. Construya una rúbrica de matriz por niveles con tres o cuatro criterios — normalmente corrección, legibilidad y enfoque, y opcionalmente el tratamiento de los casos límite —, cada uno con descripciones ancladas de cómo es un código bueno, aceptable y flojo. «Los nombres revelan la intención, no hay código muerto» es puntuable; «código limpio» no lo es.

Dé el mayor peso a la corrección, pero mantenga reales los demás criterios: una solución que apenas funciona y que nadie puede mantener no es una buena señal de contratación. Cuando adjunta la rúbrica, esta queda congelada como instantánea, de modo que todos los candidatos de la convocatoria se revisan con el estándar idéntico aunque la versión del banco evolucione después.

Step 5: Monte y acote el tiempo en el constructor

Cree la evaluación en secciones, páginas y bloques e importe el ítem de código mediante el selector. Muchos equipos añaden una primera sección breve de preguntas rápidas de criterio — leer un diff, detectar el error en un fragmento, pegadas rápidamente como opción múltiple — y colocan la tarea de programación en su propia sección.

Fije el límite de tiempo total con holgura para leer y pensar, y use un límite por página en la página de programación para que la tarea no se trague todo el intento. Dé el mayor peso a la sección de programación (por ejemplo, ×3) para que el ajuste al puesto del Decision Board refleje el trabajo y no el calentamiento. Escriba instrucciones que indiquen los lenguajes permitidos y qué ocurre si se agota el tiempo.

Step 6: Previsualice, resuelva la lista de comprobación y publique

Use Preview as candidate e intente usted mismo la tarea o, mejor aún, haga que la intente sin preparación previa un ingeniero que no la haya escrito. Si termina en diez minutos, es demasiado fácil; si no consigue terminar dentro del límite, relaje el alcance o el reloj. Corrija el enunciado allí donde haya dudado.

Cumpla después la lista de comprobación de publicación — bloquea Publish hasta que la puntuación, los tiempos y las instrucciones estén completos. Una prueba de programación sin rúbrica o con un límite de tiempo no comprobado nunca debería llegar a un candidato, y la lista se asegura de que no pueda.

Step 7: Fije controles de integridad proporcionales a las consecuencias

Cree la entrega con un nombre y una ventana temporal y elija después los interruptores de seguridad de forma deliberada. Para una criba de contratación estándar, bloquear el copiar y pegar y el bloqueo a pantalla completa con un límite razonable de infracciones suele bastar. La grabación de cámara, la grabación de pantalla, la detección de segunda pantalla y las verificaciones de identidad existen para convocatorias de consecuencias realmente altas — certificaciones, rondas finales —, no como opción por defecto.

Todo lo que active se comunica en la pantalla de consentimiento y comprobación previa antes de que el candidato empiece. Las señales de integridad son avisos para que una persona los revise en su contexto, nunca motivo de rechazo automático — salir de la pantalla completa puede ser un aviso emergente, no un fraude. La proporcionalidad evita que los buenos candidatos se marchen ante una red de vigilancia indiscriminada.

Step 8: Revise el código con la rúbrica, con la IA como apoyo

Los evaluadores revisan cada entrega con la rúbrica compartida, haciendo clic en la tarjeta de nivel que corresponde al código en cada criterio — corrección, legibilidad, enfoque. Poner a dos revisores en los casos dudosos o de altas consecuencias mantiene honesto el estándar y, como todos puntúan con la misma instantánea congelada de la rúbrica, los desacuerdos afloran como diferencias concretas en un criterio y no como vagas discrepancias de intuición.

La IA puede redactar un resumen de la entrega y sugerir puntuaciones por criterio — una primera pasada realmente útil sobre el código, con el modelo y la versión registrados para el expediente. Pero un ingeniero identificado confirma o anula cada puntuación. Aquí la IA es apoyo a la decisión, nunca quien decide: el juicio responsable sobre el código de un candidato es siempre humano.