Perguntas de entrevista para Data Engineer — Mais de 30 perguntas e respostas de especialistas

As vagas de engenharia de dados cresceram mais de 60% desde 2020, tornando-se uma das especializações de crescimento mais rápido em tecnologia [1]. Ainda assim, com uma média de 118 candidatos por vaga aberta e uma taxa de contratação de 27% [2], as entrevistas permanecem altamente competitivas. Entrevistas modernas de data engineer vão além da proficiência em SQL — testam sua capacidade de projetar pipelines escaláveis, modelar dados para analytics, gerenciar qualidade de dados e operar em ambientes de produção usando ferramentas como Spark, Kafka, dbt e Airflow [3]. As perguntas abaixo refletem os padrões usados por equipes de contratação em empresas que vão desde startups construindo seu primeiro stack de dados até empresas gerenciando data warehouses na escala de petabytes.

Pontos-chave

• Entrevistas de data engineer abrangem SQL, Python, modelagem de dados, design de pipelines ETL/ELT e arquitetura de sistemas [1].
• Espere desafios de programação em SQL e Python junto com sessões de design de pipelines em quadro branco.
• Perguntas comportamentais investigam como você lida com incidentes de qualidade de dados, comunicação com stakeholders e colaboração entre equipes.
• Conhecimento de ferramentas do stack de dados moderno (dbt, Airflow, Spark, Kafka, Snowflake, Databricks) é cada vez mais esperado.
• Demonstrar compreensão de governança de dados, linhagem e observabilidade diferencia candidatos seniores.

Perguntas comportamentais

Data engineers estão na interseção de engenharia e analytics, colaborando com data scientists, analistas e equipes de produto. Perguntas comportamentais avaliam como você navega essas relações sob restrições do mundo real [4].

1. Descreva uma vez em que um pipeline de dados que você construiu falhou em produção. Como diagnosticou e corrigiu?

Use STAR: a Situação (job ETL diário falhou às 3h da manhã, atrasando o dashboard de analytics matinal), a Tarefa (restaurar a frescura dos dados antes do horário comercial), a Ação (verificou logs do Airflow, identificou uma mudança de schema na API fonte que quebrou o passo de extração, implementou tratamento de evolução de schema e adicionou alertas), e o Resultado (pipeline restaurado em 90 minutos, adicionou testes de integração que capturam mudanças de schema automaticamente).

2. Conte-me sobre uma vez em que discordou de um data scientist ou analista sobre como os dados deveriam ser modelados. Como resolveu?

Descreva o trade-off — talvez o analista quisesse uma tabela desnormalizada ampla para performance de consultas enquanto você defendia um modelo dimensional normalizado para manutenibilidade. Explique como testou ambas abordagens com consultas representativas e encontrou um compromisso (views materializadas ou tabelas pré-agregadas) que atendeu ambas necessidades.

3. Guie-me por uma situação em que herdou um pipeline de dados legado e teve que decidir se refatorava ou reconstruía.

Avalie os critérios de decisão: qualidade da documentação, cobertura de testes, criticidade para o negócio e o custo de downtime durante a migração. Respostas fortes mostram avaliação sistemática em vez de padronizar para "reescrever tudo" ou "deixar como está."

4. Descreva uma vez em que implementou monitoramento de qualidade de dados que capturou um problema antes de chegar aos consumidores downstream.

Discuta verificações específicas de qualidade de dados: monitoramento de taxa de nulos, SLAs de frescura, detecção de anomalias de contagem de linhas e validação de schema. Mencione ferramentas como Great Expectations, testes dbt ou Monte Carlo. Quantifique o impacto — "capturou uma queda de 40% na contagem de linhas de uma mudança no sistema fonte que teria produzido relatórios de receita incorretos."

5. Conte-me sobre uma vez em que teve que explicar um conceito de engenharia de dados a um stakeholder não técnico.

Enquadrar processos ETL, latência de dados e dependências de pipeline em termos de negócio é essencial. Descreva usando analogias, dashboards ou indicadores de frescura de dados para tornar a saúde do pipeline visível e compreensível.

6. Como você lidou com uma situação em que os dados de um sistema fonte eram não confiáveis ou inconsistentes?

Discuta implementação de validação na camada de ingestão, criação de verificações de reconciliação entre fonte e destino, documentação de problemas de qualidade de dados em um catálogo de dados e comunicação de limitações conhecidas aos usuários downstream em vez de propagar silenciosamente dados ruins.

Perguntas técnicas

Perguntas técnicas testam sua profundidade em SQL, sistemas distribuídos, modelagem de dados e arquitetura de pipelines [5].

1. Explique a diferença entre ETL e ELT. Quando escolheria cada abordagem?

