As entrevistas para posições de engenharia de dados em 2026 exigem profundo conhecimento técnico em múltiplas áreas: otimização de queries SQL, arquitetura de pipelines, processamento distribuído e governança de dados. Este guia apresenta as 25 perguntas mais frequentes em processos seletivos de grandes empresas de tecnologia, com respostas detalhadas e exemplos práticos de código.

Dica de Preparação

A preparação eficaz para entrevistas de engenharia de dados requer prática hands-on. Execute os exemplos de código apresentados neste artigo em seu ambiente local e experimente variações para consolidar o aprendizado. Foque em entender os trade-offs entre diferentes abordagens, não apenas em memorizar respostas.

SQL e Otimização de Queries

1. Qual a diferença entre window functions e GROUP BY?

GROUP BY agrega dados e reduz o número de linhas no resultado final. Cada grupo produz uma única linha de saída. Window functions, por outro lado, calculam valores agregados sem colapsar o conjunto de dados - todas as linhas originais são preservadas.

sql

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Window functions são essenciais para ranking, running totals e análises comparativas onde o contexto de cada linha individual precisa ser mantido. Para análises agregadas simples, GROUP BY oferece melhor performance.

2. Como você otimizaria uma query em uma tabela com 500 milhões de linhas?

A otimização de queries em tabelas massivas envolve múltiplas estratégias complementares:

Particionamento: Dividir a tabela por data ou categoria reduz drasticamente o volume de dados escaneados. Um filtro WHERE event_date = '2026-04-11' em uma tabela particionada por data acessa apenas uma fração dos dados.

Indexes: Criar índices nas colunas usadas em cláusulas WHERE e JOIN. Para queries que filtram por múltiplas colunas, índices compostos são mais eficientes.

Materialized Views: Pré-calcular agregações frequentes. Se o dashboard executa COUNT(DISTINCT user_id) GROUP BY country diariamente, materializar esse resultado elimina processamento redundante.

Análise de Execution Plan: Identificar table scans completos, joins mal otimizados e operações de sort desnecessárias. Ferramentas como EXPLAIN ANALYZE revelam gargalos específicos.

Compressão e Columnar Storage: Formatos como Parquet reduzem I/O ao armazenar dados por coluna e comprimir valores repetidos.

3. Quando usar CTEs vs subqueries vs temp tables?

CTEs (Common Table Expressions): Ideais para queries complexas onde a mesma lógica é referenciada múltiplas vezes. Melhoram a legibilidade sem ganhos de performance - o otimizador geralmente os expande como subqueries.

Subqueries: Apropriadas para lógica simples e pontual. Em bancos modernos, subqueries correlacionadas foram otimizadas e podem ter performance comparável a joins.

Temp Tables: Necessárias quando o resultado intermediário é grande e será reutilizado várias vezes. Criar índices em temp tables pode acelerar joins subsequentes. Use quando o custo de recalcular o resultado supera o overhead de materialização.

A escolha depende do volume de dados intermediários, complexidade da query e capacidade de otimização do banco. Para detalhes sobre padrões avançados de SQL, consulte o guia sobre window functions e CTEs.

ETL vs ELT e Arquitetura de Pipelines

4. Explique as diferenças entre ETL e ELT. Quando usar cada abordagem?

ETL (Extract-Transform-Load): Transforma os dados antes de carregá-los no destino. Usado quando o sistema de destino tem capacidade limitada de processamento ou quando transformações complexas requerem ferramentas especializadas.

ELT (Extract-Load-Transform): Carrega dados brutos no destino e transforma usando o poder computacional do data warehouse. Snowflake, BigQuery e Redshift tornaram ELT o padrão moderno - aproveita processamento paralelo massivo e elasticidade de cloud.

Quando usar ETL: Integração com sistemas legados, necessidade de transformação antes de atingir o destino (ex: PII masking), ou quando ferramentas de transformação especializadas (ex: Talend) já fazem parte do stack.

