¿Cuál es la diferencia entre el aprendizaje supervisado y no supervisado, y cuándo usarías cada uno?

El aprendizaje supervisado utiliza datos etiquetados para entrenar un modelo que prediga una salida a partir de características de entrada. Lo uso cuando tengo una variable objetivo clara y suficientes ejemplos etiquetados: predicción de churn, estimación de precios, clasificación de imágenes. El aprendizaje no supervisado encuentra estructuras en los datos sin etiquetas. Lo uso cuando quiero descubrir patrones que no he definido de antemano: segmentación de clientes con k-means, modelado de temas con LDA, o detección de anomalías cuando no tengo ejemplos etiquetados de fraude. En la práctica, muchos proyectos combinan ambos: uso clustering no supervisado para identificar segmentos de clientes y luego construyo un clasificador supervisado para asignar nuevos clientes a esos segmentos en tiempo real. La decisión siempre parte de la pregunta de negocio y los datos disponibles.

¿Cómo abordas un nuevo conjunto de datos antes de construir cualquier modelo?

Empiezo con análisis exploratorio de datos antes de tocar ningún código de modelado. Compruebo la estructura y el esquema, luego examino las tasas de valores faltantes por columna y decido si imputarlos, eliminarlos o marcarlos. Analizo las distribuciones de características numéricas: asimetría, valores atípicos y si la escala varía mucho entre columnas. Para características categóricas verifico la cardinalidad y si alguna categoría aparece solo en el conjunto de prueba. También examino pronto la distribución de la variable objetivo: el desequilibrio de clases en un problema de clasificación cambia casi todas las decisiones posteriores. Cruzo las características clave con el objetivo para construir una intuición del señal disponible antes de escribir una sola línea de sklearn. Documento los hallazgos a medida que avanzo.

¿Qué es el sobreajuste y qué técnicas usas para detectarlo y prevenirlo?

El sobreajuste ocurre cuando un modelo aprende los datos de entrenamiento tan bien que captura el ruido en lugar del patrón subyacente, y el rendimiento se degrada con datos nuevos. Lo detecto comparando las métricas de entrenamiento y validación lado a lado: una gran brecha entre una precisión de entrenamiento del 97% y una de validación del 81% es una señal clara. Para prevenirlo, uso validación cruzada en lugar de una única división train-test, lo que da una estimación más fiable de la generalización. Para modelos basados en árboles ajusto la profundidad máxima y el número mínimo de muestras por hoja, y uso parada anticipada en gradient boosting. Para redes neuronales aplico dropout y monitoreo la pérdida de validación. La regularización L1 o L2 ayuda con modelos lineales. También controlo el número de características: añadir características ruidosas empeora el sobreajuste.

Cuéntame sobre una vez que tuviste que explicar un modelo o sus resultados a un público no técnico.

Construí un modelo de predicción de churn para un producto de suscripción y tuve que presentar los resultados al equipo directivo de marketing y customer success. El modelo usaba un clasificador gradient boosting con unas 40 características, lo que sabía que no significaría nada para ellos. Eliminé por completo los detalles técnicos de las diapositivas. Me centré en tres cosas: qué predice el modelo, qué nivel de confianza debemos tener en él según la precisión y el recall en datos de prueba, y sobre todo qué significaba para sus decisiones. Presenté los cinco principales factores de riesgo de churn en lenguaje claro: los clientes que no habían iniciado sesión en 21 días y no habían usado la función de informes tenían 4,2 veces más probabilidades de abandonar en 30 días. El equipo vio inmediatamente qué segmentos priorizar. Las preguntas fueron sobre estrategia, no metodología.

Describe un modelo que construiste que no funcionó tan bien como esperabas. ¿Qué hiciste?

Construí un modelo de propensión para predecir qué usuarios del nivel gratuito pasarían a un plan de pago en 60 días. Tras entrenar con seis meses de datos, el AUC en el conjunto de validación era 0,71, lo que parecía razonable. Pero cuando realizamos una prueba en vivo durante cuatro semanas, la precisión fue mucho menor de lo esperado: estábamos marcando demasiados falsos positivos. Hice un análisis post-mortem y encontré dos problemas. Primero, los datos de entrenamiento tenían un problema de fuga de etiqueta: una de las características incluía un clic en un aviso de actualización dentro de la aplicación que ocurría justo antes de la conversión, lo que significaba que el modelo había aprendido de una señal no disponible en el momento de la predicción. Segundo, el desequilibrio de clases era más severo en la población real. Reconstruí el modelo eliminando la característica con fuga y reequilibrando con SMOTE. El AUC en vivo mejoró a 0,79 y la precisión en el decil superior pasó del 31% al 58%.

Cuéntame sobre una vez que trabajaste con un equipo de ingeniería para desplegar un modelo a producción.

Después de construir un modelo de detección de fraude en tiempo real en Python, trabajé con dos ingenieros de backend para llevarlo a producción. El primer reto fue que había construido el modelo en un entorno Jupyter y el pipeline de ingeniería de características no era reproducible fuera de él. Pasé dos días refactorizando el código de preprocesamiento en un módulo Python limpio con pruebas unitarias para que ingeniería pudiera integrarlo con confianza. Acordamos un contrato de API: el modelo recibiría un payload JSON y devolvería una puntuación entre 0 y 1 con un tiempo de respuesta inferior a 50 ms. Containerice el modelo con Docker y usamos un despliegue en shadow para enrutar el 10% del tráfico real al nuevo modelo. Monitoreamos la distribución de predicciones y la latencia durante dos semanas antes de migrar completamente. El periodo shadow detectó un caso extremo donde un campo faltante causaba una predicción nula.

