Prueba técnica de programación: ejemplo y criterios para evaluarla

Qué debe evaluar una prueba técnica

Empieza por una responsabilidad concreta: validar datos, investigar un fallo, revisar un cambio o explicar una decisión de diseño. El ejercicio debe aportar una evidencia que todavía no tienes. Una prueba extensa puede añadir trabajo sin aclarar mejor si la persona podrá hacer las tareas del puesto.

La guía de muestras de trabajo de OPM describe evaluaciones con actividades similares a las del empleo y señala que deben centrarse en competencias que se esperan al incorporarse. Si una tecnología se aprenderá después, exigir dominio previo puede desajustar la prueba respecto a la vacante.

Para una incorporación junior, podrías observar cómo se entienden los requisitos y se prueban casos sencillos. En un puesto con mayor responsabilidad, quizá necesites además comentar límites, mantenimiento y decisiones ante requisitos ambiguos. Explica esa diferencia antes de evaluar; el nombre del nivel por sí solo no establece un criterio compartido.

Elegir entre revisión de código, ejercicio en directo y entrega en casa

• Revisión de código: aporta una solución pequeña y pide identificar problemas, proponer cambios y explicar prioridades. Es útil si revisar contribuciones forma parte del trabajo.
• Ejercicio acompañado: permite observar cómo se aclaran requisitos, se buscan errores y se responde al feedback. Cuenta también con la explicación inicial y la preparación del entorno.
• Entrega asíncrona: da margen para organizar el trabajo, pero necesita una dedicación prevista y un alcance claros. Reserva una conversación posterior para entender la solución.

Como ejemplo de una práctica empresarial, GitLab explica su entrevista técnica a partir de una aplicación pequeña y una propuesta de cambio preparada para la entrevista. Su guía diferencia esos ejercicios de las tareas reales de producción. Es un formato propio de esa empresa, no una duración o un procedimiento obligatorio para cualquier selección.

Utiliza datos ficticios y un repositorio de ejercicio. No pidas al candidato que resuelva un trabajo pendiente de un cliente para demostrar su capacidad. Si propone una alternativa porque el formato le dificulta mostrar su experiencia, valora si permite observar las mismas capacidades.

Ejemplo de prueba técnica backend: validar líneas de un pedido

Este ejercicio es una propuesta original de TaleCon para una conversación de selección. No corresponde a una vacante real ni a una funcionalidad que la plataforma evalúe automáticamente.

Contexto ficticio: una API recibe líneas de pedido y necesita separar las que cumplen los requisitos de las que contienen errores. La tarea consiste en escribir una función validarLineas en el lenguaje acordado para el puesto.

Qué recibe y qué devuelve

La entrada es una lista de objetos. Cada objeto debe tener un productoId que sea un texto no vacío tras eliminar espacios en los extremos, y una cantidad que sea un número entero positivo. Un número escrito como texto, por ejemplo "2", no cumple el requisito.

La salida debe contener una lista de líneas válidas y una lista de errores. Cada error debe identificar la posición original, empezando en cero, y todos los campos incorrectos de esa línea. Las válidas conservan el orden, devuelven el identificador sin espacios en los extremos y mantienen la cantidad.

Casos de aceptación

• {productoId: " A-1 ", cantidad: 2} produce una línea válida con identificador "A-1".
• {productoId: "", cantidad: 0} produce errores para ambos campos y no aparece en las válidas.
• Una cantidad 1.5, un valor null o un texto "2" produce un error de cantidad.
• Un identificador numérico o compuesto solo por espacios produce un error de identificador.
• Una lista vacía devuelve ambas listas vacías; un elemento que no sea un objeto válido produce un error de línea.

Para mantener el alcance, la entrada principal siempre será una lista. No se necesita base de datos, servidor HTTP, interfaz ni despliegue. Los productos repetidos se procesan por separado: no se pide comprobar existencias ni agrupar cantidades. La función no debe modificar la lista ni los objetos recibidos.

Qué se entrega y cuánto tiempo se propone

Solicita la función, sus pruebas y una nota breve sobre decisiones o limitaciones. Como propuesta de sesión, reserva 60 minutos: quince para leer y aclarar el enunciado, treinta para trabajar y quince para revisar la solución. El equipo debe comprobar antes que la tarea cabe en ese tiempo y adaptar la expectativa al puesto.

