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.
Ejemplo de respuesta «Teníamos un error de pagos que solo aparecía en producción, una de cada mil transacciones. Primero conseguí reproducirlo: capturé los payloads reales de los casos fallidos y monté un test que los reproducía en local. Descarté la pasarela comparando sus logs con los nuestros, y descarté datos corruptos validando el esquema. Al final era una condición de carrera: dos webhooks del mismo pago llegaban con milisegundos de diferencia y el segundo pisaba al primero. Me costó una semana porque el log agregado ocultaba el orden real de llegada. Lo resolví con un lock por id de pago y añadí un test de concurrencia para que no volviera.»
- 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.
Ejemplo de respuesta «Lo primero es pedirle el caso concreto: ¿a partir de qué volumen deja de funcionar mi enfoque? Si me dice que con 10.000 elementos por petición mi bucle se dispara, lo compruebo con datos reales de producción. Nos pasó con un listado que yo había resuelto en memoria: él tenía razón para el 5% de cuentas grandes, así que paginé la consulta. Pero si el caso que me plantea no existe en nuestros datos ni en el roadmap, lo digo con números: preferimos lo simple hoy y dejamos anotado el límite. Acepto cuando hay evidencia, defiendo cuando la evidencia está de mi lado, y nunca lo convierto en algo personal.»
- 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.
Ejemplo de respuesta «Antes de dibujar nada preguntaría tres cosas: ¿cuántas URLs nuevas al día y cuántas redirecciones?, ¿pueden caducar?, ¿importa la analítica de clics? Supongamos mil escrituras y un millón de lecturas diarias: es un sistema de lecturas, así que optimizo ahí. Generaría códigos de 7 caracteres en base 62 desde un contador con bloques pre-reservados por instancia, para evitar colisiones sin coordinar cada petición. Guardaría el mapeo en una base clave-valor y pondría una caché delante para el 20% de URLs que se llevan el 80% del tráfico. La redirección puede ser eventualmente consistente: si un enlace tarda un segundo en propagarse, no pasa nada; eso me permite replicar sin bloquear escrituras.»
- 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.
Ejemplo de respuesta «En mi último proyecto elegí TypeScript con Node porque el equipo ya dominaba JavaScript, el producto era una API con mucha integración de terceros y el tipado nos ahorraba los errores tontos de contratos entre servicios. No fue una decisión de moda: valoré que contratar perfiles fuera fácil y que el ecosistema tuviera librerías maduras para lo que necesitábamos. ¿Cuándo habría sido mala idea? Si el núcleo hubiera sido cálculo intensivo de CPU, procesamiento de imagen o algo con requisitos duros de memoria: ahí Node se ahoga y habría ido a Go o a Python con extensiones nativas. De hecho un job de generación de PDFs acabamos sacándolo a un worker separado porque bloqueaba el event loop.»
- 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.
Ejemplo de respuesta «Primero leo los tests, si los hay: son la única documentación que no miente. Si no hay, trazo el flujo con un caso real: pongo logs o un debugger en la entrada y sigo los datos hasta la salida, y con eso me dibujo un mapa de qué toca qué. Antes de añadir mi feature, escribo dos o tres tests de caracterización que fijen el comportamiento actual, aunque me parezca raro: ese comportamiento puede ser un contrato que alguien espera. Luego hago el cambio más pequeño posible y verifico que los tests siguen en verde. Lo que no haría es refactorizar a la vez que añado la feature, ni tocar sin red algo que mueva dinero o datos de usuarios: ahí primero tests, después cambios.»
- 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.
Ejemplo de respuesta «Para validar una integración con un cliente grande, hardcodeé su configuración en lugar de construir el sistema de configuración por cliente que tocaba. Lo decidí con mi responsable delante: montar lo genérico eran tres semanas y el cliente decidía en una. Dejé el atajo señalizado: un comentario con el porqué, un ticket en el backlog con la solución real estimada, y una alerta si otro cliente llegaba a ese código. El cliente firmó, y en el trimestre siguiente pagamos la deuda con el sistema genérico. Para mí la diferencia entre deuda buena y mala es esa: la buena tiene fecha, dueño y un coste que alguien aceptó en voz alta; la mala es la que se descubre seis meses después por sorpresa.»
- 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.
Ejemplo de respuesta «SQL contra NoSQL, por ejemplo: no es una guerra de religiones, es una pregunta sobre tus datos. Si tienen relaciones que importan (pedidos, clientes, facturas) y necesitas transacciones, SQL, porque las garantías te las da la base y no las tienes que reinventar en el código. NoSQL lo uso cuando el esquema es volátil o el volumen de lecturas simples es enorme: sesiones, catálogos denormalizados, eventos. El coste que asumes con NoSQL es que las preguntas que no previste se vuelven caras. Me pasó: montamos analítica sobre una base de documentos y a los seis meses cada informe nuevo era un sufrimiento; migramos esa parte a Postgres y las consultas pasaron de horas de trabajo a un JOIN.»
- 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.
Ejemplo de respuesta «Voy por orden de probabilidad. Primero, configuración: variables de entorno que faltan o apuntan a otro sitio, es la causa más común y la más barata de comprobar. Segundo, datos: en local pruebo con datos limpios y producción tiene los casos raros (nulos, acentos, registros de 2015). Tercero, versiones: ¿el lockfile se respetó en el deploy?, ¿la versión de Node o de la base es la misma? Cuarto, todo lo que en local no existe: concurrencia real, latencia de red, permisos, zona horaria del servidor. Y mientras reviso, miro los logs del error real en producción en lugar de suponer: la mitad de las veces el stack trace ya te dice en cuál de esas cuatro familias estás.»
Muchas de estas preguntas son de tipo «cuéntame una vez que…». Para estructurar esas respuestas con una historia clara, usa el método STAR.
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.