'Explícame Qué Construiste' — Cómo Responder a la Nueva Pregunta de Entrevista de 2026

Resumen: Cada vez más entrevistadores en 2026 les piden a los candidatos que expliquen un proyecto real que hayan construido, en lugar de abrir con "cuéntame de una vez que...". El cambio está impulsado por la IA, que está erosionando el valor como señal de las pruebas take-home y de las historias de comportamiento ensayadas — una explicación de proyecto en vivo es más difícil de falsificar. Prepárate de forma distinta a como lo harías para el STAR: elige un proyecto que puedas defender bajo preguntas de seguimiento, no el que suene más impresionante en una línea.

Pasaste semanas puliendo cinco historias STAR. Entonces el entrevistador dijo: "Saltémonos eso — explícame algo que realmente hayas construido", abrió un punto de tu currículum y empezó a preguntar por qué tomaste decisiones específicas dentro de él. Si tu preparación era pura narrativa y nada de profundidad, ese es el momento en que todo se desmorona.

Esto no es una nueva forma de plantear una vieja pregunta de comportamiento. Es un formato distinto, y está apareciendo con más frecuencia por una razón específica.

Por Qué "Cuéntame de una Vez Que..." Está Perdiendo Terreno

Karat encuestó a 400 líderes de ingeniería en Estados Unidos, India y China para su reporte de tendencias de contratación de 2026, y la conclusión detrás de este cambio es directa: las pruebas take-home y las respuestas de comportamiento ensayadas son las señales de contratación que se degradan más rápido con la IA. Los candidatos pueden pegar un enunciado de take-home en un modelo y obtener una solución funcional sin ninguna visibilidad de cómo realmente piensan. Una historia STAR pulida puede escribirse de la misma manera.

Explicar en vivo tu propio trabajo es mucho más difícil de tercerizar en el momento. O sabes por qué tomaste una decisión, o no lo sabes, y una pregunta de seguimiento expone esa diferencia en segundos. Por eso los líderes entrevistados por Karat describen las entrevistas en vivo como "más valiosas porque permiten a los entrevistadores observar cómo los candidatos resuelven un problema, toman decisiones y usan IA" — no porque las entrevistas en vivo sean nuevas, sino porque todo lo demás se volvió más ruidoso.

La adopción no es pareja entre mercados. Los datos de Karat muestran que las empresas en China tienen casi el doble de probabilidad de permitir abiertamente el uso de IA durante entrevistas en vivo (68% frente a 38% en Estados Unidos) y dependen mucho menos de los take-homes (20% frente a 45%) — una señal de que este giro hacia la resolución de problemas en vivo y observada avanza más rápido donde el uso de IA en el flujo de trabajo ya está normalizado, no tratado como algo que ocultar.

La misma lógica se ve a nivel de la práctica. Las guías de reclutamiento para puestos con mucho enfoque en datos ahora recomiendan abiertamente eliminar la ronda de acertijos de SQL en vivo y reemplazarla con un bloque de presentación más largo, donde el candidato le explica a dos entrevistadores algo que construyó y recibe objeciones — porque, como lo dice una de esas guías, de todos modos un modelo "escribe la misma consulta en unos catorce segundos". El acertijo dejó de ser un filtro útil. La explicación de proyecto todavía lo es.

Qué Evalúa Realmente Esta Pregunta

Los consejos genéricos de "cómo presentar tu proyecto" tratan esto como un monólogo estructurado: resume el proyecto, menciona un obstáculo, cierra con el resultado. Eso cubre tal vez un tercio de lo que realmente sucede.

La prueba real es el sondeo de preguntas de seguimiento que llega después de tu resumen inicial:

• "¿Por qué ese enfoque en vez de X?" — evalúa si entendiste el trade-off en su momento, o si solo seguiste una plantilla, un tutorial o la pauta de un compañero.
• "¿Qué cambiarías si lo reconstruyeras hoy?" — evalúa si has seguido pensando en el problema después de lanzarlo, o si lo consideras cerrado en cuanto funcionó.
• "¿Cuánto costó eso realmente / cómo rindió a escala?" — evalúa si conoces tus propios números, no solo la historia que cuentas sobre ellos.
• "Explícame el caso de falla" — evalúa si entiendes los límites de lo que construiste, no solo el camino feliz que estás narrando.

