Prueba de gerente de proyecto: preguntas de planificación y escenarios

Por qué fallan las preguntas genéricas de entrevista de PM

La mayoría de equipos de contratación hacen las mismas cinco preguntas a gerentes de proyecto: "Cuéntame sobre un proyecto difícil," "Cómo manejas el scope creep," "Describe tu proceso de planificación." Cada candidato tiene una respuesta ensayada. Nadie aprende nada.

La evaluación de PM efectiva pide a los candidatos resolver un pequeño problema, razonar sobre trade-offs, y explicar su toma de decisiones — no recitar narrativas pasadas. Este post muestra los patrones de preguntas que funcionan, qué revelan las respuestas, y cómo calificarlas.

Patrón 1: El problema de escenario (muestra de trabajo)

Da al candidato un escenario realista en 30 minutos. Escriben una respuesta de 1–2 páginas. Esto expone el pensamiento más rápido que una conversación de 60 minutos.

Ejemplo: La línea de tiempo acelerada

Tu empresa se comprometió a lanzar una característica SaaS en Q3. Es 1 de mayo. El roadmap muestra 800 horas de trabajo restante (desarrollo, QA, diseño). El equipo tiene cinco ingenieros más tú. Acabas de aprender que el cliente que impulsó el compromiso podría no renovar a menos que la característica esté en vivo antes del 15 de agosto. ¿Qué haces?

Escribe tu enfoque en 2 minutos. Nombra:

• Qué información recopolarías primero (y de quién)
• Tus opciones principales (3+) y el trade-off para cada una
• Tu recomendación
• Un riesgo importante que mitigarías inmediatamente

Qué esto revela

Las respuestas de señal alta hacen tres cosas:

1. Reconoce desconocidos primero. "Antes de decidir, necesito saber: ¿La estimación de 800 horas está fundamentada en story points o suposiciones? ¿Tenemos capacidad de QA? ¿La fecha del 15 de agosto es dura o suave?"
2. Nombra opciones y trade-offs explícitamente. "Opción A: contratar contratistas (rampa más rápida, riesgo de incorporación, riesgo cultural). Opción B: reducir alcance de características (perder expectativas del cliente, podría no importar para renovación). Opción C: flujos de trabajo paralelos (complejidad, riesgo de fusión)."
3. Recomienda una opción con rationale. "Reduciría el alcance de tres características no centrales y ejecutaría diseño-ingeniería paralela, porque incorporar contratistas ahora suma 3 semanas, pero podemos lanzar valor central antes del 15 de agosto si ingeniería comienza esta semana."

Las respuestas de señal baja:

• Hablan pasado las restricciones ("Comunicaría con las partes interesadas")
• Nombran opciones sin trade-offs ("Podríamos contratar contratistas o reducir alcance")
• Se cubren sin recomendar ("Depende de la comodidad del equipo con deuda técnica")

Patrón 2: El problema de priorización

Da un backlog de 10–15 items con información incompleta. Pide al candidato que los clasifique y defienda los 3 principales.

Ejemplo: El crunch de roadmap

Tu producto tiene cinco solicitudes activas:

• A: Característica de cumplimiento (requerida para un vertical nuevo, potencial de $200K ARR, construcción de 6 semanas)
• B: Rediseño de dashboard (punto de dolor interno, mejora retención 5%, 8 semanas)
• C: API para integraciones (tres clientes pidiendo, 4 semanas, desbloquea upsell)
• D: Optimización de rendimiento (tiempo de carga móvil es lento, afecta experiencia usuario, 3 semanas)
• E: Bug reportado por cliente en export (afecta 2% de power users, 1 semana)

Tienes 6 semanas de capacidad de equipo. Clasifica los tres principales y explica por qué.

Qué esto revela

Pensamiento de señal alta:

• Distingue importancia (cumplimiento, crecimiento) de urgencia (el bug).
• Cuantifica impacto donde es posible ("C desbloquea 3 clientes, eso es aproximadamente $20K+ ARR").
• Reconoce trade-offs ("B se siente doloroso pero entrega menor impacto de ingresos que A o C").
• Toma una decisión con razonamiento ("Haría A + C + parte de D si podemos paralelizar diseño. B y E esperan porque no son impulsados por ingresos").

Pensamiento de señal baja:

