Perguntas de Entrevista para Data Engineer: SQL, Pipelines e Confiabilidade Sob Pressão

O processo de entrevista para esse cargo é construído em torno de uma preocupação central: você consegue mover e transformar dados corretamente em escala sem que ninguém precise supervisioná-lo. Isso se manifesta em quatro áreas de habilidade conectadas: SQL e modelagem de dados, design de pipeline em padrões ETL e ELT, confiabilidade em caso de falhas, e o discernimento para comunicar trade-offs para pessoas que não escrevem código.

A maioria dos processos mistura uma rodada de SQL prática, uma rodada de design de sistema focada em um pipeline ou plataforma de dados, e uma rodada comportamental que sonda como você lida com dados corrompidos, requisitos ausentes e desacordos com cientistas de dados ou analistas. Algumas empresas também fazem um exercício para fazer em casa, onde você constrói um pequeno pipeline a partir de um conjunto de dados bruto, que testa as mesmas habilidades sem uma audiência ao vivo.

Os entrevistadores não estão apenas avaliando se sua consulta retorna as linhas corretas. Eles estão ouvindo como você narra seu raciocínio: por que você escolheu uma função de janela em vez de uma auto-junção, por que escolheu uma carga incremental em vez de uma atualização completa, por que você alertaria sobre desvio de contagem de linhas em vez de apenas contar nulos. Um candidato que murmura uma resposta correta geralmente perde para alguém que explica uma resposta ligeiramente mais áspera com clareza.

Antes da sua entrevista, crie uma lista curta de pipelines, tabelas ou incidentes do seu próprio trabalho que você possa descrever em duas ou três sentenças. Você vai recorrer a elas constantemente nas rodadas de SQL, design e comportamentais.

SQL ainda é o portão mais comum em entrevistas de data engineering, mesmo em empresas que rodam principalmente em Spark ou dbt. Espere prompts como: escrever uma consulta que retorna o pedido mais recente de cada cliente, encontrar lacunas em uma sequência de datas por conta, calcular um total móvel de sete dias de receita diária, ou desduplicar linhas sem perder a versão mais recente.

Funções de janela surgem constantemente. ROW_NUMBER() com uma cláusula PARTITION BY é a ferramenta padrão para problemas "registro mais recente por chave"; LAG() e LEAD() lidam com gap-and-island e questões de detecção de mudanças; SUM() OVER uma janela ordenada trata totais em execução sem uma auto-junção. Os entrevistadores também querem que você raciocine sobre um plano de consulta em voz alta: qual ordem de junção o otimizador poderia escolher, onde um índice ajudaria, e quando uma consulta é lenta por causa de um filtro de partição ausente em vez de uma junção ruim.

As perguntas de modelagem de dados testam um músculo diferente: design de esquema sob restrições conflitantes. Um prompt comum é projetar um esquema em estrela para um conjunto de dados de e-commerce ou assinatura, com tabelas de fatos para pedidos ou eventos e tabelas de dimensão para clientes, produtos e tempo. Esteja pronto para explicar dimensões que mudam lentamente: quando uma atualização Tipo 1 (sobrescrever) é aceitável versus quando você precisa do Tipo 2 (nova linha, datas efetivas) para preservar o histórico para uma métrica como "segmento de cliente no momento da compra".

Você também deve ser capaz de justificar trade-offs de normalização. Sistemas OLTP favorecem tabelas normalizadas para proteger a consistência de escrita; data warehouses de análise frequentemente desnormalizam deliberadamente para que uma ferramenta de BI possa consultar uma tabela larga em vez de cinco junções. Nomear esse trade-off, em vez de tratar um estilo como universalmente correto, é o que diferencia uma resposta forte de uma resposta de livro didático.

As perguntas de design de pipeline pedem para você esboçar como dados brutos se tornam uma tabela confiável. Um prompt típico: projete um pipeline que ingere eventos de clickstream e produz uma tabela de usuários ativos diários que a equipe de produto pode consultar todas as manhãs. Uma resposta forte começa com a fonte, não a ferramenta: de onde os dados originam, com que frequência chegam, qual é a latência aceitável, e o que acontece se um lote estiver atrasado ou um fluxo cair.

Espere comparar explicitamente ETL e ELT. Em ETL, você transforma dados antes de carregá-los no warehouse, o que é adequado para volumes menores ou necessidades rigorosas de conformidade. Em ELT, você carrega dados brutos primeiro e os transforma dentro do warehouse com uma ferramenta como dbt, que agora é o padrão mais comum porque computação em warehouse é barata e mantém histórico bruto para reprocessamento. Seja capaz de explicar por que escolheria um em detrimento do outro para uma determinada fonte de dados.

As perguntas de orquestração testam se você pensa sobre falhas, não apenas sobre o caminho feliz. Os entrevistadores querem ouvir sobre DAGs em uma ferramenta como Airflow ou Dagster, tentativas no nível de tarefas, backfills para um esquema que mudou no meio do histórico, e cargas incrementais que processam apenas linhas novas ou alteradas em vez de reprocessar uma tabela inteira a cada execução. Idempotência é um acompanhamento favorito: se uma tarefa falhar no meio do caminho e for reexecutada, ela produzirá linhas duplicadas ou o mesmo resultado correto?

