Preguntas de entrevista para analista de datos: SQL, negocio y casos prácticos

Las entrevistas para analista de datos tienen algo curioso: la gente se prepara solo el SQL técnico y luego se queda en blanco cuando le preguntan "las ventas han caído un 15%, ¿por dónde empezarías a investigar?". No es un problema de conocimiento — es un problema de no haber practicado el razonamiento en voz alta.

Aquí van 15 preguntas que salen en entrevistas reales, divididas en tres bloques. Con cada una incluyo la respuesta que YO daría y por qué. No son respuestas de libro de texto — son respuestas que demuestran que piensas como un analista, no como un diccionario de SQL.

### Bloque 1: SQL técnico

1. Explica la diferencia entre INNER JOIN, LEFT JOIN y FULL JOIN con un ejemplo.

INNER JOIN te da solo las filas que existen en AMBAS tablas. LEFT JOIN te da todas las de la izquierda y, si hay match, las de la derecha (si no, NULL). FULL JOIN te da todo de ambos lados. La clave es pensar en qué datos quieres PERDER: con INNER pierdes clientes sin pedidos. Con LEFT los mantienes (con pedidos en NULL). Usa LEFT cuando necesitas "todos los X, tengan o no Y".

1-- Clientes que HAN comprado (solo los que tienen pedido)
2SELECT c.nombre, p.fecha, p.importe
3FROM clientes c
4INNER JOIN pedidos p ON c.id = p.cliente_id;
5
6-- TODOS los clientes, hayan comprado o no
7SELECT c.nombre, p.fecha, p.importe
8FROM clientes c
9LEFT JOIN pedidos p ON c.id = p.cliente_id;
10-- Los que no compraron tendrán fecha=NULL, importe=NULL
11
12-- Truco: clientes que NUNCA han comprado
13SELECT c.nombre
14FROM clientes c
15LEFT JOIN pedidos p ON c.id = p.cliente_id
16WHERE p.id IS NULL;

2. ¿Cuándo usarías GROUP BY y cuándo DISTINCT?

DISTINCT elimina duplicados de la salida. GROUP BY agrupa filas para calcular algo (SUM, COUNT, AVG). Si solo quieres "valores únicos", DISTINCT. Si quieres "cuántos de cada", GROUP BY. El error típico es usar GROUP BY sin función de agregación — en ese caso, DISTINCT es más claro y expresa mejor la intención.

3. Dame un ejemplo práctico de ROW_NUMBER() que usarías en tu trabajo diario.

1-- La última compra de cada cliente (muy habitual en dashboards)
2WITH ultima_compra AS (
3  SELECT
4    cliente_id,
5    fecha,
6    importe,
7    producto,
8    ROW_NUMBER() OVER (
9      PARTITION BY cliente_id
10      ORDER BY fecha DESC
11    ) AS rn
12  FROM pedidos
13)
14SELECT cliente_id, fecha, importe, producto
15FROM ultima_compra
16WHERE rn = 1;

4. ¿Cuál es la diferencia entre una subquery y un CTE? ¿Cuándo prefieres cada una?

Un CTE (WITH ... AS) es una subquery con nombre. Funcionalmente hacen lo mismo. La diferencia es legibilidad: un CTE se lee de arriba abajo, como un programa; una subquery anidada hay que leerla de dentro hacia afuera. Uso CTEs siempre que la lógica tenga más de un paso. Subqueries para filtros simples tipo WHERE x IN (SELECT ...).

5. ¿Cómo categorizar filas con CASE WHEN? Ejemplo real.

1-- Segmentar clientes por gasto total
2SELECT
3  cliente_id,
4  SUM(importe) AS gasto_total,
5  CASE
6    WHEN SUM(importe) >= 5000 THEN 'VIP'
7    WHEN SUM(importe) >= 1000 THEN 'frecuente'
8    WHEN SUM(importe) >= 200  THEN 'ocasional'
9    ELSE 'nuevo'
10  END AS segmento
11FROM pedidos
12GROUP BY cliente_id
13ORDER BY gasto_total DESC;

6. ¿Cómo calcularías las ventas de la semana pasada vs la anterior? 7. ¿Cuál es la diferencia entre WHERE y HAVING?

Para la 6: LAG con una query preagregada por semana (ya lo vimos en el artículo de SQL analítico). Para la 7: WHERE filtra filas ANTES de agrupar. HAVING filtra grupos DESPUÉS. Si tu condición necesita SUM/COUNT/AVG, va en HAVING. Si no, va en WHERE.

### Bloque 2: interpretación de negocio

8. ¿Cuáles son los 3 KPIs más importantes de un e-commerce? ¿Por qué esos?

