Talently
Talently
Data Scientist

Data Scientist

Transforma datos en decisiones de negocio aplicando modelos estadísticos, machine learning y criterio analítico.

Un Data Scientist diseña y desarrolla modelos predictivos, analíticos y de machine learning que generan valor medible para el negocio. Su trabajo abarca desde la exploración y limpieza de datos hasta el entrenamiento, evaluación y puesta en producción de modelos. Trabaja en estrecha colaboración con product managers, ingenieros de datos y stakeholders de negocio para traducir preguntas del negocio en problemas técnicos resolubles con datos. La efectividad de su trabajo se mide en el impacto real de los modelos en producción, no en la precisión en el conjunto de validación.

PythonMachine LearningSQLTensorFlowEstadísticaMLflow

Recluta al mejor Data Scientist aquí

Empieza ahora

Responsabilidades Principales

  • •Definir el problema de negocio en términos de un problema de datos resoluble con técnicas estadísticas o de machine learning.
  • •Explorar, limpiar y transformar datos de múltiples fuentes para construir datasets de entrenamiento representativos y de calidad.
  • •Entrenar, evaluar y seleccionar modelos con métricas alineadas al objetivo de negocio, no solo a métricas técnicas.
  • •Colaborar con ingenieros de datos y MLOps para llevar modelos a producción de forma confiable y monitoreable.
  • •Comunicar hallazgos y resultados a audiencias técnicas y no técnicas con claridad y honestidad sobre las limitaciones.
  • •Monitorear el rendimiento de modelos en producción y detectar data drift o degradación que requiera reentrenamiento.

Habilidades Clave

Technical Skills

  • Python para análisis de datos y modelado: pandas, numpy, scikit-learn, y frameworks de deep learning (TensorFlow, PyTorch)
  • Estadística aplicada: distribuciones, tests de hipótesis, intervalos de confianza, regresión y análisis de series de tiempo
  • SQL avanzado para extracción y transformación de datos desde bases de datos relacionales y warehouses analíticos
  • Técnicas de machine learning supervisado y no supervisado con criterio para elegir el modelo adecuado al problema
  • Diseño de experimentos y pruebas A/B para medir el impacto causal de intervenciones en el producto
  • Herramientas de experimentación y tracking de modelos: MLflow, Weights & Biases, o equivalentes para reproducibilidad

Soft Skills

  • Pensamiento crítico para cuestionar si los datos disponibles son suficientes y representativos para el problema planteado
  • Comunicación efectiva de resultados con visualizaciones claras y narrativas que conecten los hallazgos con decisiones de negocio
  • Honestidad intelectual para reportar los límites de un modelo y los escenarios donde sus predicciones no son confiables
  • Curiosidad para explorar datos sin hipótesis preconcebidas y descubrir patrones no anticipados
  • Colaboración con stakeholders de negocio para refinar preguntas vagas en problemas técnicamente abordables
  • Criterio para determinar cuándo un problema no requiere machine learning y puede resolverse con estadística simple o reglas de negocio

Casos de uso reales

Contexto

Las predicciones permiten a las empresas anticiparse a eventos futuros y tomar decisiones proactivas en lugar de reactivas.

Ejemplos reales

  • Predicción de churn para intervención temprana en usuarios en riesgo
  • Forecasting de demanda para optimización de inventario y logística
  • Modelos de propensión de compra para personalización de ofertas
  • Predicción de lifetime value para priorización de adquisición de clientes

Contexto

Las decisiones de producto basadas en datos requieren medir el impacto causal de cambios, no solo correlaciones. El diseño correcto del experimento determina la validez de las conclusiones.

Ejemplos reales

  • Diseño de pruebas A/B con cálculo de tamaño muestral y duración mínima
  • Análisis de resultados con corrección por múltiples comparaciones
  • Detección de efectos de red en experimentos donde los usuarios interactúan entre sí
  • Pruebas de significancia práctica versus estadística en métricas de negocio

Contexto

La personalización basada en el comportamiento histórico del usuario mejora el engagement, la conversión y la retención en productos digitales.

Ejemplos reales

  • Recomendaciones de contenido con filtrado colaborativo o basado en contenido
  • Ranking personalizado de resultados de búsqueda por perfil de usuario
  • Sistemas de recomendación en frío para usuarios nuevos sin historial
  • Evaluación offline y online de sistemas de recomendación con métricas de negocio

Contexto