Quando usar ELT: Ambientes cloud-native, necessidade de manter dados brutos para auditoria, transformações iterativas que evoluem com requisitos de negócio. ELT oferece maior flexibilidade e aproveita investimento em infraestrutura de warehouse moderna.

Para padrões detalhados de implementação, veja o guia sobre ETL/ELT patterns.

5. Como você garante que um pipeline de dados seja idempotente?

Idempotência garante que executar o pipeline múltiplas vezes com os mesmos dados de entrada produz o mesmo resultado - crucial para recuperação de falhas e reprocessamento.

python

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Estratégias de idempotência:

Partition Overwrite: Reescrever a partição completa elimina duplicatas
Upsert/Merge: Usar MERGE em bancos que suportam (Snowflake, Delta Lake)
Deduplicação explícita: Ordenar por timestamp e manter apenas o registro mais recente
IDs determinísticos: Gerar chaves baseadas em conteúdo (hash de campos relevantes)

6. O que é data lineage e por que é importante?

Data lineage rastreia a origem, transformações e destino dos dados através do pipeline. Documenta o ciclo de vida completo: de qual sistema os dados vieram, quais transformações foram aplicadas, quem os acessou e para onde foram enviados.

Importância:

Debugging: Quando um relatório mostra valores incorretos, lineage identifica qual transformação introduziu o erro
Compliance: Regulamentações como GDPR exigem rastreabilidade de dados pessoais
Impact Analysis: Antes de modificar uma tabela, lineage revela quais dashboards e modelos dependem dela
Data Quality: Identificar a raiz de problemas de qualidade seguindo o fluxo reverso

Ferramentas modernas como DataHub, Amundsen e Marquez automatizam a captura de lineage integrando-se com orquestradores e data warehouses.

Streaming e Processamento de Dados em Tempo Real

7. Qual a diferença entre batch e streaming processing?

Batch Processing: Processa grandes volumes de dados acumulados em intervalos fixos (horário, diário). Otimizado para throughput máximo - processa milhões de registros de uma vez. Latência de horas ou dias.

Streaming Processing: Processa dados continuamente conforme chegam. Otimizado para latência mínima - cada evento é processado em segundos. Throughput menor que batch mas entrega resultados em tempo real.

Trade-offs: Batch oferece melhor eficiência de recursos e facilita reprocessamento histórico. Streaming permite detecção de fraude em tempo real, alertas instantâneos e experiências interativas. Arquiteturas modernas combinam ambos: Lambda Architecture usa batch para precisão e streaming para velocidade.

8. Como funciona a arquitetura do Apache Kafka?

Kafka é uma plataforma de streaming distribuída que funciona como um sistema de mensageria pub-sub escalável.

Componentes principais:

Topics: Categorias de mensagens (ex: "user-events", "transactions")
Partitions: Cada topic é dividido em partitions para paralelização. Mensagens com a mesma key vão para a mesma partition (garante ordem)
Producers: Publicam mensagens em topics
Consumers: Assinam topics e processam mensagens. Consumers em um mesmo consumer group dividem o trabalho (cada partition é consumida por apenas um consumer do grupo)
Brokers: Servidores que armazenam mensagens e coordenam a distribuição
Zookeeper/KRaft: Gerencia metadados e coordenação do cluster

Garantias: Kafka oferece durabilidade (replicação entre brokers), ordering (dentro da partition) e exactly-once semantics (com configuração adequada).

9. Como você lida com eventos que chegam fora de ordem (late-arriving data)?

Eventos fora de ordem são comuns em sistemas distribuídos devido a latência de rede, retries e múltiplas fontes de dados.

Estratégias:

Watermarks: Definir um limite de atraso aceitável (ex: 5 minutos). Processar todos os eventos com timestamp até (tempo_atual - watermark)
Allowed Lateness: Após o watermark, ainda aceitar eventos atrasados por um período adicional e atualizar resultados já emitidos
Event Time vs Processing Time: Usar event_timestamp (quando o evento ocorreu) em vez de processing_timestamp (quando foi processado) para agregações
Windowing: Tumbling windows de 1 hora com 15 minutos de allowed lateness capturam a maioria dos eventos atrasados

