Cientista de dados Perguntas de Entrevista & Respostas

Resposta modelo

A equipe de marketing gastava US$ 200 mil por mês em aquisição de usuários em 5 canais, sem uma visão clara do retorno por canal. Construí um modelo de atribuição multitoque usando cadeias de Markov, analisando 6 meses de dados da jornada do usuário. A análise revelou que um canal responsável por 30% do orçamento contribuía com apenas 8% das conversões, enquanto a busca orgânica estava subvalorizada em 3x. Apresentei os resultados ao CMO com visualizações claras. A equipe realocou US$ 60 mil mensais do canal de baixo desempenho, o que aumentou a taxa de conversão geral em 22% no trimestre seguinte.

Resposta modelo

Construí um modelo de segmentação de clientes que recomendava descontinuar uma faixa do programa de fidelidade. O VP de Sucesso do Cliente reagiu com força: aquela faixa tinha os defensores mais engajados da marca. Em vez de defender o modelo de forma abstrata, aprofundei a análise e percebi que o VP tinha razão em parte. Esses clientes tinham NPS alto, mas contribuição de receita baixa. Revisei a análise para incluir projeções de valor vitalício e receita de indicações geradas por defensores da marca. O modelo atualizado mostrou que a faixa valia ser mantida, mas precisava de reestruturação. Reduzimos o custo do programa em 40% e mantivemos o segmento de alto engajamento. A lição principal: modelos capturam o que você mede, e às vezes o stakeholder sabe o que você não está medindo.

Resposta modelo

Coloquei em produção um modelo de previsão de demanda para uma empresa de e-commerce que performava bem no backtesting, mas se degradou rapidamente: menos de 3 semanas após o lançamento. A causa raiz foi o desvio de dados. Os dados de treinamento cobriam períodos estáveis, mas lançamos o modelo logo antes de uma grande mudança de preços de um concorrente, que alterou os padrões de compra. Implementei um pipeline de monitoramento que acompanha em tempo real as distribuições das variáveis de entrada e das previsões do modelo. Quando o desvio ultrapassa um limite, o modelo é retreinado automaticamente com dados recentes. Também adicionei um fallback para heurísticas simples quando a confiança cai abaixo de um limite. Essa experiência me ensinou que implantar o modelo é apenas metade do trabalho. Monitoramento e degradação controlada são a outra metade.

Resposta modelo

A diretoria queria entender por que nosso mecanismo de recomendações às vezes sugeria produtos aparentemente aleatórios. Tinha 15 minutos na reunião do conselho. Em vez de explicar a filtragem colaborativa matematicamente, usei uma analogia: 'Imaginem um vendedor de livraria que lembra o que cada cliente comprou. Quando você entra, ele pensa nos clientes parecidos com você e recomenda o que essas pessoas amaram.' Depois mostrei 3 exemplos reais de usuários em que as recomendações faziam todo sentido quando se via a lógica de usuários similares. Mostrei também 2 casos de falha e expliquei que estávamos corrigindo com filtragem baseada em conteúdo para complementar a abordagem. Com base nessa apresentação, o conselho aprovou orçamento adicional para a equipe de recomendações.

Resposta modelo

Depende do contexto do problema e da assimetria no custo dos erros. Para um modelo de detecção de fraude em que os casos positivos correspondem a 0,1% dos dados, começo escolhendo a métrica de avaliação certa. Acurácia não tem significado aqui, então uso precisão-recall AUC, F1 ou uma função de custo personalizada que pondera os falsos negativos pelo custo de negócio. Do lado dos dados, experimento SMOTE para superamostragem sintética, subamostragem aleatória com métodos de ensemble (como EasyEnsemble) ou amostragem estratificada. No modelo, uso pesos de classe para penalizar a classificação incorreta da classe minoritária. Algoritmos como XGBoost lidam bem com o desequilíbrio usando scale_pós_weight. Também considero abordagens de detecção de anomalias: se a classe minoritária for suficientemente rara, tratar o problema como detecção de anomalias pode funcionar melhor do que classificação. O ponto central é avaliar sempre em um conjunto de validação que reflita a distribuição de classes do mundo real.

Resposta modelo

Viés é o erro decorrente de suposições excessivamente simplistas: um modelo linear tentando ajustar uma relação quadrática sempre errará, independentemente dos dados de treinamento. Variância é o erro decorrente da sensibilidade às flutuações dos dados de treinamento: um polinômio de alto grau se ajusta perfeitamente aos dados de treino, mas falha em dados novos. A relação entre eles: reduzir o viés tende a aumentar a variância e vice-versa. Na prática, começo com modelos simples (alto viés, baixa variância) e aumento a complexidade apenas quando as métricas de validação justificam. Técnicas de regularização (L1, L2, dropout, parada antecipada) permitem aumentar a capacidade do modelo enquanto se controla a variância. A validação cruzada é essencial para estimar onde se está no espectro viés-variância. Para ensembles: bagging reduz variância (Random Forest), enquanto boosting reduz viés (XGBoost). Escolho com base em se o modelo base está sofrendo underfitting ou overfitting.

Resposta modelo