As perguntas específicas de streaming surgem com mais frequência em empresas com requisitos em tempo real. Você pode ser convidado a comparar um pipeline de streaming baseado em Kafka com uma abordagem de micro-lote, ou explicar exatamente uma vez versus semântica de entrega pelo menos uma vez e qual estratégia de desduplicação você usaria a jusante quando um sistema apenas garante pelo menos uma vez.

As perguntas de confiabilidade em entrevistas de data engineer geralmente começam com um cenário: um dashboard mostra receita zero esta manhã, me mostre como você a depuraria. Uma boa resposta funciona para trás através do pipeline em ordem em vez de adivinhar aleatoriamente. Verifique se o sistema de origem realmente produziu dados, verifique os logs da tarefa de ingestão e contagens de linhas, verifique a camada de transformação para uma execução com falha ou silenciosamente ignorada, e verifique se o próprio dashboard está apontado para uma tabela ou cache desatualizado.

As verificações de qualidade de dados são um tópico frequente por si só. Os entrevistadores querem detalhes: verificações de taxa nula em campos obrigatórios, detecção de anomalias de contagem de linhas contra uma linha de base histórica, verificações de atualização que alertam quando uma tabela não foi atualizada dentro de sua janela esperada, e verificações referenciais que detectam chaves estrangeiras órfãs após uma mudança de esquema upstream. Ferramentas como testes dbt ou Great Expectations frequentemente surgem, mas nomear uma ferramenta importa menos do que explicar o que você realmente verificaria e por que essa verificação captura o modo de falha que você se importa.

Você também deve esperar perguntas sobre SLAs e SLOs para atualização de dados, e como você projetaria alertas para que a pessoa certa fosse contatada para um problema real sem sobrecarregar a equipe com ruído de variação esperada. Fale sobre como você definiria limites, rotearia alertas por severidade e evitaria um alerta que dispara todos os dias e é ignorado.

Um thread comportamental relacionado é o pós-incidente: descreva um incidente onde dados ruins chegaram a um relatório ou modelo antes de alguém perceber. Os entrevistadores estão ouvindo propriedade e mudança de processo, não culpa. Uma resposta forte nomeia a causa raiz, a correção imediata e a salvaguarda específica que você adicionou depois, como uma nova verificação de validação ou uma mudança em como backfills são revisados.

As perguntas comportamentais para data engineers se concentram menos em heroísmo individual e mais em como você lida com demandas concorrentes de pessoas que dependem dos seus pipelines. Os prompts comuns incluem: conte-me sobre uma época em que uma parte interessada precisava de dados mais rápido do que seu pipeline poderia entregar; conte-me sobre um desacordo com um cientista de dados ou analista sobre um esquema ou uma definição de métrica; conte-me sobre uma época em que você encontrou um erro em dados de produção depois que já tinha sido usado em um relatório.

Use STAR, mas mantenha a seção de ação específica para trabalho com dados. Para a história "dados já usados em um relatório ruim", explique como você descobriu o erro, quem você contou e com que rapidez, como você corrigiu os números downstream, e qual validação você adicionou para que a mesma classe de erro não pudesse escorregar novamente. Os entrevistadores querem ver que você trata incidentes de dados da maneira que um engenheiro de software trata uma interrupção de produção, não como uma inconveniência menor.

Para desacordos de esquema ou métrica, mostre que você pode manter uma posição técnica enquanto ainda alcança uma decisão com a qual a equipe possa conviver. Explique o trade-off que você estava defendendo, como desempenho de consulta versus custo de armazenamento, ou um esquema mais rigoroso versus onboarding mais rápido de uma nova fonte de dados, e como você o resolveu sem simplesmente substituir a outra pessoa.

As perguntas de priorização também são comuns: como você decide entre corrigir um pipeline instável, construir uma nova fonte de dados pela qual uma parte interessada está esperando, e pagar a dívida técnica em um modelo antigo. Uma resposta credível pesa o impacto nos negócios, o raio de explosão se o pipeline instável falhar novamente, e quanto tempo a equipe ainda pode tolerar a dívida antes que desacelere cada mudança futura.

Essas perguntas são mais fáceis de responder no papel do que em voz alta. Explicar uma função de janela, um design de pipeline ou um pós-incidente em sentenças faladas claras é uma habilidade diferente de escrever o SQL correto ou desenhar o DAG correto, e os entrevistadores avaliam a explicação tanto quanto a resposta.

Pratique narrar soluções SQL antes de tocar em um teclado: indique a abordagem, nomeie a função de janela ou estratégia de junção que você usará, depois escreva a consulta. Para prompts de design de pipeline, pratique falar através de fonte, requisitos de latência, lógica de transformação e tratamento de falhas nessa ordem todas as vezes, para que a estrutura se torne automática sob pressão. Para histórias comportamentais, ensaie até que o detalhe técnico permaneça específico sem se transformar em um monólogo.

Grave você mesmo respondendo algumas dessas perguntas e escute novamente para palavras de preenchimento, configuração divagante antes de chegar ao ponto, ou etapas puladas em um passeio por pipeline. SayNow AI pode ajudá-lo a ensaiar perguntas de entrevista para data engineer em voz alta, com feedback sobre clareza e ritmo para que seu raciocínio técnico venha com tanta confiança quanto lê na página.