Construir evaluaciones justas: diseño de preguntas MCQ, código y ensayo

Por qué el diseño importa más de lo que crees

La calidad de tus evaluaciones técnicas determina directamente la calidad de tus decisiones de contratación. Las preguntas mal diseñadas tiran tiempo, introducen sesgos y no diferencian niveles. Las bien diseñadas dan señal fiable sobre la capacidad real respetando el tiempo y el esfuerzo.

Esta guía cubre técnicas prácticas para tres tipos: opción múltiple (MCQ), retos de código y ensayos. Cada formato tiene fortalezas y trampas distintas; saber cuándo usar cada uno importa tanto como crear las preguntas.

Opción múltiple: más allá de la trivia

Las MCQ tienen mala fama porque suelen usarse mal — testean memorización de detalles oscuros de API o trivia de lenguaje en lugar de comprensión. Pero las MCQ bien hechas son un filtro eficiente para amplitud y conceptos a escala.

Principios para MCQ técnicas efectivas

Testea comprensión, no memoria. En vez de «¿cuál es el puerto por defecto de PostgreSQL?», pregunta algo que requiera razonar: «Una desarrolladora nota que sus consultas devuelven datos obsoletos tras un update. ¿Cuál es la explicación más probable?»

Usa distractores plausibles. Cada respuesta incorrecta debe representar un malentendido común. Si las opciones erróneas son obvias, no diferencias.

Evita «todas» y «ninguna de las anteriores». Testean estrategia de test, no dominio. Cuando diseñas evaluaciones genuinamente justas, foco en habilidades prácticas relevantes al rol.

Incluye preguntas basadas en escenarios. Presenta una situación realista — un snippet, un diagrama, una depuración — y pide identificar el problema o elegir el mejor enfoque. Estas correlacionan mucho más con el desempeño que el recall factual.

Trampas comunes

• Doble negación: «¿Cuál de las siguientes NO es una afirmación incorrecta sobre…?». Fuerza puzzles lógicos en lugar de mostrar conocimiento.
• Wording ambiguo. Si dos opciones podrían ser correctas según interpretación, la pregunta está rota.
• Sesgo cultural o regional. Evita modismos o referencias culturales.
• Trampas. Cazar por wording sutil mide atención lectora, no skill técnico.

Retos de código: medir habilidad real

Los retos de código son el estándar de oro para evaluar ingeniería, pero varían enormemente. La diferencia entre buenos y malos suele ser cuánto reflejan el trabajo real.

Diseñar problemas efectivos

Empieza por el puesto. Si el rol construye APIs REST, el reto debería ser construir una API pequeña — no implementar un árbol rojo-negro de memoria.

Especificaciones claras. La ambigüedad no testea «manejo de ambigüedad»: testea adivinar lo que la entrevistadora quiere. Da inputs, outputs esperados, restricciones y casos límite.

Diseña para varios niveles. Un buen reto tiene un núcleo que la mayoría completa, y extensiones para que las fuertes muestren profundidad:

• Núcleo: función que procesa transacciones y devuelve un resumen.
• Extensión 1: casos límite (transacciones concurrentes, fallos parciales).
• Extensión 2: rendimiento con grandes datasets.
• Extensión 3: errores y logging.

Permite elección de lenguaje salvo si el rol es language-specific. Mejor lectura de problem-solving cuando no pelea con sintaxis.

Tiempo y complejidad

Error común: subestimar el tiempo. Regla: si tu mejor ingeniera tarda 20 minutos, da al menos 60. Considera nervios, entornos no familiares y la sobrecarga de leer y entender.

Para take-home, bajo 2–3 horas de trabajo real. Más penaliza a quien tiene cuidados u otras obligaciones.

Criterios de evaluación

Define la rúbrica antes de ver entregas:

• Corrección. ¿Output correcto en todos los casos?
• Calidad de código. ¿Legible, estructurado, mantenible?
• Casos límite. ¿Considera bordes?
• Eficiencia. ¿Razonable para el input esperado?
• Testing. ¿Tests escritos o estructura testeable?

Tener rúbrica antes evita el sesgo de anclaje.

Preguntas tipo ensayo: comunicación y profundidad

Las preguntas de ensayo están infrautilizadas, pero son únicas para evaluar comunicación técnica, pensamiento arquitectónico y razonamiento de trade-offs.

Cuándo usar ensayos

• Roles de arquitectura. «Diseña un sistema de notificaciones que entregue 10 millones de mensajes/día. Discute trade-offs».
• Sénior y liderazgo. «Cuéntame una decisión técnica que después comprendiste que estuvo mal. ¿Qué aprendiste?»
• Roles que requieren escritura. Si el trabajo implica redactar RFC o docs, un ensayo evalúa eso directamente.

Crear buenos prompts

Específico el alcance. «Cuéntame un proyecto» es demasiado abierto. «Cuéntame una vez que tuviste que negociar fiabilidad vs. velocidad. ¿Qué consideraste?» da marco.

Especifica longitud. «300–500 palabras» previene tanto respuestas de un párrafo como ensayos de 3.000 palabras.

Pide razonamiento, no respuestas. El valor está en cómo piensan. Prompts con «por qué» y «qué trade-offs» revelan más que «qué» o «cómo».

Evaluar con justicia

Es más subjetivo que revisar código. Para mantener equidad:

• Usa rúbrica estructurada con criterios (claridad, profundidad técnica, calidad de razonamiento, conciencia práctica).
• Revisión a ciegas cuando sea posible.
• Múltiples revisores. Dos puntuaciones independientes que se comparan reducen sesgo.
• Calibra antes. Que las revisoras puntúen 2–3 ensayos de muestra y discutan diferencias antes de evaluar el resto.

Combinar tipos de evaluación

Los procesos más fuertes combinan formatos:

1. MCQ para cribado inicial. Conocimiento base en 15–20 minutos. Filtra prerequisitos.
2. Reto de código para profundidad técnica. Núcleo de la evaluación.
3. Ensayo corto para comunicación. Una pregunta bien diseñada revela comunicación y profundidad.

Cobertura sobre conocimiento, habilidad y comunicación, manteniendo el tiempo razonable.

Checklist de equidad

Antes de desplegar:

• ¿Mide habilidades realmente requeridas?
• ¿Has probado el límite de tiempo con personas del equipo actual?
• ¿Es accesible para personas con discapacidades?
• ¿Está libre de sesgos culturales, de género o socioeconómicos?
• ¿Está la rúbrica definida y documentada antes de ver entregas?
• ¿Reciben las candidaturas instrucciones claras?
• ¿Es el formato apropiado para la habilidad?

Las evaluaciones justas no son solo obligación ética — son ventaja competitiva. Cuando tu proceso mide la habilidad real, contratas mejor. Y cuando las candidaturas viven un proceso respetuoso y bien diseñado, son más propensas a aceptar y a hablar bien de tu empresa, gane o no.