¿Cómo eliges las métricas de evaluación para un problema de clasificación?

Empiezo preguntando cuál es el coste de cada tipo de error en el contexto de negocio, porque la exactitud por sí sola casi nunca cuenta toda la historia. Para la detección de fraude, un falso negativo (fraude no detectado) es mucho más costoso que un falso positivo, así que doy mucho peso al recall. Para un modelo de puntuación de leads donde la capacidad de ventas es limitada, la precisión importa más: quiero que los leads que llamamos sean de alta calidad. Cuando las clases están desequilibradas, la exactitud es especialmente engañosa. Uso la curva AUC-ROC para comparar modelos de forma independiente al umbral, y la curva precisión-recall cuando la clase positiva es rara. Para el umbral operativo final examino la puntuación F-beta y elijo un beta que refleje el compromiso de negocio. También controlo la calibración: un modelo que dice "70% de probabilidad" debería acertar aproximadamente el 70% de las veces.

¿Cómo abordas la ingeniería de características?

La ingeniería de características es a menudo donde se crea el mayor valor, y la trato como un proceso continuo en lugar de un paso único. Empiezo con el conocimiento del dominio: ¿qué cree un experto humano que predice el resultado? Eso me da un conjunto de partida rápido. Luego examino las características brutas y creo derivadas: ratios, medias móviles en diferentes ventanas temporales, tiempo transcurrido desde el último evento, y términos de interacción entre características que la lógica de negocio sugiere que podrían actuar juntas. Para datos de texto uso TF-IDF o embeddings según si la tarea necesita similitud semántica. Valido cada característica midiendo su importancia en un modelo base y ejecutando pruebas de permutación para confirmar que añade señal. También compruebo la multicolinealidad: las características altamente correlacionadas pueden desestabilizar algunos modelos.

¿Cómo piensas en poner un modelo en producción, desde el notebook hasta el sistema real?

La brecha entre un notebook funcional y un modelo de producción fiable es significativa y vale la pena planificarla desde el principio. Empiezo escribiendo el pipeline de características como Python limpio y testeable en lugar de celdas de notebook, para que el mismo código de preprocesamiento se ejecute de forma idéntica en el entrenamiento y en la inferencia. Esto previene el skew entrenamiento-servicio, una de las fuentes más comunes de degradación silenciosa del modelo. Versiono el artefacto del modelo y el pipeline de características juntos con MLflow o una herramienta similar. Defino los requisitos de monitoreo antes del lanzamiento: quiero rastrear las distribuciones de características de entrada, las distribuciones de puntuaciones de salida, y el rendimiento real versus predicho en datos de retroalimentación etiquetados. Configuro umbrales de alerta para la deriva de datos con pruebas estadísticas como el test de Kolmogorov-Smirnov.

Data scientist

Las entrevistas para data scientist van mucho más allá del SQL y los dashboards. Los entrevistadores esperan que hables sobre selección de modelos, ingeniería de características, métricas de evaluación y qué ocurre después de construir un modelo. Esta guía cubre las preguntas más frecuentes con respuestas concretas para que te prepares.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Preguntas de entrevista habituales para Data scientist

Preguntas conductuales para puestos de Data scientist

Preguntas técnicas para candidatos a Data scientist

Lo que buscan los reclutadores en las entrevistas para Data scientist

Lo que los responsables de selección buscan realmente en los candidatos a data scientist:

Mentalidad de producción, no solo de notebook. Los candidatos que entienden el skew entrenamiento-servicio, la monitorización y el versionado de modelos destacan sobre los que se quedan en la precisión del modelo.
Gestión honesta del fracaso y la incertidumbre. Los mejores data scientists hablan con claridad sobre modelos que no funcionaron y qué cambiaron. Los candidatos que solo describen éxitos son una señal de alerta.
Contexto de negocio primero. Los candidatos fuertes conectan cada elección técnica (selección de métricas, ingeniería de características, fijación de umbrales) con un resultado de negocio, no solo con una puntuación de benchmark.
Comunicación con partes interesadas no técnicas. La capacidad de traducir el output de un modelo en decisiones accionables para un equipo de marketing o finanzas es lo que separa a los data scientists con impacto de los que viven solo en notebooks.
Conciencia de los problemas de calidad de datos. Los candidatos que mencionan la fuga de etiqueta, el desequilibrio de clases y la deriva de los datos de entrenamiento desde el inicio de sus respuestas han trabajado con datos de producción reales.

Preguntas que puedes hacer al entrevistador

→¿Cómo es el proceso de despliegue de modelos aquí: quién se encarga de la puesta en producción, el equipo de data science o ingeniería?
→¿Qué tan madura es la infraestructura de datos? ¿Tienen un feature store o la ingeniería de características se hace por proyecto?
→¿Cómo es el bucle de retroalimentación para los modelos ya en producción: cómo monitorizáis la deriva y la degradación?
→¿Cuál es el equilibrio entre construir nuevos modelos y mantener y mejorar los existentes?
→¿Cómo colabora el equipo de data science con los stakeholders de producto y negocio para definir en qué trabajar a continuación?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis durante la beta. Sin compromiso.

Puestos relacionados

Analista de datos

Tech9 preguntas

Ingeniero de software

Tech9 preguntas

Product Manager

Tech9 preguntas