Preguntas de entrevista para Científico de Datos

Respuesta modelo

El equipo de retención venía perdiendo un 2,4 % de clientes particulares al trimestre y trabajaba con una segmentación RFM hecha a mano. Mi primera tarea no fue modelar, sino eliminar la ambigüedad de la definición de baja, que cada área entendía de una forma: acordamos «sin operación en 90 días y saldo inferior a 50 €». Con esa etiqueta construí un conjunto de 210 variables de comportamiento y entrené un LightGBM con validación temporal sobre 18 meses, comparándolo siempre contra dos líneas base: la regla vigente y una regresión logística. El AUC subió de 0,71 a 0,86, pero lo que convenció al comité fue la curva de elevación: con el 20 % de la cartera capturábamos el 61 % de las bajas. Lo desplegamos con reentrenamiento semanal y monitorización de deriva, y medimos el efecto real con un grupo de control aleatorizado del 10 %, no con la comparación antes-después. Doce meses más tarde, la tasa de baja había caído un 14 % y el margen retenido rondaba 1,8 M€. La parte que más defiendo es el grupo de control: sin él habríamos atribuido al modelo un efecto estacional.

Respuesta modelo

Un analista responde a la pregunta de qué ha pasado y lo hace muy bien: consultas, informes y cuadros de mando fiables. Mi trabajo empieza cuando la pregunta es qué pasaría si, o cuánto de esto es efecto y cuánto es ruido; buena parte del oficio consiste en deshacer la ambigüedad de esa pregunta antes de responderla. Eso implica diseñar la medición antes de que existan los datos —definir la unidad de aleatorización, calcular el tamaño muestral, fijar el criterio de parada— y construir modelos que producen una predicción con la que alguien toma una decisión automática. En mi último puesto convivíamos: el equipo de análisis mantenía el cuadro de mando de retención y yo era responsable del modelo de propensión y de los experimentos que validaban las campañas. También reconozco el solape: hago análisis descriptivo continuamente, porque sin entender la tabla no se puede modelar nada.

Respuesta modelo

Yo soy responsable de que el modelo sea correcto y de que resuelva el problema; el ingeniero de ML es responsable de que funcione a escala y de forma fiable. En la práctica me muevo con soltura en la frontera: empaqueto en Docker, versiono con MLflow, escribo tests con pytest y dejo el código listo para que plataforma lo integre en su CI/CD. Lo que no reivindico es ser quien optimiza latencias de inferencia, diseña la arquitectura de servicio o gestiona el clúster. Prefiero decirlo claramente en la entrevista, porque he visto candidaturas que se venden como perfil completo y luego bloquean un equipo entero.

Respuesta modelo

Empezaría por la métrica principal, que aquí sería la tasa de compra finalizada por sesión iniciada, y fijaría dos o tres métricas de guarda: importe medio del pedido, incidencias de pago y tiempo hasta la confirmación. Con la tasa base actual —supongamos un 62 %— y un efecto mínimo detectable del 1,5 puntos, calculo el tamaño muestral necesario con una potencia del 80 % y un nivel de significación del 5 %; eso me da el número de sesiones por rama y, con el tráfico diario, la duración mínima, que redondearía a semanas completas para no mezclar el efecto del día de la semana. Aleatorizaría a nivel de usuario y no de sesión, porque el mismo usuario puede volver y la contaminación sesgaría el resultado. Antes de lanzar haría un test A/A durante dos o tres días para verificar la instrumentación. Y fijaría por escrito el criterio de decisión antes de ver ningún dato, con corrección por comparaciones múltiples si evaluamos varias métricas.

Respuesta modelo