Nada de esto aparece si solo preparas la narrativa. Aparece en el momento en que alguien la interrumpe.

Cómo Prepararte de Forma Distinta a Como lo Harías para el STAR

La preparación para el STAR se optimiza para un arco limpio de cinco frases. La preparación para la explicación de proyecto se optimiza para sobrevivir a la interrupción. En concreto:

1. Elige el proyecto que puedas defender, no el que suene mejor. Una herramienta interna discreta que entiendes por completo le gana a un proyecto público llamativo donde un compañero tomó las decisiones difíciles y tú no puedes reconstruir su razonamiento.
2. Domina tus números a fondo, no tu historia. Si mencionas escala, latencia o un resultado de negocio, prepárate para una pregunta de seguimiento que te pida justificar el número en sí — de dónde salió, qué excluyó, qué lo cambió.
3. Ensaya el "por qué", no solo el "qué". Para cada decisión importante del proyecto, ten lista una frase sobre la alternativa que no elegiste y por qué. Esa es casi siempre la primera pregunta de seguimiento.
4. Adelántate a "qué cambiarías ahora". Llega con una limitación honesta de tu propio trabajo. Ofrecerla antes de que te la pregunten transmite autoconciencia; que te acorralen hasta admitirla transmite evasión.
5. Practica que te interrumpan, no solo practica hablar. Pide a alguien que se meta a mitad de tu explicación con una pregunta directa. La habilidad que evalúa este formato es recuperar el hilo de tu razonamiento ante un giro inesperado, algo que un ensayo en solitario nunca entrena.

"Pero Mi Proyecto No Era Tan Impresionante"

Este es el punto de pánico más común, y aparece constantemente en foros de candidatos: ingenieros cuyo trabajo del día a día es mantenimiento de bajo tráfico, preocupados por no tener nada grandioso o dramático que aportar en una ronda de "análisis a fondo de proyecto". Un hilo recurrente en r/Blind lo planteó sin rodeos — después de que le preguntaran repetidamente sobre escala e impacto de negocio en un sistema interno de baja visibilidad, un candidato se preguntó en voz alta si debería "pasar un par de meses inventando algo con cuidado y con detalle" en lugar de usar la cosa real.

No hagas eso. Los entrevistadores no están calificando el tamaño de tu proyecto; están calificando si tu explicación se sostiene bajo preguntas. Un proyecto pequeño y bien entendido que puedes defender desde cualquier ángulo supera a uno grande donde la primera pregunta de "por qué" revela que estabas recitando decisiones de otra persona. Si de verdad no diseñaste la arquitectura, dilo directamente, y luego habla de lo que sí hiciste tú — una extensión que construiste dentro de ella, un trade-off que enfrentaste personalmente, un bug que rastreaste y que te enseñó cómo funcionaba realmente el sistema.

El error que los entrevistadores están filtrando específicamente, según reportes reales de candidatos rechazados en esta etapa, es adjudicarte la autoría de decisiones que en realidad no puedes defender cuando alguien pregunta "qué harías diferente ahora". Reconocer una contribución real, aunque más pequeña, le gana a sobrevender una más grande que no puedes respaldar.

Una Estructura Simple para la Explicación de Proyecto en Vivo

Cuando el formato lo permita, mantén algo visual en pantalla — un diagrama, un repositorio, hasta un boceto simple — para que el entrevistador tenga algo concreto que señalar cuando interrumpa. Luego, estructura tu apertura así:

1. Una frase sobre el problema que estabas resolviendo y para quién.
2. Una frase sobre el enfoque, planteada como una decisión ("Elegí X en vez de Y porque...") y no como una descripción.
3. Deja de hablar. Deja que el entrevistador conduzca los siguientes cinco minutos con preguntas de seguimiento. Resiste el impulso de seguir narrando pasado este punto — el formato de explicación de proyecto está diseñado para que ellos tomen el control, y hablar de más aquí solo retrasa la parte que realmente se está evaluando.