ETL (Extract, Transform, Load) transforma dados antes de carregá-los no warehouse — adequado quando o warehouse tem computação limitada ou quando as transformações requerem lógica de negócio complexa. ELT (Extract, Load, Transform) carrega dados brutos primeiro e os transforma no warehouse — preferido com warehouses colunares modernos (Snowflake, BigQuery, Redshift) que têm computação elástica para transformações [3]. Discuta como dbt se tornou a ferramenta padrão para o "T" em ELT.

2. Escreva uma consulta SQL para encontrar o segundo maior salário em cada departamento.

Use uma função de janela: SELECT department, employee, salary FROM (SELECT department, employee, salary, DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank FROM employees) ranked WHERE rank = 2. Discuta por que DENSE_RANK trata empates corretamente e por que RANK ou ROW_NUMBER podem dar resultados diferentes.

3. Como projetaria um pipeline de dados incremental que processa apenas registros alterados de um sistema fonte?

Discuta estratégias de Change Data Capture (CDC): cargas incrementais baseadas em timestamp (usando colunas updated_at), CDC baseado em logs (Debezium lendo write-ahead logs do banco de dados) e comparação baseada em hash. Aborde os desafios: dados que chegam atrasados, exclusões invisíveis para abordagens baseadas em timestamp e garantias de processamento exactly-once [1].

4. Explique as diferenças entre um schema estrela e um schema floco de neve. Quando usaria cada um?

Um schema estrela tem uma tabela de fatos central conectada a tabelas de dimensão desnormalizadas — consultas mais simples, leituras mais rápidas, ideal para ferramentas de BI. Um schema floco de neve normaliza tabelas de dimensão em sub-dimensões — reduz redundância de armazenamento mas aumenta complexidade de consultas. Schemas estrela são preferidos para cargas de trabalho analíticas onde performance de consulta importa; schemas floco de neve se adequam a ambientes onde eficiência de armazenamento e integridade de dados são prioridade.

5. Como o Apache Kafka difere de uma fila de mensagens tradicional como RabbitMQ, e quando escolheria Kafka para um pipeline de dados?

Kafka é uma plataforma de streaming de eventos distribuída com logs duráveis, ordenados e reproduzíveis. RabbitMQ é um broker de mensagens otimizado para entrega ponto-a-ponto com semântica de acknowledgment. Escolha Kafka para streaming de eventos de alto throughput, agregação de logs e cenários onde múltiplos consumidores precisam ler os mesmos dados independentemente (fan-out). Escolha RabbitMQ para filas de tarefas com roteamento complexo e requisitos de entrega exactly-once [5].

6. O que é particionamento de dados e como melhora a performance de consultas em um data warehouse?

Particionamento divide tabelas grandes em segmentos baseados em uma chave (data, região, ID do cliente). Consultas que filtram pela chave de partição apenas escaneiam segmentos relevantes, reduzindo custo de I/O e computação. Discuta estratégias de particionamento: particionamento por faixa para dados de séries temporais, particionamento por hash para distribuição uniforme e a importância de escolher chaves de partição alinhadas com padrões de consulta comuns.

7. Como você lida com evolução de schema em um pipeline de dados quando fontes upstream mudam seu formato de dados?

Implemente schema registry (Confluent Schema Registry para Kafka, ou evolução de schema Avro/Parquet). Defina regras de compatibilidade para frente e para trás. Use zonas de landing que aceitam dados brutos sem enforcement de schema, depois valide e transforme em camadas de staging. Alerte sobre mudanças de schema e implemente circuit breakers que interrompem o processamento em vez de propagar dados corrompidos [3].

Perguntas situacionais

Perguntas situacionais apresentam desafios realistas de pipeline para avaliar sua abordagem de resolução de problemas [4].

1. Seu pipeline diário leva 6 horas para completar, mas o negócio precisa de dados atualizados a cada 2 horas. Como aborda isso?

Analise onde o tempo é gasto — é na extração, transformação ou carga? Implemente processamento incremental para substituir recargas completas de tabelas. Paralelize transformações independentes. Considere mover transformações pesadas para o warehouse (ELT) para aproveitar sua computação elástica. Se o SLA requer quase tempo real, avalie alternativas de streaming para as tabelas mais críticas.

2. Um data scientist reporta que a acurácia de um modelo de machine learning caiu repentinamente. Suspeita de um problema de qualidade de dados. Como você investiga?

Verifique metadados do pipeline: a execução mais recente completou com sucesso? Compare contagens de linhas, taxas de nulos e distribuições de valores contra baselines históricas. Verifique mudanças no sistema fonte (modificações de schema, atualizações de regras de negócio). Use ferramentas de linhagem de dados para rastrear as features de input do modelo até suas tabelas fonte e identificar onde o shift de distribuição ocorreu.

