15 preguntas de entrevista de ingeniería de datos que te van a hacer (y cómo responderlas)

Llevas semanas preparándote. Has hecho LeetCode, has repasado SQL, te sabes la diferencia entre un data lake y un data warehouse. Llega la entrevista y te preguntan: "¿Qué harías si tu pipeline se ejecuta dos veces por error?". Silencio. Sudor frío. Siguiente pregunta: "Explícame el CAP theorem como si yo fuera de marketing". Más silencio.

Estas preguntas no son difíciles — son preguntas que nadie te ha explicado con claridad. Aquí van 15 que salen en casi todas las entrevistas de data engineering, con respuestas que puedes dar tal cual y que demuestran que entiendes el PORQUÉ, no solo la definición de Wikipedia.

### 1. ¿Qué es un esquema estrella y por qué se usa?

Un esquema estrella es una forma de organizar tablas en un data warehouse. Tienes una tabla central de HECHOS (fact table) — por ejemplo, ventas — rodeada de tablas de DIMENSIONES (producto, cliente, fecha, tienda). La tabla de hechos tiene las métricas numéricas y foreign keys a las dimensiones.

La analogía: imagina un ticket de compra del supermercado. El ticket es el hecho (importe, cantidad, descuento). El producto, la tienda y la fecha son dimensiones — contexto que describe ese hecho. No repites la dirección de la tienda en cada línea del ticket; la referencias.

¿Por qué? Porque las queries analíticas son JOIN + GROUP BY + filtro. El esquema estrella minimiza los JOINs necesarios (máximo 1 salto) y hace que las queries sean predecibles y rápidas. Los motores columnares como Redshift o BigQuery están optimizados para este patrón.

### 2. ¿Qué es la idempotencia y por qué importa en pipelines?

Un proceso es idempotente si lo ejecutas una vez o 47 veces y el resultado es exactamente el mismo. Sin duplicados, sin efectos secundarios inesperados.

La analogía: un ascensor. Si pulsas el botón del piso 3 cinco veces seguidas, no llegas al piso 15. Llegas al 3. Eso es idempotencia.

¿Por qué importa? Porque en el mundo real los pipelines se re-ejecutan. Airflow reintenta tareas fallidas. Un deploy reinicia un servicio. Un cron se dispara dos veces. Si tu pipeline hace INSERT INTO sin más, acabas con datos duplicados. Si hace DELETE + INSERT (o MERGE/upsert), da igual cuántas veces corra.

1-- ❌ NO idempotente: si se ejecuta dos veces, duplica filas
2INSERT INTO ventas_diarias (fecha, total_ventas, num_pedidos)
3SELECT
4  current_date,
5  SUM(importe),
6  COUNT(*)
7FROM pedidos
8WHERE fecha_pedido = current_date;
9
10-- ✅ Idempotente: borra la partición antes de insertar
11DELETE FROM ventas_diarias WHERE fecha = current_date;
12
13INSERT INTO ventas_diarias (fecha, total_ventas, num_pedidos)
14SELECT
15  current_date,
16  SUM(importe),
17  COUNT(*)
18FROM pedidos
19WHERE fecha_pedido = current_date;

### 3. Explícame el CAP theorem

En un sistema distribuido, solo puedes garantizar dos de estas tres cosas a la vez: Consistencia (todos los nodos ven los mismos datos), Disponibilidad (cada petición recibe respuesta) y Tolerancia a particiones (el sistema funciona aunque se caiga la red entre nodos).

La analogía: tienes 3 amigos en un grupo de WhatsApp. Si se les cae internet a dos de ellos (partición de red), tienes que elegir: o todos ven el mismo mensaje a la vez (consistencia, pero los desconectados no pueden responder) o todos pueden seguir escribiendo por separado (disponibilidad, pero cuando vuelvan habrá mensajes que no cuadran).

En la práctica: las particiones de red PASAN. No puedes evitarlas. Así que la decisión real es entre CP (consistencia + tolerancia, como PostgreSQL o HBase — puede rechazar peticiones) y AP (disponibilidad + tolerancia, como Cassandra o DynamoDB — siempre responde, pero datos pueden estar temporalmente desincronizados).

