Preguntas de entrevista para Data Engineer — 30+ preguntas y respuestas de expertos
Los roles de ingeniería de datos han crecido más de un 60 % desde 2020, convirtiéndose en una de las especializaciones de más rápido crecimiento en tecnología [1]. Sin embargo, con un promedio de 118 solicitantes por puesto abierto y una tasa de contratación del 27 % desde la entrevista [2], las entrevistas siguen siendo altamente competitivas. Las entrevistas modernas para ingenieros de datos van más allá de la competencia en SQL — evalúan tu capacidad para diseñar pipelines escalables, modelar datos para analítica, gestionar la calidad de los datos y operar en entornos de producción usando herramientas como Spark, Kafka, dbt y Airflow [3]. Las preguntas a continuación reflejan los patrones utilizados por equipos de contratación en empresas que van desde startups construyendo su primer stack de datos hasta empresas que gestionan almacenes de datos a escala de petabytes.
Conclusiones clave
- Las entrevistas para ingenieros de datos abarcan SQL, Python, modelado de datos, diseño de pipelines ETL/ELT y arquitectura de sistemas [1].
- Espera desafíos de codificación en SQL y Python junto con sesiones de diseño de pipelines en pizarra.
- Las preguntas conductuales exploran cómo manejas incidentes de calidad de datos, comunicación con stakeholders y colaboración entre equipos.
- Se espera cada vez más el conocimiento de herramientas del stack de datos moderno (dbt, Airflow, Spark, Kafka, Snowflake, Databricks).
- Demostrar comprensión de gobernanza de datos, linaje y observabilidad diferencia a los candidatos senior.
Preguntas conductuales
Los ingenieros de datos se encuentran en la intersección de ingeniería y analítica, colaborando con científicos de datos, analistas y equipos de producto. Las preguntas conductuales evalúan cómo navegas estas relaciones bajo restricciones del mundo real [4].
1. Describe una vez que un pipeline de datos que construiste falló en producción. ¿Cómo lo diagnosticaste y reparaste?
Usa STAR: la Situación (el trabajo ETL diario falló a las 3 AM, retrasando el dashboard de analítica matutino), la Tarea (restaurar la actualización de datos antes del horario laboral), la Acción (revisé los logs de Airflow, identifiqué un cambio de esquema en la API fuente que rompió el paso de extracción, implementé manejo de evolución de esquema y agregué alertas), y el Resultado (pipeline restaurado en 90 minutos, se agregaron pruebas de integración que detectaron cambios de esquema automáticamente en adelante).
2. Cuéntame sobre una vez que estuviste en desacuerdo con un científico de datos o analista sobre cómo modelar los datos. ¿Cómo lo resolviste?
Describe el compromiso — quizás el analista quería una tabla amplia desnormalizada para rendimiento de consultas mientras tú abogabas por un modelo dimensional normalizado para mantenibilidad. Explica cómo probaste ambos enfoques con consultas representativas y encontraste un compromiso (vistas materializadas o tablas pre-agregadas) que satisfizo ambas necesidades.
3. Guíame a través de una situación en la que heredaste un pipeline de datos legado y tuviste que decidir si refactorizarlo o reconstruirlo.
Evalúa los criterios de decisión: calidad de la documentación, cobertura de pruebas, criticidad para el negocio y el costo del tiempo de inactividad durante la migración. Las respuestas fuertes muestran una evaluación sistemática en lugar de recurrir por defecto a "reescribir todo" o "dejarlo como está."
4. Describe una vez que implementaste monitoreo de calidad de datos que detectó un problema antes de que llegara a los consumidores downstream.
Discute verificaciones específicas de calidad de datos: monitoreo de tasa de nulos, SLAs de frescura, detección de anomalías en conteos de filas y validación de esquema. Menciona herramientas como Great Expectations, pruebas de dbt o Monte Carlo. Cuantifica el impacto — "detecté una caída del 40 % en el conteo de filas por un cambio en el sistema fuente que habría producido informes de ingresos incorrectos."
5. Cuéntame sobre una vez que tuviste que explicar un concepto de ingeniería de datos a un stakeholder no técnico.
Enmarcar los procesos ETL, la latencia de datos y las dependencias del pipeline en términos de negocio es esencial. Describe el uso de analogías, dashboards o indicadores de frescura de datos para hacer visible y comprensible la salud del pipeline.
6. ¿Cómo has manejado una situación en la que los datos de un sistema fuente eran poco confiables o inconsistentes?
Discute la implementación de validación en la capa de ingesta, la creación de verificaciones de conciliación entre origen y destino, la documentación de problemas de calidad de datos en un catálogo de datos y la comunicación de limitaciones conocidas a los usuarios downstream en lugar de propagar silenciosamente datos erróneos.
Preguntas técnicas
Las preguntas técnicas evalúan tu profundidad en SQL, sistemas distribuidos, modelado de datos y arquitectura de pipelines [5].
1. Explica la diferencia entre ETL y ELT. ¿Cuándo elegirías cada enfoque?
ETL (Extract, Transform, Load) transforma los datos antes de cargarlos en el almacén — adecuado cuando el almacén tiene capacidad de cómputo limitada o cuando las transformaciones requieren lógica de negocio compleja. ELT (Extract, Load, Transform) carga primero los datos brutos y los transforma en el almacén — preferido con almacenes columnares modernos (Snowflake, BigQuery, Redshift) que tienen cómputo elástico para transformaciones [3]. Discute cómo dbt se ha convertido en la herramienta estándar para la "T" en ELT.
2. Escribe una consulta SQL para encontrar el segundo salario más alto en cada departamento.
Usa una función de ventana: SELECT department, employee, salary FROM (SELECT department, employee, salary, DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank FROM employees) ranked WHERE rank = 2. Discute por qué DENSE_RANK maneja empates correctamente y por qué RANK o ROW_NUMBER podrían dar resultados diferentes.
3. ¿Cómo diseñarías un pipeline de datos incremental que procese solo registros modificados de un sistema fuente?
Discute estrategias de Change Data Capture (CDC): cargas incrementales basadas en timestamps (usando columnas updated_at), CDC basado en logs (Debezium leyendo write-ahead logs de la base de datos) y comparación basada en hash. Aborda los desafíos: datos que llegan tarde, eliminaciones invisibles para los enfoques basados en timestamps y garantías de procesamiento exactly-once [1].
4. Explica las diferencias entre un esquema estrella y un esquema copo de nieve. ¿Cuándo usarías cada uno?
Un esquema estrella tiene una tabla de hechos central conectada a tablas de dimensiones desnormalizadas — consultas más simples, lecturas más rápidas, ideal para herramientas de BI. Un esquema copo de nieve normaliza las tablas de dimensiones en subdimensiones — reduce la redundancia de almacenamiento pero aumenta la complejidad de las consultas. Los esquemas estrella se prefieren para cargas de trabajo analíticas donde el rendimiento de consultas importa; los esquemas copo de nieve se adaptan a entornos donde la eficiencia de almacenamiento y la integridad de datos son prioridades.
5. ¿Cómo se diferencia Apache Kafka de una cola de mensajes tradicional como RabbitMQ, y cuándo elegirías Kafka para un pipeline de datos?
Kafka es una plataforma de streaming de eventos distribuida con logs durables, ordenados y reproducibles. RabbitMQ es un broker de mensajes optimizado para entrega punto a punto con semántica de confirmación. Elige Kafka para streaming de eventos de alto rendimiento, agregación de logs y escenarios donde múltiples consumidores necesitan leer los mismos datos independientemente (fan-out). Elige RabbitMQ para colas de tareas con enrutamiento complejo y requisitos de entrega exactly-once [5].
6. ¿Qué es el particionamiento de datos y cómo mejora el rendimiento de consultas en un almacén de datos?
El particionamiento divide tablas grandes en segmentos basados en una clave (fecha, región, ID de cliente). Las consultas que filtran por la clave de partición solo escanean segmentos relevantes, reduciendo I/O y costo de cómputo. Discute estrategias de particionamiento: particionamiento por rango para datos de series temporales, particionamiento por hash para distribución uniforme y la importancia de elegir claves de partición que se alineen con los patrones de consulta comunes.
7. ¿Cómo manejas la evolución de esquema en un pipeline de datos cuando las fuentes upstream cambian su formato de datos?
Implementa un registro de esquemas (Confluent Schema Registry para Kafka o evolución de esquema Avro/Parquet). Define reglas de compatibilidad hacia adelante y hacia atrás. Usa zonas de aterrizaje que acepten datos brutos sin aplicación de esquema, luego valida y transforma en capas de staging. Genera alertas ante cambios de esquema e implementa circuit breakers que detengan el procesamiento en lugar de propagar datos corruptos [3].
Preguntas situacionales
Las preguntas situacionales presentan desafíos realistas de pipelines para evaluar tu enfoque de resolución de problemas [4].
1. Tu pipeline diario tarda 6 horas en completarse, pero el negocio necesita datos actualizados cada 2 horas. ¿Cómo lo abordas?
Analiza dónde se gasta el tiempo — ¿en la extracción, transformación o carga? Implementa procesamiento incremental para reemplazar recargas completas de tablas. Paraleliza transformaciones independientes. Considera mover transformaciones pesadas al almacén (ELT) para aprovechar su cómputo elástico. Si el SLA requiere casi tiempo real, evalúa alternativas de streaming para las tablas más críticas.
2. Un científico de datos reporta que la precisión de un modelo de machine learning cayó repentinamente. Sospecha un problema de calidad de datos. ¿Cómo investigas?
Revisa los metadatos del pipeline: ¿la ejecución más reciente se completó exitosamente? Compara conteos de filas, tasas de nulos y distribuciones de valores contra baselines históricas. Revisa cambios en el sistema fuente (modificaciones de esquema, actualizaciones de reglas de negocio). Usa herramientas de linaje de datos para rastrear las características de entrada del modelo hasta sus tablas fuente e identificar dónde ocurrió el cambio en la distribución.
3. Estás diseñando una plataforma de datos para una startup que actualmente tiene 10 GB de datos pero espera alcanzar 10 TB en 18 meses. ¿Cómo arquitecturas para el crecimiento sin sobreingeniería?
Comienza con un almacén en la nube gestionado (Snowflake, BigQuery) que escala elásticamente. Usa dbt para transformaciones, que escala con el cómputo del almacén. Implementa orquestación con Airflow o Dagster desde el inicio — es más difícil agregarlo después. Diseña modelos dimensionales que soporten expansión futura. Evita optimización prematura como clústeres de Spark hasta que el volumen de datos realmente lo requiera.
4. Dos equipos diferentes necesitan los mismos datos fuente pero con diferentes transformaciones y requisitos de frescura. ¿Cómo evitas duplicar pipelines?
Implementa una arquitectura medallón compartida bronze/silver/gold. Ingesta los datos brutos una vez en una capa bronze, aplica limpieza común en la capa silver y deja que cada equipo construya sus propias transformaciones en la capa gold. Usa un catálogo de datos para documentar los conjuntos de datos disponibles y prevenir que los equipos construyan pipelines de ingesta redundantes.
5. Tu pipeline usa una API que tiene un límite de tasa de 100 solicitudes por minuto, pero necesitas extraer 1 millón de registros diariamente. ¿Cómo diseñas la extracción?
Implementa limitación de tasa con backoff exponencial en el código de extracción. Usa paginación con offsets basados en cursor para extracciones incrementales. Programa la extracción durante horas de baja demanda para maximizar el rendimiento dentro de los límites de tasa. Cachea las respuestas de la API para evitar re-obtener datos sin cambios. Si la API soporta endpoints de exportación masiva, úsalos en lugar de obtención registro por registro.
Preguntas para el entrevistador
Los ingenieros de datos deben evaluar la madurez de la plataforma de datos y la cultura de ingeniería del equipo [1].
- ¿Cómo es su stack de datos actual — almacén, orquestación, transformación y herramientas de observabilidad? — Revela el entorno técnico y el estado de modernización.
- ¿Cómo manejan la calidad de datos hoy, y existe un framework de monitoreo de calidad de datos? — Indica la madurez de la gobernanza de datos.
- ¿Cuál es la proporción de ingenieros de datos respecto a científicos de datos y analistas en el equipo? — Muestra si los ingenieros de datos están integrados con los consumidores o aislados.
- ¿Cómo maneja el equipo las guardias para fallos de pipeline? — Evalúa la carga operativa y las expectativas de equilibrio trabajo-vida.
- ¿Existe un catálogo de datos o herramienta de linaje de datos? — Revela prácticas de descubribilidad y documentación.
- ¿Cuál es el mayor desafío de ingeniería de datos que enfrenta el equipo actualmente? — Proporciona información sobre si el rol se alinea con tus habilidades e intereses.
Formato de entrevista y qué esperar
Las entrevistas para ingenieros de datos típicamente incluyen cuatro a cinco rondas que evalúan tanto la capacidad de codificación como el pensamiento de diseño de sistemas [3].
Screening con reclutador (30 minutos): Discusión sobre experiencia, expectativas salariales y antecedentes técnicos de alto nivel.
Ronda de codificación SQL (60 minutos): Escribe consultas SQL en un entorno compartido — funciones de ventana, CTEs, agregaciones y joins. Espera discusiones de optimización sobre planes de ejecución de consultas.
Ronda de Python / Programación (60 minutos): Implementa lógica de procesamiento de datos — parseo de archivos, transformación de estructuras de datos o construcción de un componente simple de pipeline. Enfoque en código limpio y testeable.
Ronda de diseño de sistemas (60-90 minutos): Diseña un pipeline de datos o plataforma de datos de principio a fin. Temas comunes: diseñar un sistema de analítica en tiempo real, construir un data lake para una empresa multiproducto o arquitectar una plataforma de datos dirigida por eventos.
Ronda conductual (45-60 minutos): Preguntas sobre colaboración, respuesta a incidentes y comunicación con stakeholders no técnicos.
Cómo prepararse
La preparación para entrevistas de ingeniería de datos debe combinar práctica de SQL, estudio de diseño de pipelines y conocimiento específico de herramientas [5].
Domina SQL: Practica funciones de ventana, CTEs, self-joins y optimización de consultas. Usa plataformas como problemas de bases de datos de LeetCode, HackerRank SQL o Stratascratch. Sé capaz de escribir consultas complejas sin un IDE.
Estudia modelado de datos: Comprende esquemas estrella, esquemas copo de nieve, dimensiones que cambian lentamente (Tipo 1, 2, 3) y la arquitectura medallón (bronze/silver/gold). Prepárate para diseñar un modelo dimensional en una pizarra.
Conoce tus herramientas: Prepárate para discutir las herramientas listadas en la descripción del puesto. Para Spark, comprende RDDs vs. DataFrames, particionamiento y operaciones de shuffle. Para Airflow, comprende DAGs, operadores, sensores y XComs. Para dbt, comprende modelos, tests, macros y materializaciones incrementales.
Practica diseño de pipelines: Recorre cinco diseños de pipelines de principio a fin: batch ETL, streaming en tiempo real, replicación basada en CDC, extracción basada en API y migración de data warehouse. Para cada uno, identifica las herramientas, modos de fallo y estrategia de monitoreo.
Prepara historias de calidad de datos: Ten ejemplos específicos de problemas de calidad de datos que descubriste, investigaste y resolviste. Cuantifica el impacto de negocio de detectar (o no detectar) estos problemas.
Repasa conceptos de sistemas distribuidos: Comprende particionamiento, replicación, modelos de consistencia y el teorema CAP tal como se aplican a sistemas de datos. Libros como Designing Data-Intensive Applications de Martin Kleppmann son una preparación invaluable.
Errores comunes en entrevistas
Evita estos errores que frecuentemente descalifican a candidatos de ingeniería de datos [4].
-
Escribir SQL correcto pero no optimizado. Una consulta que produce el resultado correcto pero escanea toda la tabla innecesariamente señala falta de conciencia de producción. Siempre discute indexación, particionamiento y planes de ejecución.
-
Ignorar la calidad de datos en diseños de pipelines. Un pipeline sin validación, monitoreo y alertas está incompleto. Siempre incluye verificaciones de calidad de datos en tus respuestas de diseño de sistemas.
-
Sobreingeniería para una escala que no tienes. Proponer Kafka y Spark para una carga diaria de 10 GB es un error tan grande como usar scripts simples para una carga diaria de 10 TB. Ajusta la arquitectura al volumen de datos real y la trayectoria de crecimiento.
-
No entender el contexto de negocio. Los pipelines de datos sirven a decisiones de negocio. Los candidatos que diseñan soluciones técnicamente sólidas pero irrelevantes para el negocio pierden el punto. Haz preguntas aclaratorias sobre quién consume los datos y qué decisiones impulsan.
-
Tratar batch y streaming como intercambiables. Cada uno tiene compromisos distintos en complejidad, costo y latencia. Sé claro sobre cuándo cada enfoque es apropiado y las implicaciones operativas de elegir uno sobre el otro.
-
Descuidar las preocupaciones operativas. Monitoreo de pipelines, alertas, lógica de reintentos, colas de mensajes no entregados y procedimientos de backfill no son opcionales — son lo que hace que un pipeline esté listo para producción [3].
Conclusiones clave
Las entrevistas para ingenieros de datos evalúan tu capacidad para diseñar, construir y operar sistemas de datos que entreguen datos confiables y oportunos a las personas que los necesitan. Prepárate dominando SQL, comprendiendo las herramientas del stack de datos moderno y practicando diseño de pipelines de principio a fin. Los candidatos que se destacan son aquellos que piensan en calidad de datos, resiliencia operativa e impacto de negocio — no solo en el camino feliz.
¿Quieres asegurarte de que tu currículum destaque las habilidades correctas de ingeniería de datos? Prueba el verificador gratuito de puntuación ATS de ResumeGeni para optimizar tu currículum de ingeniero de datos antes de postular.
Preguntas frecuentes
¿Qué lenguajes de programación debo conocer para una entrevista de ingeniero de datos? SQL es esencial. Python se espera para la mayoría de los roles. Scala es valioso para entornos con uso intensivo de Spark. Java aparece en algunos entornos empresariales [5].
¿Qué tan importante es la experiencia en la nube para entrevistas de ingeniería de datos? Muy importante. La mayoría de los roles modernos de ingeniería de datos requieren experiencia con al menos una plataforma en la nube (AWS, GCP o Azure) y servicios de datos nativos de la nube (Redshift, BigQuery, Snowflake, Databricks) [1].
¿Las entrevistas de ingeniería de datos incluyen codificación en vivo? Sí. Espera al menos una ronda de codificación SQL en vivo y frecuentemente una ronda de codificación Python enfocada en lógica de transformación de datos [3].
¿Cuál es la pregunta de diseño de sistemas más común para ingenieros de datos? Diseñar un pipeline de datos por lotes con procesamiento incremental o diseñar un sistema de streaming de eventos en tiempo real son los dos escenarios más comunes.
¿Cómo me preparo para rondas de diseño de sistemas si solo he trabajado en pipelines existentes? Estudia arquitecturas de código abierto, lee publicaciones de blogs de ingeniería de empresas como Netflix, Uber y Airbnb, y practica explicando decisiones de diseño en voz alta. La habilidad clave es articular compromisos, no memorizar arquitecturas.
¿Debería aprender dbt para entrevistas de ingeniería de datos? Sí — dbt se ha convertido en una herramienta estándar en el stack de datos moderno. Se espera la comprensión de modelos, tests y materializaciones incrementales para la mayoría de los roles de analytics engineering e ingeniería de datos [5].
¿Qué certificaciones ayudan para entrevistas de ingeniería de datos? Las certificaciones en la nube (AWS Data Analytics Specialty, GCP Professional Data Engineer, Azure Data Engineer Associate) demuestran conocimiento específico de plataforma y son valoradas por muchos empleadores.