Frameworks como Apache Flink e Spark Structured Streaming implementam essas estratégias nativamente.

Modelagem de Dados e Design de Schemas

10. Qual a diferença entre star schema e snowflake schema?

Star Schema: Uma tabela fato central conectada diretamente a tabelas dimensão desnormalizadas. Simples, com joins diretos. Melhor performance para queries analíticas pois minimiza joins.

Snowflake Schema: Dimensões são normalizadas em múltiplas tabelas relacionadas. Economiza espaço de armazenamento ao eliminar redundância, mas requer mais joins e tem performance inferior em queries.

Quando usar cada um: Star schema é o padrão para data warehouses analíticos - queries são mais rápidas e o modelo é intuitivo para analistas. Snowflake schema só se justifica quando storage é extremamente caro ou quando a normalização simplifica significativamente a manutenção de dimensões muito grandes.

Armazenamento moderno em cloud é barato. Performance de queries é mais valiosa que economia de storage. Star schema vence na maioria dos casos.

Para aprofundamento em técnicas de modelagem, consulte o material sobre data modeling.

11. O que são Slowly Changing Dimensions (SCD)? Explique os tipos.

SCDs capturam mudanças em atributos de dimensões ao longo do tempo.

Tipo 1 (Overwrite): Sobrescreve o valor antigo. Não mantém histórico. Usado para correções de erros ou quando histórico é irrelevante.

Tipo 2 (Add Row): Cria nova linha para cada mudança. Adiciona colunas effective_date, end_date, is_current. Mantém histórico completo. Mais comum em cenários analíticos.

Tipo 3 (Add Column): Adiciona colunas para valores anteriores (ex: previous_address, current_address). Mantém histórico limitado. Raramente usado.

Tipo 4 (Separate History Table): Tabela principal mantém valor atual, tabela histórica registra mudanças. Usado quando queries no estado atual são muito mais frequentes que análise histórica.

Tipo 2 é o padrão em data warehousing moderno - oferece flexibilidade para análises históricas sem comprometer queries no estado atual.

12. Como você modelaria dados de eventos para suportar análises de comportamento de usuário?

Modelagem de eventos requer dupla camada: eventos brutos imutáveis e agregações materializadas.

Camada Raw: Tabela de eventos com schema flexível (event_type, user_id, timestamp, properties_json). Particionada por data. Mantém fidelidade total aos dados originais.

Camada Aggregated: Tabelas derivadas otimizadas para queries específicas:

user_sessions: Sessões agregadas com duração, páginas visitadas, conversões
daily_user_metrics: Métricas diárias por usuário (engagement, retention)
funnel_events: Eventos pré-filtrados e ordenados para análises de funil

Benefícios: Queries analíticas usam tabelas agregadas (rápidas). Quando requisitos mudam, reprocessa eventos brutos para criar novas agregações. Imutabilidade dos eventos permite auditoria e correção de bugs.

Apache Spark e Processamento Distribuído

13. Como você resolve problemas de data skew no Spark?

Data skew ocorre quando uma partition tem muito mais dados que outras, causando processamento lento e desperdício de recursos.

Técnica de Salting:

python

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Outras estratégias:

Broadcast Join: Se uma tabela é pequena (<10MB), broadcast para todos os executors evita shuffle
Adaptive Query Execution: Spark 3+ ajusta dinamicamente o número de partitions durante execução
Repartition: Redistribuir dados por chave diferente antes de operações pesadas

14. Qual a diferença entre transformations e actions no Spark?

Transformations: Operações lazy que definem o plano de execução mas não processam dados imediatamente. Exemplos: map(), filter(), join(), groupBy(). Retornam novos DataFrames/RDDs.

Actions: Disparam a execução do plano e retornam resultados ou efeitos colaterais. Exemplos: count(), collect(), write(), show().