Trabajé en un modelo de priorización de reclamaciones que alcanzaba un rendimiento correcto en validación, pero al analizar la importancia de las variables vi que dos de las tres principales eran proxies del código postal, con lo que el sistema priorizaba sistemáticamente a los clientes de determinados barrios. El efecto sobre la métrica técnica era bueno; sobre la equidad del servicio, inaceptable, y además nos exponía a un problema regulatorio. Presenté al comité la comparación de tasas de atención por grupo, propuse eliminar esas variables y medí el coste: perdíamos 4 puntos de precisión. Se aprobó la versión sin esas variables y documentamos la decisión. Prefiero un modelo algo peor y defendible ante la AEPD y ante el propio cliente que uno mejor que no podría explicar en público.

Respuesta modelo

Con una sola idea por diapositiva y siempre en el idioma de quien decide. Empiezo por la decisión que se quiere tomar, no por el método: «si aplicamos esto a la cartera, dejamos de perder en torno a mil clientes al año, con un margen de entre 700 y 1.300». Después explico en una frase de dónde sale ese número y qué tendría que ocurrir para que se equivocara. Uso curvas de elevación en lugar de AUC, y euros en lugar de puntos porcentuales cuando puedo. Nunca escondo la incertidumbre: la presento como rango, porque un rango honesto genera más confianza que una cifra exacta que nadie puede verificar. Y cierro con lo que necesito del comité: una decisión concreta, no una ronda de comentarios.

Respuesta modelo

Lo primero, cuantificar el problema en lugar de quejarme de él: qué porcentaje de registros falta, si el faltante es aleatorio o sistemático, desde qué fecha y qué decisiones se han tomado con esos datos hasta ahora. En un proyecto de previsión de demanda descubrí que el 18 % de los movimientos de almacén se registraba con hasta cuatro días de retraso, lo que arruinaba cualquier modelo diario. Reformulé el alcance a granularidad semanal, entregué valor en tres semanas y, en paralelo, presenté a operaciones el coste de la falta de calidad en euros para justificar el cambio de proceso. Seis meses después pudimos bajar a granularidad diaria. Considero parte de mi trabajo negociar el alcance con la realidad del dato, no esperar a que llegue un conjunto perfecto.

Respuesta modelo

En mi puesto actual he llevado el ciclo completo de tres modelos y he montado el marco de experimentación desde cero, pero el volumen de datos y la variedad de problemas se han estabilizado: llevo un año resolviendo variaciones del mismo caso. Me interesa su equipo porque trabajan con datos de eventos a una escala mayor y porque, por lo que he leído, la experimentación está integrada en el proceso de producto y no como una validación posterior. Busco un entorno donde el científico de datos participe en la definición del problema, y no solo en su resolución. Y busco estabilidad: valoro un contrato indefinido y un equipo con recorrido, porque los proyectos de datos tardan meses en dar resultados y me interesa quedarme a verlos.

El error de tipo I es concluir que hay efecto cuando no lo hay: lanzamos una funcionalidad inútil y asumimos su coste de desarrollo y mantenimiento. El de tipo II es no detectar un efecto que sí existe: descartamos una mejora real. Fijar alfa en 0,05 significa aceptar que, si no hay efecto alguno, uno de cada veinte tests dará positivo por azar; con cuarenta experimentos al año eso son dos falsos positivos esperados, y por eso conviene corregir por comparaciones múltiples cuando se evalúan varias métricas o varias ramas. La potencia (1 menos beta) es la otra cara y depende del tamaño muestral: un test con potencia del 40 % es casi una tirada de moneda, y en la práctica es peor que no hacer el test, porque genera confianza infundada. En decisiones reversibles y baratas subo alfa y bajo el coste del experimento; en decisiones caras o irreversibles, al contrario.

Usaría una función de ventana en lugar de autounir la tabla contra sí misma. Filtro primero los eventos de tipo compra para reducir el volumen, después numero las compras por usuario con ROW_NUMBER() OVER (PARTITION BY usuario ORDER BY fecha_evento), me quedo con las filas 1 y 2 y calculo la diferencia con un LAG o pivotando. Sobre Snowflake o Databricks cuidaría además el particionado por fecha para que el motor pode datos, y evitaría el SELECT * porque en formato columnar se paga por columna leída. Si la tabla se consulta a menudo, materializaría una tabla intermedia de primeras compras con dbt en lugar de recalcularla en cada ejecución. Una autounión aquí sería un producto cartesiano de riesgo y multiplicaría el coste de cómputo.

