Preguntas de Entrevista para Ingenieros de Datos: SQL, Pipelines y Confiabilidad bajo Presión

El ciclo de entrevista para este rol se construye alrededor de una preocupación central: ¿puedes mover y transformar datos correctamente a escala sin que alguien tenga que supervisarlo? Eso se manifiesta como cuatro áreas de habilidad conectadas: SQL y modelado de datos, diseño de pipelines en patrones ETL y ELT, confiabilidad ante fallos, y el juicio para comunicar compensaciones a personas que no escriben código.

La mayoría de ciclos mezclan una ronda de SQL práctica, una ronda de diseño de sistemas enfocada en un pipeline o plataforma de datos, y una ronda conductual que explora cómo manejas datos rotos, requisitos faltantes y desacuerdos con científicos de datos o analistas. Algunas empresas también ejecutan un ejercicio para llevar a casa donde construyes un pequeño pipeline a partir de un conjunto de datos en bruto, que prueba las mismas habilidades sin una audiencia en vivo.

Los entrevistadores no solo califican si tu consulta devuelve las filas correctas. Están escuchando cómo narras tu razonamiento: por qué elegiste una función de ventana sobre una auto-unión, por qué elegiste una carga incremental sobre una actualización completa, por qué alertarías sobre la deriva del recuento de filas en lugar de solo contar nulos. Un candidato que murmulla a través de una respuesta correcta a menudo pierde ante uno que explica una respuesta ligeramente más áspera claramente.

Antes de tu entrevista, crea una lista corta de pipelines, tablas o incidentes de tu propio trabajo que puedas describir en dos o tres oraciones cada uno. Los utilizarás constantemente en las rondas de SQL, diseño y conducta.

SQL sigue siendo la puerta más común en entrevistas de ingeniería de datos, incluso en empresas que funcionan principalmente con Spark o dbt. Espera indicaciones como: escribir una consulta que devuelva el pedido más reciente de cada cliente, encontrar brechas en una secuencia de fechas por cuenta, calcular un total rodante de siete días de ingresos diarios, o desduplicar filas sin perder la versión más reciente.

Las funciones de ventana aparecen constantemente. ROW_NUMBER() con una cláusula PARTITION BY es la herramienta estándar para problemas de "registro más reciente por clave"; LAG() y LEAD() manejan preguntas de brecha-isla y detección de cambios; SUM() OVER una ventana ordenada maneja totales rodantes sin una auto-unión. Los entrevistadores también quieren que razones sobre un plan de consulta en voz alta: qué orden de unión podría elegir el optimizador, dónde un índice ayudaría, y cuándo una consulta es lenta debido a un filtro de partición faltante en lugar de una unión mala.

Las preguntas de modelado de datos prueban un músculo diferente: diseño de esquema bajo restricciones conflictivas. Un indicador común es diseñar un esquema de estrella para un conjunto de datos de comercio electrónico o suscripción, con tablas de hechos para pedidos o eventos y tablas de dimensiones para clientes, productos y tiempo. Prepárate para explicar dimensiones que cambian lentamente: cuándo una actualización de Tipo 1 (sobrescribir) está bien versus cuándo necesitas Tipo 2 (nueva fila, fechas efectivas) para preservar el historial para una métrica como "segmento de cliente en el momento de la compra."

También deberías poder justificar compensaciones de normalización. Los sistemas OLTP favorecen tablas normalizadas para proteger la consistencia de escritura; los almacenes analíticos a menudo desnormalizan deliberadamente para que una herramienta de BI pueda consultar una tabla amplia en lugar de cinco uniones. Nombrar esa compensación, en lugar de tratar un estilo como universalmente correcto, es lo que separa una respuesta fuerte de una de libro de texto.

Las preguntas de diseño de pipeline te piden que describas cómo los datos en bruto se convierten en una tabla confiable. Un indicador típico: diseña un pipeline que ingiera eventos de clickstream y produzca una tabla de usuarios activos diarios que el equipo de producto pueda consultar cada mañana. Una respuesta fuerte comienza con la fuente, no con las herramientas: ¿de dónde se originan los datos, con qué frecuencia llegan, cuál es la latencia aceptable, y qué sucede si un lote llega tarde o un stream se cae?

Espera comparar ETL y ELT explícitamente. En ETL, transformas datos antes de cargarlos en el almacén, lo que se adapta a volúmenes más pequeños o necesidades de cumplimiento estricto. En ELT, cargas datos en bruto primero y los transformas dentro del almacén con una herramienta como dbt, que es ahora el patrón más común porque la computación del almacén es barata y mantiene el historial en bruto para reprocesamiento. Sé capaz de explicar por qué elegirías uno u otro para una fuente de datos dada.

Las preguntas de orquestación prueban si piensas en el fallo, no solo en el camino feliz. Los entrevistadores quieren escuchar sobre DAGs en una herramienta como Airflow o Dagster, reintentos a nivel de tarea, rellenos para un esquema que cambió a mitad del historial, y cargas incrementales que solo procesan filas nuevas o cambiadas en lugar de reprocesar una tabla completa cada ejecución. La idempotencia es un seguimiento favorito: si una tarea falla a mitad de camino y se vuelve a ejecutar, ¿produce filas duplicadas o el mismo resultado correcto?