Primeiro, defino a hipótese e a métrica principal. Para um novo fluxo de checkout, a hipótese pode ser 'o novo fluxo aumenta a taxa de conclusão de compras.' A métrica principal é a taxa de conversão, com métricas de guarda-rail como receita por sessão e tempo de carregamento da página. Em seguida, calculo o tamanho da amostra usando análise de poder estatístico: para um ganho absoluto de 2% a partir de uma linha base de 10%, com 80% de poder e 95% de confiança, preciso de aproximadamente 15 mil usuários por grupo. A randomização é feita no nível do usuário, não da sessão, para evitar experiências inconsistentes. Rodo o teste por pelo menos um ciclo de negócio completo para capturar efeitos do dia da semana. Para a análise, uso um teste z de duas proporções para a métrica principal e verifico efeitos de novidade examinando a trajetória da métrica ao longo do tempo. Também segmento os resultados por coortes principais de usuários: o novo fluxo pode ajudar novos usuários, mas prejudicar usuários avançados. Por fim, considero correções de comparações múltiplas se estiver testando várias métricas simultaneamente.

Resposta modelo

L1 (Lasso) adiciona o valor absoluto dos pesos à função de perda, enquanto L2 (Ridge) adiciona os pesos ao quadrado. A diferença prática principal: L1 leva pesos a exatamente zero, realizando seleção automática de variáveis. L2 encolhe os pesos em direção a zero, mas nunca os zera, mantendo todas as variáveis com influência reduzida. Uso L1 quando suspeito que muitas variáveis são irrelevantes e quero um modelo esparso e interpretável, o que é comum em conjuntos de dados de alta dimensionalidade como genômica ou texto. Uso L2 quando a maioria das variáveis contribui com algum sinal e quero evitar que uma única variável domine: típico em conjuntos de variáveis bem curados. Elastic Net combina os dois e é minha escolha padrão quando estou em dúvida: traz a esparsidade do L1 com a estabilidade do L2 para variáveis correlacionadas. A força da regularização (lambda) é sempre ajustada via validação cruzada.

Resposta modelo

Primeiro, resistiria à tentação de começar a modelar. Passaria os primeiros 2 a 3 dias em análise exploratória: perfilando cada coluna para taxas de ausência, distribuições, outliers e inconsistências. Documentaria tudo e apresentaria ao responsável pelos dados. Com frequência, ele consegue explicar anomalias que, de outra forma, desperdiçariam semanas de investigação. Para valores ausentes, minha abordagem depende do mecanismo: se estiverem completamente ausentes de forma aleatória, a imputação funciona (mediana para numéricos, moda para categóricos ou imputação baseada em modelo). Se o padrão de ausência não for aleatório, a própria ausência é informativa e eu a codificaria como uma variável. Configuraria verificações de validação de dados (Great Expectations ou similar) para identificar problemas de qualidade futuros na ingestão. Só depois de ter um conjunto de dados limpo e compreendido começaria a modelar, com um modelo simples para estabelecer uma linha de base antes de adicionar complexidade.

Resposta modelo

Recusaria de forma simples ou comprometeria a qualidade em silêncio? Nenhuma das duas opções. Dividiria o trabalho em camadas de valor. Até sexta-feira, consigo implantar um modelo simples de filtragem colaborativa usando interações usuário-item: não será perfeito, mas superará as sugestões aleatórias atuais. Apresentaria isso como Fase 1, com as limitações documentadas de forma clara. A Fase 2 (semanas 2 e 3) adicionaria variáveis baseadas em conteúdo e trataria o problema de cold-start para novos usuários. Descreveria qual melhoria de desempenho esperar de cada fase, com métricas estimadas. Também alertaria que forçar o modelo completo até sexta-feira significaria pular a avaliação offline e os testes A/B, o que implicaria implantar sem saber se o modelo realmente ajuda os usuários.

Resposta modelo

Reportaria imediatamente, sem esperar o deploy nem uma retrospectiva. Documentaria a preocupação com evidências mostrando a correlação de proxy (por exemplo, mapeamento de CEP para dados demográficos) e apresentaria tanto ao líder técnico quanto a um stakeholder de negócios. Em seguida, testaria o desempenho do modelo com e sem a variável. Com frequência, remover a variável de proxy tem impacto mínimo na acurácia geral, mas reduz significativamente o impacto diferenciado. Se a variável for genuinamente necessária para o desempenho, exploraria técnicas de modelagem com equidade embutida: pós-processamento por chances equalizadas, debiasing adversarial ou calibração por grupos protegidos. Recomendaria também implementar métricas de equidade como parte do pipeline de avaliação do modelo, não apenas acurácia, mas paridade demográfica e igualdade de oportunidade. O risco de negócio de implantar um modelo discriminatório (legal, reputacional e ético) supera em muito o ganho marginal de acurácia.

Resposta modelo

Levo 'não parece certo' a sério: especialistas de domínio frequentemente captam problemas que as métricas perdem. Primeiro, peço exemplos específicos de previsões que pareceram erradas e procuro padrões. Causas comuns: o modelo otimiza a métrica errada (alta acurácia, mas calibração ruim), o conjunto de teste não reflete a distribuição do mundo real, ou o modelo captura padrões estatísticos que violam a lógica de negócio. Examino as previsões do modelo nos exemplos específicos usando SHAP ou LIME para explicar previsões individuais. Se o modelo estiver tecnicamente correto, mas violar expectativas do domínio, posso precisar adicionar restrições de regras de negócio ou ajustar a função de perda para penalizar certos tipos de erro com mais peso. Também verifico vazamento de dados: uma pontuação de teste suspeitosamente alta combinada com ceticismo do negócio é um sinal clássico de vazamento.