Ambas penalizan la magnitud de los coeficientes para controlar el sobreajuste. L2 (ridge) penaliza el cuadrado y encoge los coeficientes de forma suave, repartiendo el peso entre variables correlacionadas; L1 (lasso) penaliza el valor absoluto y lleva coeficientes exactamente a cero, con lo que selecciona variables. Uso L1 cuando tengo cientos de variables y necesito un modelo interpretable o un conjunto reducido para producción, por ejemplo en scoring que debe explicarse a validación interna. Uso L2 cuando las variables están correlacionadas y me interesa estabilidad de las estimaciones más que parsimonia. Elastic net combina ambas y suele ser mi punto de partida cuando no tengo criterio previo claro; el parámetro se elige por validación cruzada, respetando el orden temporal si los datos lo tienen.

No, y sospecharía de inmediato del desbalanceo de clases: si el fraude es el 1 % de las operaciones, un modelo que responda siempre «no hay fraude» alcanza ese 99 %. Miraría precisión y exhaustividad sobre la clase positiva, la curva precisión-exhaustividad y el AUC-PR, que en clases muy desbalanceadas es más informativo que el ROC. Después llevaría la métrica al terreno del negocio: cuánto cuesta un fraude no detectado frente a cuánto cuesta bloquear una operación legítima, y con esa relación fijaría el umbral, que rara vez es 0,5. También comprobaría si hay fuga de información, porque una exactitud sospechosamente alta suele venir de una variable que en producción no estará disponible en el momento de la predicción.

Distingo tres cosas: deriva de las variables de entrada, deriva del concepto (cambia la relación entre entradas y objetivo) y degradación del rendimiento. Para las entradas monitorizo la distribución de las variables principales con el índice de estabilidad poblacional, con umbrales de aviso en 0,1 y de alerta en 0,2, más comprobaciones de valores nulos y de rangos. El rendimiento real solo puede medirse cuando llega la etiqueta, y a veces tarda semanas, así que en ese intervalo vigilo indicadores indirectos: distribución de la puntuación de salida y tasa de aceptación. Con alerta confirmada, primero investigo si es un problema de datos aguas arriba —un cambio en el registro de eventos, por ejemplo— antes de reentrenar, porque reentrenar sobre datos rotos consolida el error. Si la deriva es genuina, reentreno con ventana reciente y comparo contra el modelo vigente antes de sustituirlo.

Cuando la pregunta no es quién va a comprar, sino a quién cambia de comportamiento nuestra intervención. Un modelo de propensión bien entrenado identifica a quien tiene alta probabilidad de comprar, y si le enviamos el descuento a esa gente, gran parte habría comprado igualmente: gastamos margen sin generar incremento. Ahí uso modelos uplift o diseños experimentales para estimar el efecto incremental. Cuando no es posible aleatorizar —una apertura de tiendas, un cambio regulatorio, una campaña ya lanzada— recurro a métodos cuasiexperimentales: diferencias en diferencias con verificación de tendencias paralelas previas, control sintético o emparejamiento por propensión. El experimento aleatorizado sigue siendo el patrón de referencia; lo demás es una aproximación que exige explicitar los supuestos.

Nunca con validación cruzada aleatoria, porque mezclaría el futuro con el pasado y el resultado saldría optimista. Uso validación con origen móvil: entreno hasta una fecha, valido en la ventana siguiente y voy desplazando el corte, de forma que reproduzco las condiciones de producción. Respeto además el desfase real de disponibilidad de cada variable: si un dato de facturación tarda cinco días en consolidarse, el modelo no puede usarlo el mismo día. Y comparo siempre contra líneas base honestas, que en series temporales suelen ser sorprendentemente duras: el valor del periodo anterior, la media móvil o el mismo periodo del año pasado. Si mi modelo no supera claramente a la estacionalidad ingenua, no compensa el coste de mantenerlo.

