Preguntas de entrevista Senior Ingeniero de Datos

Qué se espera en el nivel Senior

Se espera arquitectura de plataforma/warehouse, fiabilidad y responsabilidad de gobernanza.

Preguntas de ejemplo para entrevista de Ingeniero de Datos

• ProgramaciónEscribe una consulta SQL para encontrar el segundo salario más alto por departamento.
  Lo que cubre una buena respuesta

  • Uso de DENSE_RANK con PARTITION BY departamento
  • Manejo de empates en salarios
  • Filtrado por rango = 2
  • Eficiencia O(n log n) por ordenación

  Ver respuesta de ejemplo

  Para encontrar el segundo salario más alto por departamento, uso la función de ventana DENSE_RANK(), que asigna rangos consecutivos sin saltos, incluso con empates. Particiono por departamento y ordeno por salario descendente. Luego filtro donde el rango sea 2. Esto devuelve todos los empleados con el segundo salario más alto, incluyendo múltiples si hay empates. Alternativa con ROW_NUMBER si solo se quiere uno, pero DENSE_RANK es más correcto para el segundo valor. Un error común es usar RANK() que salta rangos en caso de empate, dando resultados incorrectos.

  -- Encontrar segundo salario más alto por departamento
  SELECT departamento_id, salario
  FROM (
    SELECT 
      departamento_id,
      salario,
      DENSE_RANK() OVER (PARTITION BY departamento_id ORDER BY salario DESC) AS rango
    FROM empleados
  ) ranked
  WHERE rango = 2;

• TécnicaExplica la diferencia entre ETL y ELT y cuándo usarías cada uno.
  Lo que cubre una buena respuesta

  • Lugar de transformación (ETL: antes de cargar; ELT: después de cargar)
  • Latencia y volumen de datos
  • Escalabilidad y costos de cómputo
  • Casos de uso: ETL para cumplimiento, ELT para big data

  Ver respuesta de ejemplo

  ETL (Extract, Transform, Load) transforma los datos en un motor externo antes de cargarlos al almacén, ideal cuando se necesita limpieza estricta, cumplimiento normativo, o se trabaja con datos pequeños. ELT (Extract, Load, Transform) carga primero los datos brutos y luego aplica transformaciones dentro del almacén (ej. Snowflake, BigQuery). ELT es mejor para grandes volúmenes, ya que aprovecha el poder de cómputo del almacén y permite flexibilidad en transformaciones posteriores. Sin embargo, incrementa el costo de almacenamiento y puede ser más lento si el almacén no está optimizado. Un error común es asumir que ELT siempre es superior; para datos sensibles o con requisitos de tiempo real, ETL sigue siendo más adecuado.

• Técnica¿Cómo diseñarías un pipeline idempotente que se pueda re-ejecutar con seguridad?
  Lo que cubre una buena respuesta

  • Determinismo en las salidas para una misma entrada
  • Checkpointing y almacenamiento de estado intermedio
  • Deduplicación mediante claves únicas
  • Escrituras transaccionales (commit/abort)
  • Manejo de reintentos con backoff

  Ver respuesta de ejemplo

  Un pipeline idempotente garantiza que ejecutarlo múltiples veces produce el mismo resultado que una sola ejecución. Para lograrlo, diseño las transformaciones como funciones puras sin efectos secundarios. Implemento checkpointing guardando el estado procesado (offset de Kafka, marcas de agua) en almacenamiento duradero. Cada registro debe tener una clave única (por ejemplo, UUID) para que al insertar se use UPSERT o escritura por clave primaria, evitando duplicados. Las escrituras en el destino deben ser transaccionales (particionadas o con commit de dos fases). Cuando se re-ejecuta, el pipeline comienza desde el último checkpoint y salta registros ya procesados. Una trampa común es no considerar la deduplicación en el destino, causando filas repetidas tras un fallo.

• Técnica¿Cómo manejas los datos que llegan tarde en un pipeline de streaming?
  Lo que cubre una buena respuesta

  • Uso de watermarks para definir el límite de tardanza
  • Configuración de allowed lateness en ventanas
  • Emisión de resultados tempranos, completos y tardíos (update mode)
  • Side outputs para datos extremadamente tardíos
  • Estrategias: ignorar, reprocesar, o emitir actualizaciones

  Ver respuesta de ejemplo

  En streaming, los datos tardíos se manejan con watermarks, que son marcas de tiempo que indican hasta qué evento de tiempo se considera completo. Configuro una allowed lateness (ej. 10 minutos) para que las ventanas sigan aceptando eventos tardíos y emitan actualizaciones. Si los datos llegan después del watermark, puedo descartarlos o enviarlos a un side output para reprocesamiento. Con Kafka Streams o Flink, uso triggers que emiten resultados tempranos y luego actualizaciones en modo 'update'. Un error común es usar Processing Time sin considerar event time, lo que lleva a resultados incorrectos. Para latencia extrema, es mejor desacoplar con una cola y reprocesar en batch.

