E127 - Mock interview - Puesto de DS Compliance

Resumen

El episodio 127 de enCoders es la primera "mock interview" en vivo del podcast: Miguel, con experiencia en procesamiento de datos con Spark en banca, se postula simuladamente a un puesto de Data Scientist (Junior) en el equipo de compliance del banco BBVA. La primera parte es una entrevista teórica (motivación, caso hipotético de detección de fraude, manejo de nulos, separación train/test, data leakage, elección de modelo con bootstrapping y test de hipótesis, métricas con clases desbalanceadas y puesta en producción). La segunda es una entrevista de código: explorar un dataset, limpiarlo y entrenar un modelo para detectar fraude. El feedback insiste en entender primero el problema de negocio, no aplicar reglas mecánicas con los nulos, separar train/test antes de imputar, detectar el desbalance de clases, hablar en voz alta mientras se programa y explicitar los atajos. También se recomienda mostrar seguridad y energía, cuidar los nombres de variables, optimizar el tiempo con modelos rápidos como Random Forest y preguntar al reclutador qué tipo de entrevista tocará.

Capítulos

• 00:00
  IntroBienvenida al episodio 127 y presentación de Miguel, la primera persona a la que le hacen una mock interview; se espera aprender de los errores típicos de las entrevistas.
• 01:26
  Objetivos de la Mock Interview y puesto de la postulaciónMiguel busca abrirse a otros rubros porque lleva años con herramientas muy establecidas (Spark y Python para big data). El puesto es Data Scientist en el centro de excelencia de compliance de BBVA, para detectar incumplimientos de regulaciones internas y externas.
• 03:50
  Anuncio de Proyectos en LinkedInSe busca proyectos de empresas reales para estudiantes del Máster de ciencias de datos del primer semestre de 2025, de unas 17 semanas. Hay entre 30 y 50 estudiantes y se toman aproximadamente 10 proyectos.
• 05:10
  ¿Por qué eres el candidato ideal para el puesto?Miguel dice que en tres años en finanzas y banca ha resuelto y documentado requerimientos de Data owners y dueños de negocio, y que su feedback destaca que además de señalar problemas propone soluciones.
• 07:23
  Background de miguelEstudió ingeniería mecánica, pero le gustó siempre la programación (torneos ACM). Lo que más disfruta es resolver los problemas más difíciles de la empresa.
• 08:13
  Ejemplo de problema retador e impactoUn proyecto de ciencia de datos con datos sensibles que los desarrolladores no podían ver. Miguel modeló el problema en términos matemáticos (unas 30 tablas), lo que aceleró el entendimiento de todas las áreas y permitió agregar o quitar tablas en el flujo de forma automática.
• 11:12
  Caso hipotético: Detección de transacciones fraudulentasMiguel plantea hablar con los Data owners de cada tabla (compras, transferencias, ingresos) para conocer sus criterios, KPI y rangos normales por tipo de cliente. Con eso se sistematizarían alertas, y más adelante se podría añadir machine learning.
• 14:20
  Feedback y consejos para entrevistasSe destaca la importancia de entender el problema de negocio y de ver si ya está resuelto antes de reinventar la rueda. Se pasa luego a la limpieza de datos, donde Miguel recurre de nuevo a los dueños de los datos.
• 17:38
  Manejo de datos nulosMiguel propone eliminar filas con pocos nulos o columnas con muchos, e imputar con media, mediana o un modelo cuando conoce bien la tabla. Se le advierte que primero hay que revisar si los nulos están repartidos al azar o concentrados en una categoría (ejemplo de clientes VIP). Se explica que imputar con un solo valor deforma la distribución y reduce la desviación estándar, y se sugiere usar un modelo como regresión lineal.
• 23:13
  División entre train y testMiguel parte por separar datos de entrenamiento y test, y entrenar primero un modelo base como referencia de métrica.
• 24:09
  Data LeakageMiguel explica que la separación debe hacerse antes de imputar para no usar información del test (por ejemplo, la media o mediana del test) en el entrenamiento, lo que daría resultados irreales y mal desempeño en producción.
