Mock interview de ML engineer — práctica con IA

Las entrevistas de ML engineer caen en algún punto entre data science y backend, y los candidatos que lo hacen bien son los que dejan de fingir ser una cosa o la otra. Los hiring managers quieren a alguien capaz de coger un notebook de Jupyter, entregarlo como servicio y darse cuenta de cuándo el AUC offline deja de predecir el comportamiento online. Esta guía muestra cómo usar mock interviews con IA para ensayar los loops de ML exactos que producen ofertas — no el gauntlet de coding estilo FAANG, sino la conversación práctica de «¿de verdad puedes entregar un modelo?».

Rondas típicas de una entrevista de ML engineer

El loop de ML engineer varía muchísimo según la empresa. En empresas ML-first (laboratorios de investigación, startups de IA), espere 5–6 rondas: un phone screen de fundamentos, una entrevista de coding (Python más NumPy/PyTorch), una ronda de ML system design, una ronda de discusión de papers o de research-fit, una behavioral y una charla con el hiring manager. En empresas de producto (la mayor parte del mercado), el loop se comprime a 4 rondas: un phone screen, una entrevista de coding, un ML system design y case study, y una behavioral. Tiempo total: 5–7 horas de conversación a lo largo de 1–2 días.

La ronda de mayor rendimiento para la práctica de mock con IA es el ML system design. Mapea casi a la perfección con el formato del mock — prompt abierto («diseña un sistema de recomendación para vídeos cortos»), ida y vuelta sobre tradeoffs, puntuación según estructura y profundidad. La ronda de case study es el segundo mejor objetivo: «la accuracy de nuestro modelo de churn cayó de 0,84 a 0,71 la semana pasada, ¿qué haces?» — exactamente el tipo de investigación que se va desarrollando y que los mocks con IA manejan bien.

Principales temas técnicos

Feature engineering y data pipelines

El listón ha pasado de «¿sabes escribir una window function en SQL?» a «¿sabes diseñar un feature store?». Espere preguntas sobre training-serving skew, point-in-time correctness, features online vs batch, y cuándo materializar vs computar bajo demanda. Tooling: Feast, Tecton, soluciones in-house — conozca los tradeoffs. Una pregunta favorita: «tu modelo predice bien offline pero se degrada online — explícame tu investigación». Las respuestas fuertes encadenan feature freshness, label leakage, distribution shift y bugs de serving-time.

Entrenamiento y modelado

La mayoría de los roles de product ML no exigen que inventes arquitecturas novedosas. Exigen que elijas la clase de modelo correcta, depures el entrenamiento y expliques tradeoffs. Esté listo para hablar de: gradient boosting vs redes neuronales para datos tabulares, cuándo los transformers son excesivos, regularización más allá de L2 (dropout, early stopping, data augmentation), el tradeoff bias-variance en términos concretos, y qué aspecto tiene realmente «este modelo está overfit» en las curvas de loss. Saque a relucir el desbalanceo de clases, la calibración y la diferencia entre accuracy y AUC sin que te lo pidan — a los entrevistadores les encanta cuando anticipas la siguiente pregunta.

Model serving y MLOps

Aquí es donde el ML engineer se diferencia del data scientist. Esté listo para hablar de: batch vs real-time serving, latency budgets (qué significa realmente 50 ms p99 para un modelo del tamaño de XGBoost vs un LLM de 7B), versionado de modelos, infraestructura de A/B testing para ML (no solo para botones), shadow deployment, estrategia de rollback cuando un modelo regresa, y patrones de feature flag para ML. Herramientas: BentoML, KServe, Triton, Ray Serve, vLLM. Conocer una bien gana a conocer cinco nombres.

Evaluación y métricas

Las métricas online rara vez se mueven igual que las offline. Esté listo para explicar por qué y qué harías al respecto. Temas: correlación offline-online, métricas proxy, evaluación contrafactual, off-policy estimation para ranking, poblaciones holdout, y las trampas concretas del modelado de CTR (selection bias, position bias). Una pregunta común: «el equipo quiere entregar un modelo que mejora el NDCG un 2 % offline — ¿qué dices?». Las respuestas que interrogan el framework de eval puntúan más alto que las que simplemente se fían del número.

LLMs y el nuevo stack

La mitad de las ofertas de ML en 2026 mencionan LLMs aunque el rol no sea específico de LLM. Esté listo: prompt engineering vs fine-tuning vs RAG (cuándo eliges cada uno), evaluación de embeddings, elección de vector DB (Qdrant vs pgvector vs Pinecone), economía de latencia y coste a escala, mitigación de alucinaciones. Si el rol es específico de LLM, añada: curación de datos de entrenamiento, diseño del eval harness (el tuyo propio, no solo MMLU), distillation, tradeoffs de cuantización.

Preguntas de escenario habituales

• «Diseña un sistema de recomendación para una app de vídeo corto estilo TikTok, 100M DAU.» (Candidate generation, ranking, diversidad, cold start, feedback loops.)
• «La precision de tu modelo de fraude cayó de 0,91 a 0,74 de la noche a la mañana. ¿Qué haces?» (Distribution shift, retraso de labels, cambio en el feature pipeline, adversarial drift.)
• «Construye un copiloto de soporte al cliente con LLM. ¿Cuál es tu framework de eval?» (Eval set offline, ratings humanos online, suite de regresión, tests de alucinación.)
• «El equipo quiere hacer fine-tune de Llama para code review. ¿Deberían?» (Coste vs prompt engineering vs RAG, disponibilidad de datos, eval, drift con el tiempo.)
• «Tienes un clasificador binario con 99,5 % de accuracy. ¿Deberías entregarlo?» (Desbalanceo de clases, base rate, coste de negocio de falsos positivos vs negativos, calibración.)

Áreas de enfoque behavioral — qué buscan los hiring managers

Los hiring managers de ML buscan tres señales menos obvias. Primero, confianza calibrada — ML es la disciplina en la que sobreafirmar te delata ante los datos. Los candidatos fuertes dicen «no estoy seguro, así es como lo averiguaría» sin pestañear. Segundo, sentido de negocio — los ML engineers capaces de conectar un lift de 0,03 en NDCG offline con un valor en dólares consiguen ofertas senior más rápido que los que solo saben hablar de matemáticas. Tercero, colaboración con personas no-ML — la mayoría del trabajo de ML fracasa por la comunicación con PM, data engineering u ops, no por la arquitectura del modelo. Espere prompts sobre un proyecto que fracasó, y responda con la fricción cross-funcional, no con la algorítmica.

Cómo usar la práctica de mock con IA para este rol

Ponga el tipo de entrevista en «ML System Design» y elija su seniority con honestidad. Los loops de ML senior esperan que lideres la conversación; el nivel medio espera que respondas bien a los prompts; el junior espera fundamentos limpios. Pegue la oferta si la tiene — la IA pondera las preguntas hacia el stack de la empresa (las empresas de recsys reciben más profundidad de ranking, las de LLM reciben más profundidad de eval y serving).

Para practicar coding, use el mock para el walkthrough verbal de un pipeline de ML («¿cómo implementarías un leave-one-out cross-validation para un forecast de series temporales?») y combínelo con un notebook real. No lo uses como sustituto de escribir PyTorch de verdad.

Un drill que rinde rápido: haz cinco case studies seguidos en los que hagas triage de un modelo degradado. El reconocimiento de patrones de «¿esto es label leakage, distribution shift o un bug del pipeline?» es la habilidad de entrevista más transferible en ML.

Preguntas frecuentes