Las 20 Preguntas de Entrevista Comportamental Más Frecuentes para Desarrolladores
Estaba sentado frente a un candidato — senior, buen currículum, había destrozado la ronda técnica — y le hice una pregunta sencilla: “Cuéntame de una vez que no estuviste de acuerdo con una decisión técnica en tu equipo.”
Silencio. Mira hacia arriba. Después dice: “Bueno, generalmente intento mantener las cosas profesionales y buscar consenso.”
Eso fue todo. Esa fue su respuesta completa.
Yo esperé. Él esperó. Los dos esperamos. Pasé a la siguiente pregunta. Y ya sabía que el debrief no iba a ir bien para él.
Eso fue hace tres años, y desde entonces he visto alguna versión de esa escena repetirse docenas de veces. Ingenieros que pasan semanas grindando LeetCode y estudiando system design, y llegan a la ronda comportamental con cero preparación. Como si fuera un trámite. Una charla casual antes de las preguntas “de verdad.”
No lo es. Yo personalmente he visto rondas comportamentales eliminar candidatos que por lo demás eran excelentes. Y he visto gente con un coding flojo conseguir la oferta porque contaron historias que hicieron que todo el panel se inclinara hacia adelante.
La cuestión es que las preguntas comportamentales son predecibles. No en el mal sentido — en el sentido de “puedes preparar el 80% de lo que te van a preguntar.” Las preguntas se repiten. Los temas se repiten. Y si conoces el marco, puedes llegar listo.
Así que vamos a repasar las 20 preguntas que veo con más frecuencia, cómo pensar en cada una, y cómo evitar terminar como mi amigo el senior silencioso.
El método STAR, rápido
Seguramente ya lo escuchaste. Situación, Tarea, Acción, Resultado. No es complicado, y ese es un poco el punto — le da un esqueleto a tu respuesta para que no te vayas por las ramas.
- Situación — plantea la escena. Dónde estabas, cuál era el proyecto, cuál era el contexto. Dos o tres frases, máximo.
- Tarea — cuál era tu responsabilidad específica. No la del equipo. La tuya.
- Acción — qué hiciste concretamente. Aquí está la carne. Sé específico. “Analicé los datos” es débil. “Perfilé los endpoints de la API, identifiqué que el 80% de la latencia venía de tres queries, y propuse una capa de cache al equipo” es fuerte.
- Resultado — qué pasó. Cuantifica si puedes. “Redujimos el tiempo de respuesta un 40%.” Si el resultado no fue genial, di qué aprendiste. Una reflexión honesta siempre vale más que un final feliz inventado.
El error más común con STAR no es la falta de estructura. Es pasarte tres minutos en la Situación y treinta segundos en la Acción. Invierte esa proporción. La Acción es lo que están evaluando.
Si quieres profundizar en cómo funciona el scoring y las trampas clásicas, escribí un artículo aparte sobre errores en entrevistas comportamentales que cubre el lado de la evaluación.
Las 20 preguntas, agrupadas por tema
Las agrupé por lo que realmente están evaluando. Los temas se repiten de empresa en empresa, aunque la formulación cambie. Si preparas dos buenas historias por tema, vas a poder responder la mayoría de lo que te lancen.
Trabajo en equipo y colaboración
1. Cuéntame de un proyecto cross-funcional en el que hayas trabajado.
Quieren escuchar que puedes operar fuera de tu burbuja de ingeniería. Habla de cómo te comunicaste con stakeholders no técnicos. Adaptaste tu lenguaje? Alineaste a la gente en los tradeoffs? Una buena respuesta muestra que entiendes que entregar software es un deporte de equipo que va más allá del código.
2. Describe una situación en la que ayudaste a un compañero que estaba trabado.
Aquí se evalúa empatía e instinto de mentoría. No lo cuentes como “le resolví el problema.” Cuéntalo como “le ayudé a encontrar el camino.” Sesiones de pair programming, code reviews donde explicaste el razonamiento, documentación que creaste para facilitar su onboarding.
3. Dame un ejemplo de cuando tuviste que colaborar con alguien cuyo estilo de trabajo era muy diferente al tuyo.
Se evalúa adaptabilidad. Quizás tú trabajas en asíncrono y la otra persona en síncrono. Tú planificas, la otra persona se lanza directo. Lo clave: qué hiciste para cerrar la brecha? No “estaba equivocado y lo toleré.” Más bien “me di cuenta de que necesitábamos un proceso compartido, así que propuse X.”
4. Cuéntame de una vez que recibiste feedback crítico.
Resiste la tentación de elegir algo trivial. “Me dijeron que comentara más mi código” no es una historia convincente. Elige un feedback que te haya dolido un poco. Muestra que lo procesaste, extrajiste lo útil, y cambiaste tu comportamiento. Growth mindset demostrado con acciones, no con palabras.
Conflicto y desacuerdo
5. Describe una vez que no estuviste de acuerdo con una decisión técnica.
El clásico absoluto. Todas las empresas preguntan alguna variante. Estructura: cuál era la decisión, cuál era tu posición, cómo defendiste tu punto de vista, qué pasó. Lo crítico: muestra que argumentaste con datos, no con ego. Y si perdiste el debate, muestra que te comprometiste de todas formas. “Disagree and commit” es literalmente un criterio de evaluación en algunas empresas.
6. Cuéntame de un conflicto con un manager o tech lead.
Terreno delicado, pero hay que ser honesto. Buscan madurez profesional. Escalaste por los canales correctos. Separaste a la persona del problema. No fuiste por encima de su cabeza primero. Si el conflicto se resolvió, explica cómo. Si no, explica qué aprendiste sobre trabajar con distintos estilos de liderazgo.
7. Dame un ejemplo de una vez que rechazaste un requerimiento.
La tensión producto vs ingeniería es universal. Las respuestas ganadoras muestran que entendiste el objetivo de negocio detrás del requerimiento, y que tu rechazo fue constructivo — “esto es por qué es riesgoso, y aquí hay una alternativa que cubre el 90% de la necesidad por el 30% del costo.” No simplemente “dije que no.”
8. Cuéntame de una vez que tuviste que manejar prioridades contradictorias de diferentes stakeholders.
Esto va de comunicación y priorización, no de heroísmo. Las buenas respuestas muestran un marco: evaluaste el impacto, comunicaste los tradeoffs de forma transparente, y obtuviste alineación explícita antes de avanzar. La peor respuesta: “simplemente trabajé muy duro y lo hice todo.”
Liderazgo y ownership
9. Describe un proyecto que hayas liderado de principio a fin.
Aunque no seas lead, quieren ver iniciativa. Habla de cómo definiste el alcance, cómo dividiste el trabajo, cómo manejaste los obstáculos. Menciona las partes poco glamorosas — la alineación con stakeholders, la documentación, el handoff. Esos detalles señalan ownership real, no solo código.
10. Cuéntame de una vez que tuviste que tomar una decisión sin tener toda la información.
Toda entrevista de nivel senior incluye esto. El marco: qué información tenías, qué faltaba, cómo evaluaste el riesgo, y cuál fue tu proceso de decisión. Muestra que actuaste de forma deliberada a pesar de la incertidumbre, no que adivinaste y tuviste suerte.
11. Dame un ejemplo de cuando mentoreaste a alguien.
No necesitas haber sido mentor oficial. Las code reviews cuentan. Ayudar a un junior a debuggear algo cuenta. Dar un tech talk cuenta. Lo que buscan: invertiste tiempo en el crecimiento de alguien más sin que te lo pidieran?
12. Describe una vez que identificaste un problema que nadie más había visto.
Esto va de pensamiento proactivo. Quizás detectaste un problema de seguridad durante una code review. Quizás te diste cuenta de que un plan de migración tenía un hueco. Mientras más fuerte sea el factor “nadie estaba mirando esto,” mejor. Y asegúrate de explicar qué hiciste al respecto, no solo que lo notaste.
Fracaso y aprendizaje
13. Cuéntame de una vez que fracasaste.
La pregunta que todos temen y casi todos responden mal. No elijas algo donde fuiste el héroe que atrapó el problema a tiempo. Elige un fracaso real. Un deploy que rompió producción. Una mala decisión de arquitectura. Un deadline que no cumpliste porque subestimaste la complejidad. Y después — aquí está todo el punto — explica específicamente qué cambiaste como resultado. “Aprendí a ser más cuidadoso” no vale nada. “Implementé smoke tests pre-deploy para el equipo que atraparon tres incidentes en el siguiente trimestre” lo vale todo.
14. Describe un proyecto que no salió como esperabas.
Similar a la pregunta de fracaso, pero más sobre adaptabilidad que responsabilidad personal. Cómo te ajustaste? Re-definiste el alcance? Comunicaste el retraso temprano? Identificaste qué sí se podía entregar? Muestra el pivote, no el pánico.
15. Cuéntame de un error que cometiste y que afectó al equipo.
La prueba de confianza. Quieren ver que lo asumiste, lo comunicaste y lo corregiste sin esconderte. Si al principio intentaste tapar el error, decirlo honestamente (y decir qué aprendiste) vale más que una versión edulcorada.
16. Dame un ejemplo de una vez que tuviste que aprender algo rápido bajo presión.
Esto sale mucho en entornos que se mueven rápido. Nueva stack tecnológica, codebase desconocido, incidente de producción en un sistema que nunca tocaste. El marco de respuesta: cuál era la presión, cómo abordaste el aprendizaje (documentación? preguntar a las personas correctas? leer el código?), y qué tan rápido te volviste operativo.
Desafíos técnicos y resolución de problemas
17. Describe el problema técnico más complejo que hayas resuelto.
Elige algo donde la complejidad no fuera solo algorítmica. Problemas entre servicios, debugging de race conditions, desenredar código legacy sin documentación — complejidad del mundo real. Recorre tu proceso de debugging paso a paso. Muestra pensamiento sistemático, no intuición heroica.
18. Cuéntame de una vez que tuviste que hacer un tradeoff técnico importante.
Performance vs legibilidad. Time-to-market vs mantenibilidad a largo plazo. Build vs buy. La clave: muestra que evaluaste ambos lados con datos, involucraste a las personas correctas, y tomaste una decisión defendible. Incluso si al final resultó ser la equivocada.
19. Dame un ejemplo de una vez que mejoraste un proceso o sistema.
No una reescritura — una mejora. Quizás implementaste CI/CD para un equipo que desplegaba manualmente. Quizás introdujiste guías de code review. Quizás automatizaste un flujo de testing doloroso. Muestra iniciativa y seguimiento.
20. Describe una vez que tuviste que trabajar con un deadline muy ajustado.
No buscan “trabajé semanas de 80 horas.” Buscan priorización, comunicación de tradeoffs, y la capacidad de entregar algo significativo incluso cuando no puedes entregar todo. Habla de qué cortaste, por qué, y cómo lo comunicaste.
Errores comunes
He participado en suficientes debriefs para ver los patrones. Esto es lo que hunde a la gente:
Quedarse en lo hipotético. “Normalmente yo haría…” no vale nada. Necesitan un “yo hice.” Situación específica, acciones específicas, resultado específico. Siempre.
Contar historias de equipo en primera persona del plural. “Decidimos que…” durante tres minutos seguidos. Te están entrevistando a ti, no a tu equipo. Di qué hiciste tú. No es presumir. Es responder la pregunta.
Elegir fracasos “seguros”. “Mi mayor fracaso fue ser demasiado perfeccionista con la calidad del código.” Por favor. Elige uno real. El entrevistador reconoce una evasiva a kilómetros.
Hablar largo sin estructura. Cinco minutos de divagación donde el punto llega en el minuto cuatro. Usa STAR. Llega a la Acción en los primeros sesenta segundos. Ahí es donde pasa el scoring.
Olvidar el Resultado. Contaste una historia genial y después… se quedó en el aire. Siempre aterriza. Cuál fue el resultado? Qué cambió? Qué aprendiste?
Si algo de esto te suena, lo desglosé en más detalle en errores en entrevistas comportamentales que te cuestan el puesto.
Preguntas frecuentes
Cuántas historias necesito preparar realmente?
Ocho a diez, y deberían cubrir varios temas cada una. Una buena historia de conflicto también puede funcionar para una pregunta de liderazgo. Una historia de fracaso puede servir como historia de desafío técnico. Mapea tus historias a los cinco temas de arriba y asegúrate de que hay solapamiento. No necesitas veinte historias únicas para veinte preguntas.
Debería memorizar mis respuestas?
Por favor, no. Las respuestas memorizadas suenan memorizadas. Prepara los puntos clave — el setup de la Situación, los detalles esenciales de la Acción, el Resultado cuantificado — y cuéntalo naturalmente cada vez. Va a salir un poco diferente cada vez, y eso está perfecto. Eso es lo que lo hace sonar real.
Qué hago si no tengo una historia para alguna de estas preguntas?
Probablemente sí la tienes, solo no la has enmarcado todavía. Ese “desacuerdo” quizás fue un hilo de Slack donde argumentaste por un diseño de API diferente. Ese “fracaso” quizás fue un sprint donde te sobrecomprometiste. Repasa tus últimos dos o tres proyectos y extrae los momentos. No tienen que ser dramáticos.
Practicar con alguien de verdad ayuda?
Más que cualquier otra cosa. Cuando por fin hice entrevistas simuladas para las rondas comportamentales — no solo las técnicas — mis respuestas pasaron de divagar a ser precisas en unas tres sesiones. Escucharte en voz alta es completamente diferente a ensayar en tu cabeza. Busca un amigo, un colega, un compañero de práctica y recorran estas preguntas. La incomodidad pasa rápido.
La ronda comportamental no es un test de personalidad. Es una evaluación estructurada con preguntas predecibles y criterios de scoring claros. Trátala como cualquier otra habilidad técnica: aprende el marco, practica con historias reales, recibe feedback, itera. Y si estás armando un plan de preparación más amplio que cubra también coding y system design, mira cómo preparar una entrevista técnica — ahí está el panorama completo.
Tu experiencia pasada es la materia prima. STAR es la estructura. La preparación es lo que marca la diferencia.
Listo para practicar? Accede al early access —>