Preguntas de entrevista para programador / desarrollador de software y cómo responderlas
Una entrevista de desarrollador rara vez es un examen de definiciones. El entrevistador quiere ver cómo piensas cuando algo se rompe, cómo decides entre dos diseños imperfectos y cómo trabajas con código que no escribiste tú. Suele haber una parte técnica o de coding (en vivo o un test previo), pero la mayor parte del tiempo se va en que expliques tus decisiones: por qué elegiste esa estructura de datos, por qué metiste una cola en vez de llamar directo, por qué ese bug tardó tres días.
Lo que separa a quien aprueba de quien no suele ser el conocimiento, sino la capacidad de razonar en voz alta sin bloquearse. Mucha gente sabe resolver el problema pero se calla mientras piensa, o suelta la solución sin explicar el camino. Aquí tienes preguntas específicas del puesto con una guía para enfocar cada una. Léelas, pero no te quedes ahí: la respuesta solo cuenta si la sabes decir bajo presión.
Qué evalúan en esta entrevista
- Resolución de problemas y razonamiento técnico en voz alta
- Debugging sistemático bajo incertidumbre
- Diseño y arquitectura: manejar trade-offs sin respuesta única
- Calidad de código y colaboración en code reviews
- Comunicación: explicar decisiones técnicas con claridad
- Manejo de código heredado y deuda técnica
Preguntas frecuentes para programador / desarrollador de software
- 01
Cuéntame el bug más difícil que has depurado. ¿Cómo lo encontraste y por qué te costó tanto?
No describas el bug, describe tu método: cómo lo reprodujiste, qué hipótesis descartaste y cómo aislaste la causa. Lo que evalúan es tu proceso de debugging, no la anécdota.
- 02
Estás en una code review y un compañero te marca que tu solución no escala. ¿Qué haces?
Demuestra que separas el ego del código. Cuenta cómo pides el caso concreto que rompe tu enfoque, qué preguntas para entender el límite real y cuándo aceptas frente a cuándo defiendes con datos.
- 03
Diséñame a grandes rasgos un sistema que acorte URLs (o un feed, un carrito...). ¿Por dónde empiezas?
Empieza por las preguntas, no por la solución: volumen, lecturas vs escrituras, latencia aceptable. Razona los trade-offs en voz alta (consistencia vs disponibilidad, dónde cachear) en lugar de soltar una arquitectura cerrada de memoria.
- 04
¿Por qué elegiste [tu lenguaje/framework principal] en tu último proyecto y cuándo habría sido mala idea?
Habla de criterios reales: ecosistema, rendimiento, el equipo que lo mantendrá. Que reconozcas cuándo NO era la opción correcta vale más que defenderlo como si fuera perfecto para todo.
- 05
Tienes que añadir una feature a una parte del código que no entiendes y nadie la documentó. ¿Cómo procedes?
Muestra estrategia ante el código heredado: leer los tests, trazar las entradas y salidas, hacer cambios pequeños y verificables. Menciona qué te negarías a tocar sin red de seguridad.
- 06
Hablame de una vez que tomaste un atajo técnico (deuda técnica) a propósito. ¿Cómo lo justificaste?
Deja claro que fue una decisión consciente con coste conocido, no descuido. Explica qué ganaste (plazo, validar una hipótesis), cómo lo dejaste documentado y qué plan había para pagarlo.
- 07
Diferencia entre dos cosas que parecen similares en tu stack (p. ej. lista vs diccionario, SQL vs NoSQL, síncrono vs asíncrono): ¿cuándo usas cada una?
Responde con el cuándo, no con la definición de manual. Ancla cada opción a un caso de uso y al coste que asumes (memoria, latencia, complejidad). Si puedes, cita una vez que elegiste mal y lo cambiaste.
- 08
Tu código pasa en local pero falla en producción. ¿Qué revisas primero?
Enumera sospechosos por probabilidad: variables de entorno, versiones de dependencias, datos reales vs de prueba, concurrencia, zona horaria. Lo importante es el orden de tu razonamiento, no acertar la causa exacta.
Consejos para destacar
- Piensa en voz alta durante el coding. El silencio te penaliza más que un error: el entrevistador necesita ver tu razonamiento, no solo el resultado.
- Antes de codear, repite el problema y pregunta por los casos límite. Lanzarte a teclear sin aclarar requisitos es la señal de alarma número uno.
- Cuando defiendas una decisión técnica, nombra el trade-off que aceptaste. «Elegí X aun sabiendo que Y» suena a senior; «X es mejor» suena a junior.
- Lleva dos o tres proyectos preparados para contar con detalle: qué problema resolvían, tu decisión más difícil y qué harías distinto. Es el material del que salen la mitad de las repreguntas.
Practica una entrevista para programador / desarrollador de software
Pega tu CV y la oferta y habla con un reclutador de IA que adapta las preguntas a tu puesto. Feedback honesto por competencias, sin tarjeta.