Senior Data Scientist — Perguntas de entrevista data scientist

Como você projeta uma plataforma de experimentação que atenda múltiplas equipes de produto rodando testes simultaneamente?

O problema central é interferência: equipes rodando experimentos sobrepostos nos mesmos usuários podem contaminar os resultados umas das outras, então você precisa de um sistema de atribuição em camadas — camadas ortogonais ou um esquema de bucketing baseado em hash que permita experimentos independentes rodarem no mesmo tráfego sem colisão, além de guardrails que sinalizem quando dois experimentos tocam uma métrica de formas que poderiam interagir. Além da atribuição, a plataforma precisa de detecção automatizada de sample ratio mismatch, cálculos de poder padronizados embutidos no fluxo de lançamento, e um pipeline de resultados que ninguém consiga contornar silenciosamente espiando números brutos antes do teste terminar — o trabalho da plataforma é tornar o caminho estatisticamente correto também o mais fácil.

Um stakeholder pede para você provar que uma campanha de marketing causou um aumento de receita, e um experimento randomizado nunca foi rodado. Como você aborda isso?

Você recorre ao design quase-experimental mais próximo que os dados sustentam: difference-in-differences se houver um grupo não tratado comparável e um pré-período limpo, controle sintético se não existir um único grupo de comparação não tratado mas uma combinação ponderada de outros puder aproximá-lo, ou regression discontinuity se a campanha tiver mirado usuários acima de algum limiar. Cada um deles se apoia numa suposição — tendências paralelas, ausência de efeitos de antecipação, ausência de um confounder simultâneo — que você não consegue provar, só argumentar com diagnósticos do pré-período, e a entrega precisa incluir essa suposição explicitamente em vez de apresentar uma estimativa pontual como fato consumado.

Como você traduz uma pergunta de negócio ambígua como "por que a retenção caiu no trimestre passado" numa análise mensurável?

Comece forçando precisão sobre "retenção" e "caiu" — qual coorte, qual janela de tempo, comparado a qual baseline —, porque metade dos pedidos ambíguos se dissolve assim que a métrica é realmente definida, e muitas vezes você descobre que o stakeholder estava reagindo a um artefato do dashboard em vez de uma mudança real. Daí você decompõe a métrica (a queda está concentrada num segmento, canal, release?) antes de recorrer a ferramentas causais, porque a segmentação geralmente estreita uma pergunta aberta para uma hipótese específica e testável mais rápido do que qualquer modelo faria.

Como você constrói padrões e práticas de revisão de data science numa equipe em crescimento sem virar um gargalo?

Codifique os modos de falha que você já viu se repetir — leakage, testes subdimensionados, p-values mal interpretados, métricas que não correspondem ao custo de negócio — num checklist de revisão leve em vez de exigir que cada análise passe pessoalmente por você, porque revisão pessoal não escala além de um punhado de pessoas e cria uma fila que, sob pressão de prazo, ensina todo mundo a pulá-la. Combine isso com ferramentas compartilhadas (uma biblioteca padrão de cálculo de poder, um template para relatos de experimentos) para que a prática correta seja também o caminho de menor resistência, e reserve seu tempo pessoal de revisão para decisões com peso financeiro ou estratégico real, não análises rotineiras.

Um teste A/B diz que uma mudança ganha; uma análise observacional mais longa diz que ela prejudica a retenção. Como você reconcilia isso?

Verifique primeiro a mecânica antes de confiar em qualquer um dos números: efeitos de novidade e primazia se dissipam na janela curta de um teste, mas aparecem em dados observacionais mais longos, e uma mudança de métrica concentrada num segmento para o qual o teste não tinha poder estatístico suficiente acaba diluída no resultado agregado. Procure interferência — a mudança afetou o grupo de controle indiretamente, por meio de um recurso compartilhado, um marketplace ou um modelo de recomendação retreinado com dados dos dois braços? — porque isso quebra a suposição de independência da qual o A/B testing depende. Se a mecânica estiver correta e o conflito for real, confie no resultado randomizado para o efeito causal e no observacional para saber quem é afetado e por quê, e diga isso explicitamente em vez de escolher o número que combina com a decisão que você já queria tomar.