Qué prueba técnica tomarle a un candidato de IA (y cuál no sirve)

El error de evaluar el examen y no el criterio

Casi toda empresa que contrata a alguien para un puesto de IA arma la prueba pensando “quiero ver si sabe programar” o “quiero ver si conoce los modelos”. El resultado casi siempre es el mismo: un examen de trivia disfrazado de evaluación técnica. Preguntas sobre arquitecturas de modelos, acertijos de algoritmos sacados de una entrevista de ingeniería de software, o el clásico encargo de “arma un chatbot” sin ningún contexto de negocio detrás.

El problema no es que esas preguntas sean difíciles. El problema es que no predicen nada sobre el trabajo real. Un candidato puede recitar de memoria la diferencia entre dos arquitecturas de modelos y no tener idea de cómo priorizar qué proceso automatizar primero en tu operación. Puede resolver un acertijo de programación en diez minutos y quedarse en blanco cuando le preguntas qué haría si el área comercial se resiste a usar la herramienta que acaba de construir.

Esto pasa porque quien diseña la prueba copia el molde de una entrevista de ingeniería de software, donde sí tiene sentido medir código bajo presión, y lo aplica a un puesto que en realidad se parece más al de un gerente de operaciones con criterio técnico. Esa confusión de rol produce una prueba que filtra al candidato equivocado: descarta al que sabía resolver tu problema porque no rindió bien el examen, y aprueba al que domina el vocabulario pero nunca ha tenido que sostener un resultado frente a un gerente.

La consecuencia se paga después, no en la entrevista. Contratas a alguien que suena impecable en la jerga técnica y a los tres meses sigue sin mover ningún número del negocio, porque nadie evaluó si sabía diagnosticar un proceso: solo si sabía usar una herramienta.

Qué es una prueba técnica de IA (y qué no)

Antes de diseñar la prueba hay que tener clara la definición de lo que se está midiendo. No es un examen de conocimientos ni un filtro de vocabulario: es la herramienta que te dice si esa persona sabe convertir un dolor de negocio en una decisión con criterio.

• No es un examen de memoria sobre nombres de modelos, versiones o parámetros técnicos.
• No es un acertijo de programación de los que se usan para filtrar ingenieros de software junior.
• No es “arma un chatbot” en un día, sin proceso definido, sin dolor real ni usuario detrás.
• No es medir cuántas herramientas conecta el candidato ni qué tan rápido arma un flujo automatizado.
• No es un examen que solo un técnico puede calificar: si dirección no entiende la respuesta, la prueba está mal diseñada.

Una prueba técnica de IA bien diseñada se parece más a un caso de consultoría que a un examen de programación. No mide si el candidato sabe escribir código elegante: mide si sabe leer un proceso, encontrar dónde está el dolor real y proponer un camino con criterio, sabiendo qué se puede resolver con IA y qué no.

El caso de negocio: la única prueba que sí sirve

Si quieres saber cómo va a trabajar un candidato en tu operación, entrégale un fragmento real de tu operación. No un ejercicio abstracto ni un problema de manual: un proceso concreto de tu empresa, con un dolor conocido, con datos reales o razonablemente cercanos a la realidad. Esto no es un lujo de empresas grandes con equipo de RRHH sofisticado; es el mínimo indispensable para que la prueba prediga algo.

Cómo armar el caso

• Parte de un proceso real de tu empresa con un dolor conocido: tiempo de respuesta a leads, cuellos de botella en soporte, reportes que tardan días en cerrarse.
• Da contexto de negocio, no solo datos técnicos: volumen actual, costo aproximado del problema, quién lo sufre dentro de la operación.
• Pide un diagnóstico antes que una solución: que identifique qué parte del proceso se puede automatizar, cuál no, y por qué.
• Deja espacio para preguntas: un candidato que no pregunta nada sobre el proceso real es una señal débil, no de seguridad.
• No exijas código productivo: un prototipo simple, un flujo dibujado a mano o una propuesta escrita con criterio valen más que código bonito sin contexto de negocio.

Este es exactamente el criterio que separa a un automatizador de un gerente de IA: el primero necesita que le entreguen el problema resuelto en instrucciones técnicas; el segundo sabe encontrar el problema por su cuenta. Si quieres profundizar en esa transición, el sitio tiene el recorrido /recursos/roadmap-ia-de-automatizador-a-gerente-ia y el contenido /contenido/de-automatizador-a-gerente-ia, que explican cómo se construye ese criterio con el tiempo.

Qué NO preguntar (aunque parezca riguroso)

Hay preguntas que suenan exigentes y en realidad no miden nada relevante para el puesto. Estas son las que más se repiten en procesos de selección de IA copiados de moldes de ingeniería de software, y las que deberías sacar del tuyo:

• Preguntas de memoria sobre modelos: qué diferencia hay entre dos arquitecturas, cuántos parámetros tiene tal modelo o cuál es la ventana de contexto de una versión específica.
• Acertijos de algoritmos típicos de una entrevista de ingeniería de software, como invertir un árbol o encontrar el ciclo más corto en un grafo, sin relación con el trabajo real del puesto.
• “Arma un chatbot” sin contexto: sin proceso, sin dolor definido, sin usuario real detrás; solo mide si sabe conectar una API en poco tiempo.
• Preguntas trampa de vocabulario técnico (“¿qué es RAG?”, “¿qué es un agente?”) que evalúan si memorizó un glosario, no si sabe aplicar el concepto a tu operación.
• Pruebas cronometradas de código puro, que premian velocidad de tecleo sobre calidad de diagnóstico y terminan filtrando a favor del candidato equivocado.