### 4. ¿Qué son las Slowly Changing Dimensions (SCD)?

Las dimensiones cambian con el tiempo. Un cliente cambia de dirección. Un producto sube de precio. Un empleado cambia de departamento. La pregunta es: ¿qué haces con el valor anterior?

• ▹SCD Tipo 1: sobrescribes el valor antiguo. Simple, pero pierdes el historial. Ejemplo: corriges un typo en el nombre de un producto.
• ▹SCD Tipo 2: añades una nueva fila con fecha de inicio/fin. Conservas todo el historial. Ejemplo: un cliente cambia de ciudad y quieres saber dónde vivía cuando compró cada producto.
• ▹SCD Tipo 3: añades una columna con el valor anterior (ej. ciudad_anterior). Solo guardas un nivel de historial.

El tipo 2 es el más preguntado en entrevistas y el más usado en producción. Requiere campos como valid_from, valid_to y un flag is_current para saber cuál es la versión activa.

### 5. ¿Cuál es la diferencia entre ETL y ELT?

ETL: Extraes datos del origen, los Transformas fuera del warehouse (en Spark, Python, un servidor intermedio) y luego los Cargas ya limpios. ELT: Extraes, Cargas los datos crudos en el warehouse, y Transformas dentro usando SQL (con dbt, por ejemplo).

La analogía: ETL es como cocinar en casa y llevar el plato hecho al restaurante. ELT es llevar los ingredientes crudos al restaurante y cocinar allí, donde tienes una cocina industrial más potente.

Hoy la tendencia es ELT porque los warehouses modernos (Snowflake, BigQuery, Redshift) tienen compute masivo y es más fácil depurar transformaciones en SQL que en código distribuido. Pero ETL sigue teniendo sentido cuando los datos crudos son demasiado grandes o sensibles para cargar enteros.

### 6. ¿Qué es un data lake vs un data warehouse?

Un data warehouse almacena datos ESTRUCTURADOS, ya modelados y listos para consultas analíticas (esquema estrella, tablas optimizadas). Un data lake almacena datos en CUALQUIER formato (JSON, CSV, Parquet, imágenes, logs) sin estructura previa. Es más barato y flexible, pero más difícil de consultar.

La analogía: el warehouse es una biblioteca organizada con el sistema Dewey — sabes exactamente dónde está cada libro. El data lake es un almacén de Amazon — tiene de todo, pero necesitas un catálogo y un buen sistema de búsqueda para encontrar algo útil.

En la realidad actual, la frontera se difumina con el concepto "lakehouse" (Delta Lake, Iceberg): tienes la flexibilidad del lake con las garantías ACID y el rendimiento del warehouse.

### 7. ¿Cómo garantizas la calidad de datos en un pipeline?

La respuesta corta: validando en cada capa. La respuesta que quiere oír el entrevistador:

1. 01.Validaciones en la ingesta: ¿llegaron datos? ¿El schema es el esperado? ¿Hay nulls donde no debería?
2. 02.Validaciones post-transformación: ¿los totales cuadran con la fuente? ¿Hay duplicados? ¿Los rangos de fechas son coherentes?
3. 03.Contratos de datos: acuerdos formales con los equipos upstream sobre qué campos existen, qué tipos tienen y qué valores válidos aceptan.
4. 04.Alertas proactivas: si algo falla, te enteras TÚ primero — no el CEO mirando un dashboard vacío.
5. 05.Tests automatizados: frameworks como Great Expectations o checks SQL que corren en cada ejecución del pipeline.

### 8. ¿Qué es el backfilling y cuándo lo necesitas?

Backfilling es reprocesar datos históricos. Lo necesitas cuando: cambias la lógica de una transformación y quieres aplicarla al pasado, descubres un bug que afectó datos de los últimos 3 meses, añades una nueva métrica y necesitas calcularla para todo el historial, o una fuente de datos estuvo caída y necesitas recuperar lo perdido.

