Qué evalúan realmente las entrevistas para ingeniero de datos

Quién está realmente en la sala

Para un puesto de ingeniero de datos, rara vez te evalúa un reclutador generalista después de la primera llamada. Las rondas técnicas suelen estar a cargo de un ingeniero de datos senior o el líder de ingeniería de datos, a veces con un ingeniero de analytics o un científico de datos presente si los pipelines que construirías alimentan sus modelos. Esto importa porque las preguntas vienen de personas a las que han despertado a las 3am por un DAG roto, no de una rúbrica escrita por RRHH. Escuchan si realmente has operado un pipeline en producción, no si puedes definir ETL.

Las empresas más pequeñas suelen concentrar todo en dos rondas: una sesión técnica en vivo y una conversación con quien sea dueño de la plataforma de datos. Las más grandes lo dividen en un filtro de SQL/Python, una ronda de diseño de sistema o pipeline, y una ronda de valores o manejo de stakeholders con alguien del equipo al que alimentarías datos — a menudo un analista o un product manager, y es la ronda para la que los candidatos menos se preparan porque parece charla informal y no lo es.

El filtro de SQL y Python

Rara vez es trivia. Te dan un esquema — a menudo algo como pedidos, clientes, eventos — y te piden escribir una consulta usando funciones de ventana: totales acumulados, rango dentro de partición, un self-join para encontrar huecos o solapamientos en rangos de fechas. El punto no es la sintaxis, es si recurres a la herramienta correcta sin que te guíen hacia ella. Un candidato que resuelve "encuentra la primera y segunda compra de cada cliente" con una subconsulta correlacionada cuando un LAG() lo haría limpiamente está diciéndole algo al entrevistador sobre cómo escribirá SQL en producción bajo presión de tiempo.

En el lado de Python, espera manipulación de datos con pandas o Python puro — deduplicar un dataset desordenado, parsear JSON malformado, manejar nulos que significan cosas diferentes en distintas columnas. Cada vez más te pedirán razonar sobre un job de Spark: por qué una transformación es lenta, dónde está ocurriendo un shuffle, si reparticionar antes de un join ayudaría. Si solo has ejecutado Spark a través de una plataforma gestionada como Databricks y nunca has tenido que explicar por qué un job se derramó a disco, aquí se nota.

Cómo suena aquí una respuesta superficial: recitar que los índices "aceleran las consultas" sin poder decir qué pasa con el rendimiento de escritura, o explicar correctamente la sintaxis de una función de ventana pero ser incapaz de decir cuándo usarías ROW_NUMBER() sobre RANK() y qué se rompe si te equivocas en una tabla con claves duplicadas.

La ronda de diseño de pipeline o sistema

Esta es la ronda que separa a quienes han configurado una herramienta de quienes han sido dueños de un sistema. Típicamente te pedirán diseñar algo como: ingerir eventos de una aplicación a un warehouse, mantener una tabla de dimensión sincronizada con una fuente upstream que cambia, o construir un pipeline que tenga que hacer backfill de tres años de historia sin duplicar la factura de cómputo.

El entrevistador escucha un conjunto pequeño de cosas, y surgen en casi todas las versiones de esta pregunta:

• Idempotencia. ¿Tu pipeline puede re-ejecutarse sobre los mismos datos sin producir duplicados o totales contados doble? Si tu respuesta no menciona cómo manejarías un job que falla a mitad de camino y se reintenta, esa es una laguna que explorarán.
• Evolución de esquema. ¿Qué pasa cuando un sistema fuente agrega una columna, o cambia un tipo de int a string? ¿Fallas ruidosamente, o corrompes silenciosamente las tablas downstream? Mencionar un schema registry, o cómo las pruebas de dbt o Great Expectations atraparían esto, señala que ya te quemaste con esto antes.
• Batch versus streaming, y por qué. No "streaming es mejor" — esa es la respuesta superficial. La respuesta real explica el trade-off: Kafka o Kinesis te da baja latencia y complejidad que ahora posees, versus un batch job programado en Airflow o Dagster que es más simple de razonar y depurar pero significa datos obsoletos durante lo que dure la ejecución programada.
• Particionamiento y costo. Si diseñas una tabla sin decir cómo la particionarías — por fecha, usualmente, en un warehouse como BigQuery o Snowflake — y sin reconocer que un full table scan en una tabla de hechos de varios terabytes cuesta dinero real, el entrevistador nota la omisión aunque no lo diga.
• Slowly changing dimensions. Si el escenario involucra una dimensión que cambia con el tiempo (la dirección de un cliente, la categoría de un producto), ¿la sobrescribes, o la versionas con algo como SCD Type 2? Equivocarte en esto no te reprueba directamente, pero no conocer el término cuando el entrevistador dice "cómo manejarías que un cliente cambie de región" es revelador.

