SQL para entrevistas: fundamentos para principiantes

Domina SQL para entrevistas con SELECT, JOIN, GROUP BY, HAVING y NULL. Aprende lo esencial para responder con seguridad y pasar el filtrado.

Tienes una sola noche. No una semana, no un fin de semana: una sola noche para dejar de sentirte rezagado con SQL y empezar a sentirte lo bastante preparado como para entrar a una ronda de filtrado sin quedarte en blanco. La buena noticia es que las basic interview questions de SQL en nivel inicial suelen girar una y otra vez sobre el mismo pequeño conjunto de ideas. La mala noticia es que la mayoría de los recursos de estudio te entregan una lista de 80 preguntas y te desean suerte, que es la forma más rápida de memorizar nada útil.

Esta guía funciona de otra manera. Ordena los conceptos del modo en que los entrevistadores realmente los presentan: empezando por SELECT y WHERE, pasando por GROUP BY y HAVING, y llegando después a joins, claves y los errores con NULL que silenciosamente hacen perder puntos fáciles a los candidatos. Si sigues la secuencia de práctica de 30 minutos del final, podrás decir las respuestas con claridad en voz alta, que es la verdadera prueba.

Los 10 fundamentos de SQL que necesitas antes que nada

¿Cuáles son los fundamentos esenciales de SQL que un principiante debería memorizar primero para una entrevista?

La trampa en la que caen la mayoría de los principiantes es intentar abarcarlo todo antes de poder responder las preguntas obvias. Los fundamentos de SQL para entrevistas tienen una jerarquía natural, e ignorarla significa pasar dos horas con window functions mientras sigues sin tener claro por qué existe GROUP BY.

El conjunto inicial que de verdad importa, en este orden: SELECT y FROM (cómo pides datos), WHERE (cómo filtras filas), ORDER BY (cómo ordenas resultados), GROUP BY (cómo resumes por categoría), HAVING (cómo filtras después de resumir), y los tres tipos clave de claves: primary, unique y foreign. Todo lo demás —subqueries, CTEs, window functions, stored procedures— se construye sobre esto. Primero domina la base.

Por experiencia real de contratación, el tema más sobrepreparado en nivel inicial son las subqueries. Los candidatos llegan listos para explicar subqueries correlacionadas, pero tropiezan cuando se les pregunta por qué existe HAVING. El tema menos preparado, de forma constante, es el comportamiento de NULL. Aparece en casi todas las entrevistas de filtrado y hace caer a personas que por lo demás tienen una buena intuición para escribir consultas.

¿Cómo explicas SQL a alguien que nunca lo ha usado?

La versión más clara y sencilla en lenguaje cotidiano sería algo así: "SQL es un lenguaje para hacer preguntas a una base de datos. Una base de datos guarda información en tablas: filas y columnas, como una hoja de cálculo. SQL te permite decir: dame las filas de esta tabla donde esta condición sea verdadera, ordenadas de esta manera."

Si necesitas un punto de apoyo concreto, usa empleados y departamentos. Tienes una tabla `employees` con columnas como `name`, `salary` y `department_id`. Tienes una tabla `departments` con `department_id` y `department_name`. SQL es la forma de conectar esas tablas y extraer exactamente las filas que te interesan. Ese enfoque —tablas, filas, columnas, preguntas— basta para una respuesta de nivel inicial y suena natural, no memorizado.

¿Qué temas de SQL aparecen primero en una entrevista básica y cuáles pueden esperar?

Según la guía de prácticas de contratación de SHRM y las rúbricas técnicas de evaluación publicadas habitualmente, los filtros de SQL para nivel inicial casi siempre empiezan con consultas de una sola tabla antes de introducir escenarios con varias tablas. Eso significa que SELECT, WHERE, ORDER BY, GROUP BY y HAVING son el primer filtro. Los joins vienen después. Las subqueries y los temas de rendimiento vienen en tercer lugar, si es que aparecen en una ronda básica.

Lo que puede esperar sin problema hasta que tengas más tiempo: CTEs, window functions, índices y optimización de consultas, stored procedures y diferencias de sintaxis específicas de cada base de datos. Estos temas importan para puestos de nivel medio y senior. Para una entrevista de nivel inicial, conocerlos es un plus, no un requisito.

