Cómo Evaluar Habilidades de Ingeniería de Prompts al Contratar en 2026

Qué significa "ingeniería de prompts" en la contratación de 2026

Hace dos años, "prompt engineer" significaba principalmente "conoce las palabras mágicas". Hoy la profesión se ha dividido en tres especializaciones reales, y la evaluación que construyas depende de cuál estés buscando:

• Prompt engineer aplicado. Construye prompts de producción dentro de una aplicación, evalúa resultados, depura por qué un modelo cambió de comportamiento después de una actualización del proveedor. Vive en código, en harnesses de evaluación y en los logs de API.
• Prompt-systems engineer. Diseña la orquestación alrededor del prompt — retrieval, tool use, guardrails, fallbacks. Más cercano a un backend engineer que piensa en términos de tokens.
• Conversational designer / especialista en prompts. Escribe prompts y personalidades para interfaces de producto (soporte, ventas, coaching). Más cercano a UX writing con un toque técnico.

Si tu evaluación es la misma para los tres, contratarás a la persona equivocada en al menos dos de ellos. Este artículo se enfoca en los dos primeros, donde el proceso técnico es más importante.

Qué evaluar (y qué no)

Evalúa esto:

• Disciplina de evaluación. ¿Puede el candidato escribir un pequeño conjunto de evaluación antes de escribir el prompt y usarlo para decidir cuándo un prompt es mejor que otro?
• Razonamiento sobre modos de fallo. Dado un prompt y una muestra de salidas malas, ¿puede hipotetizar qué está fallando y qué palanca tirar — temperatura, system prompt, ejemplos few-shot, cambios en retrieval, forma de tool-call?
• Conciencia de costo y latencia. ¿Sabe cuánto le cuesta su prompt por llamada, qué compraría una reducción del 50%, y qué optimización perdería menos calidad?
• Leer la mente del modelo, no la propia. Cuando el candidato itera un prompt, ¿responde a lo que el modelo realmente hizo o a lo que esperaba que hiciera?

No evalúes esto:

• Patrones de prompts memorizados ("chain-of-thought", "ReAct", "tree-of-thought"). Recitar el catálogo no demuestra nada sobre si pueden aplicarlo.
• Los quirks actuales de un modelo de proveedor específico. Los quirks cambiarán el próximo trimestre.
• Si pueden producir un prompt "perfecto" en 10 minutos. El trabajo real con prompts es iterativo, y pedir excelencia de una sola vez selecciona por memorización, no por habilidad.

Etapa 1: Un breve MCQ sobre fundamentos de LLM

Una evaluación de primera ronda de 20 minutos con 10-15 preguntas de opción múltiple filtra a los candidatos que han "usado ChatGPT mucho" y se llaman a sí mismos prompt engineers. Cubre conceptos en los que deberían ser fluidos: tokens vs. caracteres, por qué temperatura 0 no es determinista entre proveedores, qué cuestan las ventanas de contexto, cuándo retrieval gana a fine-tuning, y qué miden los harnesses de evaluación.

Construye el banco a partir de conceptos, no de trivialidades de proveedor. El constructor de evaluaciones MCQ de ClarityHire soporta preguntas agrupadas con orden aleatorio para que los candidatos no se enseñen unos a otros en Discord. Para este rol específicamente, no uses MCQ para la decisión final — úsalo como una verificación de piso.

Etapa 2: Un take-home con un pequeño conjunto de evaluación imperfecto

Esta es la etapa de mayor señal. Dale al candidato un pequeño conjunto de datos de 40-80 ejemplos de entrada con salidas deseadas (resúmenes de llamadas con calidad evaluada a mano, ejemplos de clasificación con casos intencionalmente ambiguos, un pequeño corpus RAG con tres trampas). Pídele que:

1. Construya un conjunto de evaluación a partir de los datos — incluyendo las métricas que usaría y por qué.
2. Escriba un prompt base y reporte sus puntuaciones.
3. Itere al menos tres versiones, con el delta de puntuación y una oración explicando el cambio.
4. Envíe un breve resumen de los compromisos que consideró, qué haría con otro día, y qué fallos no corrigió.

Una duración útil de take-home para este trabajo es 90-120 minutos, con límite. Por debajo de 60, solo aprendes si pueden escribir un prompt. Por encima de 2 horas, seleccionas a quien tiene un sábado libre, no a los candidatos más fuertes.

Lo que estás evaluando:

• ¿Construyeron una evaluación antes de iterar o iteraron por intuición?
• ¿Cada versión de prompt hizo un cambio específico y defendible?
• ¿Detectaron los casos intencionalmente ambiguos o los ignoraron?
• ¿Fue el resumen específico sobre compromisos o fue copy de marketing de su propio trabajo?

Esta es también la etapa donde los candidatos asistidos por IA simplemente pueden hacer que otro LLM escriba el envío completo. El análisis de coherencia de código de ClarityHire ejecuta una verificación de autenticidad sobre los prompts y resumen enviados específicamente para detectar los patrones característicos de respuestas generadas por LLM — prosa demasiado fluida, advertencias defensivas que el candidato nunca probó, y ausencias convenientes de la iteración desordenada que dejaría un humano. Úsalo como contexto para el seguimiento en vivo, no como veredicto.

