Entrevistas de engenharia de dados não são entrevistas de analytics com um pouco de Python parafusado em cima. A banca está tentando descobrir se dá para confiar em você com o pipeline que alimenta todo dashboard, modelo e relatório financeiro da empresa, e se você perceberia esse pipeline produzindo números errados em silêncio. Por isso as perguntas se concentram em design, correção e operação, e não em algoritmos espertos. Estas são as que realmente aparecem, o que cada uma está sondando e como se monta uma boa resposta.
Esses são os padrões da vaga em geral; se você quer a lista curta de uma entrevista específica, cole o anúncio real da vaga no Question Predictor gratuito e receba as vinte perguntas com maior chance de cair naquele processo.
O que as entrevistas de engenheiro de dados realmente testam?
Quatro coisas: se você consegue projetar um pipeline que sobrevive ao contato com dados sujos vindos de cima, se o seu SQL vai além de um join e um GROUP BY, se você modela os dados de um jeito que os analistas não precisem fazer engenharia reversa das suas intenções, e se você trata correção como um problema de engenharia em vez de uma esperança. Conhecer ferramentas importa muito menos que julgamento.
Os pesos mudam conforme a empresa: times de produto centrados em warehouse puxam para modelagem e SQL, times de plataforma puxam para throughput e custo, startups querem saber se você consegue subir a coisa toda sozinho e mantê-la barata. A geração de código tornou trivial escrever uma transformação, então as bancas agora gastam o tempo nas decisões que um gerador não toma: por que essa granularidade, por que essa chave de partição, o que acontece num replay.
Como é o processo de entrevista para engenheiro de dados?
Um processo típico tem de quatro a seis etapas ao longo de duas a três semanas: triagem com recrutador, uma prova de SQL, uma rodada de design de pipeline, uma rodada de modelagem e uma conversa comportamental. Processos para sênior incluem uma rodada mais funda de sistemas, sobre throughput, custo e falhas. Desafios para casa são menos comuns do que já foram, mas ainda aparecem em empresas menores.
- Triagem com recrutador (20 a 30 minutos). Stack, escala, faixa salarial. Descreva o seu maior pipeline em duas frases: volume, latência, quem consome.
- Prova de SQL (45 a 60 minutos). SQL ao vivo num editor compartilhado, com window functions como filtro de sempre.
- Rodada de design de pipeline (60 minutos). Você recebe uma origem, um consumidor e uma expectativa de frescor, e então projeta o caminho entre eles e defende a escolha.
- Rodada de modelagem de dados (45 a 60 minutos). Design de schema para um negócio descrito, normalmente com uma pegadinha sobre histórico ou dados atrasados.
- Gerente de contratação ou comportamental. Senso de dono e stakeholders. Perguntas sobre plantão também costumam cair aqui.
Se você já sabe qual é a empresa, os bancos de perguntas por empresa dão uma leitura mais rápida do estilo da casa do que vasculhar fóruns.
Que perguntas de design de pipeline aparecem numa entrevista de engenheiro de dados?
As perguntas de design te entregam uma origem, um destino e uma restrição, e observam como você raciocina. A banca quer que você pergunte sobre volume, frescor, estabilidade de schema e quem grita quando quebra antes de desenhar uma única caixa. Bons candidatos dimensionam o problema em voz alta e depois projetam a coisa mais simples que atende ao requisito e pode ser reexecutada com segurança.
Me explique um pipeline que você construiu, de ponta a ponta. O que isso sonda: se você já operou alguma coisa, ou só contribuiu com uma task na DAG de outra pessoa. Dê o formato em ordem (origem, ingestão, armazenamento, transformação, entrega) e depois os números: linhas por dia, latência, custo, quem dependia disso. Termine com o que deu errado uma vez e o que você mudou, porque especificidade aqui compra credibilidade para o resto do processo.
Projete um pipeline que ingere cerca de 500GB de eventos de clickstream por dia e deixa tudo pronto para os analistas às 9h. O que isso sonda: dimensionamento, particionamento e a distância entre chegada e prontidão. Esclareça primeiro o requisito de frescor, porque diário até as 9h é um problema de batch, não de streaming. Aterrisse os eventos crus em object storage particionado por data e hora, transforme numa tabela modelada e mantenha a camada crua imutável para poder dar replay. Fale de tamanho de arquivo; milhares de arquivinhos são o tiro no pé clássico.
Como você lida com eventos atrasados ou fora de ordem? O que isso sonda: se você entende que os dados não chegam com educação. Separe event time de ingestion time, defina uma janela de atraso que você aceita e reprocesse as partições afetadas em vez de remendar linhas individuais.
Batch ou streaming: como responder à pergunta de arquitetura?
Responda a partir dos requisitos, não da preferência. Streaming justifica o custo quando alguma coisa age sobre o dado em segundos: checagem de fraude, estoque ao vivo, alertas. Batch é o certo para quase tudo que alimenta um dashboard ou um relatório mensal. A armadilha aqui é o entusiasmo, porque um candidato que puxa uma stack de streaming para gerar um relatório diário está otimizando o próprio interesse, não o negócio.
Quando você escolheria streaming em vez de batch, e o que isso te custa? O que isso sonda: julgamento sobre carga operacional. Cite os custos com honestidade: teste mais difícil, backfill mais difícil, estado para gerenciar, mais superfície de plantão, um time que agora precisa entender watermarks. Depois dê a condição que justifica tudo isso, que é um consumidor agindo sobre o dado mais rápido do que a sua cadência de batch consegue entregar.
Qual a diferença entre event time e processing time? O que isso sonda: fundamentos de streaming. Event time é quando a coisa aconteceu; processing time é quando o seu sistema viu. Agregados com janela em processing time derivam e acabam discordando em silêncio da fonte da verdade.
Como você conseguiria semântica exactly-once num pipeline de streaming? O que isso sonda: se você repete marketing ou explica mecânica. De ponta a ponta, você constrói entrega at-least-once mais escritas idempotentes, usando uma chave determinística para que um replay sobrescreva em vez de duplicar. Sinks transacionais e offsets commitados junto com a escrita são o que torna isso real.
Que perguntas de modelagem de dados você deve esperar?
As rodadas de modelagem testam se você projeta para as perguntas que o negócio vai fazer, e não para os dados que você por acaso tem. Espere um negócio descrito, um pedido de schema e então uma complicação: histórico, hierarquia, ou um atributo que muda. Modelagem dimensional ainda é a língua comum, mesmo em times que dão nomes mais modernos às suas camadas.
Explique star schema versus uma tabela única, larga e desnormalizada. Qual você construiria? O que isso sonda: raciocínio sobre granularidade e mudança. Cubra simplicidade de consulta e custo de armazenamento de um lado, custo de join e atributos duplicados do outro, e então escolha com base na engine e nos consumidores. Warehouses colunares deixaram as tabelas largas mais baratas do que já foram, mas o star ainda ganha quando as dimensões mudam de forma independente.
Como você modela uma dimensão de mudança lenta (SCD)? O que isso sonda: histórico. Tipo 1 sobrescreve e perde o passado; tipo 2 adiciona uma linha por versão, com datas de validade e uma flag de atual, que é o que a maioria dos times de analytics precisa para relatório point-in-time.
Como você particionaria uma tabela grande, e o que dá errado? O que isso sonda: design físico. Particione pela coluna que os consumidores filtram, normalmente uma data, fique de olho no tamanho da partição e mantenha o particionamento separado de clustering ou sort keys. A falha clássica é particionar por algo de alta cardinalidade, como user ID, gerando milhões de arquivinhos e consultas mais lentas do que sem partição nenhuma.
Quão fundo vai a rodada de SQL para engenheiros de dados?
Mais fundo que nas rodadas de analista. Joins e agregação são pressupostos; o filtro são window functions, deduplicação e raciocinar sobre um plano de execução. A maioria das provas roda três ou quatro perguntas cada vez mais cruéis, e a última normalmente precisa de uma window function ou de um self-join. Explique a abordagem antes de digitar, porque o raciocínio pesa mais na nota do que a sintaxe.
Encontre o segundo maior valor por grupo, por exemplo a segunda pessoa mais bem paga de cada departamento. O que isso sonda: fluência em window functions. Recorra a DENSE_RANK ou ROW_NUMBER numa subconsulta e filtre pelo rank do lado de fora, e diga qual você escolheu e por quê, porque empates se comportam de forma diferente.
Deduplique uma tabela para que só a linha mais recente por chave sobreviva. O que isso sonda: a tarefa real mais comum do trabalho. ROW_NUMBER particionado pela chave, ordenado por timestamp decrescente, filtrado em 1. Depois pergunte o que desempata quando duas linhas têm o mesmo timestamp, porque em dados reais isso vai acontecer.
Uma consulta sobre uma tabela particionada ficou lenta. Como você diagnostica? O que isso sonda: depuração guiada por evidência. Leia o plano, verifique se o partition pruning realmente aconteceu (uma função em volta da coluna de partição costuma matá-lo), procure skew, cheque estatísticas desatualizadas, cheque se o layout de arquivos degradou para muitos arquivos pequenos.
Que perguntas sobre orquestração os entrevistadores fazem?
As perguntas de orquestração testam se os seus pipelines podem ser reexecutados sem medo. A palavra para ter na ponta da língua é idempotência: rodar a mesma task para a mesma data lógica duas vezes deve produzir o mesmo resultado, não o dobro. Espere perguntas seguintes sobre dependências, retries, alertas e backfill de um ano de histórico sem derreter o cluster nem o orçamento.
Como você torna um job agendado idempotente e seguro para backfill? O que isso sonda: maturidade operacional. Parametrize cada task por uma data lógica em vez de por "agora", escreva numa partição chaveada por essa data e substitua essa partição na reexecução em vez de fazer append.
Como você lida com dependências entre pipelines de times diferentes? O que isso sonda: se você já trabalhou numa organização de verdade. Prefira um sinal explícito (um dataset marcado como completo, um evento, um sensor com timeout) a um offset de agendamento baseado em esperança.
Como os entrevistadores testam qualidade de dados?
Eles descrevem um número errado e observam você investigar. O sinal que querem é que você trate correção como algo testável: contagem de linhas, taxa de nulos, unicidade das chaves, integridade referencial, checagem de distribuição contra ontem, frescor. Candidatos que dizem que dariam uma olhada no dashboard perdem a rodada; candidatos que descrevem asserções dentro do pipeline capazes de bloquear uma publicação ruim ganham.
Como você sabe que um pipeline produziu dados corretos? O que isso sonda: se a qualidade é projetada desde o início ou checada depois. Coloque testes dentro do próprio pipeline: chaves únicas, restrições de não nulo, faixas aceitas, variação na contagem de linhas em relação à execução anterior.
Um stakeholder diz que o número de receita de ontem está errado. Me conte a investigação. O que isso sonda: depuração estruturada mais comunicação. Defina o que "errado" significa (contra qual fonte, por quanto), depois suba camada por camada, comparando contagens e totais em cada fronteira para isolar onde o número diverge.
Uma fonte upstream muda o tipo de uma coluna sem avisar. Como você lida com isso? O que isso sonda: lidar com coisas fora do seu controle. Falhe rápido na ingestão com uma checagem de schema em vez de converter em silêncio, coloque o lote ruim em quarentena e corrija para a frente com um replay.
Que perguntas comportamentais engenheiros de dados recebem?
As rodadas comportamentais para vagas de dados focam em confiança e stakeholders. Espere uma pergunta sobre um incidente em que os seus dados estavam errados, e outra sobre um pedido ao qual você resistiu. Responda com uma estrutura enxuta: a situação, o que você decidiu, o trade-off que aceitou e a mudança duradoura que veio depois.
Me fale de uma vez em que os seus dados estavam errados e outra pessoa percebeu primeiro. O que isso sonda: senso de dono e honestidade. Não minimize. Diga o que quebrou, por quanto tempo ficou errado, quem tomou decisão em cima daquilo, como você comunicou, e a checagem que você adicionou para que não volte a acontecer em silêncio.
Me fale de um pedido que você recusou, ou negociou para baixo. O que isso sonda: se você consegue proteger uma plataforma de cem pedidos avulsos. Mostre que entendeu a necessidade por trás, ofereceu um caminho mais barato até ela e deixou visível o custo do pedido original, em vez de simplesmente dizer não e virar o time que todo mundo contorna.
Que erros afundam candidatos a engenheiro de dados?
Quase sempre falhas de julgamento, e não lacunas de conhecimento. As bancas raramente reprovam alguém por não conhecer uma ferramenta específica; elas reprovam quem projeta antes de perguntar, quem não consegue reexecutar o próprio pipeline, ou quem trata um número errado como problema dos outros. Estes são os padrões que encerram rodadas.
- Projetar antes de perguntar. Volume, frescor, estabilidade de schema e consumidores precisam estar definidos antes de você desenhar qualquer coisa. Começar por um nome de ferramenta perde a rodada de design.
- Citar ferramentas em vez de mecânica. Dizer que usaria uma engine específica não explica nada. Diga o que o job faz, como ele particiona, onde acontece o shuffle, quanto custa.
- Ignorar replay e backfill. Um design que não pode ser reexecutado com segurança para uma data passada não é um design de produção, e entrevistadores sênior checam isso de propósito.
- Tratar qualidade como trabalho dos outros. Se a sua resposta para um número errado é que o analista deveria ter pego, a rodada acabou.
- SQL que para nos joins. Window functions são o filtro padrão hoje, e não dominá-las passa a impressão de pouca profundidade, por melhores que tenham sido as suas respostas de arquitetura.
Como se preparar para uma entrevista de engenheiro de dados?
Ensaie um pipeline que você conhece de cor, com números reais anexados, porque ele vai ancorar metade do processo. Treine window functions e deduplicação até virarem memória muscular. Pratique um design em voz alta contra o relógio, já que o formato pune quem consegue pensar mas não consegue narrar. Prepare duas histórias de incidente e uma de stakeholder.
Antes do processo em si, cole o anúncio real da vaga no Question Predictor gratuito e trabalhe as vinte perguntas que ele aponta para aquela vaga específica, já que um time de plataforma de lakehouse e um time de analytics engineering vão te perguntar coisas bem diferentes.
Para as rodadas ao vivo, o GhostPilot é um copiloto de entrevista em tempo real: um painel lateral no Chrome e um app opcional de desktop para Windows que transcrevem a chamada, pegam a pergunta assim que ela cai e têm uma resposta estruturada pronta uns dois segundos depois. Ele ajuda mais nas perguntas com armadilha embutida, como um enunciado de design que quer, sem dizer, uma estratégia de replay. É um roteiro, não um script, e as especificidades continuam vindo do seu próprio trabalho. O plano gratuito te dá 10 minutos de entrevista ao vivo por semana, sem precisar de cartão.
FAQ de entrevista para engenheiro de dados
Por quanto tempo devo me preparar para uma entrevista de engenheiro de dados? Duas a três semanas servem para a maioria dos candidatos de nível pleno: uma semana em SQL e modelagem, uma semana praticando design em voz alta, alguns dias nas histórias. Analistas migrando para engenharia devem planejar mais tempo, principalmente em design de pipeline.
Entrevistas de engenheiro de dados ainda incluem perguntas de algoritmos? Algumas empresas grandes mantêm uma rodada de algoritmos, normalmente de fácil a médio. A maioria dos times trocou isso por SQL e um exercício prático em Python de parsing ou transformação. Não deixe a maratona de algoritmos espremer a modelagem.
Qual rodada pesa mais? Design de pipeline, para candidatos pleno e sênior, porque testa julgamento, comunicação e profundidade de uma vez só. Para vagas júnior, a prova de SQL é o portão de verdade, e é onde acontece a maioria das reprovações.
Devo admitir quando não usei uma ferramenta que eles citaram? Sim. "Nunca rodei isso em produção, mas é assim que eu pensaria sobre o problema e o que eu checaria primeiro" ganha de blefar, e entrevistadores de dados são especialmente bons em detectar enrolação, porque passam o dia encontrando coisas erradas.