Si se realiza en casa, comunica el límite de dedicación y pide detenerse al alcanzarlo, anotando qué falta. Una entrega incompleta puede servir para comentar prioridades; registra qué no se pudo comprobar sin exigir que la persona siga trabajando indefinidamente.

Criterios para revisar el ejercicio sin improvisar

Prepara la ficha antes de recibir soluciones y aplica los mismos criterios a quienes participan en la misma vacante. Estos son los criterios propuestos para este ejemplo:

• Comportamiento: separa válidas y errores conforme al enunciado, conserva el orden y no modifica la entrada.
• Casos límite: contempla campos ausentes, tipos incorrectos, espacios y lista vacía.
• Pruebas: permite ejecutar comprobaciones que cubren los requisitos y muestra qué resultados espera.
• Comprensión: la persona puede explicar cómo se recorre la lista, dónde se valida y por qué tomó esas decisiones.
• Alcance y claridad: la solución permite revisar lo pedido sin añadir infraestructura innecesaria.

Para cada criterio, registra evidencia suficiente, pendiente de aclaración o no observada, junto con un ejemplo. «No observada» no explica por sí sola la causa: comprueba si faltaron tiempo, instrucciones o una pregunta de seguimiento.

La ficha sobre métodos de selección de CIPD sitúa las tareas basadas en habilidades entre las herramientas de evaluación. La elección debe responder a las capacidades del puesto y al proceso de selección. Esta ficha de observación es una propuesta editorial, no una escala validada ni una decisión automática sobre contratación.

Durante la revisión puedes pedir: «Enséñame una prueba que detectaría que se ha modificado la entrada» o «¿Qué cambiarías si hubiese que agrupar productos repetidos?». La segunda pregunta explora una ampliación; no la conviertas después en un requisito oculto de la entrega inicial.

Cómo aclarar el uso de inteligencia artificial

Comunica antes de empezar si se permite documentación, búsqueda web, asistentes de código o colaboración con otra persona. Si el objetivo incluye trabajo con IA, explica qué tendrá que justificar el candidato: comprensión del resultado, verificación y cambios realizados.

La política pública de GitLab sobre IA en selección permite un uso transparente en evaluaciones técnicas y pide que la persona pueda explicar sus prompts y decisiones. Es un ejemplo de política declarada; cada empresa debe comunicar las reglas de su propio proceso.

Para el ejercicio de esta guía, una opción es permitir asistencia y pedir una nota con las herramientas utilizadas y las comprobaciones efectuadas. Si existen cuentas o servicios necesarios, aclara cómo se facilitarán. No presupongas que todo el mundo dispone de la misma suscripción. Usa únicamente el material ficticio del ejercicio, sin información de clientes o proyectos privados.

Cómo prepararte como candidato

Antes de empezar, confirma el lenguaje, la versión, la dedicación prevista y cómo se entregará. Si algo del enunciado admite interpretaciones distintas, pregunta o deja documentada tu suposición. Prepara una forma sencilla de ejecutar las pruebas y explicar el comportamiento.

Prioriza los requisitos acordados. Durante la conversación, muestra un caso válido, un error y una comprobación de un límite. Explica lo que cambiarías con más tiempo y reconoce lo que no has verificado. Tu experiencia previa puede aportar contexto, como explicamos en la guía de entrevista por competencias y método STAR.

Dónde encaja la prueba dentro del proceso con TaleCon

La prueba debe responder a una necesidad definida dentro del proceso de selección. En TaleCon, el porcentaje de encaje orienta la revisión de perfiles; no sustituye el análisis técnico ni demuestra por sí solo el interés del candidato.

Para coordinar la conversación, consulta la guía de entrevistas en TaleCon, que describe el control «Solicitar nueva entrevista». El enunciado, los criterios y la evaluación que proponemos aquí son trabajo del equipo de selección: no atribuimos a la plataforma un editor de código, ejecución de pruebas o corrección automática.

Fuentes y alcance de la guía

Fuentes consultadas el 28 de octubre de 2026: OPM, CIPD y las páginas públicas de entrevistas técnicas y uso de IA de GitLab, enlazadas en el texto. El caso de pedido, el reparto de tiempo y la ficha son propuestas originales para adaptar al puesto. No se han creado vacantes ni se ha evaluado a candidatos reales para elaborar este artículo.