Cómo responder a lo básico de consultas sin divagar

¿Cómo explicas SELECT y FROM en 30 segundos?

La respuesta oral que resiste preguntas de seguimiento: "SELECT le dice a la base de datos qué columnas quiero ver. FROM le dice en qué tabla buscar. Así que `SELECT name, salary FROM employees` me devuelve solo esas dos columnas de cada fila de la tabla employees."

La pregunta de seguimiento que suele venir después es: "¿Y si quieres todas las columnas?" La respuesta es `SELECT *`, y conviene mencionar enseguida que en código de producción lo evitarías porque trae datos innecesarios. Esa frase adicional demuestra que entiendes el compromiso real, no solo la sintaxis. En una entrevista básica de SQL, esa diferencia suele separar una respuesta aceptable de una sólida.

¿Cómo explicas WHERE sin confundirlo con HAVING?

WHERE filtra filas antes de que ocurra cualquier agrupación o agregación. Esa es la distinción completa, y vale la pena decirla exactamente así.

Ejemplo concreto: "Tengo una tabla `orders`. `WHERE amount > 100` me devuelve solo los pedidos de más de 100 dólares: filtra filas individuales. Eso es WHERE." El error que cometen los candidatos es intentar usar WHERE después de un GROUP BY, algo que SQL no permite. WHERE no sabe lo que es un grupo. Solo conoce filas. Quédate con esa imagen: WHERE ve filas, HAVING ve grupos; así podrás responder la diferencia bajo presión sin vacilar. La documentación oficial de PostgreSQL sobre agregación deja explícita esta secuencia: WHERE se ejecuta antes de agrupar y HAVING después.

¿Cómo explicas ORDER BY y GROUP BY con claridad en menos de un minuto?

Estas dos cláusulas se confunden porque ambas cambian el aspecto de los resultados, pero hacen tareas completamente distintas.

ORDER BY trata de ordenar. `ORDER BY salary DESC` te devuelve las mismas filas, solo que clasificadas de mayor a menor salario. No se combina nada, no se resume nada: solo reorganizas la salida. GROUP BY trata de resumir. `GROUP BY department_id` agrupa todas las filas con el mismo departamento en una sola fila, para que puedas hacer preguntas de agregación: cuántos empleados hay en cada departamento, cuál es el salario promedio por departamento. Una clasifica, la otra resume. Un informe que muestra ventas totales por región usa GROUP BY. Un informe que muestra a los 10 mejores vendedores usa ORDER BY.

¿Cómo explicas HAVING cuando el entrevistador quiere la versión corta?

Una frase clara: "HAVING filtra el resultado de un GROUP BY, del mismo modo que WHERE filtra filas individuales." Luego apóyala enseguida con un ejemplo, porque la frase sola suena a una definición memorizada.

Ejemplo: "Si agrupo las ventas por vendedor y solo quiero ver a los vendedores con ventas totales superiores a 10.000 dólares, no puedo usar WHERE: todavía no existe ninguna fila individual con ese total. Uso `HAVING SUM(amount) > 10000` después del GROUP BY." Esa respuesta es lo bastante específica para resistir una pregunta de seguimiento y lo bastante corta para decirla sin divagar.

Aquí tienes el contraste entre una respuesta floja y una precisa. Floja: "HAVING es como WHERE pero para grupos." Precisa: "WHERE filtra filas antes de agrupar. HAVING filtra el resultado agrupado. Si intentas usar WHERE sobre una función agregada como SUM o COUNT, SQL devolverá un error, porque en la etapa de WHERE esas agregaciones aún no se han calculado." La segunda versión resistiría una pregunta de seguimiento. La primera no.

Claves, restricciones y lo que los entrevistadores usan para ver si de verdad conoces la tabla

¿Cuál es la diferencia entre primary key, unique key y foreign key?

Las preguntas de SQL de nivel inicial sobre claves hacen tropezar a los candidatos porque las definiciones suenan parecidas hasta que las anclas en lo que cada clave realmente impone.

