"Engenheiro de dados" virou um dos cargos mais procurados dos últimos cinco anos. O LinkedIn está cheio de posts sobre o tema, os bootcamps vendem isso como o próximo passo natural, e toda empresa de porte médio parece ter um "time de dados", mesmo que ninguém tenha muita certeza do que ele faz. Tudo isso criou uma confusão genuína sobre o que essa carreira realmente significa na prática.
Se você é um engenheiro de software sênior avaliando uma mudança de área, ou já está em data engineering e quer entender melhor onde está pisando, vale a pena separar o sinal do ruído.
O que um engenheiro de dados realmente faz (além da descrição de vaga)
A descrição de vaga típica de data engineer inclui tarefas como "construir pipelines de dados", "manter a infraestrutura de dados" e "colaborar com data scientists". Tudo verdade, mas isso não diz muita coisa sobre quais problemas concretos você resolve no dia a dia.
Na prática, o trabalho central é garantir que os dados cheguem aonde precisam chegar, no formato certo, com a latência que o negócio exige e com confiabilidade suficiente para que as decisões tomadas com base nesses dados façam sentido. Isso parece simples até você começar a ver os problemas reais: fontes de dados que mudam de formato sem aviso, pipelines que falham silenciosamente, dados que chegam corretos em desenvolvimento e corrompidos em produção, e a tensão constante entre o que o negócio precisa hoje e o que é tecnicamente sustentável.
Para resolver isso você precisa de capacidade de raciocinar sobre sistemas distribuídos, entender trade-offs de latência vs throughput vs consistência, saber debugar pipelines em produção sem visibilidade perfeita e conseguir trabalhar com stakeholders não técnicos que sabem o que querem, mas nem sempre sabem articular o problema por trás disso.
Mesmo que muitas descrições de vaga sugiram o contrário, construir modelos de machine learning não faz parte do trabalho. Isso é data science ou ML engineering. O data engineer constrói a infraestrutura sobre a qual esses modelos vão rodar, mas não constrói os modelos em si. Confundir os dois papéis é uma fonte comum de expectativas desalinhadas em muitas entrevistas e nos primeiros meses de um cargo.
O stack que importa vs o stack que só soa bem no LinkedIn
Existe uma lista de tecnologias que aparece em quase todas as vagas de data engineering: Spark, Kafka, Airflow, dbt, Snowflake, Databricks, Flink, Kubernetes. Olhar para essa lista e achar que precisa conhecer tudo isso antes de começar é um erro comum.
O stack que realmente importa para um data engineer sênior não é uma lista de ferramentas. É a capacidade de entender quando aplicar cada uma e por quê.
SQL continua sendo central. Não o SQL básico para fazer joins, mas o SQL como linguagem para expressar transformações de dados complexas, otimizar queries que rodam sobre milhões de linhas e entender o que o motor do banco de dados faz com o que você escreve. Engenheiros que subestimam o SQL em favor de ferramentas mais "modernas" costumam descobrir que a maioria dos problemas de performance tem solução ali mesmo.
Python cumpre o papel de cola. Você não precisa ser um especialista em Python orientado a objetos para ser um bom data engineer, mas precisa conseguir escrever scripts robustos, tratar erros corretamente e construir pipelines que falhem de forma controlada e rastreável.
Um orquestrador em profundidade também é essencial. Airflow é o mais comum, mas o que importa é entender profundamente pelo menos um: como ele lida com falhas, retries, dependências entre tarefas e backfills. Os orquestradores são a parte do stack que mais dói quando estão mal configurados.
Para armazenamento, o mercado tem várias opções: Snowflake, BigQuery, Redshift, Databricks. Os padrões de otimização diferem, mas os princípios são parecidos: particionamento, clustering, materialização de resultados intermediários, custo de queries.
O que dá para deixar para depois, quando já tiver a base, é Kafka para streaming, Spark para processamento distribuído em escala e infraestrutura como código para o data stack.
Quanto paga a carreira de Data Engineer em dólares e o que determina isso
As remunerações em data engineering para posições remotas com empresas dos EUA ou da Europa variam bastante, mas há faixas que dá para afirmar com honestidade.
Um data engineer sênior com cinco anos ou mais de experiência, bom domínio do stack relevante e capacidade de trabalhar de forma autônoma em um time remoto está numa faixa de USD 60.000 a 120.000 por ano, dependendo da empresa, do cargo específico e de como você se posiciona na entrevista.
O que puxa esse número para cima é a experiência com streaming (Kafka, Flink), a capacidade de desenhar a arquitetura da data platform, não só implementá-la, e um histórico de ter construído coisas que escalam. O nível de inglês também importa muito, não para passar num teste, mas para se comunicar com eficácia em reuniões, na documentação e na tomada de decisões técnicas.
O que não move o número de forma tão direta quanto se imagina é a quantidade de ferramentas do stack que você conhece. As empresas que melhor pagam nesse espaço buscam engenheiros capazes de resolver problemas de dados, não de listar todos os componentes do Modern Data Stack.
Se você vem do desenvolvimento, o que muda e o que não muda
Para um engenheiro de software que está avaliando migrar para data engineering, a boa notícia é que as habilidades de engenharia de software são diretamente transferíveis e escassas no universo de dados.
Muitos data engineers vêm de um background de análise de dados ou data science, o que significa que são fortes em SQL e estatística, mas menos fortes em práticas de engenharia: testes, versionamento, observabilidade, automação de deploys, design de sistemas. Um software engineer sênior que aprende o stack de dados tem uma vantagem real, porque traz as práticas de engenharia que muitos times de dados precisam, mas não têm.
O domínio muda. Em vez de pensar na latência das requisições HTTP, você pensa na latência de ingestão. Em vez de pensar em contratos de API, você pensa em esquemas de dados e em como eles evoluem. Em vez de pensar na disponibilidade dos serviços, você pensa no frescor dos dados e nos SLAs dos pipelines. Já a forma de raciocinar sobre sistemas se transfere sem atrito: um engenheiro que consegue pensar em termos de confiabilidade, escalabilidade e manutenibilidade de sistemas distribuídos consegue aplicar esse raciocínio a sistemas de dados desde o primeiro dia.
O período de transição mais difícil costuma ser o primeiro em que você está em produção com pipelines reais. Você descobre que os dados em produção são muito mais sujos do que qualquer dataset de treinamento que já viu, e que a maioria dos problemas de data engineering é de qualidade de dados, não de infraestrutura.
Como é a entrevista de Data Engineering (e por que ela é diferente de software)
Se você vem do desenvolvimento de software e está entrevistando para uma vaga de data engineering, o processo tem diferenças que vale a pena antecipar.
A parte técnica costuma incluir SQL mais avançado do que você está acostumado em entrevistas de backend: window functions, CTEs, otimização de queries, design de esquemas para casos analíticos. Vale revisar mesmo que você tenha anos de experiência com SQL, porque o SQL usado em data engineering é muito mais voltado para transformações complexas do que para o CRUD típico de backend.
O design de sistemas também aparece, mas o domínio é diferente: vão pedir para você desenhar um pipeline de ingestão, um sistema de dados em tempo real ou a arquitetura de um data warehouse. Os princípios são parecidos com os de design de sistemas de backend (consistência, disponibilidade, latência, throughput), mas aplicados a volumes e padrões de acesso diferentes.
Há perguntas sobre qualidade de dados que não aparecem em entrevistas de software: como você detecta que um pipeline gerou dados incorretos? Como você desenha alertas de qualidade? O que você faz quando uma fonte de dados muda de formato sem aviso? Essas perguntas querem saber se você tem experiência com problemas reais de dados em produção, não só com a infraestrutura que os move.
A soft skill mais valorizada nesse tipo de cargo é a capacidade de trabalhar com stakeholders não técnicos que sabem qual análise querem, mas nem sempre conseguem articular o problema de dados por trás disso. Essa tradução é parte do trabalho e parte do que diferencia os bons data engineers dos que sabem usar as ferramentas, mas não agregam critério.
A posição real sobre essa carreira
Data engineering é uma carreira genuinamente boa para um engenheiro sênior interessado nesse domínio. A demanda é real, a remuneração em modelo remoto é competitiva e as habilidades de engenharia de software têm alta transferência.
Não é uma mudança fácil de fazer em três meses aprendendo Airflow e Spark em tutoriais. O trabalho real tem complexidade genuína (sistemas distribuídos, qualidade de dados, stakeholders com necessidades conflitantes) e exige o mesmo tipo de critério e experiência acumulada que qualquer área de engenharia de software.
O hype gerou expectativas desalinhadas nos dois sentidos: candidatos que acham que o título basta, e empresas que usam "data engineer" para descrever cargos que vão de analista SQL a arquiteto de plataforma de dados. Antes de se comprometer com essa mudança ou com um cargo específico, vale a pena entender exatamente qual problema você está sendo contratado para resolver.
O título diz data engineer. O que importa é qual sistema você está construindo e o quão bem você consegue construí-lo.
