Senior Data Scientist — Preguntas de entrevista data scientist

¿Cómo diseñas una plataforma de experimentación que sirva a múltiples equipos de producto corriendo tests simultáneamente?

El problema central es la interferencia: equipos corriendo experimentos superpuestos sobre los mismos usuarios pueden contaminar los resultados entre sí, así que necesitas un sistema de asignación en capas — capas ortogonales o un esquema de bucketing basado en hash que permita que experimentos independientes corran sobre el mismo tráfico sin colisión, más guardrails que alerten cuando dos experimentos tocan una métrica de formas que podrían interactuar. Más allá de la asignación, la plataforma necesita detección automatizada de sample ratio mismatch, cálculos de potencia estandarizados integrados en el flujo de lanzamiento, y un pipeline de resultados que nadie pueda saltarse silenciosamente espiando los números crudos antes de que el test concluya — el trabajo de la plataforma es hacer que el camino estadísticamente correcto también sea el más fácil.

Un stakeholder te pide probar que una campaña de marketing causó un aumento de revenue, y nunca se corrió un experimento aleatorizado. ¿Cómo lo abordas?

Recurres al diseño cuasiexperimental más cercano que los datos soporten: difference-in-differences si hay un grupo no tratado comparable y un pre-período limpio, control sintético si no existe un único grupo de comparación no tratado pero una combinación ponderada de otros puede aproximarlo, o regression discontinuity si la campaña apuntó a usuarios por encima de algún umbral. Cada uno de estos descansa en un supuesto — tendencias paralelas, ausencia de efectos de anticipación, ausencia de un confounder simultáneo — que no puedes probar, solo argumentar con diagnósticos del pre-período, y el entregable tiene que incluir ese supuesto explícitamente en lugar de presentar una estimación puntual como hecho consumado.

¿Cómo traduces una pregunta de negocio ambigua como "por qué cayó el retention el trimestre pasado" en un análisis medible?

Empieza forzando precisión sobre "retention" y "cayó" — qué cohorte, qué ventana de tiempo, comparado con qué baseline —, porque la mitad de las solicitudes ambiguas se disuelven en cuanto la métrica realmente se define, y a menudo descubres que el stakeholder reaccionaba a un artefacto del dashboard y no a un cambio real. Desde ahí descompones la métrica (¿la caída está concentrada en un segmento, un canal, un release?) antes de recurrir a herramientas causales, porque la segmentación suele estrechar una pregunta abierta hacia una hipótesis concreta y testeable más rápido que cualquier modelo.

¿Cómo construyes estándares y prácticas de revisión de data science en un equipo en crecimiento sin convertirte en un cuello de botella?

Codifica los modos de falla que has visto repetirse — leakage, tests infrapotenciados, p-values mal leídos, métricas que no coinciden con el costo de negocio — en un checklist de revisión ligero en lugar de exigir que cada análisis pase personalmente por ti, porque la revisión personal no escala más allá de un puñado de personas y crea una cola que, bajo presión de plazos, le enseña a todos a saltársela. Combina eso con tooling compartido (una librería estándar de cálculo de potencia, una plantilla para documentar experimentos) para que la práctica correcta sea también el camino de menor resistencia, y reserva tu tiempo personal de revisión para decisiones con peso financiero o estratégico real, no para análisis rutinarios.

Un test A/B dice que un cambio gana; un análisis observacional más largo dice que perjudica la retención. ¿Cómo reconcilias eso?

Revisa primero la mecánica antes de confiar en cualquiera de las dos cifras: los efectos de novedad y primacía se desvanecen en la ventana corta de un test pero aparecen en datos observacionales más largos, y un cambio de métrica concentrado en un segmento para el que el test no tenía potencia estadística suficiente se diluye en el resultado agregado. Busca interferencia — ¿el cambio afectó al grupo de control indirectamente, a través de un recurso compartido, un marketplace o un modelo de recomendación reentrenado con datos de ambos brazos? — porque eso rompe el supuesto de independencia del que depende el A/B testing. Si la mecánica está bien y el conflicto es real, confía en el resultado aleatorizado para el efecto causal y en el observacional para saber a quién afecta y por qué, y dilo explícitamente en vez de elegir la cifra que coincide con la decisión que ya querías tomar.