Una respuesta superficial a una pregunta de diseño suena fluida sobre herramientas y silenciosa sobre fallos. "Usaría Airflow para orquestarlo y depositarlo en Snowflake" es una oración sin ingeniería — nombra el proveedor y omite la decisión. Una respuesta sólida dice por qué: por qué este orquestador maneja backfills de la forma que necesitas, por qué las clustering keys de este warehouse importan para el patrón de consulta que los analistas realmente ejecutan.

Las preguntas que suenan como charla informal

"Cuéntame de una vez que un pipeline que construiste se rompió en producción" no es un rompehielos. Usualmente es la pregunta más diagnóstica de todo el proceso, porque una respuesta superficial te da el síntoma ("el dashboard mostraba números incorrectos") y una respuesta real te da el mecanismo: qué monitoreo o falta de él significó que te enteraste por un stakeholder en lugar de una alerta, cuál resultó ser la causa raíz — un archivo que llegó tarde, un bug de timezone, un cambio de esquema upstream del que nadie te avisó — y qué cambiaste después para que no pudiera pasar de la misma forma dos veces.

De manera similar, "cómo decides qué testear en un pipeline" se pregunta para ver si escribes verificaciones de calidad de datos como hábito — conteos de filas, umbrales de nulos, integridad referencial entre un fact y sus dimensiones — o si el testing es algo que haces después de un incidente porque alguien te lo dijo. Mencionar una práctica específica, como afirmar que una foreign key en una tabla de hechos siempre resuelve a una fila en la dimensión, cae mejor que decir "escribo tests para mis pipelines", que podría describir cualquier trabajo con la palabra pipeline en él.

"Cómo le explicarías a un stakeholder por qué su reporte tiene un día de retraso" está probando algo diferente nuevamente: si puedes traducir una causa técnica — un rate limit de API fuente, una dependencia downstream que no terminó — a lenguaje con el que un no-ingeniero puede actuar, sin simplificarlo hasta la nada ni ahogarlos en terminología de DAG que no tienen.

Qué delata a alguien que no ha hecho el trabajo

Los entrevistadores en este campo notan un patrón específico: fluidez con nombres de herramientas y ninguna opinión sobre sus límites. Alguien que realmente ha ejecutado dbt en producción puede decirte dónde su framework de testing se queda corto y qué agregan encima. Alguien que realmente ha operado Airflow puede decirte qué se rompe cuando un DAG tiene demasiadas tareas dinámicas, o por qué movieron una transformación pesada fuera de un PythonOperator y al warehouse mismo. Si cada respuesta nombra una herramienta y se detiene ahí, esa es la respuesta superficial, y la gente que contrata ingenieros de datos ha escuchado cientos de ellas.

El otro indicador es hablar de volumen de datos sin hablar de costo o patrón de consulta. "Teníamos miles de millones de filas" no es, por sí solo, un hecho de ingeniería. ¿Qué significó eso para cómo se particionó, clusterizó o compactó la tabla, y qué hubiera pasado con la factura del warehouse si te hubieras equivocado? Un entrevistador que ha sido dueño de un dashboard de costos de Snowflake o BigQuery hará una pregunta de seguimiento y descubrirá rápido si los miles de millones de filas fueron algo con lo que lidiaste o algo que mencionaste.

Qué hacer a continuación

Antes de tu próxima entrevista, elige dos pipelines que realmente hayas construido y prepárate para describir, en términos específicos: cómo los re-ejecutarías de forma segura después de un fallo parcial, qué pasaría si el esquema fuente cambiara debajo tuyo, y un incidente donde se rompió y qué cambiaste después. Practica decir el trade-off, no solo la herramienta — batch versus streaming, desnormalizado versus normalizado, orquestador A versus orquestador B — porque esa es la forma de oración que el entrevistador está escuchando.

Si el problema más difícil ahora es llegar a esa entrevista en primer lugar — anuncios que piden experiencia específica en warehouse u orquestación que tienes en otra forma, y aplicaciones que quedan en silencio — jobmarket.pro lee el anuncio completo, lo empareja con tu experiencia real, y prepara la aplicación desde eso en lugar de una plantilla genérica.