Currículo de engenheiro de dados: como migrar da análise sem perder o ATS

Um analista de dados competente monta uma vaga de engenheiro de dados e escreve o currículo com o vocabulário errado. Ele descreve SQL, Power BI e um projeto de análise de churn, exatamente como fazia até então, e o parser não encontra nenhum termo da vaga: pipeline, orquestração, Airflow, transformação. A experiência de lidar com dado pode até ser suficiente, mas o texto não fala a língua da vaga, e a triagem corta antes de qualquer recrutador ler.

Este guia mostra o que muda no vocabulário de quem migra de análise para engenharia de dados, quais ferramentas nomear e como, e como descrever um pipeline pelo problema de confiabilidade que ele resolve, não pela lista de tecnologias usadas.

Regra do Pipeline Nomeado: todo projeto de engenharia de dados no currículo precisa responder duas perguntas em uma frase só: de onde o dado vem e o que garante que ele chega íntegro do outro lado. Ferramenta sem essas duas respostas é só uma lista de nomes.

Pipeline, orquestração e transformação são os três termos que faltam no currículo de quem vem da análise

Analista de dados escreve o currículo em torno de consulta e painel. Engenheiro de dados escreve em torno de pipeline: a sequência de extração, transformação e carga que entrega dado confiável para outra pessoa consumir. Se essas três palavras não aparecem no seu currículo, o parser não tem como associar sua experiência à vaga, mesmo que você já tenha automatizado relatórios que dependiam exatamente disso.

Antes: Analista de dados com experiência em automação de relatórios e tratamento de dados em Python.
Depois: Engenheiro de Dados | pipelines de extração e transformação em Python e SQL, orquestrados em Airflow, alimentando data warehouse em BigQuery.

A segunda versão usa os mesmos fatos da primeira, mas nomeados no vocabulário da vaga. Nenhuma linha da experiência precisa mudar, apenas a forma de descrevê-la.

Nomear a ferramenta pelo produto vale ainda mais em engenharia do que em análise

Vaga de engenharia de dados costuma listar uma stack específica, porque trocar de ferramenta no meio de um pipeline em produção custa caro. Isso torna o nome do produto ainda mais decisivo na triagem do que em vagas de análise.

• Airflow: o orquestrador mais citado em vaga brasileira. Se você usou Dagster ou Prefect, cite os dois, o orquestrador usado e Airflow como termo de mercado equivalente, porque muitas vagas usam o nome genericamente.
• Spark: cite se processou dado em volume que exigia processamento distribuído, e diga se foi via Databricks, EMR ou Spark standalone, porque cada um pede experiência de operação diferente.
• dbt: ferramenta de transformação que virou padrão de mercado. Cite se você escreveu modelos em dbt, não apenas se rodou um pipeline que o usava.
• Kafka: só cite para casos reais de streaming, como dado que precisa chegar em segundos, não em lote diário.
• BigQuery / Snowflake / Databricks: o data warehouse ou lakehouse de destino. Vagas frequentemente pedem experiência em um específico, então nomeie o que você usou de fato, sem generalizar para data warehouse.

Um pipeline se descreve pelo problema de confiabilidade que resolve, não pela lista de tecnologias que passa por ele

Listar tecnologias em sequência soa como um diagrama de arquitetura, não como trabalho de engenharia. O que prova competência é o problema que o pipeline resolvia antes de existir: dado atrasado, dado duplicado, falha silenciosa, custo de reprocessamento.

Antes: Pipeline de dados com Python, Airflow e BigQuery.
Depois: Reconstruí o pipeline diário de vendas que falhava silenciosamente quando a fonte atrasava, adicionando checagem de integridade em Python, reexecução automática no Airflow e particionamento no BigQuery para reduzir custo de consulta.

A segunda versão prova que você entende os modos de falha de um pipeline em produção, não apenas a sintaxe das ferramentas envolvidas.

Modelagem dimensional continua sendo cobrada mesmo em vaga que fala só em engenharia

Quem constrói o pipeline geralmente também decide o esquema final que o time de análise vai consultar. Por isso termos como esquema estrela, tabela fato e tabela dimensão aparecem em vagas de engenharia, não só de BI.

Se você já modelou um data mart ou organizou tabelas fato e dimensão para um time de análise consumir, escreva isso de forma explícita. É um sinal de que você pensa no consumidor final do dado, não só na movimentação dele.

Migrar de analista para engenheiro de dados exige um projeto de pipeline público, não um curso de Spark sozinho

A transição de analista para engenheiro de dados é uma das mais comuns na área, e o obstáculo raramente é falta de capacidade técnica. É a ausência de prova de que você já pensou em pipeline como sistema, e não como script.

Construa um pipeline público completo: uma fonte real ou pública, extração agendada, transformação em dbt ou Python, orquestração em Airflow e um destino consultável. Documente as decisões de confiabilidade tomadas no caminho. Um projeto assim, com repositório público, vale mais do que qualquer certificado listado sozinho. Os princípios gerais de transição estão em como estruturar um currículo de transição de carreira, e o vocabulário completo de dados, incluindo os termos que ainda valem de analista, está na lista de palavras-chave por área.

O que fazer agora com o seu currículo de engenheiro de dados

Se o seu currículo ainda fala em análise e relatório quando a vaga fala em pipeline e orquestração, o problema não é sua experiência, é a tradução dela. Cada candidatura nesse formato compete em desvantagem contra quem escreveu a mesma bagagem no vocabulário que o parser reconhece.

Rode a análise gratuita em /ats com a vaga colada para ver exatamente quais termos de engenharia estão faltando no seu texto atual. Se o score vier baixo, a otimização completa custa R$ 7,80 via PIX em /checkout. Se a sua experiência ainda estiver mais no lado de análise e painel, o guia certo é o de currículo de analista de dados.

Perguntas frequentes