• Hace todo o no puede elegir ("Podemos hacer A y B si despriorizamos D").
• Prioriza emoción sobre lógica ("B es el punto de dolor de mi equipo").
• Lista categorías MoSCoW sin elegir ("A es Must Have, B es Should Have").

Patrón 3: La pregunta de riesgo y mitigación

Describe un proyecto real. Pide al candidato que identifique tres riesgos y cómo mitigaría cada uno.

Ejemplo: La dependencia entre equipos

Estamos lanzando un rediseño de pago en tres equipos: tu equipo (4 ingenieros, 6 semanas), el equipo de datos (necesita instrumentar eventos nuevos, dice 4 semanas), y el equipo de cumplimiento (debe auditar todos los cambios, generalmente toma 2 semanas). Los tres flujos están en paralelo. La fecha límite de lanzamiento duro es 8 semanas. Nombra tres riesgos y una mitigación concreta para cada uno.

Qué esto revela

Las respuestas de señal alta identifican:

1. Riesgo de dependencia: "La instrumentación de datos está en la ruta crítica. Si se atrasan una semana, golpeamos nuestra fecha límite de lanzamiento. Mitigación: Asignaría un enlace a su standup, bloquearía el schema antes de la semana 3, haría revisiones de dependencia semanales."
2. Riesgo de comunicación: "Cumplimiento se siente como una puerta al final. Si no los involucramos temprano, señalarán problemas en la semana 7. Mitigación: Los tendría revisar el diseño en la semana 1, unirse a revisiones técnicas, e hacer una auditoría piloto de una característica en la semana 5."
3. Riesgo de alcance: "Los equipos podrían interpretar 'rediseño de pago' diferentemente. Un equipo podría añadir características que los otros no planifican. Mitigación: Escribiría una página de una sola página definiendo alcance, obtendría aprobación de los tres líderes, lo bloquearía."

Las respuestas de señal baja:

• "El riesgo principal es que perdamos la fecha límite" (reformula la restricción, no perspicaz).
• "Necesitamos buena comunicación" (cierto pero no concreto).
• Nombran riesgos pero sin mitigación real ("Podríamos excedernos" — está bien, pero ¿qué haces?).

Rúbrica de calificación (4 dimensiones)

Califica cada uno 1 (bajo) a 5 (alto). Un PM fuerte puntúa 4+ en los cuatro. Un PM promedio puntúa 3–4; por debajo del promedio es 2–3.

Cuándo usar cada patrón

• Escenario (muestra de trabajo): Primer screening, asincrónico, 30 min. Filtra por velocidad de toma de decisiones y claridad.
• Priorización: Segunda ronda, en vivo, 20 min. Prueba juicio bajo restricciones.
• Mitigación de riesgos: Ronda final o entrevista estructurada, en vivo, 15 min. Prueba profundidad de dominio y pensamiento de sistemas.

Apílalos en este orden: muestra de trabajo, luego priorización, luego entrevista de riesgo. Juntos cuestan 90 minutos y exponen la mayoría de lo que importa: velocidad, juicio, y profundidad.

Errores comunes al ejecutar estas pruebas

Error 1: Aceptar respuestas vagas. Si dicen "Mejoraría la comunicación," pregunta "¿Cómo, específicamente? ¿Quién habla con quién? ¿Cuándo?"

Error 2: Preguntar un escenario pero no pedir que lo defiendan. Una respuesta escrita es un inicio, pero una sesión de debrief de 10 minutos donde empujas atrás ("¿Y si la fecha límite es realmente dura?") revela cómo piensan bajo presión.

Error 3: Calificar en base a simpatía en lugar de señal. Un candidato podría ser amable y aún cubrirse en cada decisión. Ancla tu rúbrica a comportamiento observable, no comodidad.

Cómo se compara a entrevistas de PM tradicionales

Las entrevistas de PM tradicionales hacen preguntas comportamentales ancladas a experiencia pasada. Muestras de trabajo + problemas de escenario piden a candidatos resolver problemas ahora. Ambas importan, pero si solo haces una, la muestra de trabajo es señal más alta para el trabajo día a día.

Siguiente: Cómo evaluar gerentes de proyecto a escala

Si estás construyendo un proceso de contratación de PM desde cero, comienza con el patrón de muestra de trabajo (problema de escenario) como tu primer screening, luego usa los otros dos patrones en rondas en vivo. ClarityHire puede administrar y calificar ambos para asegurar consistencia entre candidatos.