Lazy Evaluation: Spark constrói um DAG (Directed Acyclic Graph) de transformations. Apenas quando uma action é chamada, o otimizador analisa o DAG completo, aplica otimizações (predicate pushdown, column pruning) e executa.

Benefício: Permite otimizações globais. Se você faz df.filter().select().filter(), Spark combina os filtros e aplica antes do select, minimizando dados processados.

15. Quando usar repartition() vs coalesce()?

repartition(): Redistribui dados uniformemente em N partitions com full shuffle. Aumenta ou diminui o número de partitions. Usa hash partitioning para distribuição equilibrada.

coalesce(): Reduz o número de partitions sem full shuffle. Move dados de partitions que serão eliminadas para partitions vizinhas. Mais eficiente que repartition para redução.

Quando usar:

repartition(): Aumentar paralelismo antes de operações pesadas, ou redistribuir por chave específica (repartition("user_id")) para otimizar joins
coalesce(): Reduzir partitions antes de escrever arquivos (evitar milhares de arquivos pequenos), ou consolidar após filtros pesados que eliminaram muitos dados

Regra prática: Para diminuir partitions, prefira coalesce (mais eficiente). Para aumentar ou redistribuir uniformemente, use repartition.

Orquestração e Gerenciamento de Pipelines

16. Compare Apache Airflow, Dagster e Prefect.

Apache Airflow: Orquestrador maduro com vasta comunidade. Define workflows como DAGs em Python. Scheduling robusto, monitoring e retry logic. Interface web completa. Curva de aprendizado íngreme e setup complexo.

Dagster: Foco em data assets e testing. Cada step produz um asset rastreável. Type system forte, desenvolvimento local facilitado. Software-defined assets permitem declarar dependências entre datasets. Melhor para engenharia de dados moderna.

Prefect: Developer-friendly com foco em simplicidade. Hybrid execution model (orquestração em cloud, execução local). Dynamic workflows mais fáceis que Airflow. Observabilidade nativa.

Escolha:

Airflow: Ecossistema maduro, integração com ferramentas legadas, equipe já familiarizada
Dagster: Novos projetos data-centric, foco em qualidade e testing
Prefect: Equipes pequenas, prototipagem rápida, workflows dinâmicos

Para fundamentos de orquestração com Airflow, veja o guia sobre Airflow fundamentals.

17. Como você lida com falhas em pipelines de produção?

Estratégias de resiliência:

Retries com Backoff Exponencial: Falhas transientes (network glitches) resolvem-se com retries. Aguardar 1s, 2s, 4s, 8s entre tentativas evita sobrecarga.

Idempotência: Pipelines idempotentes podem ser reexecutados sem efeitos colaterais. Partition overwrite garante que reprocessar não duplica dados.

Dead Letter Queues: Mensagens que falharam após múltiplos retries vão para DLQ. Permite processar mensagens válidas enquanto investiga falhas.

Alertas Granulares: Alertar apenas em falhas críticas. Retries automáticos não devem acionar alertas - apenas falhas após todos os retries.

Circuit Breakers: Se uma API externa está falhando consistentemente, parar de chamá-la temporariamente evita cascata de erros.

Monitoring: Métricas de latência, throughput e taxa de erro. Dashboards que mostram saúde do pipeline em tempo real.

18. Como você valida que um pipeline está production-ready?

Checklist de produção:

Testing: Unit tests para lógica de transformação, integration tests com dados de staging, testes de volume com dados de produção.

Monitoring: Métricas de data freshness (há quanto tempo os dados foram atualizados), data quality (% de nulos, valores fora de range), pipeline duration.

Alerting: SLAs definidos (ex: dados devem ser atualizados em até 2h). Alertas quando SLAs são violados ou quando falhas ocorrem.

Documentation: Runbooks para troubleshooting, documentação de schemas e transformações, diagrama de arquitetura.

Idempotência: Validar que reexecutar o pipeline não corrompe dados.

Disaster Recovery: Backups, capacidade de rollback, procedimentos de recuperação documentados.

Performance: Validar que o pipeline escala com crescimento de dados. Load testing com 2x, 5x, 10x o volume atual.