3. Você está projetando uma plataforma de dados para uma startup que atualmente tem 10 GB de dados mas espera alcançar 10 TB em 18 meses. Como arquiteta para crescimento sem sobre-engenharia?

Comece com um warehouse de nuvem gerenciado (Snowflake, BigQuery) que escala elasticamente. Use dbt para transformações, que escala com a computação do warehouse. Implemente orquestração com Airflow ou Dagster desde o início — é mais difícil adicionar depois. Projete modelos dimensionais que suportem expansão futura. Evite otimização prematura como clusters Spark até que o volume de dados realmente demande.

4. Duas equipes diferentes precisam dos mesmos dados fonte mas com transformações e requisitos de frescura diferentes. Como evitar duplicar pipelines?

Implemente uma arquitetura medallion compartilhada bronze/prata/ouro. Ingira dados brutos uma vez na camada bronze, aplique limpeza comum na camada prata e deixe cada equipe construir suas próprias transformações de camada ouro. Use um catálogo de dados para documentar datasets disponíveis e prevenir que equipes construam pipelines de ingestão redundantes.

5. Seu pipeline usa uma API que tem limite de taxa de 100 requests por minuto, mas você precisa extrair 1 milhão de registros diariamente. Como projeta a extração?

Implemente limitação de taxa com backoff exponencial no código de extração. Use paginação com offsets baseados em cursor para pulls incrementais. Agende extração durante horários de baixo pico para maximizar throughput dentro dos limites de taxa. Cache respostas da API para evitar re-buscar dados não alterados. Se a API suporta endpoints de exportação em massa, use-os em vez de busca registro-a-registro.

Perguntas para o entrevistador

Data engineers devem avaliar a maturidade da plataforma de dados e a cultura de engenharia da equipe [1].

1. "Como é o stack de dados atual — warehouse, orquestração, transformação e ferramentas de observabilidade?" — Revela ambiente técnico e status de modernização.
2. "Como vocês lidam com qualidade de dados hoje, e existe um framework de monitoramento de qualidade de dados?" — Indica maturidade de governança de dados.
3. "Qual é a proporção de data engineers para data scientists e analistas na equipe?" — Mostra se data engineers estão integrados com consumidores ou isolados.
4. "Como a equipe lida com on-call para falhas de pipeline?" — Avalia carga operacional e expectativas de work-life balance.
5. "Existe um catálogo de dados ou ferramenta de linhagem de dados implementada?" — Revela práticas de descoberta e documentação.
6. "Qual é o maior desafio de engenharia de dados que a equipe está enfrentando atualmente?" — Fornece insight sobre se a função se alinha com suas habilidades e interesses.

Formato da entrevista e o que esperar

Entrevistas de data engineer tipicamente incluem quatro a cinco rodadas que avaliam tanto capacidade de programação quanto pensamento de design de sistemas [3].

Triagem com recrutador (30 minutos): Discussão de experiência, expectativas salariais e background técnico geral.

Rodada de programação SQL (60 minutos): Escreva consultas SQL em um ambiente compartilhado — funções de janela, CTEs, agregações e joins. Espere discussões de otimização sobre planos de execução de consultas.

Rodada Python / Programação (60 minutos): Implemente lógica de processamento de dados — parsing de arquivos, transformação de estruturas de dados ou construção de um componente simples de pipeline. Foco em código limpo e testável.

Rodada de design de sistemas (60-90 minutos): Projete um pipeline de dados ou plataforma de dados end-to-end. Prompts comuns: projete um sistema de analytics em tempo real, construa um data lake para uma empresa multi-produto ou arquitete uma plataforma de dados orientada a eventos.

Rodada comportamental (45-60 minutos): Perguntas sobre colaboração, resposta a incidentes e comunicação com stakeholders não técnicos.

Como se preparar

A preparação para entrevista de data engineer deve combinar prática de SQL, estudo de design de pipeline e conhecimento específico de ferramentas [5].

Domine SQL: Pratique funções de janela, CTEs, self-joins e otimização de consultas. Use plataformas como problemas de banco de dados do LeetCode, HackerRank SQL ou Stratascratch. Seja capaz de escrever consultas complexas sem IDE.

Estude modelagem de dados: Entenda schemas estrela, schemas floco de neve, slowly changing dimensions (Tipo 1, 2, 3) e a arquitetura medallion (bronze/prata/ouro). Esteja pronto para projetar um modelo dimensional em quadro branco.

Conheça suas ferramentas: Esteja preparado para discutir as ferramentas listadas na descrição da vaga. Para Spark, entenda RDDs vs. DataFrames, particionamento e operações de shuffle. Para Airflow, entenda DAGs, operators, sensors e XComs. Para dbt, entenda models, tests, macros e materializações incrementais.

