Skip to article
Behavioral Questions5 min

Cómo responder 'Cuéntame sobre un proyecto desafiante'

Elegir el proyecto equivocado — o perderte en el contexto — arruina esta respuesta. Aprende a elegir la historia correcta y estructurarla para mostrar lo que realmente hiciste.

Cómo responder 'Cuéntame sobre un proyecto desafiante'

Intención de búsqueda: Candidatos que eligen el proyecto equivocado (demasiado pequeño, demasiado antiguo) o que dedican todo el tiempo al contexto y se saltan la parte de "qué hice yo."


Dos errores que hunden esta respuesta

La pregunta sobre el proyecto desafiante parece sencilla — pero la mayoría de los candidatos la responden de una de estas dos formas incorrectas:

Eligen un proyecto que no era realmente desafiante. Una entrega rutinaria con un plazo ajustado no es un desafío — es una semana normal. Los entrevistadores notan cuando el "desafío" está inflado.

Pasan toda la respuesta explicando el contexto. Tres minutos describiendo el proyecto, la empresa, los stakeholders, el sistema heredado — luego 15 segundos sobre lo que realmente hicieron y "y resultó bien." El entrevistador no aprendió nada sobre el candidato.

La solución para ambos errores es la misma: elige una historia donde el obstáculo era real y tus decisiones específicas marcaron la diferencia.


Qué hace que un proyecto sea "desafiante" en términos de entrevista

Un proyecto vale la pena si tenía al menos uno de estos elementos:

  • Ambigüedad técnica — no había una solución clara, tuviste que encontrarla
  • Limitaciones de recursos — alcance demasiado grande, equipo demasiado pequeño, plazo demasiado ajustado, y aun así lo entregaste
  • Conflicto de stakeholders — prioridades en competencia que tuviste que navegar y alinear
  • Alto riesgo — consecuencias significativas si fallabas (impacto en clientes, ingresos, fiabilidad del sistema)
  • Que fuiste responsable de algo que falló — lideraste o construiste algo que falló a mitad del proyecto y tuviste que recuperarte

Los proyectos rutinarios con una semana difícil no califican. Un proyecto donde chocaste contra un muro, tomaste decisiones bajo incertidumbre y saliste al otro lado con un resultado real — ese sí califica.


La estructura: Problema → Tus decisiones → Resultado

El enfoque STAR estándar funciona aquí, pero el énfasis pertenece a la sección de Acción — específicamente las decisiones que tomaste cuando las cosas eran más difíciles.

Situación (15 %): Una o dos frases. ¿Cuál era el proyecto y qué lo hacía de alto riesgo?

Tarea (10 %): ¿De qué eras responsable?

Acción (55 %): Repasa el desafío real y tu respuesta. No la respuesta de tu equipo — la tuya. ¿Qué analizaste, decidiste, construiste o cambiaste? Si te encontraste con múltiples obstáculos, elige el más significativo y profundiza en él.

Resultado (20 %): ¿Qué entregó el proyecto? Sé específico — cifras, plazos, impacto posterior.

Respuesta débil

"Tuvimos un proyecto importante de renovación de infraestructura el año pasado. Era muy complejo con muchas partes móviles entre diferentes sistemas. El equipo trabajó muy duro y conseguimos completarlo, aunque tardó más de lo esperado. El nuevo sistema es mucho más estable."

"Partes móviles" y "muy complejo" son relleno — señalan que el candidato no puede describir la complejidad real. "Tardó más de lo esperado" sin explicación de por qué o cómo se gestionó es una señal de alerta. "Mucho más estable" es inconmensurable.

Respuesta sólida

"Lideré la migración de un motor de precios en tiempo real desde una configuración on-premise de un solo tenant a un servicio cloud multitenancy. El desafío era que no podíamos desconectarlo — procesaba operaciones en vivo durante el horario de mercado. Cualquier tiempo de inactividad significaba pérdida directa de ingresos.

A mitad del proceso, descubrimos que los requisitos de latencia eran más estrictos de lo que especificaba el documento original: el nuevo entorno tenía 40 ms más de overhead de red que nuestra línea base on-premise. Teníamos unas dos semanas antes de nuestra fecha de salida a producción externa.

Realicé un spike — tres días de profiling y pruebas — para aislar si el overhead era de red, serialización o cómputo. Era serialización. Cambiamos de JSON a un protocolo binario, lo que recuperó 35 ms. No perfecto, pero dentro del umbral aceptable. Decidí lanzar con esa solución en lugar de retrasar, documenté el riesgo residual y obtuve el visto bueno de los responsables de producto y trading.

Cumplimos la fecha de lanzamiento. La latencia quedó 18 ms por encima de la línea base — muy dentro de la tolerancia. Cero interrupciones en las operaciones durante los primeros 30 días."

Esta respuesta nombra un obstáculo técnico específico y real (regresión de latencia), describe el proceso de diagnóstico del candidato, muestra una decisión concreta bajo presión (lanzar con riesgo residual conocido) y cierra con un resultado verificable.


Cómo elegir el proyecto correcto

Hazte estas preguntas:

  • ¿Soy el protagonista? Si tu historia trata principalmente de lo que hizo tu equipo, busca otra historia.
  • ¿Era real el obstáculo? ¿Podría alguien razonablemente haber fallado aquí, o simplemente fue trabajo duro con un resultado seguro?
  • ¿Tengo un resultado específico? Si no puedes decir qué cambió gracias a este proyecto, la historia no está lista.
  • ¿Es reciente? A menos que estés al inicio de tu carrera, usa algo de los últimos cuatro años.
  • ¿Es relevante? El desafío debe corresponderse con algo a lo que se enfrentará el nuevo puesto.

Practica ahora

La parte más difícil de esta respuesta no es la historia — es saber cuándo dejar de dar contexto y empezar a hablar de lo que hiciste.

Prueba una sesión gratuita en Interview Sparring →