"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 dice cosas 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 es asegurarse de que los datos lleguen donde tienen que 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 aviso, pipelines que fallan silenciosamente, datos que llegan correctos en desarrollo y corruptos en producción, y la constante tensión entre qué necesita el negocio hoy y qué es sostenible técnicamente.
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 muchos primeros meses en 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 de 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á mal configurada.
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 de trabajar autónomamente 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 experiencia en streaming (Kafka, Flink), capacidad de diseñar la arquitectura del 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 efectividad en reuniones, en documentación y en 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 que pueden resolver problemas de datos, no ingenieros que pueden nombrar 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 moverse a data engineering, la buena noticia es que las habilidades de ingeniería de software son directamente transferibles y escasas en el espacio de 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 trae las prácticas de ingeniería que muchos data teams necesitan pero no tienen.
El dominio cambia. En vez de pensar en latencia de requests HTTP, pensás en latencia de ingesta. En vez de pensar en API contracts, pensás en schemas de datos y cómo evolucionan. En vez de pensar en disponibilidad de servicios, pensás en frescura de datos y SLAs de 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 problemas 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 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 el CRUD típico de backend.
El diseño de sistemas aparece también, 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 parecidos al diseño de sistemas de backend (consistencia, disponibilidad, latencia, throughput), pero aplicados a volúmenes y patrones de acceso diferentes.
Hay preguntas sobre calidad de datos que no existen en 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 aviso? Estas preguntas buscan saber si tenés experiencia con los 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
Ingeniero de datos es una carrera genuinamente buena para un ingeniero senior 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 haces 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.