Estas preguntas siguen usándose porque son cómodas de calificar: tienen una respuesta correcta y no exigen que quien evalúa entienda de negocio. El problema es que optimizan por lo fácil de medir, no por lo que de verdad importa en el puesto. Un examen fácil de calificar y una contratación acertada casi nunca son la misma cosa.

La rúbrica: qué puntuar y cómo

Una buena rúbrica no pone nota al código ni a la elegancia de la respuesta. Puntúa cuatro cosas, en este orden de peso, y cada una vale más que la anterior en la decisión final.

Diagnóstico

¿El candidato identificó correctamente dónde está el dolor del proceso, o se fue directo a proponer una herramienta sin entender el problema? El diagnóstico es la habilidad más escasa y la más valiosa: separa a quien resuelve tu problema de quien resuelve el problema que él ya sabe resolver de antes.

Criterio de proceso

¿Supo distinguir qué parte del proceso conviene automatizar y cuál no? Un candidato con criterio de proceso reconoce cuándo la automatización agrega riesgo, cuándo el cuello de botella es humano o de decisión y no técnico, y cuándo el problema real es de datos, no de modelo.

Cómo maneja la ambigüedad

El caso de negocio real siempre tiene información incompleta, igual que tu operación. ¿El candidato pidió los datos que faltaban, hizo supuestos explícitos y razonables, o se paralizó, o inventó certeza donde no la había? Cómo se comporta frente a la ambigüedad es más predictivo que cualquier respuesta técnica perfecta.

Cómo explica

¿Puede explicar su propuesta a alguien de dirección sin jerga, en términos de tiempo, costo y resultado? Si la única forma de entender su respuesta es tener formación técnica, tienes un problema: ese candidato no va a poder alinear al resto de la empresa alrededor de lo que construya.

Cómo correr la prueba sin ser técnico

No necesitas saber programar para evaluar bien esta prueba. Necesitas escuchar las cosas correctas y desconfiar de las respuestas que suenan bien pero no dicen nada.

• Pide que explique su propuesta en dos minutos, sin tecnicismos. Si no puede, es una alerta, no un detalle menor.
• Pregunta “por qué” tres veces seguidas sobre alguna decisión de su propuesta. Un candidato con criterio real sostiene el argumento; uno que memorizó un guion se pierde.
• Fíjate en las preguntas que hace antes de responder, no solo en la respuesta final. Quien pregunta por el volumen, el costo actual o quién sufre el problema está pensando en negocio.
• Compara cuánto tiempo dedica al “problema” frente al que dedica a la “herramienta”. Si el noventa por ciento de su respuesta habla de la herramienta y casi nada del proceso, ya tienes tu respuesta.
• Involucra a alguien del área afectada por el proceso del caso (ventas, operaciones, soporte) en la revisión: esa persona detecta enseguida si la propuesta tiene sentido operativo real.

Cómo se ve en la práctica

Una distribuidora mediana, alrededor de ochenta personas, en Perú, buscaba a alguien para liderar la adopción de IA en su área comercial. El proceso de selección inicial filtraba por currículum: maestrías, certificaciones, cursos de modelos generativos. Los tres finalistas técnicamente más fuertes en papel tenían discursos casi idénticos: hablaban de agentes, de automatización y de integración de herramientas con soltura.

El dueño de la empresa, con apoyo externo puntual, cambió la prueba a último momento. En vez de pedirles que armaran un demo, les entregó un caso real: el proceso de seguimiento a cotizaciones, con datos reales del volumen mensual, el tiempo promedio de respuesta y el costo aproximado de las cotizaciones que se perdían por demora. Les pidió un diagnóstico escrito, no un prototipo.

Dos de los tres finalistas técnicamente más fuertes propusieron directamente un flujo automatizado de respuesta con IA generativa, sin preguntar por qué se perdía tiempo en el proceso. El tercer candidato, el que en papel parecía el más débil (sin maestría, con experiencia mixta entre operaciones y ventas), hizo algo distinto: preguntó quién aprobaba las cotizaciones, cuántas pasaban por más de una persona y si existía un cuello de botella de decisión antes de llegar a la parte técnica. Encontró que el verdadero atraso estaba en una aprobación manual innecesaria, no en la generación de la cotización.

Contrataron al tercero. A los cuatro meses, el tiempo de respuesta a cotizaciones bajó de manera medible y la tasa de cierre de esas cotizaciones subió, no porque hubiera un modelo más sofisticado, sino porque el proceso se rediseñó primero y la IA se usó donde de verdad aportaba. El candidato “más técnico” en papel nunca hubiera llegado a ese diagnóstico, porque nunca preguntó por el proceso.

Mi criterio

Cómo saber si lo hiciste bien

No hay una prueba perfecta, pero sí señales claras de que tu proceso de evaluación está midiendo lo correcto. Antes de cerrar tu vacante, revisa esto.

• La prueba usa un proceso real de tu empresa, no un ejercicio genérico sacado de internet.
• Puedes explicarle el resultado a otro directivo sin traducir jerga técnica primero.
• El candidato hizo preguntas sobre el negocio antes de proponer una solución.
• La rúbrica pesa más el diagnóstico que el código o la herramienta usada.
• Alguien del área afectada por el proceso participó en la revisión, no solo el equipo técnico.

Si tu prueba técnica cumple estas cinco condiciones, estás evaluando lo que de verdad predice el desempeño en el puesto: criterio, no vocabulario. Si no las cumple, probablemente estás a punto de contratar al candidato que mejor rinde examen, no al que mejor te va a resolver el problema.