La clave: si tu pipeline es idempotente (pregunta 2), backfillear es simplemente re-ejecutar con un rango de fechas diferente. Si NO es idempotente... tienes un problema gordo y probablemente acabes con duplicados.

### 9. ¿Cuándo denormalizas y cuándo normalizas?

Normalizas (3NF) en bases de datos operacionales (OLTP): evitas redundancia, reduces errores de actualización, cada dato vive en un solo sitio. Denormalizas en bases analíticas (OLAP): precomputes JOINs, aceptas redundancia a cambio de velocidad de lectura.

La analogía: en tu cuenta del banco (OLTP), tu dirección se guarda UNA vez y se referencia desde todas tus cuentas. En el informe trimestral del banco (OLAP), tu dirección se copia en cada fila porque el analista no quiere hacer un JOIN cada vez que abre el informe.

En un warehouse tipo estrella siempre hay denormalización controlada. Las dimensiones suelen estar denormalizadas (la tabla dim_producto incluye el nombre de la categoría directamente, no una FK a una tabla aparte de categorías).

### 10. ¿Qué son las window functions y para qué sirven?

Las window functions calculan valores sobre un conjunto de filas RELACIONADAS con la fila actual, sin colapsar el resultado en un GROUP BY. Puedes calcular rankings, totales acumulados, diferencias con la fila anterior, o promedios móviles — todo sin perder el detalle de cada fila.

1-- Ventas diarias con acumulado mensual y ranking
2SELECT
3  fecha,
4  producto,
5  importe,
6  SUM(importe) OVER (
7    PARTITION BY producto
8    ORDER BY fecha
9    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
10  ) AS acumulado_producto,
11  ROW_NUMBER() OVER (
12    PARTITION BY DATE_TRUNC('month', fecha)
13    ORDER BY importe DESC
14  ) AS ranking_dia_en_mes
15FROM ventas
16WHERE fecha >= '2026-01-01'
17ORDER BY fecha;

Las window functions son probablemente la habilidad SQL más preguntada en entrevistas de data engineering. Si dominas PARTITION BY, ORDER BY dentro de OVER(), y las funciones LAG/LEAD/ROW_NUMBER/RANK, estás por encima del 80% de los candidatos.

### 11. ¿Qué es el data lineage y por qué importa?

Data lineage es saber DE DÓNDE viene cada dato y POR DÓNDE ha pasado hasta llegar a su estado actual. Es el "árbol genealógico" de un dato. Si un dashboard muestra un número raro, el lineage te permite rastrear hacia atrás: ¿de qué tabla sale? ¿Qué transformación le afectó? ¿Qué fuente original lo generó?

La analogía: es como la trazabilidad alimentaria. Si hay un brote de salmonela, necesitas saber exactamente de qué granja salió el huevo, qué camión lo transportó y a qué supermercados llegó. Sin trazabilidad, tiras TODOS los huevos del país. Con trazabilidad, solo los de esa granja.

En la práctica: herramientas como dbt generan lineage automáticamente (ves el grafo de dependencias entre modelos). En pipelines custom, lo implementas con metadatos: cada tabla registra cuándo se actualizó, desde qué fuente, con qué versión del código.

### 12. ¿Batch o streaming? ¿Cómo decides?

Batch: procesas datos en bloques (cada hora, cada día). Streaming: procesas datos en tiempo real conforme llegan. La decisión depende de UNA pregunta: ¿cuánto tiempo puede esperar el consumidor de esos datos?

• ▹El dashboard de ventas del mes se actualiza una vez al día → batch.
• ▹La detección de fraude en una transacción bancaria necesita respuesta en milisegundos → streaming.
• ▹Las recomendaciones de una app de música se recalculan cada hora → batch (o micro-batch).
• ▹Las alertas de un sensor de temperatura en una fábrica → streaming.

El 90% de los casos de uso en empresas son batch. El streaming es más complejo (estado, ordering, late arrivals) y más caro de operar. No elijas streaming por moda — elige cuando la latencia del batch es inaceptable para el negocio.

