Test de SQL: ejercicios y qué revisar en cada uno

Alguien puede recordar la sintaxis exacta de un JOIN y aun así no entender cómo modelar bien una relación entre tablas. Un test de SQL que solo mide sintaxis se queda corto: lo que de verdad importa es si la persona entiende el modelo de datos que tiene enfrente y puede razonar sobre él.

Conviene aplicarlo junto al ejercicio de lenguaje del rol, sea un test de Python o el que corresponda, y corregir ambos con los mismos criterios de evaluación de código.

Qué evaluar en un test de SQL por nivel

Un nivel junior debería poder escribir consultas con SELECT, WHERE, ORDER BY y JOIN básicos, y entender la diferencia entre un INNER JOIN y un LEFT JOIN en la práctica, no solo en teoría.

Un nivel semi senior debería, además, manejar agregaciones con GROUP BY y HAVING, subconsultas, y empezar a razonar sobre el rendimiento de una consulta, entendiendo por qué unas son más lentas que otras.

Un nivel senior debería poder diseñar el esquema de una base de datos desde cero, decidir cuándo normalizar y cuándo desnormalizar según el caso de uso, optimizar consultas complejas con criterio sobre índices, y detectar problemas de rendimiento antes de que se conviertan en un incidente en producción.

Ejercicios con solución

Ejercicio junior o semi senior. Dado un esquema con tablas de clientes, pedidos y productos, pide escribir una consulta que devuelva, por cliente, el total gastado en los últimos seis meses, incluyendo a los clientes que no tuvieron ningún pedido en ese periodo.

Solución esperada: un LEFT JOIN desde clientes hacia pedidos, con filtro de fecha y agregación con SUM, usando COALESCE o similar para mostrar cero en vez de nulo en los clientes sin pedidos.

Ejercicio senior. Entrega una consulta que funciona correctamente pero es lenta sobre una tabla grande, y pide identificar el problema y proponer una solución, ya sea reestructurando la consulta, sugiriendo un índice, o ambas cosas, explicando el razonamiento detrás de la elección.

Qué revisar en cada respuesta

Revisa si la consulta devuelve el resultado correcto, incluyendo casos límite como el ejemplo de clientes sin pedidos, que muchas soluciones incorrectas omiten sin darse cuenta. Revisa también si la persona eligió el tipo de JOIN correcto para el caso, un error muy común es usar INNER JOIN cuando el problema requiere incluir registros sin coincidencia. Revisa la legibilidad de la consulta, con nombres de alias claros y estructura fácil de seguir. Y revisa si, al preguntarle, la persona puede explicar por qué eligió ese enfoque y qué alternativas consideró. Esa explicación aporta más señal que cualquier test de algoritmos resuelto en silencio.

Señales de dominio real

Alguien con dominio real de SQL, más allá de la sintaxis, muestra ciertas señales reconocibles: piensa en el modelo de datos antes de escribir la consulta, en vez de empezar a teclear de inmediato. Considera casos límite sin que se los señalen explícitamente, como valores nulos o registros sin coincidencia. Puede explicar en términos simples por qué una consulta sería lenta sobre una tabla grande, incluso sin ser un experto en optimización de bases de datos. Y distingue con naturalidad cuándo un problema se resuelve mejor con SQL y cuándo conviene procesarlo en el código de la aplicación.

Para ver cómo evaluar el diseño de la capa de datos dentro de un rol de backend completo, en prueba de backend está la guía con ejercicio tipo y rúbrica.

Un test de SQL bien armado revela si la persona entiende el modelo de datos, no solo la sintaxis. Si quieres aplicar ejercicios por nivel con criterios de corrección claros, puedes agendar una demo y lo vemos con tu stack.

Preguntas frecuentes

¿Debo evaluar un motor de base de datos específico o SQL en general?
Los fundamentos de SQL son bastante transferibles entre motores. Si el rol requiere experiencia específica con un motor particular, como PostgreSQL o MySQL, puedes agregar una pregunta puntual sobre alguna característica propia de ese motor, pero la base del ejercicio funciona igual.

¿Se debe permitir consultar documentación durante el test de SQL?
Sí. En el trabajo real nadie escribe consultas complejas de memoria sin consultar nada, y permitirlo mide capacidad de resolver problemas reales en vez de memorización de sintaxis.

¿Cuánto tiempo debería durar el ejercicio?
Entre 30 y 60 minutos suele ser suficiente para un ejercicio bien diseñado, dependiendo del nivel y de si se incluye el componente de optimización de consultas lentas.

¿Un buen resultado en SQL garantiza que la persona entiende bien el modelado de datos?
No completamente. Saber escribir buenas consultas y saber diseñar un esquema desde cero son habilidades relacionadas pero distintas. Si el rol requiere diseño de esquemas, vale la pena incluir un ejercicio específico para eso.