Primary key: identifica de forma única cada fila de una tabla, no puede ser NULL y solo puede haber una por tabla. En una tabla `employees`, `employee_id` es la primary key: cada empleado tiene una y no se repite. Unique key: también garantiza unicidad, pero puede permitir NULL (en la mayoría de las bases de datos) y una tabla puede tener varias unique keys. Una columna `email` es el ejemplo clásico de unique key: dos usuarios no pueden compartir correo, pero la columna es distinta de la primary key. Foreign key: vincula una tabla con otra. La columna `department_id` en `employees` es una foreign key que hace referencia a `department_id` en la tabla `departments`. Impide asignar a un empleado a un departamento que no existe.

¿Qué hacen realmente las restricciones SQL en una tabla real?

Piensa en las restricciones como barandillas que bloquean datos incorrectos antes de que entren en la tabla. NOT NULL significa que una columna no puede quedar vacía; si intentas insertar una fila sin un valor obligatorio, la base de datos la rechaza. CHECK añade una condición: `CHECK (age >= 18)` significa que no puede insertarse ninguna fila con edad inferior a 18. UNIQUE evita valores duplicados en una columna. PRIMARY KEY combina NOT NULL y UNIQUE en una sola restricción.

Un formulario de registro es el ejemplo real más claro. La tabla `users` tiene `email` como UNIQUE (no hay cuentas duplicadas), `username` como NOT NULL (no puedes registrarte sin uno) y `user_id` como PRIMARY KEY. Sin estas restricciones, los datos incorrectos se cuelan en silencio —correos duplicados, nombres de usuario vacíos, filas sin identificador— y limpiarlos después es mucho más costoso que bloquearlos al nivel de la tabla. La documentación de MySQL sobre restricciones cubre cada una en detalle si quieres la sintaxis exacta para tu dialecto.

¿Por qué a los entrevistadores les importa la normalización en nivel inicial?

En nivel inicial, la normalización significa una cosa: dejar de guardar el mismo dato en varios sitios. Si tienes una tabla `customers` y una tabla `orders`, la dirección del cliente pertenece a `customers`, no repetida en cada fila de `orders`. Cuando el cliente se muda, actualizas una fila en lugar de cientos.

El error común en esquemas de nivel inicial es poner `customer_name` y `customer_email` directamente en la tabla `orders`. Entonces, si un cliente cambia su correo, tienes que actualizar cada pedido que haya hecho; y si olvidas uno, tus datos quedan inconsistentes. La normalización no consiste en memorizar 1NF, 2NF y 3NF para una entrevista de nivel inicial. Consiste en poder decir: "Procuro mantener cada dato en un solo lugar para que las actualizaciones sean limpias."

Joins, subqueries y el punto en el que los principiantes suelen vacilar

¿Cuándo debes usar INNER JOIN frente a LEFT JOIN en una pregunta de entrevista básica?

Primero la regla simple: INNER JOIN devuelve solo las filas que tienen coincidencia en ambas tablas. LEFT JOIN devuelve todas las filas de la tabla de la izquierda, más las coincidencias de la derecha, y coloca NULL donde no hay coincidencia a la derecha.

Aquí es donde la regla simple se complica. Si tienes una tabla `customers` y una tabla `orders` y quieres ver a todos los clientes, incluidos los que nunca han hecho un pedido, INNER JOIN eliminará silenciosamente a esos clientes. LEFT JOIN los conserva y muestra NULL en las columnas del pedido. Las preguntas de SQL para principiantes casi siempre incluyen un escenario en el que importan las filas ausentes: clientes sin pedidos, empleados sin jefe, productos sin ventas. La pregunta que debes hacerte es: "¿Me da igual que desaparezcan filas si no hay coincidencia?" Si sí, INNER JOIN. Si no, LEFT JOIN. La documentación de PostgreSQL sobre tipos de joins explica con claridad el comportamiento completo.

¿Cómo explicas una subquery sin hacer que suene intimidante?

Una subquery es una consulta dentro de otra consulta. La consulta interna se ejecuta primero y produce un resultado, y la consulta externa usa ese resultado. Esa es toda la idea.