Las preguntas específicas de streaming aparecen más en empresas con requisitos en tiempo real. Se te puede pedir que compares un pipeline de streaming basado en Kafka contra un enfoque de micro-lote, o que expliques exactamente-una vez versus semántica de al-menos-una-vez y qué estrategia de deduplicación usarías aguas abajo cuando un sistema solo garantiza al-menos-una-vez.

Las preguntas de confiabilidad en preguntas de entrevista para ingenieros de datos generalmente comienzan con un escenario: un panel muestra cero ingresos esta mañana, caminame a través de cómo lo depuraría. Una buena respuesta trabaja hacia atrás a través del pipeline en orden en lugar de adivinar al azar. Verifica si el sistema fuente realmente produjo datos, verifica los registros del trabajo de ingesta y los recuentos de filas, verifica la capa de transformación para una ejecución fallida o silenciosamente omitida, y verifica si el panel en sí está apuntando a una tabla en caché o estancada.

Los controles de calidad de datos son un tema frecuente por derecho propio. Los entrevistadores quieren especificidades: controles de tasa nula en campos requeridos, detección de anomalías de recuento de filas contra un plan base histórico, controles de frescura que alerten cuando una tabla no se ha actualizado dentro de su ventana esperada, y controles referenciales que detecten claves foráneas huérfanas después de un cambio de esquema ascendente. Las herramientas como pruebas dbt o Great Expectations a menudo aparecen, pero nombrar una herramienta importa menos que explicar qué verificarías realmente y por qué esa verificación detecta el modo de fallo que te importa.

También deberías esperar preguntas sobre SLAs y SLOs para frescura de datos, y cómo diseñarías alertas para que la persona correcta sea localizadora por un problema real sin abrumar al equipo con ruido de varianza esperada. Habla sobre cómo establecerías umbrales, enrutarías alertas por severidad, y evitarías una alerta que se dispare todos los días e ignorada.

Un hilo conductual relacionado es la retrospectiva: describe un incidente donde datos malos llegaron a un informe o un modelo antes de que alguien lo atrapara. Los entrevistadores están escuchando propiedad y cambio de proceso, no culpa. Una respuesta fuerte nombra la causa raíz, la solución inmediata, y la salvaguardia específica que agregaste después, como una nueva verificación de validación o un cambio en cómo se revisan los rellenos.

Las preguntas conductuales para ingenieros de datos se enfocen menos en heroísmos individuales y más en cómo manejas demandas competitivas de personas que dependen de tus pipelines. Las indicaciones comunes incluyen: cuéntame sobre una vez que una parte interesada necesitaba datos más rápido que tu pipeline podía entregar; cuéntame sobre un desacuerdo con un científico de datos o analista sobre un esquema o una definición de métrica; cuéntame sobre una vez que encontraste un error en datos de producción después de que ya había sido utilizado en un informe.

Usa STAR, pero mantén la sección de acción específica para el trabajo de datos. Para la historia de "datos ya usados en un informe malo", explica cómo descubriste el error, a quién se lo dijiste y qué tan rápido, cómo corregiste los números aguas abajo, y qué validación agregaste para que la misma clase de error no pudiera deslizarse nuevamente. Los entrevistadores quieren ver que tratas incidentes de datos de la manera que un ingeniero de software trata una interrupción de producción, no como una molestia menor.

Para esquema o desacuerdos de métrica, muestra que puedes mantener una posición técnica mientras aún llegas a una decisión que el equipo pueda tolerar. Explica la compensación que estabas defendiendo, como rendimiento de consulta versus costo de almacenamiento, o un esquema más estricto versus incorporación más rápida de una nueva fuente de datos, y cómo la resolviste sin simplemente anular a la otra persona.

Las preguntas de priorización también son comunes: cómo decides entre arreglar un pipeline inestable, construir una nueva fuente de datos que una parte interesada está esperando, y pagar deuda técnica en un modelo antiguo. Una respuesta creíble pesa el impacto empresarial, el radio de explosión si el pipeline inestable falla nuevamente, y cuánto más tiempo el equipo puede tolerar la deuda antes de que ralentice todos los cambios futuros.

Estas preguntas son más fáciles de responder en papel que en voz alta. Explicar una función de ventana, un diseño de pipeline, o una retrospectiva de incidente en oraciones habladas claras es una habilidad diferente de escribir el SQL correcto o dibujar el DAG correcto, y los entrevistadores califican la explicación tanto como la respuesta.

Practica narrar soluciones de SQL antes de tocar un teclado: establece el enfoque, nombra la función de ventana o estrategia de unión que usarás, luego escribe la consulta. Para indicaciones de diseño de pipeline, practica hablar a través de fuente, requisitos de latencia, lógica de transformación, y manejo de fallos en ese orden cada vez, para que la estructura se vuelva automática bajo presión. Para historias conductuales, ensaya hasta que el detalle técnico se mantenga específico sin convertirse en un monólogo.

Grábate respondiendo a algunas de estas preguntas y escucha de nuevo para palabras de relleno, configuración que se ramifica antes de llegar al punto, o pasos omitidos en un recorrido de pipeline. SayNow AI puede ayudarte a ensayar preguntas de entrevista para ingenieros de datos en voz alta, con retroalimentación sobre claridad y ritmo para que tu razonamiento técnico se comunique con tanta confianza como se lee en la página.