Prueba de backend: qué mide una buena evaluación

Un endpoint que funciona en el caso feliz, con datos perfectos y sin usuarios concurrentes, dice muy poco sobre si esa persona puede construir un sistema que sobreviva en producción. Una buena prueba de backend mide justamente lo que pasa cuando las cosas no salen como el caso ideal.

Qué evaluar en backend

Una prueba de backend completa evalúa cuatro dimensiones: diseño de la API, con endpoints coherentes y bien pensados desde la perspectiva de quien los va a consumir; modelado de datos, con una estructura que refleje bien las relaciones del dominio del problema; manejo de errores, con respuestas claras y códigos de estado apropiados cuando algo falla; y consideración básica de concurrencia, entendiendo qué pasa cuando dos operaciones intentan modificar el mismo recurso al mismo tiempo.

Ninguna de estas cuatro dimensiones es opcional para un rol de backend real. Un ejercicio que solo revisa si el endpoint devuelve el JSON esperado en el caso ideal deja fuera exactamente lo que separa a un desarrollador de backend sólido de uno que solo sabe conectar piezas.

Diseño de API y datos

Un buen diseño de API se nota en detalles concretos: nombres de endpoints consistentes y predecibles, uso correcto de métodos HTTP según la acción que realizan, y respuestas con una estructura uniforme que no cambia de forma arbitraria entre endpoints distintos.

El modelado de datos se evalúa revisando si las relaciones entre entidades están bien pensadas, si hay normalización razonable sin llegar a la sobreingeniería, y si la persona puede explicar por qué estructuró los datos de esa forma y qué alternativas consideró, como desnormalizar por razones de rendimiento en un caso específico.

Ejercicio tipo con rúbrica

Ejercicio. Pide construir una API simple para un sistema de reservas, con endpoints para crear, listar y cancelar reservas. Especifica que dos personas no deberían poder reservar el mismo horario al mismo tiempo, y que el sistema debe manejar de forma clara los casos de datos inválidos o recursos inexistentes.

Rúbrica de corrección, sobre cuatro criterios:

Diseño de API: los endpoints son coherentes, usan los métodos HTTP correctos y las respuestas siguen una estructura consistente.

Modelado de datos: las relaciones entre entidades están bien pensadas y reflejan correctamente el dominio del problema.

Manejo de errores y casos límite: el sistema responde de forma clara ante datos inválidos, recursos inexistentes o intentos de reserva duplicada.

Justificación de decisiones: la persona puede explicar cómo evitó la doble reserva del mismo horario y qué otras alternativas consideró para resolver ese problema de concurrencia.

Cómo puntuar una prueba de backend sin sesgo

El riesgo más común al corregir una prueba de backend es premiar el estilo de código que se parece más al propio, en vez de evaluar si la solución es correcta y razonable dentro de sus propios términos. Usa la rúbrica de forma consistente para todos los candidatos, y si dos evaluadores corrigen el mismo ejercicio, compara los puntajes antes de comunicar el resultado final para detectar diferencias de criterio.

Otra fuente de sesgo frecuente es penalizar más duramente un enfoque que resuelve el problema de forma distinta a como el evaluador lo hubiera resuelto, aunque ambos enfoques sean válidos. Antes de restar puntos por una decisión de diseño distinta a la esperada, pregúntate si esa decisión realmente introduce un problema, o si simplemente no es la que tú habrías tomado.

Para ver cómo evaluar específicamente el manejo del modelo de datos con consultas SQL dentro de un ejercicio de backend, en test de SQL está la guía con ejercicios y soluciones comentadas. Si la pila del equipo es Python, en test de Python están los ejercicios por nivel, y la rúbrica con la que se revisa lo entregado está en evaluación de código.

Una prueba de backend que mide diseño de API, datos, errores y concurrencia te ahorra descubrir esas brechas en producción. Si quieres aplicarla con rúbrica y ejercicios por seniority, puedes agendar una demo y lo revisamos con tus vacantes reales.

Preguntas frecuentes

¿Debo evaluar un lenguaje o framework específico, o los principios de diseño de backend en general?
Ambos aportan valor, pero si el equipo trabaja con una pila tecnológica específica, evaluar directamente en esa pila da una señal más cercana al trabajo real que evaluar principios en abstracto.

¿Cuánto tiempo debería durar una prueba de backend completa?
Entre 60 y 120 minutos según la complejidad del ejercicio, con tiempo adicional para la conversación de revisión donde la persona explica sus decisiones.

¿Es necesario que el candidato implemente autenticación completa en el ejercicio?
No siempre. A menos que sea el foco específico de la evaluación, puedes simplificar esa parte para concentrar el tiempo disponible en el diseño de API, los datos y el manejo de errores, que suelen aportar más señal.

¿Cómo evalúo la consideración de concurrencia sin un entorno de pruebas complejo?
Con una pregunta directa suele bastar: pídele a la persona que explique qué pasaría si dos usuarios intentan la misma operación al mismo tiempo, y qué mecanismo usaría para evitar el conflicto, incluso si no lo implementa completamente en el tiempo disponible.