Ejemplo que lo hace concreto: "Quiero encontrar a todos los empleados que ganan más que el salario promedio. Podría calcular el promedio en una consulta y luego escribir una segunda consulta usando ese número. O puedo hacerlo en un solo paso: `SELECT name FROM employees WHERE salary > (SELECT AVG(salary) FROM employees)`." La consulta interna calcula el promedio. La consulta externa lo usa. Dos pasos, una sola sentencia.

¿Cuál es la forma más rápida de distinguir un join de una subquery en una entrevista?

Regla mnemotécnica: usa un JOIN cuando necesites columnas de ambas tablas en el resultado. Usa una subquery cuando solo necesites un valor de otra tabla para filtrar o comparar.

Si quieres listar empleados junto con el nombre de su departamento, necesitas columnas de `employees` y de `departments`: eso es un JOIN. Si quieres encontrar a los que más gastan sin necesitar ninguna columna de la tabla `orders` en la salida final, una subquery puede ser más limpia. En una entrevista real, a un candidato que escribió una subquery donde se esperaba un JOIN le dieron crédito parcial por la lógica correcta, pero le pidieron reescribirla: el entrevistador quería ver si entendía que la versión con JOIN era más legible y más fácil de indexar. Conocer ambos patrones y poder explicar por qué elegiste uno es lo que separa una respuesta aceptable de una sólida.

NULL, DISTINCT y agregados: las pequeñas trampas que cuestan puntos fáciles

¿Por qué NULL sigue rompiendo las respuestas de SQL de los principiantes?

NULL no es cero. No es una cadena vacía. Significa que el valor es desconocido o está ausente, y esa diferencia rompe la lógica de comparación habitual.

`WHERE salary = NULL` nunca devolverá filas, aunque haya salarios NULL. SQL exige `WHERE salary IS NULL`. La razón es que NULL comparado con cualquier cosa —incluso con otro NULL— devuelve NULL, no TRUE ni FALSE. Así que el filtro elimina en silencio todas las filas. Las basic SQL interview questions casi siempre incluyen al menos una pregunta sobre NULL, y la respuesta que funciona es: "NULL significa desconocido, así que no puedes usar = para encontrarlo. Debes usar IS NULL o IS NOT NULL." Un ejemplo real de limpieza de datos que muestra por qué esto importa: un equipo calculó tiempos medios de respuesta y obtuvo un valor sospechosamente alto porque olvidó que los tiempos NULL estaban siendo excluidos por la función agregada, no tratados como cero.

¿Cómo usas DISTINCT sin esconder un problema de datos?

DISTINCT elimina filas duplicadas del resultado. El riesgo es usarlo para que un resultado desordenado parezca limpio sin entender por qué existen los duplicados.

Si tienes una tabla `contacts` y `SELECT DISTINCT email` devuelve menos filas que `SELECT email`, tienes correos duplicados en tus datos. DISTINCT es la herramienta correcta cuando los duplicados son esperables e inocuos, por ejemplo, para obtener una lista única de países desde una tabla de ventas. Es la herramienta incorrecta cuando los duplicados señalan un problema de integridad de datos que debería corregirse en el origen. En una entrevista, si recurres a DISTINCT, prepárate para explicar por qué están los duplicados y si eliminarlos es lo correcto.

¿Qué hacen mal SUM, COUNT, AVG, MIN y MAX cuando hay NULL?

La regla que los principiantes olvidan: la mayoría de las funciones agregadas ignoran NULL por completo. `AVG(salary)` calcula el promedio solo de los salarios no NULL; no trata NULL como cero. `COUNT(salary)` cuenta solo los valores de salario no NULL. `COUNT(*)` cuenta todas las filas, independientemente de NULL.

Ejemplo con una tabla pequeña: cinco empleados con salarios de 50.000, 60.000, NULL, 70.000, NULL. `AVG(salary)` devuelve 60.000: el promedio de tres valores, no de cinco. `COUNT(salary)` devuelve 3. `COUNT(*)` devuelve 5. Si esperabas que AVG tuviera en cuenta a los cinco empleados, tu resultado es incorrecto. La solución suele ser `COALESCE(salary, 0)` para sustituir NULL por cero antes de agregar, pero solo si cero es realmente la interpretación empresarial correcta.

