Como simular uma entrevista de analista de dados

As entrevistas de analista de dados têm estrutura previsível e, mesmo assim, pegam candidatos bem preparados de surpresa, porque a preparação costuma acontecer em silêncio, enquanto a entrevista acontece em voz alta. Esta seção apresenta a simulação que fecha essa lacuna. Construa-a a partir das três rodadas presentes em quase toda entrevista de analista.

Primeiro, um exercício de SQL ao vivo: de 20 a 30 minutos sobre um schema realista. Segundo, um case de métricas: um número se moveu, e você precisa raciocinar sobre o motivo. Terceiro, comportamental: histórias sobre stakeholders, um momento em que sua análise estava errada, um prazo que atrasou. Faça as três de uma vez quando possível, porque resistência também faz parte da entrevista real.

Dê a cada parte um limite de tempo rígido e fale cada resposta em voz alta como se o entrevistador estivesse presente, ou pratique contra um entrevistador de IA; a página de entrevista simulada explica como configurar isso com perguntas específicas da vaga.

Escolha um schema com três ou quatro tabelas relacionadas, pedidos, usuários, sessões, pagamentos, e avance por perguntas de dificuldade crescente: uma agregação com filtro, um join com group by, e depois uma pergunta de função de janela como um total acumulado, um rank dentro de um grupo, ou uma variação mês a mês. Funções de janela, self-joins e o tratamento de NULL são exatamente onde entrevistas reais separam os candidatos.

Narre o tempo todo: qual é a granularidade de cada tabela, por que você faz o join por essas chaves, onde poderia haver contagem duplicada. Entrevistadores avaliam essa narração, e é exatamente isso que a prática silenciosa nunca desenvolve. Quando uma query falha, faça o debug em voz alta também; se recuperar com limpeza soa melhor do que acertar em silêncio.

Termine a rodada explicando sua query final de volta em linguagem simples, uma frase por cláusula. Se essa explicação ficar confusa, a versão na entrevista também vai ficar.

A rodada de case tem um formato padrão: uma métrica se moveu, diagnostique-a. Ensaie uma estrutura fixa. Primeiro defina a métrica com precisão, incluindo seu denominador. Depois segmente: por plataforma, região, coorte de usuários, janela de tempo. Em seguida, formule hipóteses por categorias, problemas no pipeline de dados, mudanças de produto, eventos externos, mudança de mix, e diga qual query ou gráfico testaria cada uma. Encerre explicando o que você faria a seguir, não só o que aconteceu.

Um exercício concreto: uma analista se preparando para uma vaga de e-commerce se dá o cenário de que a conversão semanal caiu 8 por cento, trabalha a estrutura em voz alta por 15 minutos, e só depois verifica se ancorou o denominador antes de levantar hipóteses. A maioria das primeiras tentativas pula a etapa de definição, e é exatamente esse hábito que a simulação existe para corrigir.

Mais enunciados de case para usar como fonte estão reunidos no hub de bancos de perguntas.

Uma única simulação muda pouco; uma cadência muda o resultado. Duas ou três sessões por semana nas duas semanas antes das entrevistas formam um ritmo viável, cada uma terminando com feedback escrito: uma coisa que funcionou, uma coisa a corrigir, uma pergunta que travou você. Repita as perguntas que travaram você no início da sessão seguinte, já que a repetição espaçada nos seus pontos fracos reais supera sempre perguntas novas.

Varie também a pressão do entrevistador. Deixe que perguntas de acompanhamento te interrompam, deixe que suas suposições sejam contestadas, e pratique dizer com clareza não sei, seguido de como você descobriria. Como é uma sessão com um entrevistador de IA do início ao fim, e como o feedback é gerado depois, está descrito no hub de entrevistas simuladas.