Como Fazer um Simulado de Entrevista para Cientista de Dados

Os processos de entrevista para cientista de dados variam mais de empresa para empresa do que os de analista, e tentar se preparar para toda combinação possível é a forma mais garantida de chegar exausto à rodada presencial final. Esta seção reduz o escopo às quatro etapas que cobrem a maioria dos processos, para que seu tempo de simulado reflita a distribuição real.

As quatro são: uma conversa sobre estatística e machine learning, um estudo de caso sobre experimento ou métricas, uma etapa de programação em SQL e, frequentemente, Python, e uma análise aprofundada de um projeto que você conduziu. Vagas com foco forte em análise de produto dão mais peso à etapa de estudo de caso; vagas com foco forte em machine learning dão mais peso a perguntas de modelagem e, às vezes, incluem uma conversa sobre design de sistemas de ML. Leia a descrição da vaga e distribua o peso do seu simulado da mesma forma.

Treine as etapas separadamente no início e depois, na semana anterior às entrevistas, treine tudo como um processo único; a página de simulado de entrevista explica como fazer sessões cronometradas com um entrevistador de IA que faz perguntas de aprofundamento.

O erro mais comum aqui não é falta de conhecimento, e sim explicar mal algo que você sabe quando está sendo observado. Treine em voz alta o conjunto padrão de perguntas, cada uma em dois níveis de profundidade: uma frase em linguagem simples que um product manager conseguiria acompanhar, seguida da versão técnica com as premissas explicitadas.

• O que é e o que não é um valor-p, e o que o poder estatístico proporciona.
• O equilíbrio entre viés e variância, e como a regularização negocia entre os dois.
• Quando a precisão importa mais do que o recall, com um exemplo concreto.
• Por que um modelo com boas métricas offline ainda pode falhar em produção.
• Overfitting: como detectar e o que mudar quando ele é encontrado.

Esse treino em dois níveis importa porque entrevistadores de verdade costumam fazer a mesma pergunta das duas formas, e alternar entre os níveis com fluidez é o que transmite senioridade.

Na etapa de estudo de caso, você recebe uma mudança de produto e precisa desenhar o teste. Treine uma estrutura fixa: escolha a métrica de sucesso e seu denominador, defina a unidade de randomização, aponte as métricas de proteção, dimensione o teste de forma aproximada levando o poder estatístico em conta, e enuncie a regra de decisão antes mesmo de os dados chegarem. Depois, cite as armadilhas clássicas: espiar os dados cedo demais, unidades de randomização incompatíveis, efeitos de novidade e interferência entre variantes.

Um exemplo concreto: uma cientista de dados se preparando para uma vaga em um marketplace se dá 15 minutos para decidir se um novo algoritmo de ranqueamento deve ser lançado, percorre a estrutura em voz alta e, no final, verifica uma única coisa: se a unidade de randomização escolhida resiste à interação entre compradores e vendedores. Essa única verificação é o que decide o caso em um marketplace, e o treino é o que torna isso automático.

Mais enunciados de casos e bancos de perguntas por função estão reunidos no hub de bancos de perguntas.

Um simulado sem feedback escrito se apaga da memória em um dia. Termine cada sessão com três linhas: o que funcionou, o que travou e a pergunta que você quer tentar de novo na próxima vez. Comece a próxima sessão por essa pergunta. Ao longo de cinco ou seis sessões, isso converge para seus pontos fracos reais, que é exatamente o sentido de fazer simulados em vez de apenas ler.

Para a análise aprofundada de projeto, treine um mesmo projeto em três profundidades: um resumo de 2 minutos, uma explicação de 10 minutos e um interrogatório de 30 minutos em que cada escolha é questionada. Entrevistadores continuam perguntando até encontrar o limite da sua real responsabilidade; saber onde esse limite está antes deles mantém a etapa tranquila. Como são as sessões completas e o feedback gerado automaticamente é explicado no hub de simulados de entrevista.