La secuencia de práctica de 30 minutos que sí se fija

¿Cómo deberías usar los primeros 10 minutos si solo tienes una noche?

Los minutos 0 a 10 son para recordar, no para dominar. Escribe, en papel o en un editor de texto, las cinco cláusulas básicas en orden: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY. Después escribe una frase explicando qué hace cada una. No busques nada. Lo que no puedas escribir de memoria es lo primero que necesitas repasar.

Las preguntas básicas de entrevista SQL a nivel de filtrado casi siempre empiezan con estas cláusulas. Si puedes explicar cada una en una frase y escribir una consulta simple usando cada una, ya has cubierto el primer filtro. Esto es práctica de recuperación, no lectura, y la investigación en ciencias del aprendizaje sobre la recuperación espaciada de la Association for Psychological Science muestra de forma consistente que el recuerdo activo supera la revisión pasiva para retener bajo presión de tiempo.

¿Qué deberías practicar en los minutos 10 a 20 si eres completamente principiante?

Pasa a consultas de una sola tabla con filtrado y agrupación. Usa este enunciado: "Tienes una tabla `sales` con las columnas `salesperson`, `region` y `amount`. Escribe una consulta que muestre las ventas totales por región, pero solo para las regiones en las que las ventas totales superen los 50.000 dólares."

Ese único enunciado te obliga a usar SELECT, FROM, GROUP BY, HAVING y una agregación SUM en secuencia. Escribe la consulta. Léela en voz alta. Luego cambia ligeramente el enunciado: filtra por otro umbral, añade ORDER BY para ordenar las regiones. El objetivo no es escribir SQL perfecto; es sentirte cómodo moviéndote entre cláusulas sin bloquearte.

¿Qué deberías practicar en los últimos 10 minutos antes de la entrevista?

Pasa a joins y a una subquery. Enunciado: "Tienes las tablas `customers` y `orders` vinculadas por `customer_id`. Escribe una consulta que devuelva a todos los clientes, incluidos los que nunca han hecho un pedido." Eso te obliga a decidirte por un LEFT JOIN. Luego: "Encuentra al cliente que ha realizado más pedidos." Eso puede resolverse con una subquery o con un JOIN más ORDER BY y LIMIT; prueba ambas.

Después de cada consulta, di la respuesta en voz alta en una sola frase: "Usé LEFT JOIN aquí porque necesitaba conservar a los clientes aunque no tuvieran pedidos coincidentes." Ese resumen hablado es exactamente lo que los entrevistadores quieren escuchar. La experiencia de acompañar a principiantes en filtros de SQL de nivel inicial muestra repetidamente el mismo patrón: los candidatos que pueden escribir la consulta pero no explicarla en lenguaje claro reciben preguntas de seguimiento más duras, mientras que los que empiezan con la explicación y luego escriben la consulta tienden a avanzar más rápido.

Los seguimientos que suelen venir después

¿Qué preguntas de seguimiento deberías esperar después de responder una pregunta básica de SQL?

La maniobra estándar del entrevistador tras una respuesta básica de SQL es comprobar si la respuesta fue memorizada o comprendida. Si explicas GROUP BY, te preguntarán: "¿Qué pasa si seleccionas una columna que no está en el GROUP BY?" (SQL dará error o devolverá valores arbitrarios según el dialecto.) Si explicas INNER JOIN, te preguntarán: "¿Qué pasa si hay varias filas coincidentes en el lado derecho?" (Obtendrás filas duplicadas en el lado izquierdo: una por cada coincidencia.)

Espera estas comprobaciones en una ronda normal de filtrado: "¿Puedes mostrármelo en una consulta?", "¿Qué pasaría si hubiera NULL en esos datos?", "¿Por qué elegiste ese enfoque en lugar de una subquery?" El patrón es siempre el mismo: un nivel más profundo que la definición que acabas de dar.

¿Cómo respondes cuando te piden escribir la consulta en el momento?