Los patrones anómalos en datos de transacciones, comportamiento de usuarios o métricas operacionales pueden indicar fraude, fallos del sistema o cambios importantes en el negocio.

Ejemplos reales

  • Detección de transacciones fraudulentas en tiempo real con modelos de clasificación
  • Identificación de cuentas comprometidas por patrones de comportamiento inusuales
  • Monitoreo de métricas de producto para detección automática de anomalías
  • Modelos de detección de bots en plataformas con contenido generado por usuarios

Contexto

El texto no estructurado (reseñas, tickets de soporte, comentarios) contiene información valiosa que los modelos de NLP pueden extraer y cuantificar.

Ejemplos reales

  • Análisis de sentimiento en reseñas de producto para monitoreo de percepción de marca
  • Clasificación automática de tickets de soporte para priorización y routing
  • Extracción de entidades y temas de feedback de usuarios para roadmap de producto
  • Modelos de embeddings para búsqueda semántica en catálogos de productos

Preguntas básicas

ML es justificado cuando: el problema tiene patrones complejos no codificables con reglas explícitas, hay suficientes datos históricos de calidad, la mejora sobre una baseline simple es medible y relevante para el negocio, y el costo de implementar y mantener el modelo es menor que el beneficio. Muchos problemas se resuelven mejor con regresión logística, reglas de negocio o estadística descriptiva. El modelo más simple que resuelve el problema es siempre preferible.
Análisis exploratorio: distribuciones de variables, valores nulos y su patrón (MCAR, MAR, MNAR), outliers, correlaciones entre features, y distribución de la variable target. Verificar si el dataset es representativo del problema real. Detectar data leakage: features que no estarían disponibles en el momento de la predicción. Entender el origen de los datos y si su proceso de recolección introduce sesgos. El EDA es la inversión que previene modelos con rendimiento engañoso.
Overfitting: el modelo aprende el ruido del training set y no generaliza. Se detecta comparando la métrica en entrenamiento vs. validación: una brecha grande indica overfitting. Estrategias de mitigación: regularización (L1, L2, dropout en redes neuronales), reducción de la complejidad del modelo, más datos de entrenamiento, early stopping, y cross-validation para una estimación más robusta del rendimiento real.
Depende del costo relativo de los errores: si los falsos negativos son más costosos que los falsos positivos (detección de enfermedades, fraude), priorizar recall. Si los falsos positivos son más costosos (spam filter que elimina emails legítimos), priorizar precision. Accuracy es engañosa en clases desbalanceadas. F1 es útil cuando se necesita un balance y las clases son desbalanceadas. Siempre alinear la métrica con el costo de negocio real de cada tipo de error.
Data leakage ocurre cuando información que no estaría disponible en el momento de la predicción real se incluye como feature de entrenamiento. Ejemplo: incluir el resultado del evento que se quiere predecir, o una variable calculada después de que ocurre el evento. El modelo aprende a usar esa información y muestra métricas excelentes en validación, pero en producción esa información no existe y el rendimiento colapsa. La revisión temporal del dataset es crítica para evitarlo.
Primero, asegurarse de que la métrica de evaluación sea adecuada (no accuracy). Técnicas para manejar el desbalance: ajustar los class weights en el modelo para penalizar más los errores en la clase minoritaria, oversampling de la minoría (SMOTE), undersampling de la mayoría, o una combinación. Evaluar con curva ROC-AUC, precision-recall curve, y F1 ponderado. La técnica óptima depende del volumen de datos y del dominio del problema.
Cross-validation divide el dataset en k folds, entrenando k veces usando k-1 folds y validando en el restante. El resultado es el promedio y la desviación estándar de k métricas. Es preferible porque: reduce la varianza en la estimación del rendimiento, usa todos los datos para evaluación, y detecta si el modelo es sensible a qué datos quedan en el training set. Una división única puede dar un resultado optimista o pesimista por azar según cómo quedaron los datos.
Traducir las métricas técnicas a impacto de negocio: en lugar de 'el modelo tiene AUC de 0.85', mostrar 'el modelo identifica correctamente el 80% de los clientes que van a cancelar, con un 15% de falsas alarmas'. Mostrar ejemplos concretos de predicciones correctas e incorrectas. Ser honesto sobre las limitaciones y los escenarios donde el modelo no es confiable. El objetivo es que el stakeholder entienda qué puede y qué no puede esperar del modelo para tomar decisiones informadas.

Preguntas técnicas