• 27:07
  Entrenamiento del modeloSe plantea una clasificación binaria. Miguel detecta por sí mismo que hay desbalance de clases (por ejemplo, 1% de fraudes), que un modelo ingenuo daría 99% de precisión y que existen modelos especializados, aunque no recuerda sus nombres.
• 28:50
  Elección del mejor modelo y test de hipótesisEntre 10 modelos, uno con 98% no es necesariamente mejor que uno con 97%, porque puede ser suerte. Miguel propone repetir entrenamientos y usar un test de Student. Se explica variar la semilla pseudoaleatoria (por ejemplo, 100 iteraciones), obtener media y desviación estándar y aplicar un t-test; se menciona bootstrapping y que la desventaja principal es el tiempo computacional.
• 35:57
  Métrica a comparar y desbalanceMiguel elige una métrica que penalice los falsos negativos (recall), porque el fraude es lo que se quiere detectar y un falso positivo solo incomoda al cliente. Se explica el F1 score como media armónica entre precisión y recall.
• 39:00
  Producción y ejecución del modeloMiguel describe ejecutar el modelo, por ejemplo diariamente, con el mismo preprocesamiento y normalización del entrenamiento. Destaca que el valor está en que el usuario de negocio reciba las alertas (por correo o a los asesores) y tome decisiones.
• 41:24
  Conclusión de la primera parte y feedbackFeedback: falta de seguridad y energía al inicio, pausas y entonación ascendente. Se valora la proactividad, la comunicación, el entendimiento del negocio, separar train/test, detectar el desbalance y explicar los falsos negativos y el F1. Se critica no explicar bien cómo aplicar el test de hipótesis con muchos valores y no eliminar nulos por reflejo. Cris y un observador añaden comentarios sobre nervios y actitud.
• 51:51
  MemesPausa con memes de la semana sobre DeepSeek y OpenAI, AWS frente a Oracle y aranceles a librerías de Python. Luego se comentan preguntas típicas como "¿por qué deberíamos contratarte?" y "cuéntame sobre ti", que conviene preparar con tres puntos clave.
• 56:18
  Coding InterviewComienza la parte de código: explorar un dataset, limpiarlo y crear un modelo para predecir fraude. Se pide pensar en voz alta mientras se programa.
• 56:51
  Data CleaningMiguel corrige a mano el encabezado del CSV (caracteres especiales, primera columna sin nombre) por rapidez, y se le pide declarar siempre los atajos. Explora ~5000 filas, descarta ID, analiza país de origen, relación de cuentas, horario y monto, y decide eliminar los nulos de monto y frecuencia porque ningún caso fraudulento los tiene. La discusión sobre si las variables son independientes del fraude queda sin zanjar.
• 01:11:58
  Implementación de un modeloMiguel busca en Google el comando para separar train/test, usa estratificado para mantener la proporción de fraudes y entrena un KNN con n=20, evaluando con recall. Reconoce que algunas columnas son categóricas y que falta tratamiento de la hora.
• 01:17:53
  Feedback del códigoSe recomienda normalizar para KNN y probar Random Forest, que no requiere escalar. Se critica el arreglo manual sin avisar y los nombres de variables poco claros, y se valora haber detectado ID, el comportamiento cíclico de las horas y haber sido transparente al no recordar algo. El dataset es sintético, por lo que las variables no se correlacionan con el fraude.
• 01:23:40
  Reflexiones y preguntas finales de la entrevistaMiguel dice que necesita más práctica con pandas y elegir modelos rápido. Se pregunta si se contrataría para un puesto Junior y responde que tiene experiencia funcional pero debe reforzar lo técnico. Se aconseja preguntar al reclutador el tipo de entrevista.
• 01:30:26
  CierreSe invita a pedir más mock interviews por Discord, a dar like, suscribirse y comentar. El tema de la próxima semana son los avances del proyecto de creación de shorts.

Palabras clave