Decir lo correcto y construir la consulta en vivo son habilidades distintas. Cuando te pidan escribirla al momento, narra lo que haces: "Voy a empezar con SELECT y las columnas que necesito, luego FROM para nombrar la tabla, y después añadiré un WHERE para filtrar antes de agrupar." Ese comentario en voz alta hace dos cosas: muestra tu razonamiento y te compra unos segundos para pensar sin quedarte en silencio.

Ejercicio que puedes hacer ahora mismo en papel: "Tienes una tabla `employees` con `name`, `department` y `salary`. Escribe una consulta para encontrar el salario promedio por departamento, solo para los departamentos con más de cinco empleados." Escríbela sin buscar nada. Si te atascas, di en voz alta lo que intentas hacer; a menudo los entrevistadores te darán una pista si ven que estás pensando bien.

¿Cómo lo haces si solo conoces un dialecto de SQL?

Dilo directamente y sin disculparte: "He trabajado principalmente con PostgreSQL, así que escribiré la consulta en esa sintaxis, pero estoy dispuesto a señalar si algo es específico de un dialecto." Esa es una respuesta limpia y profesional. Es mucho mejor que escribir sintaxis de MySQL sin estar seguro de las diferencias y quedar en evidencia cuando el entrevistador pregunte por una función concreta.

Las diferencias reales entre dialectos en nivel inicial son menores: LIMIT frente a TOP para limitar filas, algunas diferencias en funciones de cadenas y algunos casos particulares en el manejo de NULL. Según la referencia SQL de W3Schools, la sintaxis básica de DML (SELECT, WHERE, JOIN, GROUP BY) es lo bastante consistente entre MySQL, PostgreSQL y SQL Server como para que una respuesta de principiante en cualquiera de ellos se entienda correctamente. El mayor riesgo es afirmar que dominas un dialecto que solo has revisado por encima.

Cómo Verve AI puede ayudarte a destacar en tu entrevista técnica de SQL

La parte más difícil de prepararse para una entrevista de SQL no es aprender la sintaxis, sino ser capaz de explicar una consulta con claridad mientras la escribes en directo, bajo presión y con alguien observándote. Esa distancia entre saber la respuesta y entregarla con fluidez es exactamente lo que Verve AI Interview Copilot está diseñado para cerrar.

Verve AI Interview Copilot lee tu pantalla en tiempo real —ya sea que estés resolviendo un enunciado de SQL en HackerRank, LeetCode o CodeSignal, o dentro de una ronda técnica en vivo— y muestra sugerencias basadas en lo que realmente aparece en tu pantalla, no en un prompt genérico. Si estás a mitad de una consulta y dudas entre usar HAVING o WHERE, Verve AI Interview Copilot puede mostrarte la diferencia en ese momento, antes de que el silencio se vuelva incómodo. La función Secondary Copilot te ayuda a mantenerte concentrado en un solo problema a la vez, en lugar de dispersarte hacia temas cercanos cuando aumenta la presión. Y como la aplicación de escritorio es invisible para la compartición de pantalla a nivel del sistema operativo, el apoyo se queda entre tú y la pantalla. Para un principiante que va a una ronda de filtrado de SQL con solo una noche de preparación, tener algo que responda a lo que realmente está ocurriendo, y no a un guion prefabricado, es la ventaja estructural que la memorización por sí sola no puede darte.

Conclusión

No necesitas saber todo SQL antes de una ronda básica de filtrado. Necesitas conocer el puñado de ideas a las que los entrevistadores vuelven una y otra vez: SELECT hasta HAVING, los tres tipos de claves, la decisión entre LEFT JOIN e INNER JOIN, y las trampas con NULL que rompen silenciosamente las respuestas con agregaciones. Es un conjunto manejable, y se puede aprender en una sola noche enfocada.

Haz la secuencia de 30 minutos una vez. Escribe las consultas en papel. Di las respuestas en voz alta. El objetivo no es sonar como alguien que ha leído un libro de texto, sino como alguien que realmente ha usado estas herramientas y sabe por qué existe cada una. Entra con eso, y los fundamentos no serán lo que te detenga.