### 13. ¿Qué es un data contract?

Un data contract es un acuerdo formal entre el equipo que PRODUCE datos y el equipo que los CONSUME. Define: qué campos tiene la tabla/evento, qué tipos de datos, qué valores son válidos, qué garantías de freshness hay, y quién es el owner.

La analogía: es como la especificación de una API REST. Cuando un backend te dice "este endpoint devuelve un JSON con campo `price` de tipo float, nunca null", eso es un contrato. Si lo cambian sin avisarte, tu frontend se rompe. Un data contract es lo mismo pero para tablas y eventos.

¿Por qué importa? Porque sin contratos, el equipo de backend cambia un campo de nombre, tu pipeline se rompe, y te enteras cuando el CEO dice "el dashboard está vacío". Con contratos, el cambio se detecta antes de llegar a producción.

### 14. ¿Cómo manejas datos duplicados?

Los duplicados son el enemigo número 1 de un data engineer. Llegan por re-ejecuciones, por producers que envían el mismo evento dos veces (at-least-once delivery), por merges de fuentes que se solapan, o por bugs en la ingesta.

Estrategias de deduplicación:

1. 01.Prevención: pipelines idempotentes (DELETE + INSERT, MERGE/upsert, particionado).
2. 02.Detección en ingesta: hash del registro completo como ID natural. Si el hash ya existe, descarta.
3. 03.Detección post-hoc: ROW_NUMBER() OVER (PARTITION BY clave_natural ORDER BY timestamp DESC) y quedarte solo con rn = 1.
4. 04.En streaming: ventanas de deduplicación con estado (Kafka Streams, Spark Structured Streaming).

1-- Deduplicar eventos: quedarse solo con el más reciente por event_id
2WITH ranked AS (
3  SELECT
4    *,
5    ROW_NUMBER() OVER (
6      PARTITION BY event_id
7      ORDER BY received_at DESC
8    ) AS rn
9  FROM raw_events
10)
11SELECT *
12FROM ranked
13WHERE rn = 1;

### 15. ¿Cómo diseñarías un pipeline de datos desde cero?

Esta es la pregunta "system design" de data engineering. No hay una respuesta única, pero sí un framework mental que demuestra madurez:

1. 01.Entender el problema de negocio: ¿Qué decisión se va a tomar con estos datos? ¿Quién los consume? ¿Con qué latencia?
2. 02.Identificar las fuentes: ¿APIs, bases de datos, archivos, eventos? ¿Qué volumen? ¿Con qué frecuencia cambian?
3. 03.Definir la arquitectura de capas: raw (datos crudos, inmutables), staging (limpieza y validación), gold (modelado, listo para consumo).
4. 04.Elegir herramientas según el volumen y la latencia: ¿GBs al día? Python + SQL bastan. ¿TBs al día? Spark. ¿Milisegundos? Kafka + Flink.
5. 05.Garantizar calidad: validaciones en cada capa, alertas, contratos con upstream.
6. 06.Orquestar: cómo se ejecuta, con qué frecuencia, qué pasa si falla, cómo se reprocesa.
7. 07.Monitorizar: métricas del pipeline (duración, filas procesadas, errores), no solo del dato final.

En la entrevista, lo que diferencia a un junior de un mid es que el mid menciona los TRADE-OFFS: "Podríamos usar streaming, pero dado que la latencia aceptable es de 1 hora, batch es más simple de operar y debuggear. Si el requisito cambia, podemos migrar a micro-batch con Spark Structured Streaming."

### El consejo final

Las entrevistas de data engineering no buscan que recites definiciones — buscan que PIENSES como un ingeniero. Eso significa: entender el problema antes de proponer la solución, considerar trade-offs, mencionar qué puede salir mal, y ser honesto sobre lo que no sabes.

Si quieres practicar estos conceptos con ejercicios reales (no solo leerlos), en BigDataStack los trabajamos en profundidad: modelado dimensional, window functions, pipelines idempotentes, calidad de datos y diseño de arquitecturas. Cada concepto con código que puedes ejecutar, no solo teoría.