Middle Data Scientist — Perguntas de entrevista data scientist

Explique como você escolheria features para um modelo de churn e evitaria leakage.

Comece pelo que é conhecível no momento da previsão — uma feature calculada a partir de dados que só existem depois do resultado (como "dias desde a abertura do e-mail de cancelamento", se esse e-mail só é enviado depois de alguém já ter decidido sair) vaza o label direto para o input e dá um modelo que parece ótimo offline e falha em produção. Depois de descartar leakage, você reduz a lista com conhecimento de domínio, correlação com o target, e algo como permutation importance, e então verifica multicolinearidade entre os sobreviventes em vez de confiar num único score de importância isolado.

Como funciona a cross-validation k-fold, e por que um único split train/test não basta?

Você divide os dados em k folds, treina em k-1 deles e valida no fold restante, depois roda por todas as k combinações e tira a média dos resultados. Um único split dá uma estimativa ruidosa que depende muito de quais linhas caíram no conjunto de teste — um split sortudo ou azarado pode fazer um modelo medíocre parecer ótimo ou um bom modelo parecer ruim. A cross-validation troca mais poder computacional por uma estimativa muito mais estável de como o modelo generaliza, e é isso que você usa para comparar modelos honestamente antes de escolher um.

Como você projetaria um teste A/B para uma mudança que suspeita ter um efeito pequeno numa página de baixo tráfego?

Um efeito esperado pequeno com baixo tráfego é a pior combinação para poder estatístico, então o primeiro passo é verificar pela matemática se o teste é sequer viável num prazo razoável, em vez de projetá-lo e torcer. Se não for, as opções honestas são ampliar a população elegível, estender a duração, mudar para uma métrica mais sensível (uma métrica proxy contínua em vez de uma conversão binária), ou aceitar um efeito mínimo detectável maior e deixar explícito que efeitos reais menores vão passar despercebidos.

Quando você usaria uma window function em vez de uma subquery para calcular um total acumulado em SQL?

Uma window function como SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) calcula o total acumulado numa única passada sem colapsar linhas, e a maioria dos otimizadores de consulta a otimiza muito melhor do que a subquery correlacionada equivalente, que reescaneia linhas anteriores para cada linha de saída. A abordagem de subquery ainda aparece em codebases antigas e como a resposta "ingênua" em entrevistas — reconhecer quando substituí-la é, por si só, um sinal de maturidade em SQL.

Você mostra a um product manager um modelo com 92% de acurácia e ele quer lançar. O que você verifica antes de concordar?

Primeiro, o balanço de classes — se 92% dos dados são da classe majoritária, um modelo que sempre prevê a classe majoritária também atinge 92% de acurácia sendo inútil, então precision, recall e uma matriz de confusão por classe importam mais que a acurácia sozinha. Segundo, se a métrica corresponde ao custo de negócio real: para detecção de fraude um falso negativo é caro e um falso positivo é um incômodo menor, então você ajustaria o limiar em direção ao recall mesmo que custe alguma acurácia bruta, e diria isso explicitamente antes de alguém lançar.