Etapa 3: Una sesión de trabajo en vivo con un LLM

Sesenta minutos, pantalla compartida, en un editor real con acceso a API — no una interfaz de chat. El candidato recibe un problema nuevo de forma similar al take-home pero con un giro que no pudo haber preparado. Un nuevo modo de fallo en los datos, un presupuesto de latencia más ajustado, un cambio de un modelo a otro durante la sesión.

Lo que debes escuchar:

• ¿Leen cuidadosamente la salida del modelo antes de cambiar el prompt o adivinan?
• Cuando el modelo devuelve basura, ¿piensan en por qué antes de recurrir a "sé más cuidadoso" en el system prompt?
• ¿Forman una hipótesis, aíslan una variable y la prueban — o hacen diez cambios a la vez?
• ¿Dicen "No sé qué está haciendo este modelo aquí, déjame hacer una prueba rápida" sin entrar en pánico?

Esta etapa reemplaza la ronda de live coding en un proceso de software. La habilidad siendo probada es la misma — razonamiento diagnóstico rápido bajo observación — pero el medio es diferente.

Etapa 4: Una entrevista sobre modos de fallo y producción

Una conversación estructurada de 45 minutos sobre producción. Trae ejemplos reales (anonimizados) de prompts que funcionaron en dev y se rompieron en producción, luego pídele al candidato que los diagnostique. Prompts útiles:

• "La puntuación de evaluación de este prompt bajó 15% de la noche a la mañana sin un deploy. ¿Qué investigas primero?"
• "Esta salida es correcta el 95% de las veces e incorrecta catastróficamente el 5%. Recórreme tu plan para llevar lo catastrófico a menos del 0,5% sin perder el 95%."
• "Tu agente de tool-calling entró en un bucle de reintento de 12 pasos y costó 40$ en una única consulta de usuario. ¿Cómo encuentras la causa?"

Esta ronda prueba la dimensión de pensamiento en producción que un take-home no puede alcanzar, y claramente separa a los candidatos que han enviado prompts a usuarios reales de aquellos que solo han construido demos.

Puntúa con una rúbrica, no con novedad

Usa una escala de 1-4 en cuatro dimensiones — disciplina de evaluación, razonamiento sobre modos de fallo, pensamiento en producción, comunicación — anclada a descripciones específicas de cómo se ve cada puntuación. Las tarjetas de puntuación de entrevistas estructuradas de ClarityHire bloquean la rúbrica y requieren envío independiente de puntuaciones antes del debrief, lo que importa más aquí que en cualquier otro proceso técnico porque "el modelo dijo algo genial" es la señal falsa más seductora en la industria en este momento.

Pondera las dimensiones según el rol:

• Prompt engineer aplicado. Peso pesado en disciplina de evaluación y razonamiento sobre modos de fallo.
• Prompt-systems engineer. Peso pesado en pensamiento en producción; la sesión en vivo puede inclinarse hacia depuración de orquestación.
• Conversational designer. Peso más ligero en evaluación y sesiones en vivo, más pesado en comunicación y revisión de portafolio.

Consideraciones de integridad específicas para contratación de IA

La ironía de contratar prompt engineers es que son los candidatos mejor equipados para usar IA para falsificar la evaluación. Tres ajustes prácticos:

1. Haz el conjunto de datos del take-home personalizado. Un conjunto de datos público estándar ya estará en el cookbook de prompts de alguien. Uno pequeño generado internamente no lo está.
2. Prueba el take-home en vivo. Un seguimiento de 20 minutos sobre "¿por qué hiciste este cambio específico entre v2 y v3?" encuentra a los candidatos que realmente hicieron la iteración. Los envíos pegados de IA no tienen un autor que pueda responder.
3. Usa señales de integridad como iniciadores de conversación. La biometría de pulsaciones, eventos de paste y coherencia de código te dan contexto para el debrief. Nunca los uses para auto-rechazar — en este nivel de habilidad, perderás candidatos fuertes por falsos positivos.

Qué hacer a continuación

Si estás a punto de abrir un puesto de ingeniería de prompts:

1. Decide cuál de las tres especializaciones realmente necesitas antes de escribir la descripción del trabajo.
2. Construye el conjunto de datos del take-home a partir de tu propio producto o dominio, no de un benchmark público.
3. Elige las cuatro dimensiones de puntuación y pondera según la especialización antes de diseñar preguntas.
4. Empareja el take-home con una sesión de trabajo en vivo y una conversación de producción — ninguno solo es suficiente.
5. Bloquea la rúbrica en una plataforma de entrevistas estructuradas para que el debrief revele desacuerdo real en lugar de consenso alrededor de la respuesta que suena más impresionante.

El mercado para prompt engineers en 2026 todavía tiene más puestos abiertos que candidatos calificados. Tu proceso compite por atención con todos los otros equipos de IA contratando a las mismas personas, y los candidatos que pueden pasar un proceso serio sabrán — en la primera ronda — si tu proceso es serio o teatro.