Las entrevistas de ingeniería de datos no son entrevistas de analítica con algo de Python encima. El panel está calculando si se te puede confiar el pipeline que alimenta todos los dashboards, modelos e informes financieros de la empresa, y si te darías cuenta de que está produciendo números equivocados en silencio. Por eso las preguntas se agrupan en torno al diseño, la corrección y las operaciones, y no a los algoritmos ingeniosos. Estas son las que salen de verdad, qué mide cada una y cómo se construye una buena respuesta.
Estos son los patrones del puesto en general; si quieres la lista corta para una entrevista concreta, pega la oferta de empleo real en el Question Predictor gratuito y obtén las veinte preguntas con más probabilidad de salir en ese proceso concreto.
¿Qué evalúan de verdad las entrevistas de ingeniero de datos?
Cuatro cosas: si sabes diseñar un pipeline que sobreviva al contacto con datos sucios de origen, si tu SQL va más allá de un join y un GROUP BY, si modelas los datos de forma que los analistas no tengan que adivinar tus intenciones, y si tratas la corrección como un problema de ingeniería y no como un deseo. Conocer herramientas importa mucho menos que el criterio.
Los pesos cambian según la empresa: los equipos de producto centrados en el warehouse se apoyan en el modelado y en SQL, los equipos de plataforma en el rendimiento y el costo, y las startups quieren saber si puedes montar todo tú solo y mantenerlo barato. La generación de código ha vuelto trivial escribir una transformación, así que los paneles dedican ahora su tiempo a las decisiones que un generador no puede tomar: por qué esta granularidad, por qué esta clave de partición, qué pasa en un replay.
¿Cómo es el proceso de entrevista para ingeniero de datos?
Un proceso típico tiene entre cuatro y seis etapas repartidas en dos o tres semanas: un filtro con el reclutador, una prueba de SQL, una ronda de diseño de pipelines, una ronda de modelado y una conversación conductual. Los procesos senior añaden una ronda de sistemas más profunda sobre rendimiento, costo y fallos. Las pruebas para casa son menos comunes que antes, pero siguen apareciendo en empresas pequeñas.
- Filtro con el reclutador (20 a 30 minutos). Stack, escala, banda salarial. Describe tu pipeline más grande en dos frases: volumen, latencia, quién lo consume.
- Prueba de SQL (45 a 60 minutos). SQL en vivo sobre un editor compartido, con las window functions como filtro habitual.
- Ronda de diseño de pipelines (60 minutos). Te dan un origen, un consumidor y una expectativa de frescura, y tú diseñas el camino entre ellos y lo defiendes.
- Ronda de modelado de datos (45 a 60 minutos). Diseño de esquema para un negocio descrito, normalmente con una trampa sobre el histórico o los datos que llegan tarde.
- Responsable de contratación o ronda conductual. Responsabilidad y stakeholders. Las preguntas sobre guardias (on-call) suelen caer aquí también.
Si ya sabes con qué empresa vas, los bancos de preguntas por empresa dan una lectura más rápida del estilo de la casa que rastrear foros.
¿Qué preguntas de diseño de pipelines salen en una entrevista de ingeniero de datos?
Las preguntas de diseño te dan un origen, un destino y una restricción, y luego observan cómo razonas. El panel quiere que preguntes por el volumen, la frescura, la estabilidad del esquema y quién grita cuando se rompe antes de dibujar una sola caja. Los buenos candidatos dimensionan el problema en voz alta y después diseñan lo más simple que cumple el requisito y se puede volver a ejecutar sin riesgo.
Explícame un pipeline que hayas construido, de principio a fin. Qué mide: si has operado algo de verdad o solo has aportado una tarea al DAG de otra persona. Da la forma en orden (origen, ingesta, almacenamiento, transformación, servicio) y luego los números: filas al día, latencia, costo, quién dependía de él. Termina con lo que salió mal alguna vez y qué cambiaste, porque los detalles concretos aquí te compran credibilidad para el resto del proceso.
Diseña un pipeline que ingiera unos 500GB de eventos de clickstream al día y los deje listos para los analistas a las 9am. Qué mide: dimensionamiento, particionado y la distancia entre la llegada y la disponibilidad. Aclara primero el requisito de frescura, porque diario a las 9am es un problema de batch y no de streaming. Aterriza los eventos crudos en almacenamiento de objetos particionado por fecha y hora, transfórmalos en una tabla modelada y mantén la capa cruda inmutable para poder hacer replay. Menciona el tamaño de los ficheros; miles de ficheros diminutos son la herida autoinfligida clásica.
¿Cómo manejas los eventos que llegan tarde o desordenados? Qué mide: si entiendes que los datos no llegan con buenos modales. Separa el tiempo de evento del tiempo de ingesta, define una ventana de retraso que estés dispuesto a aceptar y reprocesa las particiones afectadas en vez de parchear filas sueltas.
Batch o streaming: ¿cómo responder a la pregunta de arquitectura?
Responde desde los requisitos, no desde tus preferencias. El streaming se gana su costo cuando algo actúa sobre los datos en cuestión de segundos: control de fraude, inventario en vivo, alertas. El batch es lo correcto para casi todo lo que alimenta un dashboard o un informe mensual. La trampa aquí es el entusiasmo, porque un candidato que echa mano de un stack de streaming para mover un informe diario está optimizando por lo que le parece interesante y no por el negocio.
¿Cuándo elegirías streaming en vez de batch, y qué te cuesta? Qué mide: criterio sobre la carga operativa. Nombra los costos con honestidad: pruebas más difíciles, backfills más difíciles, estado que gestionar, más superficie de guardia (on-call), un equipo que ahora tiene que entender los watermarks. Luego da la condición que lo justifica todo, que es un consumidor actuando sobre los datos más rápido de lo que tu cadencia de batch puede entregar.
¿Cuál es la diferencia entre el tiempo de evento y el tiempo de procesamiento? Qué mide: fundamentos de streaming. El tiempo de evento es cuando pasó la cosa; el tiempo de procesamiento es cuando tu sistema la vio. Los agregados con ventanas sobre el tiempo de procesamiento se desvían y acaban discrepando en silencio de la fuente de la verdad.
¿Cómo conseguirías semántica exactly-once en un pipeline de streaming? Qué mide: si repites marketing o explicas la mecánica. De extremo a extremo, construyes entrega at-least-once más escrituras idempotentes, usando una clave determinista para que un replay sobrescriba en lugar de duplicar. Los sinks transaccionales y los offsets confirmados junto con la escritura son lo que lo hace real.
¿Qué preguntas de modelado de datos deberías esperar?
Las rondas de modelado comprueban si diseñas para las preguntas que hará el negocio en vez de para los datos que casualmente tienes. Espera un negocio descrito, una petición de esquema y luego una complicación: histórico, jerarquía o un atributo que cambia. El modelado dimensional sigue siendo el idioma común, incluso en equipos que llaman a sus capas algo más moderno.
Explica el esquema en estrella frente a una única tabla ancha desnormalizada. ¿Cuál construirías? Qué mide: razonar sobre granularidad y cambio. Cubre la simplicidad de consulta y el costo de almacenamiento por un lado, y el costo de los joins y los atributos duplicados por el otro, y luego elige según el motor y los consumidores. Los warehouses columnares han abaratado las tablas anchas, pero la estrella sigue ganando cuando las dimensiones cambian de forma independiente.
¿Cómo modelas una dimensión de cambio lento (slowly changing dimension)? Qué mide: el histórico. El tipo 1 sobrescribe y pierde el pasado; el tipo 2 añade una fila por versión con fechas de validez y una marca de fila actual, que es lo que la mayoría de los equipos de analítica necesita para reportar a una fecha concreta.
¿Cómo particionarías una tabla grande y qué puede salir mal? Qué mide: diseño físico. Particiona por la columna por la que filtran los consumidores, normalmente una fecha, vigila el tamaño de las particiones y mantén el particionado separado del clustering o de las sort keys. El fallo clásico es particionar por algo de alta cardinalidad como el ID de usuario, generando millones de ficheros diminutos y consultas más lentas que si no particionaras nada.
¿Hasta dónde llega la ronda de SQL para ingenieros de datos?
Más lejos que en las rondas de analista. Los joins y las agregaciones se dan por supuestos; el filtro son las window functions, la deduplicación y razonar sobre un plan de consulta. La mayoría de las pruebas llevan tres o cuatro preguntas cada vez más desagradables, y la última suele necesitar una window function o un self-join. Habla del enfoque antes de teclear, porque el razonamiento puntúa más que la sintaxis.
Encuentra el segundo valor más alto por grupo, por ejemplo la segunda persona mejor pagada de cada departamento. Qué mide: soltura con las window functions. Echa mano de DENSE_RANK o ROW_NUMBER en una subconsulta y filtra por el ranking fuera, y luego di cuál elegiste y por qué, porque los empates se comportan distinto.
Deduplica una tabla para que solo sobreviva la fila más reciente por clave. Qué mide: la tarea real más habitual del puesto. ROW_NUMBER particionado por la clave, ordenado por timestamp descendente, filtrado a 1. Después pregunta qué rompe el empate cuando dos filas comparten timestamp, porque en datos reales lo van a compartir.
Una consulta sobre una tabla particionada se ha vuelto lenta. ¿Cómo la diagnosticas? Qué mide: depuración guiada por evidencias. Lee el plan, comprueba si de verdad hubo poda de particiones (una función envolviendo la columna de partición suele cargársela), busca skew, revisa si las estadísticas están obsoletas y mira si el layout de ficheros ha degenerado en muchos ficheros pequeños.
¿Qué preguntas de orquestación hacen los entrevistadores?
Las preguntas de orquestación comprueban si tus pipelines se pueden volver a ejecutar sin miedo. La palabra que hay que tener lista es idempotencia: ejecutar la misma tarea para la misma fecha lógica dos veces debería dar el mismo resultado, no el doble. Espera preguntas de seguimiento sobre dependencias, reintentos, alertas y cómo rellenar un año de histórico sin fundir el clúster ni el presupuesto.
¿Cómo haces que un job programado sea idempotente y admita backfill sin riesgo? Qué mide: madurez operativa. Parametriza cada tarea por una fecha lógica en vez de por "ahora", escribe en una partición con esa fecha como clave y reemplaza esa partición al reejecutar en lugar de añadir filas.
¿Cómo gestionas las dependencias entre pipelines de equipos distintos? Qué mide: si has trabajado en una organización real. Prefiere una señal explícita (un dataset marcado como completo, un evento, un sensor con timeout) antes que un desfase de horario esperanzado.
¿Cómo evalúan los entrevistadores la calidad de datos?
Describen un número equivocado y observan cómo investigas. La señal que buscan es que trates la corrección como algo comprobable: recuentos de filas, tasas de nulos, unicidad en las claves, integridad referencial, comprobaciones de distribución contra las de ayer, frescura. Los candidatos que dicen que mirarían el dashboard a ojo pierden la ronda; los que describen aserciones dentro del pipeline capaces de bloquear una publicación mala la ganan.
¿Cómo sabes que un pipeline ha producido datos correctos? Qué mide: si la calidad está diseñada desde dentro o comprobada a posteriori. Mete los tests en el propio pipeline: claves únicas, restricciones de no nulo, rangos aceptados, variaciones del recuento de filas frente a la ejecución anterior.
Un stakeholder dice que la cifra de ingresos de ayer está mal. Explícame la investigación. Qué mide: depuración estructurada más comunicación. Define qué significa mal (contra qué fuente, en cuánto se desvía) y luego sube aguas arriba capa por capa, comparando recuentos y totales en cada frontera para aislar dónde diverge el número.
Una fuente aguas arriba cambia el tipo de una columna sin avisar. ¿Cómo lo manejas? Qué mide: lidiar con cosas fuera de tu control. Falla rápido en la ingesta con una comprobación de esquema en vez de convertir el dato en silencio, pon en cuarentena el lote malo y luego arregla hacia delante con un replay.
¿Qué preguntas conductuales les hacen a los ingenieros de datos?
Las rondas conductuales para puestos de datos giran en torno a la confianza y a los stakeholders. Espera una pregunta sobre un incidente en el que tus datos estaban mal, y otra sobre una petición que rechazaste. Responde con una estructura apretada: la situación, qué decidiste, el compromiso que aceptaste y el cambio duradero que vino después.
Háblame de una vez en la que tus datos estaban mal y se dio cuenta antes otra persona. Qué mide: responsabilidad y honestidad. No lo minimices. Di qué se rompió, cuánto tiempo estuvo mal, quién actuó sobre esos datos, cómo lo comunicaste y qué comprobación añadiste para que no pueda repetirse en silencio.
Háblame de una petición que rechazaste o que negociaste a la baja. Qué mide: si sabes proteger una plataforma de cien peticiones puntuales. Demuestra que entendiste la necesidad de fondo, que ofreciste un camino más barato para cubrirla y que hiciste visible el costo de la petición original, en vez de decir que no y convertirte en el equipo al que todo el mundo esquiva.
¿Qué errores hunden a los candidatos a ingeniero de datos?
Sobre todo fallos de criterio, no huecos de conocimiento. Los paneles rara vez rechazan a alguien por no conocer una herramienta concreta; rechazan a quien diseña antes de preguntar, a quien no puede reejecutar su propio pipeline o a quien trata un número equivocado como problema de otro. Estos son los patrones que terminan rondas.
- Diseñar antes de preguntar. El volumen, la frescura, la estabilidad del esquema y los consumidores se establecen antes de dibujar nada. Empezar por el nombre de una herramienta pierde la ronda de diseño.
- Nombrar herramientas en lugar de mecánica. Decir que usarías un motor concreto no explica nada. Di qué hace el job, cómo particiona, dónde ocurre el shuffle, cuánto cuesta.
- Ignorar el replay y el backfill. Un diseño que no se puede reejecutar sin riesgo para una fecha pasada no es un diseño de producción, y los entrevistadores senior lo comprueban a propósito.
- Tratar la calidad como el trabajo de otro. Si tu respuesta ante un número equivocado es que el analista debería haberlo pillado, la ronda se acabó.
- SQL que se queda en los joins. Las window functions son el filtro estándar ahora, y no dominarlas se lee como falta de profundidad por muy buenas que fueran tus respuestas de arquitectura.
¿Cómo deberías prepararte para una entrevista de ingeniero de datos?
Ensaya un pipeline que domines a fondo, con números reales pegados a él, porque va a anclar la mitad del proceso. Machaca las window functions y la deduplicación hasta que sean memoria muscular. Practica un diseño en voz alta contra el reloj, ya que el formato castiga a quien sabe pensarlo pero no narrarlo. Prepara dos historias de incidentes y una de stakeholders.
Antes del proceso en sí, pega la oferta de empleo real en el Question Predictor gratuito y repasa las veinte preguntas que marque para ese puesto concreto, porque un equipo de plataforma lakehouse y un equipo de analytics engineering te van a preguntar cosas muy distintas.
Para las rondas en vivo, GhostPilot es un copiloto de entrevistas en tiempo real: un panel lateral de extensión de Chrome y una app de escritorio opcional para Windows que transcriben la llamada, cazan la pregunta en cuanto aterriza y tienen una respuesta estructurada lista unos dos segundos después. Donde más ayuda es en las preguntas con trampa, como un enunciado de diseño que en realidad busca una estrategia de replay. Es un prompt, no un guion, y los detalles concretos siguen saliendo de tu propio trabajo. El plan gratuito te da 10 minutos de entrevista en vivo a la semana, sin tarjeta.
FAQ de la entrevista para ingeniero de datos
¿Cuánto tiempo debería prepararme para una entrevista de ingeniero de datos? Dos o tres semanas le bastan a la mayoría de candidatos de nivel medio: una semana de SQL y modelado, una semana practicando diseño en voz alta, unos días con las historias. Quien viene de analista y se pasa a ingeniería debería contar con más tiempo, sobre todo en diseño de pipelines.
¿Las entrevistas de ingeniero de datos siguen incluyendo preguntas de algoritmos? Algunas empresas grandes mantienen una ronda de algoritmos, normalmente de nivel fácil o medio. La mayoría de los equipos la han sustituido por SQL y un ejercicio práctico de Python de parseo o transformación. No dejes que machacar algoritmos te quite tiempo de modelado.
¿Qué ronda pesa más? El diseño de pipelines, para candidatos de nivel medio y senior, porque mide criterio, comunicación y profundidad a la vez. Para puestos junior, la prueba de SQL es la verdadera puerta, y ahí es donde ocurren la mayoría de los rechazos.
¿Debería admitir que no he usado una herramienta que mencionan? Sí. "Eso no lo he tenido en producción, pero así es como lo razonaría y esto es lo que comprobaría primero" gana a farolear, y los entrevistadores de datos son especialmente buenos detectando humo porque se pasan el día encontrando cosas mal.