No lo retiro, pero cambio cómo lo cuento. Entiendo la preocupación: un intervalo mal presentado parece indecisión. Lo reformulo en lenguaje de negocio —«esperamos entre 700.000 y 1.300.000 € de margen adicional, con un valor central de un millón»— y explico en una frase por qué ese rango es información útil y no ruido: si el resultado sale en la parte baja, la campaña sigue siendo rentable, y eso es precisamente lo que el comité necesita saber para decidir. Si la presión persiste, ofrezco llevar el detalle metodológico a un anexo, pero el rango se queda en la diapositiva principal. Quitar la incertidumbre para que la cifra suene mejor es donde empiezan los problemas de credibilidad del equipo de datos.

Que el resultado no es fiable todavía y explico por qué en treinta segundos: mirar el p-valor de forma continua dispara los falsos positivos muy por encima del 5 % declarado, y con cuatro días no hemos cubierto ni un ciclo semanal completo, así que el efecto puede ser puro comportamiento de fin de semana. Propongo dos salidas: esperar a la duración planificada, que fijamos antes de lanzar, o adoptar de forma explícita un método de parada anticipada —secuencial o bayesiano— con sus umbrales definidos de antemano, no improvisados. Si la decisión es reversible y de bajo coste, puedo aceptar lanzar con la evidencia disponible siempre que quede registrado que es una decisión de riesgo asumido y que seguiremos midiendo. Lo que no acepto es reescribir el criterio después de ver el dato.

Lo comunico el mismo día, sin esperar a tener la solución completa. Primero cuantifico el daño: reentreno sin esa variable y comparo el rendimiento real, y reviso qué decisiones se han tomado con las predicciones afectadas durante esos tres meses. Con esa estimación planteo al responsable del área tres opciones con su coste: retirar el modelo y volver a la regla anterior, mantenerlo con umbral ajustado mientras se reconstruye, o pausar la campaña dependiente. Después escribo el análisis de la causa raíz: cómo entró esa variable, por qué la validación temporal no lo detectó y qué comprobación automática añadimos al proceso para que no vuelva a pasar. Ocultarlo no es una opción: en una auditoría o en una revisión de riesgo de modelo aparecería igualmente, y entonces el problema ya no sería técnico.

Hablo directamente con el equipo antes de escalar nada, porque casi siempre hay un motivo de prioridades que desconozco. Llevo cuantificado lo que cuesta el retraso —fecha de campaña que se pierde, margen estimado— porque una prioridad se negocia con números, no con urgencia. Mientras tanto no me quedo parado: construyo una versión provisional de la tabla en mi propio esquema, aunque sea menos eficiente, y avanzo con el modelado y la validación para que, cuando llegue la tabla definitiva, solo haya que cambiar la fuente. Si el bloqueo persiste, lo elevo con ambos responsables presentes y con una propuesta concreta de reparto de trabajo, no como una queja.

Pregunto primero qué se quiere capturar con esa variable, porque casi siempre se busca un efecto de renta, de densidad urbana o de coste logístico que puede medirse de forma más directa y menos problemática. El código postal actúa como aproximación de características protegidas y puede introducir discriminación indirecta, con riesgo regulatorio bajo el RGPD y bajo el Reglamento Europeo de Inteligencia Artificial en usos de alto riesgo como el crédito. Propongo tres pasos: sustituirlo por variables explícitas del fenómeno que interesa, medir el rendimiento con y sin la variable para conocer el coste real de excluirla, y evaluar disparidad de tasas por subgrupo. Después llevo esa comparación a negocio y a cumplimiento normativo para que la decisión se tome con la información delante y quede documentada.