La parte más difícil de este formato no es conocer tu proyecto. Es mantener la compostura cuando una pregunta de seguimiento cae sobre un detalle que no esperabas tener que defender, en vivo, sin oportunidad de editar tu respuesta antes. Eso es genuinamente difícil de simular en solitario — es exactamente el momento para el que está hecha la asistencia de entrevista en tiempo real, que muestra discretamente los números de tu propio proyecto, la línea de tiempo o el trade-off que te están pidiendo justificar mientras aún estás a mitad de tu respuesta, para que una pregunta de seguimiento certera no te deje en blanco.

Si además estás construyendo historias STAR para el resto de tu proceso de entrevistas, nuestra guía del método STAR cubre esa otra mitad, y nuestra guía de entrevista de comportamiento para ingenieros de software vale la pena combinarla con esta, ya que la mayoría de los procesos de 2026 siguen corriendo ambos formatos uno tras otro.

Preguntas Frecuentes

¿Esto está reemplazando por completo las entrevistas de comportamiento, o solo se está sumando a ellas?

En su mayoría, se está sumando. La encuesta de 2026 de Karat a líderes de ingeniería encontró que la resolución de problemas en vivo y la discusión de una muestra de trabajo ahora se ubican por encima de los take-homes y las respuestas de comportamiento ensayadas como señales confiables, pero pocas empresas han eliminado por completo las preguntas estilo STAR. La meta realista de preparación es un proceso que incluya ambos formatos, con la ronda de explicación de proyecto pesando más de lo que solía pesar.

¿Qué hago si el proyecto del que quisiera hablar fue sobre todo mantenimiento, no algo impresionante que construí desde cero?

Elige el proyecto en el que puedas responder preguntas de seguimiento, no el que suene mejor en una sola frase. Un proyecto aburrido de mantenimiento que dominas a fondo le gana a uno vistoso donde te vas a quedar en blanco con "por qué elegiste ese enfoque". Los entrevistadores están escuchando cómo piensas ante un detalle específico, no el tamaño de la base de código.

¿Qué hago si yo no diseñé la arquitectura, o no estoy seguro de poder explicar qué cambiaría ahora?

Di con honestidad lo que realmente hiciste. Si heredaste el diseño, dilo, y luego habla de las partes que sí decidiste tú: cómo lo extendiste, un trade-off que enfrentaste trabajando dentro de él, o un cambio que harías si tuvieras tiempo ahora. Adjudicarte una autoría que no tuviste es exactamente el error que esta pregunta está diseñada para detectar, y suele ser obvio en el momento en que una pregunta de seguimiento cae sobre una decisión que no puedes defender.

¿En qué se diferencia esto de simplemente ensayar mi proyecto para una revisión de portafolio?

Una revisión de portafolio es, en gran medida, de una sola vía: tú presentas, ellos escuchan, tal vez una o dos preguntas al final. Una explicación de una muestra de trabajo es adversarial por diseño — los entrevistadores interrumpen a mitad de tu explicación con "por qué no X en vez de eso", "cuánto costaría eso a una escala 10 veces mayor" o "qué decían realmente los datos". Ensayar una narración fluida no te prepara para ser interrumpido; ensayar tu razonamiento, sí.

¿Debería llevar una demo real o diapositivas, o solo explicarlo de forma verbal?

Lleva algo que puedas señalar si el formato lo permite — un diagrama, un repositorio, una captura de pantalla, hasta un boceto en una servilleta funciona por videollamada. No se trata de acabado de producción; se trata de darle al entrevistador algo concreto contra lo cual hacer preguntas de seguimiento, que es exactamente lo que este formato busca evaluar. Una descripción puramente verbal facilita pasar por alto detalles que preferirías no tener que defender.

---

Autor · Alex Chen. Consultor de carrera y ex reclutador técnico. Pasó 5 años del lado de la contratación antes de dedicarse a ayudar a candidatos. Escribe sobre la dinámica real de las entrevistas, no consejos de libro de texto.