"Data engineer" se convirtió en uno de los títulos más buscados de los últimos cinco años. LinkedIn está lleno de posteos, los bootcamps lo venden como el próximo paso natural, y cada empresa mediana parece tener un "data team", aunque nadie esté muy seguro de qué hace. Todo eso creó una confusión genuina sobre qué significa la carrera en la práctica.
Si sos un ingeniero de software senior evaluando hacer un pivot, o si ya estás en data engineering y querés entender mejor dónde estás parado, vale la pena separar la señal del ruido.
Qué hace realmente un ingeniero de datos (más allá del job description)
El job description típico de data engineer incluye tareas como “construir pipelines de datos", “mantener la infraestructura de datos" y “colaborar con data scientists”. Todo cierto, pero no dice mucho sobre qué problemas concretos resolvés en el día a día.
En la práctica, el trabajo central consiste en asegurarse de que los datos lleguen adonde deben llegar, en el formato correcto, con la latencia que el negocio necesita y con suficiente confiabilidad como para que las decisiones que se toman sobre esos datos sean válidas. Eso parece simple hasta que empezás a ver los problemas reales: fuentes de datos que cambian de formato sin previo aviso, pipelines que fallan silenciosamente, datos que llegan correctos en desarrollo y corruptos en producción, y la constante tensión entre lo que necesita el negocio hoy y lo que es técnicamente sostenible.
Para resolver eso necesitás capacidad de razonar sobre sistemas distribuidos, entender trade-offs de latencia vs throughput vs consistencia, saber depurar pipelines en producción sin visibilidad perfecta y poder trabajar con stakeholders no técnicos que saben qué quieren pero no siempre saben articular el problema subyacente.
Aunque muchos job descriptions lo sugieran, construir modelos de machine learning no forma parte del trabajo. Eso es data science o ML engineering. El data engineer construye la infraestructura sobre la que esos modelos van a operar, pero no los construye. Confundir los dos roles es una fuente de expectativas desalineadas en muchas entrevistas y en los primeros meses de un puesto.
El stack que importa vs el stack que solo suena bien en LinkedIn
Hay una lista de tecnologías que aparece en casi todos los job postings de data engineering: Spark, Kafka, Airflow, dbt, Snowflake, Databricks, Flink, Kubernetes. Ver esa lista y pensar que necesitás conocer todo eso antes de empezar es un error común.
El stack que realmente importa para un data engineer senior no es una lista de herramientas. Es la capacidad de entender cuándo aplicar cada herramienta y por qué.
SQL sigue siendo central. No el SQL básico para hacer joins, sino SQL como lenguaje para expresar transformaciones de datos complejas, optimizar queries que corren sobre millones de filas y entender qué hace el motor de base de datos con lo que escribís. Los ingenieros que subestiman SQL en favor de herramientas más "modernas" suelen descubrir que la mayoría de los problemas de rendimiento tienen solución ahí.
Python cumple el rol de pegamento. No necesitás ser un experto en Python orientado a objetos para ser un buen data engineer, pero sí necesitás poder escribir scripts robustos, manejar errores correctamente y construir pipelines que fallen de manera controlada y logueable.
Un orquestador en profundidad también es clave. Airflow es el más común, pero lo que importa es entender profundamente al menos uno: cómo maneja fallos, reintentos, dependencias entre tareas y backfills. Los orquestadores son la parte del stack que más duele cuando están mal configurados.
Para almacenamiento, el mercado tiene varias opciones: Snowflake, BigQuery, Redshift, Databricks. Los patrones de optimización difieren, pero los principios son parecidos: particionamiento, clustering, materialización de resultados intermedios, costo de queries.
Lo que podés dejar para después, una vez que tengas la base, es Kafka para streaming, Spark para procesamiento distribuido a escala e infraestructura como código para el data stack.
Cuánto paga la carrera de Data Engineer en USD y qué lo determina
Las compensaciones en data engineering para roles remotos con empresas de EE.UU. o Europa varían bastante, pero hay rangos que se pueden decir con honestidad.
Un data engineer senior con cinco o más años de experiencia, buen manejo del stack relevante y capacidad para trabajar de forma autónoma en un equipo remoto está en un rango de USD 60.000 a 120.000 anuales, dependiendo de la empresa, el rol específico y cómo se posiciona en la entrevista.
Lo que mueve el número hacia arriba es la experiencia en streaming (Kafka, Flink), la capacidad de diseñar la arquitectura de la data platform y no solo implementarla, e historial de haber construido cosas que escalan. También importa mucho el nivel de inglés, no para aprobar un test, sino para comunicarse con eficacia en reuniones, en la documentación y en la toma de decisiones técnicas.
Lo que no mueve el número tan directamente como se cree es la cantidad de herramientas del stack que conocés. Los mejores pagadores en este espacio buscan ingenieros capaces de resolver problemas de datos, no de enumerar todos los componentes del Modern Data Stack.
Si venís del desarrollo, lo que cambia y lo que no
Para un ingeniero de software que está evaluando mudarse a data engineering, la buena noticia es que las habilidades de ingeniería de software son directamente transferibles y escasas en el ámbito de los datos.
Muchos data engineers vienen de un background de análisis de datos o data science, lo que significa que son fuertes en SQL y en estadística, pero menos fuertes en prácticas de ingeniería: testing, versionado, observabilidad, automatización de deployments, diseño de sistemas. Un software engineer senior que aprende el stack de datos tiene una ventaja real porque aporta las prácticas de ingeniería que muchos data teams necesitan, pero no tienen.
El dominio cambia. En vez de pensar en la latencia de las requests HTTP, pensás en la latencia de ingesta. En vez de pensar en contratos de API, pensás en esquemas de datos y en cómo evolucionan. En vez de pensar en la disponibilidad de los servicios, pensás en la frescura de los datos y en los SLAs de los pipelines. La forma de razonar sobre sistemas, en cambio, se transfiere sin fricción: un ingeniero que puede pensar en términos de confiabilidad, escalabilidad y mantenibilidad de sistemas distribuidos puede aplicar ese razonamiento a sistemas de datos desde el primer día.
El período de transición más difícil suele ser el primero en el que estás en producción con pipelines reales. Descubrís que los datos en producción son mucho más sucios que cualquier dataset de entrenamiento que hayas visto, y que la mayoría de los problemas de data engineering son de calidad de datos, no de infraestructura.
Cómo se ve la entrevista de Data Engineering (y por qué es diferente a software)
Si venís del desarrollo de software y entrevistás para un rol de data engineering, el proceso tiene diferencias que vale la pena anticipar.
La parte técnica suele incluir SQL más avanzado de lo que estás acostumbrado en entrevistas de backend: ventanas, CTEs, optimización de queries, diseño de esquemas para casos analíticos. Vale repasarlo aunque tengas años de experiencia con SQL, porque el SQL que se usa en data engineering está mucho más orientado a transformaciones complejas que al CRUD típico de backend.
El diseño de sistemas también aparece, pero el dominio es diferente: te van a pedir que diseñes un pipeline de ingesta, un sistema de datos en tiempo real o la arquitectura de un data warehouse. Los principios son similares al diseño de sistemas de backend (consistencia, disponibilidad, latencia, throughput), pero aplicados a volúmenes y patrones de acceso distintos.
Hay preguntas sobre la calidad de los datos que no figuran en las entrevistas de software: ¿cómo detectás que un pipeline produjo datos incorrectos? ¿Cómo diseñás alertas de calidad? ¿Qué hacés cuando una fuente de datos cambia de formato sin previo aviso? Estas preguntas buscan saber si tenés experiencia con problemas reales de datos en producción, no solo con la infraestructura que los mueve.
El soft skill que más se valora en este tipo de roles es la capacidad de trabajar con stakeholders no técnicos que saben qué análisis quieren, pero no siempre pueden articular el problema de datos subyacente. Esa traducción es parte del trabajo y parte de lo que distingue a los data engineers buenos de los que saben usar las herramientas, pero no agregan criterio.
La posición real sobre esta carrera
La ingeniería de datos es una carrera genuinamente buena para un ingeniero senior al que le interesa el dominio. La demanda es real, la compensación en remoto es competitiva y las habilidades de ingeniería de software tienen alta transferencia.
No es un pivot fácil que hagas en tres meses aprendiendo Airflow y Spark de tutoriales. El trabajo real tiene complejidad genuina (sistemas distribuidos, calidad de datos, stakeholders con necesidades conflictivas) y requiere el mismo tipo de criterio y experiencia acumulada que cualquier área de ingeniería de software.
El hype generó expectativas desalineadas en ambas direcciones: candidatos que creen que el título alcanza, y empresas que usan "data engineer" para describir roles que van desde analista SQL hasta arquitecto de plataforma de datos. Antes de comprometerse con el pivot o con un rol específico, vale la pena entender exactamente qué problema estás siendo contratado para resolver.
El título dice data engineer. Lo que importa es qué sistema estás construyendo y qué tan bien podés construirlo.
