Preguntas de entrevista para Data Engineer: respuestas que funcionan

Llegas a la fase técnica de una entrevista para Data Engineer y te preguntas qué tipo de preguntas te van a hacer. No es solo saber teoría. El entrevistador quiere ver si sabes diseñar, si entiendes los fallos comunes y si puedes explicar tus decisiones.

Aquí tienes una lista realista de preguntas agrupadas por fase, con ejemplos de respuestas y lo que realmente evalúa cada una.

La primera pantalla: el filtro rápido#

Estas preguntas suelen venir de un recruiter o en los primeros minutos de la llamada técnica. No buscan un diseño perfecto. Quieren saber si tienes la base para no perder el tiempo en la siguiente ronda.

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

Qué evalúa: Si entiendes los flujos de datos modernos y no solo repites siglas.

Respuesta modelo: "ETL transforma los datos antes de cargarlos en el destino, típicamente en un data warehouse. ELT carga los datos en bruto y luego los transforma dentro del propio destino, usando su poder de cómputo. Hoy en día ELT es más común con herramientas como Snowflake o BigQuery porque son muy buenos procesando datos en bruto."

2. Explica qué es un data lake y cómo se diferencia de un data warehouse.

Qué evalúa: Conceptos básicos de arquitectura de datos.

Respuesta modelo: "Un data warehouse guarda datos estructurados y limpios, optimizados para consultas SQL rápidas. Un data lake guarda datos en su formato original, estructurados o no, a bajo costo. La diferencia clave es que el warehouse es para análisis inmediato y el lake es para almacenamiento flexible, a menudo como zona de staging o para machine learning."

Preguntas técnicas: el diseño y la lógica#

Aquí es donde se pone serio. No esperan que recites la documentación. Quieren ver tu proceso de pensamiento para resolver problemas de datos del mundo real.

3. Diseña un pipeline para procesar logs de una aplicación web en tiempo casi real.

Qué evalúa: Tu conocimiento del ecosistema y tu capacidad para elegir herramientas adecuadas.

Cómo responder: Empieza por el origen. "Los logs se escriben en archivos o se envían a un sistema de mensajería como Kafka. Para procesarlos en tiempo casi real, usaría Kafka Connect para ingestarlos en un topic. Luego, un consumidor con Apache Flink o Spark Streaming leería del topic, parsearía el JSON, aplicaría transformaciones básicas como filtrar errores o extraer campos, y escribiría el resultado limpio en una tabla en Snowflake o un bucket en S3 en formato Parquet."

Error común: Saltar directamente a nombrar herramientas sin definir el flujo. Primero el flujo, luego las herramientas.

4. ¿Cómo manejarías una tabla de hechos que crece muy rápido y las consultas se vuelven lentas?

Qué evalúa: Estrategias de rendimiento y conocimiento de bases de datos.

Cómo responder: "Primero, revisaría las consultas más lentas para ver si falta un índice en las columnas del WHERE o JOIN. Segundo, implementaría un particionado de la tabla por fecha, por ejemplo, por mes o por día, para que el escáner solo lea los datos relevantes. Tercero, consideraría agregar una capa de agregados precalculados para los reportes más comunes, o usar un sistema analítico como BigQuery que escala cómputo de forma independiente."

5. ¿Qué es la partición de datos y cuándo la usarías?

Qué evalúa: Conceptos fundamentales de almacenamiento y rendimiento.

Respuesta modelo: "La partición divide una tabla grande en segmentos más pequeños basados en el valor de una columna, como la fecha. La usaría cuando una tabla tiene miles de millones de filas y las consultas siempre filtran por esa columna. Así, el motor solo lee el segmento necesario, lo que ahorra costos y acelera las consultas."

6. Describe un error de datos (data quality issue) que hayas encontrado y cómo lo solucionaste.

Qué evalúa: Experiencia práctica y resolución de problemas reales.

Respuesta modelo: "Encontré que una fuente de datos enviaba duplicados porque un job upstream se ejecutaba dos veces. Implementé una lógica de deduplicación usando ROW_NUMBER() en la carga incremental, particionando por la clave de negocio y ordenando por timestamp descendente. También configuré una alerta para detectar picos inesperados en el volumen de esa fuente."

Preguntas de comportamiento: cómo trabajas en equipo#

La parte blanda no es un trámite. Aquí buscan señales de si eres alguien con quien quieren trabajar cada día.

7. Cuéntame de una vez que tuviste que explicar un problema técnico complejo a un stakeholder no técnico.

Qué evalúa: Comunicación y empatía.

Cómo responder: Usa el método STAR (Situación, Tarea, Acción, Resultado). "Un dashboard tardaba 30 segundos en cargar. El equipo de producto pensaba que era un problema de la interfaz. Les expliqué con una analogía: es como pedir un libro en una biblioteca desordenada. Primero hay que ordenar los estantes (índices y particiones). Les mostré un gráfico simple del antes y después. Entendieron la prioridad y nos dieron tiempo para la optimización."