Plataformas de Dados em Cloud e Arquitetura Lakehouse

19. O que é uma arquitetura Lakehouse?

Lakehouse combina flexibilidade de data lakes (armazenamento barato de dados brutos em formatos abertos) com capacidades de data warehouses (ACID transactions, schema enforcement, performance de queries).

Componentes:

Storage Layer: Object storage (S3, GCS, ADLS) com formatos colunares (Parquet, ORC)
Metadata Layer: Delta Lake, Iceberg ou Hudi adicionam transações ACID, time travel, schema evolution
Processing Layer: Spark, Presto, Trino executam queries SQL diretamente no lake

Benefícios: Elimina duplicação de dados entre lake e warehouse. Dados brutos permanecem acessíveis para ML e análises exploratórias. Custo menor que warehouses proprietários. Formatos abertos evitam vendor lock-in.

Casos de uso: Empresas com grandes volumes de dados (PB+), necessidade de ML sobre dados brutos, requisitos de governança e compliance.

20. Como otimizar custos em cloud data platforms?

Storage: Usar lifecycle policies para mover dados antigos para storage classes mais baratas (S3 Glacier, GCS Nearline). Comprimir dados (Parquet com Snappy ou Zstandard). Particionar para evitar full table scans.

Compute: Auto-scaling para ajustar recursos à demanda. Usar spot instances para workloads tolerantes a interrupções. Agendar jobs batch para horários de menor custo. Separar workloads críticos (production) de exploratórios (desenvolvimento).

Data Transfer: Minimizar cross-region transfers. Usar PrivateLink/VPC endpoints para evitar charges de internet egress. Comprimir dados antes de transferir.

Query Optimization: Particionar tabelas, usar columnar formats, criar materialized views para queries frequentes. Clusters dedicados para queries pesadas evitam impacto em workloads interativos.

Monitoring: Dashboards de custo por projeto, equipe e workload. Identificar queries caras e otimizá-las.

Qualidade e Governança de Dados

21. Como você implementa data quality checks em pipelines?

Quality checks em três estágios:

1. Ingestion: Validar schema (colunas esperadas presentes, tipos corretos), detectar duplicatas, verificar completeness (% de valores não-nulos acima de threshold).

2. Transformation: Validar business rules (ex: amount >= 0, end_date > start_date), detectar outliers estatísticos (valores além de 3 desvios padrão), garantir referential integrity (foreign keys válidas).

3. Output: Validar row counts (comparar com expectativas históricas), verificar data freshness (timestamp mais recente dentro de janela aceitável), testar queries críticas de negócio.

Ferramentas: Great Expectations para testes declarativos, dbt tests para validações em transformações SQL, custom scripts para regras de negócio específicas.

Ações: Quality checks falhados devem pausar o pipeline, alertar equipe e registrar detalhes do problema. Dados com falhas vão para quarantine table para investigação.

22. O que são data contracts e por que são importantes?

Data contracts são acordos explícitos entre producers e consumers de dados sobre schema, formato, SLAs e semântica.

Componentes:

Schema: Colunas, tipos, constraints (not null, unique)
SLAs: Latência máxima, freshness esperada, disponibilidade
Semantics: Definição clara de campos (ex: "revenue" é antes ou depois de impostos?)
Ownership: Quem é responsável pelos dados, como reportar problemas

Benefícios: Previne quebras silenciosas quando schemas mudam. Consumers confiam que dados atendem especificações. Producers sabem quais mudanças requerem coordenação. Facilita evolução independente de sistemas.

Implementação: Schemas versionados (Avro, Protobuf), schema registries (Confluent Schema Registry), testes automatizados que validam contratos.

Design de Sistemas e Arquitetura

23. Projete um pipeline de real-time analytics para um e-commerce.

Requisitos: Processar eventos de cliques, visualizações de produto e compras. Dashboard mostra métricas em tempo real: usuários ativos, produtos mais vistos, revenue por minuto.

Arquitetura:

Ingestion: Frontend envia eventos para Kafka via API gateway. Kafka particiona por user_id para preservar ordem.

Stream Processing: Flink ou Spark Streaming consome Kafka, processa windowing (janelas de 1 minuto), calcula agregações (count de eventos, sum de revenue, distinct users).

Storage: Resultados agregados vão para Redis (cache para dashboard em tempo real) e TimescaleDB (histórico para análises posteriores).

Serving: API lê do Redis para latência sub-100ms. Dashboard atualiza via WebSocket.

Batch Layer: Jobs Spark noturnos processam eventos completos do dia, geram relatórios detalhados, armazenam em data warehouse para análises históricas.

Monitoring: Alertas de lag do Kafka consumer, latência de processamento, discrepâncias entre contagens em tempo real e batch.

24. Como você migraria um data warehouse legado on-premise para cloud?

Fase 1 - Assessment: Inventário completo de tabelas, jobs ETL, dependências. Identificar queries mais executadas (otimizar primeiro). Calcular volume de dados e estimar custos de cloud.

Fase 2 - Proof of Concept: Migrar subset de dados críticos. Validar performance, testar conectividade, treinar equipe em novas ferramentas.

Fase 3 - Hybrid Operation: Replicação bidirecional temporária. Novos workloads vão para cloud, legados permanecem on-premise. Migração incremental por domínio (ex: primeiro sales, depois marketing).

Fase 4 - Cutover: Desativar sistema legado após validação completa. Monitorar closely nas primeiras semanas.

Desafios: Downtime mínimo (usar change data capture para sync contínua), compatibilidade de SQL dialects (automatizar conversão onde possível), treinamento de equipe, gestão de custos de cloud.

25. Como você debugaria um dashboard que mostra números inconsistentes?

1. Reproduzir: Capturar query exata que o dashboard executa. Executar manualmente e verificar se inconsistência persiste.

2. Verificar Freshness: Checar timestamps de atualização das tabelas fonte. Possível que dados estejam stale.

3. Analisar Transformações: Seguir data lineage reverso. Validar cada step de transformação executando queries intermediárias.

4. Comparar com Ground Truth: Se possível, comparar com fonte autoritativa (ex: comparar revenue do dashboard com sistema financeiro oficial).

5. Verificar Joins: Joins incorretos podem duplicar ou perder dados. Validar contagens antes e depois de cada join.

6. Testar Lógica de Agregação: Executar agregações manualmente. Verificar filtros de data (timezone issues são comuns), deduplicação adequada.

7. Revisar Recent Changes: Checar deploys recentes de pipelines, mudanças de schema, alterações em business logic.

Ferramentas: Data diff entre versões, profiling de distribuições, query logs para comparar execuções anteriores.

Pronto para mandar bem nas entrevistas de Data Engineering?

Pratique com nossos simuladores interativos, flashcards e testes tecnicos.

Explorar Data Engineering

Preparação Efetiva para Entrevistas de Engenharia de Dados

Dominar os conceitos apresentados neste guia exige preparação hands-on e prática constante. As questões técnicas em entrevistas de engenharia de dados avaliam tanto conhecimento teórico quanto capacidade de resolver problemas reais de arquitetura e performance.

Próximos passos para sua preparação:

Configure um ambiente local com Spark, Kafka e Airflow para executar os exemplos de código
Implemente os padrões de idempotência e data quality em projetos pessoais
Estude casos de uso reais de empresas como Uber, Netflix e Airbnb sobre arquitetura de dados
Pratique design de sistemas com foco em trade-offs e justificativas de decisões arquiteturais
Aprofunde-se em otimização de queries SQL e modelagem dimensional

Para uma preparação estruturada e completa, explore o track de engenharia de dados da SharpSkill, com módulos interativos, questões práticas e simulações de entrevistas reais.

As posições de engenharia de dados em 2026 são altamente competitivas, mas a preparação adequada e o domínio dos fundamentos apresentados neste artigo posicionam candidatos para sucesso em processos seletivos das principais empresas de tecnologia.