• ProgramaciónUsa funciones de ventana para calcular una media móvil de 7 días.
  Lo que cubre una buena respuesta

  • Uso de AVG() con cláusula OVER y ROWS BETWEEN
  • Ordenación por fecha para definir la ventana
  • Manejo adecuado de bordes (ej. primeros 6 días)
  • Complejidad O(n) por partición sin auto-join

  Ver respuesta de ejemplo

  Para una media móvil de 7 días, uso AVG() sobre una ventana definida por ORDER BY fecha con ROWS BETWEEN 6 PRECEDING AND CURRENT ROW. Esto promedia los últimos 7 registros (incluyendo el actual). Si los datos son diarios, la ventana cubre exactamente 7 días. Para los primeros días donde hay menos de 7 registros, el promedio se calcula con los disponibles. Es importante que los datos estén ordenados por fecha y que no haya huecos; si los hay, es preferible usar RANGE INTERVAL. Un error común es usar ROWS BETWEEN sin verificar la cardinalidad, lo que puede incluir más o menos filas de las esperadas en presencia de duplicados.

  -- Media móvil de 7 días usando ventana
  SELECT
    fecha,
    valor,
    AVG(valor) OVER (ORDER BY fecha ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS media_movil_7d
  FROM series_temporales;

• Diseño de sistemasDiseña un data warehouse para la analítica de una empresa de comercio electrónico.
  Lo que cubre una buena respuesta

  • Modelo estrella con tabla de hechos (ventas) y dimensiones (producto, cliente, tiempo)
  • Tabla de hechos con medidas: cantidad, precio, descuento
  • Dimensiones con SCD tipo 2 para cambios históricos
  • Particionamiento por fecha, índices en claves foráneas
  • ETL: carga incremental, control de calidad

  Ver respuesta de ejemplo

  El data warehouse se diseña con modelo estrella. La tabla de hechos principal es Ventas con columnas: id_producto, id_cliente, id_tiempo, cantidad, precio_unitario, descuento. Las dimensiones: DimProducto (con categorías, proveedor), DimCliente (con segmentos, geografía), DimTiempo (día, mes, trimestre, año). Para cambios en atributos de dimensiones (ej. cambio de categoría de producto), uso SCD tipo 2 manteniendo versiones con fechas de vigencia. La tabla de hechos se particiona por mes y se aplica compresión. El ETL corre diariamente con carga incremental usando marcas de tiempo y validaciones de integridad referencial. Las consultas comunes incluyen ventas por región, tendencias mensuales y top productos. Un error común es no prever la granularidad de la tabla de hechos; se debe definir al nivel de línea de pedido.

• ConductualCuéntame de un problema de calidad de datos que detectaste y corregiste.
  Lo que cubre una buena respuesta

  • Problema específico: duplicados en tabla de transacciones por fallo de red
  • Detección mediante checksum y comparación de registros
  • Impacto: sobreestimación de ingresos en reportes
  • Solución: agregar validación de unicidad en pipeline con hash y upsert
  • Monitoreo posterior con alertas de calidad

  Ver respuesta de ejemplo

  En un pipeline de ingesta de ventas desde una API, detecté que, tras una caída del servicio, se procesaron duplicados al reintentar sin verificar idempotencia. Los duplicados hicieron que los reportes de ingresos estuvieran inflados en un 3%. Los detecté al comparar el total de registros diarios con un checksum calculado a partir de los IDs de transacción. Implementé una validación en el pipeline: cada registro lleva un ID único; en la base de datos destino usé una clave primaria compuesta (ID + origen) con UPSERT. Además, añadí una etapa de deduplicación basada en hash previo a la carga. Monitoreo con alertas automáticas si la tasa de duplicados supera el 0.01%. La lección fue siempre diseñar pipelines idempotentes desde el inicio.

• Conductual¿Cómo priorizas la fiabilidad de los pipelines frente a las nuevas solicitudes?
  Lo que cubre una buena respuesta

  • Evaluación del impacto de cada solicitud en fiabilidad
  • Negociación de SLAs y tiempo de entrega
  • Implementación de automatización para reducir carga manual
  • Presupuesto de mantenimiento vs nuevas funcionalidades
  • Uso de pruebas de regresión y entornos staging

  Ver respuesta de ejemplo

  Priorizo evaluando el costo de no hacer una mejora de fiabilidad frente al valor del nuevo requerimiento. Si el pipeline tiene incidentes recurrentes, dedico un sprint a mejorar monitoreo, alertas y recuperación automática. Comunico a los stakeholders que la fiabilidad es un requisito no funcional y negocio SLAs: un 99.9% de uptime justifica invertir en redundancia, mientras que una solicitud urgente puede esperar si no hay holgura. Automatizo pruebas de integración y despliegue (CI/CD) para liberar tiempo. Mantengo un backlog separado para deuda técnica. Un ejemplo: rechacé una nueva característica de enriquecimiento porque los pipelines batch tenían fallos cada semana; primero implementé checkpointing y luego añadí la funcionalidad. Al final, la fiabilidad mejoró y la nueva característica se entregó más rápido sin incidentes.

Qué evalúan los entrevistadores

Cómo prepararte

• Afina tu SQL: las funciones de ventana y la optimización aparecen en casi todos los procesos.
• Para el diseño de pipelines, empieza por la idempotencia, los reintentos y los backfills.
• Menciona de forma proactiva la calidad de datos y el linaje; señala madurez de producción.

Preguntas frecuentes