Cómo entrevistar a ingenieros de machine learning: Un manual 2026

Por qué los procesos de selección de ML de 2023 ya no funcionan

Una entrevista estándar de machine learning en 2023 pedía al candidato explicar sesgo-varianza, derivar regresión logística, codificar k-means y esbozar un pipeline de recomendaciones en una pizarra. En junio de 2026, las cuatro preguntas se resuelven en menos de treinta segundos por cualquier modelo que el candidato tenga abierto en otra pestaña. Las preguntas siguen siendo buenas — la señal se ha perdido.

Lo que no ha desaparecido es lo que realmente necesitas para contratar: criterio bajo incertidumbre, fluidez en MLOps, capacidad de depurar un modelo degradado en producción, y disposición para decir "no necesitamos machine learning para esto". A continuación está el proceso que vemos funcionando en 2026 para contratar ingenieros de ML, la rúbrica para puntuarlo y dónde aplicar señales de integridad para que la asistencia de IA no haga que el proceso sea inútil.

Qué cambió en los últimos 24 meses

Tres cambios que el proceso debe reflejar:

• Los LLMs democratizaron los fundamentos. Las preguntas definitivas, las derivaciones de algoritmos clásicos y las descripciones de selección de modelos estándar ahora son lo básico — cada candidato las acierta porque el modelo las acierta. No te dicen nada.
• La producción es la mayor parte del trabajo. Entrenar un modelo es quizás el 10% del trabajo. El resto es pipelines de datos, detección de drift, higiene de feature store, harnesses de evaluación, on-call para latencia de inferencia. Un proceso que no explora el trabajo en producción contrata investigadores para roles de ingeniería.
• "Ingeniero de ML" ahora abarca tres trabajos. ML clásico / tabular, deep learning / visión-NLP, e ingeniería de LLM aplicada / RAG / agentes. No ejecutes el mismo proceso para los tres. Elige la vía antes de escribir la rúbrica.

El proceso: cuatro etapas, ~5 horas en total

Un proceso que produce señal real en 2026:

1. Codificación ML aplicada (en directo, 60 min). Un pequeño problema de ML realista que el candidato resuelve con un entrevistador presente.
2. Diseño de sistema ML (en directo, 60 min). Diseño de un sistema de producción de extremo a extremo, con discusión explícita de coste, drift y evaluación.
3. Depuración en producción (asincróno + demostración en directo, 90 min). Un pipeline roto o un modelo degradado que el candidato diagnostica.
4. Comportamiento / colaboración (en directo, 45 min). Propiedad de proyectos pasados, conflicto, experiencia on-call.

Si solo puedes ejecutar dos etapas, ejecuta #2 y #3. Tienen la validez predictiva más alta para el trabajo de ingeniería de ML y el riesgo de fuga de LLMs más bajo.

Etapa 1: Codificación ML aplicada — hazla específica, no algorítmica

Reemplaza el clásico "implementa regresión logística desde cero" con una tarea aplicada de 45 minutos: aquí hay un pequeño conjunto de datos, aquí hay un objetivo, construye una línea base, justifica la métrica y entrega un notebook que otro ingeniero podría revisar. El candidato usa un editor real con pandas, scikit-learn y PyTorch instalados. Se les anima a usar documentación. Si pueden pegar completamente desde un LLM o no es tu elección — pero sé explícito de cualquier manera (véase nuestro punto de vista sobre el uso de IA en rondas de código).

Lo que estás evaluando:

• Encuadre del problema. ¿Preguntaron para qué es la predicción antes de entrenar algo?
• Elección de evaluación. ¿Por qué esta métrica? ¿Cómo se ve la matriz de confusión en el umbral operativo?
• Disciplina de iteración. ¿Validaron la línea base antes de ajustar? ¿Filtraron el conjunto de prueba?
• Calidad del código. ¿Reproducible? ¿Otro ingeniero podría ejecutar este notebook? ¿Tienen sentido las celdas?

Un candidato que silenciosamente ejecuta ocho celdas de ajuste de modelo y produce un AUC de 0,94 no te ha mostrado nada. Un candidato que encuadra el problema, construye una línea base tonta y llega a 0,78 con razonamiento claro es una contratación más fuerte.

Usa una rúbrica estructurada para que dos entrevistadores que califican el mismo notebook converjan en una puntuación.

Etapa 2: Diseño de sistema ML — la hora con más señal que ejecutarás

Elige un problema que se mapee a tu superficie de producto actual: "diseña un pipeline de predicción de abandono que se ejecute diariamente y alimente el sistema de marketing del ciclo de vida". O para roles de LLM: "diseña un sistema RAG para tickets de soporte con un presupuesto de latencia de 200ms p95".

El candidato tiene que hablar sobre:

