Cómo evaluar a ingenieros de Machine Learning en procesos de selección técnica

Por qué el proceso estándar de software no captura a los ingenieros ML

La ingeniería de Machine Learning es una disciplina que se sitúa entre la ciencia de datos y el software de producción. Un proceso que copia tu entrevista estándar de ingeniero senior — dos rondas de LeetCode, un diseño de sistemas, una entrevista de comportamiento — aprobará ingenieros full-stack excepcionales que no pueden poner en producción un modelo, y rechazará profesionales que pueden construir ML en producción pero escriben código de menos elegancia que un recién graduado con tres meses de práctica de LeetCode.

El proceso correcto mide cuatro cosas simultáneamente: el criterio de modelado del candidato, su capacidad para escribir código que un compañero puede mantener, su comprensión de cómo un sistema ML falla en producción, y su honestidad sobre qué sabe y qué no sabe. Ninguna de esas cosas se evalúa en una pregunta sobre árboles binarios.

Este artículo es para responsables de contratación y líderes técnicos que diseñan un proceso de entrevista para ingenieros ML desde cero — o que intentan corregir uno que sigue produciendo falsos positivos.

Las cuatro dimensiones que vale la pena evaluar

Una evaluación útil para ingenieros ML puntúa según estas dimensiones, con anclajes en cada nivel:

1. Criterio de modelado. Dado un objetivo de producto vago, ¿puede el candidato enmarcarlo como un problema ML, elegir un modelo inicial razonable, nombrar los modos de fallo y explicar por qué no usaría un enfoque más complejo?
2. Fundamentos de programación ML. ¿Puede escribir Python limpio, estructurar un script de entrenamiento, depurar un error de forma de tensor y razonar sobre qué hace realmente una operación NumPy a nivel de array?
3. Pensamiento de producción. ¿Comprende cómo se sirve el modelo, cómo cambian los datos de entrenamiento, cómo se calculan las características en línea versus fuera de línea, y cómo se detecta una degradación silenciosa?
4. Alcance honesto. ¿Puede decir "no sé, pero aquí es cómo averiguaría" sin pánico, y puede cuestionar un problema mal especificado?

Cada etapa del proceso debe diseñarse para evaluar una o dos de estas dimensiones, no las cuatro a la vez.

Etapa 1: Una evaluación de criterio de modelado, no una prueba de programación

La primera etapa técnica no debe ser una prueba de programación. Debe ser una conversación de 30–45 minutos, enmarcada como una entrevista de comportamiento estructurada, sobre un problema real.

Ejemplo de pregunta: "Tu responsable de producto quiere añadir una función que recomiende tres documentos de la base de conocimiento de la empresa cuando un empleado abre un nuevo ticket de soporte. ¿Qué preguntas haces antes de escribir código? ¿Cuál es tu primer modelo? ¿Qué podría salir mal?"

Qué debes escuchar:

• ¿Preguntó sobre volumen, latencia y qué significa "bien" antes de proponer un modelo?
• ¿Comenzó con algo aburrido (TF-IDF o una pequeña búsqueda de embeddings) antes de buscar fine-tuning?
• ¿Nombró un modo de fallo honesto sin ser solicitado (arranque en frío, ruido de etiquetas, bucles de retroalimentación)?
• ¿Distinguió entre métricas offline y éxito en línea?

Un candidato que salta directamente a "haría fine-tuning de un transformer" sin hacer una sola pregunta aclaratoria te está mostrando exactamente cómo diseñará sistemas en el trabajo. Esa es una señal.

Etapa 2: Un ejercicio para llevar a casa limitado con presentación defendida

Las rondas de programación pura para ML son una trampa. O el problema es lo suficientemente pequeño como para parecer un juguete, o es lo suficientemente realista como para que el candidato invierta 20 horas en ello y los candidatos más fuertes rechacen. Un ejercicio para llevar a casa limitado — limitado a dos horas, con la presentación ponderada tan pesadamente como el código — soluciona ambos.

Un buen ejercicio para llevar a casa para candidatos ML incluye:

• Un pequeño conjunto de datos real con una esquina sucia conocida
• Un objetivo vago ("predice X, optimiza para Y") con una o dos ambigüedades intencionales
• Una presentación requerida: decisiones tomadas, alternativas rechazadas, qué harías con una semana más
• Una permisión explícita para herramientas de IA, con la regla de que el seguimiento en vivo sondeará el razonamiento propio del candidato

La duración del ejercicio para llevar a casa importa. Pasadas dos horas, las tasas de finalización caen drásticamente y comienzas a seleccionar candidatos que casualmente tienen un sábado libre, no los ingenieros ML más fuertes.