Mi respuesta: tasa de conversión (visitantes → compradores), ticket medio y LTV (valor de vida del cliente). La conversión te dice si el funnel funciona, el ticket medio te dice si vendes bien, y el LTV te dice si retienes. Todo lo demás (páginas vistas, sesiones, rebote) son métricas de actividad, no de resultado. Un analista que solo mira actividad no está midiendo valor.

9. Tu jefe dice "tenemos 50.000 seguidores en Instagram, estamos creciendo". ¿Qué le preguntas?

Le pregunto: "¿Cuántos de esos seguidores han comprado algo?". Seguidores es una métrica de vanidad — mide atención, no valor. Si 50.000 seguidores generan 0 ventas, no están creciendo: están acumulando audiencia sin retorno. Las métricas que importan son las que se conectan con ingresos o costes. Lo demás es ruido que queda bien en una slide.

10. ¿Cómo definirías la métrica "cliente activo"? 11. ¿Correlación implica causalidad?

Para la 10: depende del negocio. En un SaaS, un cliente activo puede ser "ha hecho login en los últimos 7 días". En un e-commerce, "ha comprado en los últimos 90 días". La clave es que la definición sea precisa, medible y acordada con negocio ANTES de construir el dashboard. Un "activo" sin definición exacta no se puede medir.

Para la 11: no. Correlación mide co-movimiento; causalidad requiere un mecanismo. El consumo de helados y los ahogamientos correlacionan, pero no porque el helado mate: ambos suben con el calor. Para demostrar causalidad necesitas un experimento controlado (A/B test) o, al menos, controlar por las variables confusoras.

### Bloque 3: casos prácticos

12. "Las ventas cayeron un 15% este mes. ¿Por dónde empiezas?"

Framework mental: segmentar hasta encontrar dónde está la caída. Paso 1: ¿es todas las tiendas o una? Paso 2: ¿todos los productos o un segmento? Paso 3: ¿es tráfico (menos gente viene) o conversión (la misma gente compra menos)? Paso 4: ¿hay un evento externo (festivo, competidor, fallo técnico)? La clave es ir de lo general a lo específico sin inventarse la respuesta antes de mirar.

13. "Necesitamos un dashboard nuevo para el equipo de marketing." ¿Qué haces primero?

NO abro Tableau/Looker. Primero pregunto: ¿qué decisiones van a tomar con ese dashboard? ¿Con qué frecuencia lo miran? ¿Qué métricas les importan y cómo las definen? Un dashboard que nadie usa es código muerto. Antes de construir, asegúrate de que el consumidor sabe qué quiere hacer con los datos.

14. "El dashboard dice que vendimos 100k€ pero finanzas dice que fueron 95k€." ¿Qué pasa?

Discrepancias entre fuentes es el pan de cada día. Las causas habituales: diferente definición de "venta" (con o sin IVA, con o sin devoluciones, fecha de pedido vs fecha de cobro), distinto corte temporal (el dashboard puede incluir pedidos cancelados que finanzas ya descontó), o un filtro que falta. La respuesta correcta es investigar la diferencia fila a fila hasta encontrar las transacciones que están en uno y no en otro.

15. Tienes 10 peticiones de 5 departamentos. ¿Cómo priorizas?

Criterios: impacto en ingresos/costes × urgencia × esfuerzo de hacerlo. Una petición que impacta en decisiones de 500k€ y tarda 2 horas va primera. Una que impacta en una curiosidad y tarda 2 días va última. Y comunico la priorización — nadie se enfada si le dices "la tuya va tercera porque primero hay dos que bloquean una decisión mayor", pero sí se enfada si desapareces sin explicar.

### Cómo prepararte

• ▹SQL técnico: practica con ejercicios reales, no memorices sintaxis. Si puedes resolver un "top N por grupo" sin mirar Google, vas bien.
• ▹Negocio: para cada métrica que uses en el trabajo, pregúntate POR QUÉ importa. Si no puedes explicarlo en una frase, no la entiendes.
• ▹Casos: practica en voz alta. Di "primero haría X, luego Y" aunque estés solo. La fluidez verbal marca la diferencia.
• ▹Pide el puesto que quieres: si dicen "analista senior" y solo sabes SELECT, no es tu entrevista todavía. Pero si sabes window functions y puedes explicar una caída de KPIs, dale.

Las preguntas de entrevista para analista no son difíciles si las has pensado antes. El problema es llegar sin haberlas pensado nunca, y eso se arregla con práctica deliberada. Si quieres más ejercicios de SQL con datos reales y feedback inmediato, eso es exactamente lo que trabajamos en la plataforma.