8. ¿Cómo priorizas tu trabajo cuando tienes múltiples pipelines rotos?

Qué evalúa: Gestión de crisis y pensamiento crítico.

Respuesta modelo: "Primero, evalúo el impacto de negocio. ¿Cuántos usuarios o reportes se ven afectados? Una pipeline de facturación va primero. Segundo, miro la gravedad. ¿Están llegando datos corruptos o no llega nada? Tercero, comunico el plan al equipo y a los stakeholders afectados, con un tiempo estimado si es posible."

9. Describe un proyecto donde la documentación era pobre o inexistente.

Qué evalúa: Iniciativa y autonomía.

Respuesta modelo: "Heredé un pipeline sin documentación. Empecé a mapear el flujo de datos dibujándolo en una pizarra virtual. Cada vez que entendía un paso, lo anotaba. Pregunté a los desarrolladores originales las dudas específicas. Al final, no solo tenía el pipeline documentado, sino que encontré dos transformaciones redundantes que eliminamos."

10. ¿Qué haces cuando no estás de acuerdo con el diseño técnico propuesto por un compañero?

Qué evalúa: Colaboración y humildad.

Respuesta modelo: "Pido que me explique su razonamiento completo. A veces, al escucharlo, entiendo algo que no había considerado. Si sigo en desacuerdo, propongo hacer una prueba de concepto rápida con ambos enfoques en un entorno de staging y que los datos nos den la razón. Lo importante es llegar a la mejor solución, no tener razón."

Preguntas avanzadas: arquitectura y trade-offs#

Para roles senior, esperan que pienses en sistemas completos.

11. ¿Cómo diseñarías un sistema de monitoreo para tus pipelines de datos?

Qué evalúa: Visión de largo plazo y operaciones.

Respuesta modelo: "Implementaría tres niveles de monitoreo. Primero, métricas de infraestructura: uso de CPU, memoria, espacio en disco. Segundo, métricas del pipeline: tiempo de ejecución, volumen de filas procesadas, tasa de error. Tercero, métricas de calidad de datos: nulos inesperados, distribución de valores, duplicados. Usaría herramientas como Datadog o Grafana para los dashboards y alertas automáticas cuando un umbral se rompe."

12. ¿Qué harías si un pipeline crítico falla a las 3 de la mañana?

Qué evalúa: Resiliencia y operaciones.

Respuesta modelo: "Primero, el sistema debería tener alertas automáticas y, si es posible, reintentos configurados. Si la alerta me llega, reviso los logs rápidamente para clasificar el error. Si es un problema transitorio de red, el reintento automático debería resolverlo. Si es un error de datos, necesito intervenir: corregir el dato fuente o parchear el código. Luego, al día siguiente, hago un post-mortem para añadir mejoras y que no vuelva a pasar."

---

Checklist de preparación antes de la entrevista#

• Investiga la empresa: qué stack usan, qué problemas de datos probablemente tengan.
• Repasa SQL a fondo: window functions, CTEs, optimización de queries.
• Practica en voz alta explicando tus proyectos pasados usando el método STAR.
• Prepara preguntas para ellos: qué herramientas usan, cómo manejan la calidad de datos, cómo es un día típico.
• Revisa los conceptos clave: diferencias entre OLTP y OLAP, cuándo usar Spark vs. Flink, modelos de datos dimensionales.
• Usa herramientas como el decodificador de ofertas de empleo para entender qué pide realmente la vacante.
• Haz una prueba de tu currículum con el verificador de compatibilidad con sistemas de seguimiento de candidatos para pasar el primer filtro.

Si quieres ver qué perfiles están buscando ahora mismo, puedes explorar ofertas de empleo actualizadas. Y si necesitas repasar conceptos, nuestro blog tiene guías prácticas sobre arquitectura de datos.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuánto dura típicamente una entrevista técnica para Data Engineer?

Depende de la empresa. Una pantalla técnica inicial suele ser de 45 a 60 minutos. Una entrevista técnica profunda puede durar de 90 minutos a 2 horas, a veces con un ejercicio práctico en casa.

¿Es mejor usar Python o SQL para resolver los ejercicios de diseño?

SQL es esencial y se espera que lo domines. Python es necesario para transformaciones más complejas o cuando el ejercicio implica streaming. Pregunta al entrevistador qué prefiere si no está claro.

¿Debo memorizar la sintaxis exacta de cada herramienta?

No. Lo importante es saber qué herramienta usar para cada problema y por qué. La sintaxis específica se busca en la documentación. En la entrevista, explica tu razonamiento.

¿Qué pasa si no sé la respuesta a una pregunta técnica?

No inventes. Di que no lo sabes, pero explica cómo lo averiguarías o qué enfoque probarías. Los entrevistadores valoran la honestidad y el pensamiento estructurado.

¿Las preguntas de comportamiento son tan importantes como las técnicas?

Sí. Muchas veces el "culture fit" decide entre dos candidatos técnicamente similares. Prepara ejemplos concretos de tus experiencias pasadas, tanto éxitos como fracasos de los que aprendiste.