Pratique design de pipelines: Percorra cinco designs de pipeline end-to-end: batch ETL, streaming em tempo real, replicação baseada em CDC, extração baseada em API e migração de data warehouse. Para cada um, identifique as ferramentas, modos de falha e estratégia de monitoramento.

Prepare histórias de qualidade de dados: Tenha exemplos específicos de problemas de qualidade de dados que descobriu, investigou e resolveu. Quantifique o impacto de negócio de capturar (ou perder) esses problemas.

Revise conceitos de sistemas distribuídos: Entenda particionamento, replicação, modelos de consistência e o teorema CAP como se aplicam a sistemas de dados. Livros como Designing Data-Intensive Applications de Martin Kleppmann são preparação inestimável.

Erros comuns na entrevista

Evite estas armadilhas que frequentemente desqualificam candidatos de engenharia de dados [4].

1. Escrever SQL correto mas não otimizado. Uma consulta que produz o resultado certo mas escaneia toda a tabela desnecessariamente sinaliza falta de consciência de produção. Sempre discuta indexação, particionamento e planos de execução.

2. Ignorar qualidade de dados nos designs de pipeline. Um pipeline sem validação, monitoramento e alertas está incompleto. Sempre inclua verificações de qualidade de dados nas suas respostas de design de sistemas.

3. Sobre-engenharia para escala que não possui. Propor Kafka e Spark para uma carga diária de 10 GB é tanto um erro quanto usar scripts simples para uma carga diária de 10 TB. Adeque a arquitetura ao volume de dados real e trajetória de crescimento.

4. Não entender o contexto de negócio. Pipelines de dados servem decisões de negócio. Candidatos que projetam soluções tecnicamente sólidas mas irrelevantes para o negócio perdem o ponto. Faça perguntas clarificadoras sobre quem consome os dados e que decisões eles impulsionam.

5. Tratar batch e streaming como intercambiáveis. Cada um tem trade-offs distintos em complexidade, custo e latência. Seja claro sobre quando cada abordagem é apropriada e as implicações operacionais de escolher um sobre o outro.

6. Negligenciar preocupações operacionais. Monitoramento de pipeline, alertas, lógica de retry, dead-letter queues e procedimentos de backfill não são opcionais — são o que torna um pipeline pronto para produção [3].

Pontos-chave

Entrevistas de data engineer avaliam sua capacidade de projetar, construir e operar sistemas de dados que entregam dados confiáveis e oportunos às pessoas que precisam deles. Prepare-se dominando SQL, entendendo ferramentas do stack de dados moderno e praticando design de pipeline end-to-end. Os candidatos que se destacam são aqueles que pensam sobre qualidade de dados, resiliência operacional e impacto no negócio — não apenas o caminho feliz.

Quer garantir que seu currículo destaque as habilidades certas de engenharia de dados? Experimente o verificador gratuito de pontuação ATS do ResumeGeni para otimizar seu currículo de data engineer antes de se candidatar.

Perguntas frequentes

Que linguagens de programação devo conhecer para uma entrevista de data engineer? SQL é essencial. Python é esperado para a maioria das funções. Scala é valioso para ambientes com uso intensivo de Spark. Java aparece em alguns ambientes enterprise [5].

Quão importante é experiência em nuvem para entrevistas de engenharia de dados? Muito importante. A maioria das funções modernas de engenharia de dados requer experiência com pelo menos uma plataforma de nuvem (AWS, GCP ou Azure) e serviços de dados nativos de nuvem (Redshift, BigQuery, Snowflake, Databricks) [1].

Entrevistas de data engineer incluem programação ao vivo? Sim. Espere pelo menos uma rodada de programação SQL ao vivo e frequentemente uma rodada de programação Python focada em lógica de transformação de dados [3].

Qual é a pergunta de design de sistemas mais comum para data engineers? Projetar um pipeline de dados batch com processamento incremental, ou projetar um sistema de streaming de eventos em tempo real, são os dois prompts mais comuns.

Como me preparo para rodadas de design de sistemas se só trabalhei em pipelines existentes? Estude arquiteturas open-source, leia posts de blogs de engenharia de empresas como Netflix, Uber e Airbnb, e pratique explicando decisões de design em voz alta. A habilidade-chave é articular trade-offs, não memorizar arquiteturas.

Devo aprender dbt para entrevistas de engenharia de dados? Sim — dbt se tornou uma ferramenta padrão no stack de dados moderno. Entender models, tests e materializações incrementais é esperado para a maioria das funções de analytics engineering e engenharia de dados [5].

Que certificações ajudam para entrevistas de engenharia de dados? Certificações de nuvem (AWS Data Analytics Specialty, GCP Professional Data Engineer, Azure Data Engineer Associate) demonstram conhecimento específico de plataforma e são valorizadas por muitos empregadores.