Bagging (Random Forest): entrena modelos en paralelo sobre subsets aleatorios de datos, promedia sus predicciones para reducir varianza. Robusto al overfitting, paralelizable. Boosting (XGBoost, LightGBM): entrena modelos secuencialmente, cada uno corrigiendo los errores del anterior, reduciendo bias. Generalmente más preciso pero más propenso a overfitting y requiere más tuning. Bagging es preferible cuando se quiere robustez con mínimo tuning. Boosting cuando se optimiza el rendimiento máximo en tabular data.
Definir la métrica primaria (tasa de conversión) y el mínimo efecto detectable que sea relevante para el negocio. Calcular el tamaño muestral necesario para alcanzar la potencia estadística deseada (generalmente 80%) con ese efecto mínimo. Asignar usuarios aleatoriamente a grupos control y tratamiento. Ejecutar el experimento el tiempo mínimo calculado sin hacer early stopping. Analizar con test estadístico apropiado y reportar tanto la significancia estadística como el tamaño del efecto práctico.
El sesgo de selección ocurre cuando la muestra no es representativa de la población objetivo. Ejemplos: analizar solo los usuarios activos para entender la retención (los churneados no están en el dataset), o entrenar un modelo de crédito con datos de clientes que la empresa ya aprobó previamente. Las conclusiones no generalizan porque el proceso de recolección de datos está correlacionado con la variable de interés. Identificarlo requiere entender cómo se generaron y filtraron los datos antes de cualquier análisis.
Monitorear la distribución de las features de entrada comparando producción vs. entrenamiento con tests estadísticos (KS test, PSI para variables continuas, chi-squared para categóricas). Monitorear la distribución de las predicciones del modelo. Si hay labels disponibles con delay, monitorear también el rendimiento real. Definir umbrales de alerta que indiquen cuándo investigar o reentrenar. Herramientas: Evidently AI, WhyLogs, o implementación propia con Prometheus para las métricas.
SHAP values proporcionan explicaciones locales (para cada predicción) y globales (importancia de features) consistentes con la teoría de juegos cooperativos. Para cada predicción, SHAP muestra cuánto contribuyó cada feature al resultado respecto a la predicción base. En contextos regulados (crédito, contratación), combinar SHAP con reglas de negocio para generar explicaciones en lenguaje natural. LIME es una alternativa más rápida pero menos consistente. La interpretabilidad debe diseñarse antes de elegir el modelo, no como afterthought.
Reducir el tamaño del dataset de entrenamiento con muestreo estratificado para iteraciones de experimentación rápida. Usar feature selection para eliminar variables de baja importancia antes del entrenamiento. Paralelizar el entrenamiento con múltiples CPU/GPU. Para deep learning, usar mixed precision training y gradient checkpointing. Implementar early stopping basado en métricas de validación. Separar el ciclo de experimentación rápida (dataset pequeño, pocos epochs) del entrenamiento final (dataset completo).
Detectar con el Variance Inflation Factor (VIF): valores superiores a 5-10 indican multicolinealidad problemática. También con la matriz de correlación entre features. El problema: los coeficientes del modelo se vuelven inestables y difíciles de interpretar, aunque el rendimiento predictivo no se degrada necesariamente. Soluciones: eliminar una de las variables correlacionadas, combinarlas en un componente (PCA), o usar regularización L2 (Ridge) que maneja la multicolinealidad por diseño.
Feature engineering es el proceso de crear o transformar variables para que el modelo pueda aprender mejor los patrones relevantes. Ejemplos: extraer componentes temporales de una fecha (día de la semana, hora, días desde último evento), crear ratios entre variables, aplicar transformaciones logarítmicas a distribuciones sesgadas, o construir features de agregación sobre ventanas temporales. En la práctica, pasar de features crudas a features bien diseñadas suele mejorar el rendimiento más que cambiar de Random Forest a XGBoost.

Preguntas avanzadas