• Fuentes de datos, requisitos de actualización, evolución del esquema
• Ingeniería de características, protección contra fuga, elección de feature store (o sin feature store, y por qué)
• Selección de modelo con compensaciones explícitas de coste / latencia / precisión
• Harness de evaluación: métricas offline, métricas online, la brecha entre ellas
• Implementación: modo sombra, canario, criterios de reversión
• Monitoreo: data drift, prediction drift, business-metric drift, umbrales de alertas
• On-call: qué página despierta a alguien, qué runbook siguen

Un modo de fallo común: los candidatos describen la arquitectura pero nunca nombran un solo número — sin objetivo de QPS, sin presupuesto de latencia, sin cadencia de reentrenamiento. Presiona por números. El diseño de sistemas de ML sin números es escritura creativa.

Esta etapa es el análogo más cercano al trabajo que el ingeniero hará el lunes. Ponle más peso en tu tarjeta de puntuación.

Etapa 3: Depuración en producción — lo que el LLM no puede fingir

Envía al candidato una prueba para hacer en casa: aquí hay un notebook + un pequeño conjunto de datos + un artefacto de modelo. La métrica de evaluación del modelo en el conjunto de retención se ve excelente. La métrica de producción del modelo se ha estado degradando silenciosamente durante seis semanas. Encuentra el error.

Planta un fallo realista: una característica que solía poblarse el 99% del tiempo ahora se puebla el 60%, con los valores faltantes siendo rellenados silenciosamente con la media de la columna (y la media es incorrecta). O los datos de entrenamiento filtraron la etiqueta a través de una característica casi duplicada. O el modelo de embedding que usa el equipo fue cambiado a una nueva versión y el índice no fue reconstruido.

El candidato entrega un diagnóstico escrito y una corrección propuesta, luego la defiende en una demostración de 30 minutos. Esta es la ronda donde descubres si realmente han sido propietarios de un sistema en producción. Es también la ronda donde la asistencia de LLM ayuda menos — el error no está en el código, está en los datos y la historia de la implementación. El candidato tiene que razonar sobre un sistema, no regurgitar una definición.

Sigue el patrón de demostración: prueba específicamente, exige que defienda su hipótesis, pregunta qué habrían entregado primero.

Etapa 4: Comportamiento — elige historias de colaboración e incidentes

Salta "cuéntame un momento en el que liderizaste un proyecto." Pregunta:

• "Recórrme el último incidente en producción que poseyiste. ¿Qué se rompió, qué entregaste, qué cambiaste en el proceso después?"
• "Cuéntame un momento en el que decidiste no usar ML para un problema. ¿Qué entregaste en su lugar?"
• "¿Cuándo fue la última vez que mataste un modelo en producción? ¿Por qué?"

Estas preguntas filtran ingenieros que han entregado, no investigadores que han publicado. Califica con una rúbrica estructurada para que no colapse en vibes.

Mantenerlo honesto: dónde importan más las señales de integridad

La ronda de fundamentos se ha ido porque los LLMs la dominaron; eso deja las Etapas 1 y 3 como las rondas donde la asistencia de IA distorsiona materialmente la señal. Dos cosas que hacer:

• Ejecuta biometría de pulsación de teclas y análisis de coherencia del código en la ronda de codificación aplicada. Los eventos de pegado en ráfaga, cambio de autoría a mitad del notebook y desajustes de fluidez código-comentario todos salen a la superficie en el informe de integridad.
• Usa la demostración de depuración de producción como la verificación real. Un candidato que pegó su diagnóstico desde un LLM no puede defenderlo cuando preguntas "¿cuál es el siguiente experimento que ejecutarías?" La demostración es más fiable que cualquier clasificador.

El objetivo no es prohibir la asistencia de IA — los ingenieros la usan en el trabajo. El objetivo es confirmar que la persona que estás contratando es la persona que puede hacer el trabajo.

Qué evitar

• "Codifica regresión lineal desde cero." Cualquiera puede pegarlo. No te dice nada.
• "¿Cuál es la diferencia entre regularización L1 y L2?" Lo mismo.
• Puzles algorítmicos estilo LeetCode. Los ingenieros de ML ocasionalmente necesitan estructuras de datos, pero una rutina diaria de leet no predice ingeniería de ML. Si quieres una pantalla de codificación, usa un pequeño problema de manipulación de datos con pandas en su lugar.
• Pruebas para hacer en casa de dos horas sin demostración. La demostración es lo que hace que la prueba para hacer en casa funcione.

Qué hacer a continuación

Elige la vía (tabular / DL / LLM-aplicada), escribe una rúbrica para cada etapa antes de la primera entrevista, y ejecuta el proceso de extremo a extremo en un ingeniero interno para calibrar. Rastrea la correlación de puntuación a rendimiento en seis meses — ese bucle de retroalimentación es lo que hace que el proceso sea mejor el próximo trimestre.

Los equipos que contratan bien en 2026 no están haciendo preguntas más difíciles. Están haciendo preguntas donde la respuesta requiere que el candidato piense en voz alta, defienda elecciones, y razone sobre sistemas que el LLM nunca ha visto. El proceso anterior está construido alrededor de ese principio.