Cuando llega la presentación, el análisis de coherencia de código de ClarityHire te proporciona una puntuación de autenticidad por presentación e identifica los patrones característicos del código generado por IA — pegados en bloque, sin depuración iterativa, casos extremos manejados defensivamente que el candidato nunca probó. Usa eso como contexto para el seguimiento en vivo, no como un veredicto.

Etapa 3: Programación en vivo más un diseño de sistema ML

La ronda presencial debe ser dos rondas técnicas, no cuatro. Los candidatos de ML se agotan rápidamente con entrevistas de programación apiladas, y obtienes más señal de la profundidad que de la amplitud.

Programación en vivo (60 minutos). Programar en pareja un ejercicio enfocado — implementar un pequeño bucle de entrenamiento, depurar un notebook con un error sutil, construir un transformador de características con un caso extremo difícil. Ejecutarlo en un editor real con ejecución, no en una pizarra. El editor de código colaborativo de ClarityHire te proporciona Monaco más ejecución integrada para que el candidato pueda ejecutar su código y veas el patrón de pulsaciones de un trabajo problem-solving auténtico.

La capa de integridad importa aquí. Si la biometría de pulsaciones del candidato y la coherencia de código se ven completamente diferentes en la ronda en vivo que en el ejercicio para llevar a casa, has aprendido algo útil para la revisión.

Diseño de sistema ML (60 minutos). Recorre la arquitectura de una característica ML en producción: flujo de datos, pipeline de entrenamiento, stack de servicio, monitoreo, cadencia de reentrenamiento y rutas infelices. Puntúa según las mismas cinco dimensiones que usa una rúbrica de diseño de sistemas — aclaración de requisitos, articulación de trade-offs, razonamiento de modos de fallo, conciencia de costos y respuesta al cuestionamiento — con una capa específica de ML: detección de drift, antigüedad de características, retardo de etiquetas y el problema de arranque en frío.

Qué puntuar y cómo

Usa una rúbrica estructurada, puntuada de forma independiente antes de la revisión. Para cada etapa, el entrevistador califica 1–4 en las dimensiones relevantes con descripciones de anclajes, luego confirma la puntuación antes de ver la evaluación de ningún compañero. Las fichas de entrevista estructuradas de ClarityHire bloquean la rúbrica pre-revisión específicamente para prevenir el efecto rebaño que arruina la mitad de todas las decisiones de contratación.

Pondera las dimensiones según el rol:

• Ingeniero ML orientado a investigación — pondera criterio de modelado y diseño de sistema ML fuertemente; la programación en vivo puede ser más ligera.
• Ingeniero ML aplicado / plataforma — pondera pensamiento de producción y programación en vivo; la pantalla de criterio de modelado es una verificación de piso.
• Ingeniero ML junior / recién graduado — pondera alcance honesto y fundamentos de programación ML; estás apostando por el crecimiento, no por la experiencia actual.

Errores comunes a evitar

• Evaluar solo trivialidades de PyTorch. Un candidato que memorizó la diferencia entre torch.cat y torch.stack no ha probado nada sobre si puede poner en producción un modelo.
• Preguntar LeetCode algorítmico para un rol de ingeniero ML. Un candidato perfectamente válido fallará esto y contratarás a la persona equivocada.
• Un ejercicio para llevar a casa de cinco horas. Esto es falta de respeto al candidato a nivel senior, y un sesgo de selección contra padres e candidatos subempleados.
• Sin componente de producción. Si tu proceso nunca pregunta sobre servicio, monitoreo o reentrenamiento, contratarás investigadores y los verás luchar en guardia.
• Un solo entrevistador en cada etapa. El drift en la contratación de ML entre entrevistadores es severo. Dos entrevistadores por etapa, calibrados trimestralmente, es el piso.

Qué hacer a continuación

Si estás a punto de abrir un rol de ingeniero ML:

1. Anota las cuatro dimensiones de puntuación antes de diseñar las preguntas.
2. Construye la pantalla de criterio de modelado primero — es la etapa más barata de ejecutar y el filtro de señal más alta.
3. Limita el ejercicio para llevar a casa a dos horas y pondera la presentación al 50% de la puntuación.
4. Decide qué pesos de proceso quieres para el rol específico (investigación, aplicado, junior) antes de que entre el primer candidato.
5. Bloquea la rúbrica en tu plataforma de entrevistas para que las puntuaciones de compañeros se confirmen de forma independiente y la revisión exponga desacuerdo real en lugar de reforzar la opinión más ruidosa.

El mercado para ingenieros ML en 2026 sigue siendo activo, y tu proceso compite por la atención con todas las demás empresas que contratan a las mismas personas. Un proceso claro, respetuoso y de dos etapas que haga las preguntas correctas superará un desafío de cuatro etapas que haga las equivocadas.