Pipeline automatizado con: ingesta de nuevos datos, validación de calidad del dataset, reentrenamiento del modelo con tracking en MLflow o equivalente, evaluación automática contra el modelo en producción, y promoción automática o manual según el delta de rendimiento. Monitoreo continuo de data drift y performance drift como triggers de reentrenamiento. Feature store para garantizar consistencia entre el modelo entrenado y el servido. El sistema debe poder revertir al modelo anterior automáticamente si el nuevo degrada.
Un modelo predictivo captura correlaciones, no causalidad. Intervenir basándose en una correlación puede ser inefectivo o contraproducente. Para establecer causalidad: diseñar un experimento aleatorio controlado si es posible. Si el RCT no es viable, usar métodos quasi-experimentales: difference-in-differences, regresión discontinua, variables instrumentales o propensity score matching. El error más frecuente es escalar una intervención basada en correlación sin haber validado su efecto causal en un experimento.
Las métricas offline (NDCG, precision@k) no correlacionan necesariamente con métricas de negocio. La evaluación real requiere un experimento A/B donde un grupo recibe las recomendaciones del nuevo modelo y otro las del modelo actual o una baseline. Medir métricas de negocio: click-through rate, conversión, tiempo en plataforma, diversidad de consumo, y efectos de largo plazo en retención. Los sistemas de recomendación también pueden crear filter bubbles que dañan la retención a largo plazo aunque mejoren las métricas de corto plazo.
Auditar el modelo con métricas de equidad: paridad demográfica, igualdad de oportunidades, y calibración por grupos protegidos. El trade-off entre equidad y rendimiento debe ser explícito y decidido por el negocio y stakeholders afectados, no solo por el equipo técnico. Documentar las limitaciones del modelo y los grupos donde su rendimiento es inferior. Implementar monitoreo continuo de métricas de equidad en producción. Considerar si el dataset histórico tiene sesgos que el modelo puede amplificar.
Definir un proceso estándar: hipótesis clara con métrica de éxito definida antes de empezar, experimento mínimo viable para validar la hipótesis rápidamente con datos limitados, revisión de resultados antes de invertir en producción completa. Mantener un registro de experimentos con resultados, incluyendo los negativos (los resultados negativos son aprendizaje, no fracasos). Priorizar los experimentos según el impacto esperado en métricas de negocio, no según el interés técnico del equipo. La velocidad de aprendizaje es más valiosa que la perfección de cada experimento.
Estandarizar el formato de serialización de modelos (ONNX, PMML, o un formato acordado) para desacoplar el framework de entrenamiento del de inferencia. Definir una interfaz de API clara entre el modelo y la aplicación. Implementar un model registry compartido (MLflow, SageMaker Model Registry) donde data science sube modelos versionados y engineering los despliega. Automatizar la validación del modelo antes de cada deploy. El objetivo es que el ciclo de vida del modelo sea tan predecible y confiable como el del software de la aplicación.

Errores comunes en entrevistas

Un modelo con AUC de 0.95 que no mueve ninguna métrica de negocio no aporta valor. Los entrevistadores de empresas con equipos de data science maduros preguntan siempre qué pasó con el modelo después de entrenarlo: ¿se desplegó? ¿qué métrica de negocio mejoró? ¿cuánto? Un candidato que solo habla de métricas de validación demuestra que trabaja en modo académico.
Un modelo con AUC de 0.99 en un problema difícil debe levantar sospechas, no celebraciones. Los entrevistadores con experiencia preguntan inmediatamente si se verificó la ausencia de data leakage. No mencionar espontáneamente esta verificación es una señal de que no se realizó o no se comprendió su importancia.
El deep learning no es la solución óptima para todos los problemas. En tabular data estructurada, XGBoost o LightGBM frecuentemente superan a redes neuronales con mucho menos costo de entrenamiento e inferencia. Proponer la solución más compleja disponible sin justificación de por qué es necesaria demuestra preferencia por la novedad sobre el pragmatismo.
Decir 'los usuarios que usan feature X tienen 3x más retención, por lo que debemos que más usuarios usen X' confunde correlación con causalidad. Los usuarios que usan X pueden ser simplemente más comprometidos por otras razones. Esta confusión lleva a intervenciones costosas sin impacto real. Es uno de los errores conceptuales más frecuentes en entrevistas de data science.
Un modelo que se entrena una vez y se despliega sin monitoreo es una deuda técnica en crecimiento. Los modelos se degradan con el tiempo por data drift. No mencionar cómo se monitorea el rendimiento en producción, cuándo se reentrenan y cómo se gestiona el ciclo de vida demuestra experiencia limitada a proyectos académicos o de notebook, no a sistemas de ML en producción real.
Empezar a entrenar modelos sin preguntar cómo se recolectaron los datos, si hay sesgo de selección, si el período histórico es representativo del futuro, o si hay suficientes ejemplos de la clase de interés demuestra pensamiento de notebook, no de sistema en producción. Las preguntas sobre la calidad y representatividad de los datos deben preceder siempre al modelado.