Questions to Ask in a Backend Developer Interview

La entrevista va bien, te preguntan si tienes alguna duda, y se te ocurren cero preguntas con contenido. Sales con la sensación de que aceptaste la oferta a ciegas, sin saber si el equipo tiene alertas a las tres de la mañana ni si el código es un desastre heredado.

Las preguntas que haces al final dicen mucho de ti. Para un perfil backend con experiencia, son la prueba de que piensas en operación, en mantenimiento y en cómo se toman las decisiones técnicas. Y para ti, son la mejor forma de detectar problemas antes de firmar.

Aquí van 12 preguntas agrupadas por lo que revelan, con ejemplos concretos de cómo leer cada respuesta.

La realidad del equipo#

Estas cuatro preguntas te dicen cómo es el día a día real, no el que cuenta la web de la empresa.

1. ¿Cómo es una semana típica del equipo? ¿Cuánto tiempo va a reuniones y cuánto a código?

Suena simple. No lo es. Si te dicen que hay tres ceremonias de Scrum al día, daily de 30 minutos y retrospectivas eternas, sabes que el desarrollo se va a ahogar en reuniones.

Respuesta sana: mencionan daily cortas, algún bloque de foco sin reuniones, y un tiempo razonable dedicado a escribir y revisar código.

2. ¿Cuántos desarrolladores tocan el mismo servicio o repositorio a la semana?

Si son diez personas metiendo cambios en el mismo servicio, los despliegues se vuelven frágiles y las revisiones de código se acumulan. Si te dicen que cada servicio tiene un dueño claro, hay más orden del que parece.

3. ¿Cómo se hace la revisión de código? ¿Quién aprueba y cuánto tarda?

Busca detalles: cuántos aprobadores hacen falta, si hay bloqueos por revisiones pendientes, si se revisa con criterios o solo por cumplir. Un equipo que no tiene proceso de revisión está acumulando deuda técnica a velocidad constante.

4. ¿Quién está de guardia y cómo se reparten las incidencias?

Esto es lo que casi nadie pregunta y todo el mundo debería. Si hay guardias 24/7 entre cuatro personas, tu vida social se va a ver afectado. Pregunta también por la compensación de las guardias y por la frecuencia real de los incidentes nocturnos.

Las prioridades reales de la empresa#

Aquí descubres si la empresa invierte en calidad o solo habla de ella.

5. ¿Qué porcentaje del tiempo dedican a pagar deuda técnica y cómo deciden qué abordar?

Si la respuesta es "cuando podamos", la deuda nunca se paga. Un equipo maduro tiene un hueco explícito en cada sprint o en cada trimestre, y sabe priorizar entre deuda operativa y deuda de arquitectura.

6. ¿Cuándo fue la última vez que reescribieron o retiraron un servicio? ¿Cómo decidieron hacerlo?

Los equipos que saben retirar código son equipos que saben mantener sistemas. Si nunca han eliminado nada, probablemente tienen servicios zombies que alguien mantiene con miedo a romperlos.

7. ¿Cómo deciden entre construir algo a medida o usar una herramienta ya existente?

Esto revela la cultura técnica. Un extremo es reescribir todo desde cero por orgullo, el otro es meter dependencias sin leer la documentación. Busca un punto medio con criterios explícitos: coste de mantenimiento, control necesario, tamaño del equipo.

8. ¿Cómo se documentan las decisiones de arquitectura? ¿Dónde puedo ver un ejemplo?

No preguntes solo si documentan. Pide un ejemplo. Si te enseñan un ADR (Architecture Decision Record) o un documento de diseño con fecha y contexto, es buena señal. Si te dicen "lo tenemos todo en Slack", prepárate.

Los criterios de éxito#

Estas preguntas te dan la información que necesitas para triunfar los primeros meses y para saber si la empresa tiene expectativas claras.

9. ¿Qué espera que haya conseguido la persona que ocupe este puesto a los tres meses?

Una respuesta vaga como "integrarse bien" no sirve. Busca algo concreto: un servicio desplegado, una feature en producción, dominar un área del sistema. Si no saben decirte, no sabrán evaluarte tampoco.

10. ¿Cómo miden el rendimiento de un desarrollador backend? ¿Qué métricas usan?

Mucho cuidado con las métricas tipo "número de commits" o "líneas de código". Lo razonable es evaluar por entregas, por impacto en el sistema, por la calidad del trabajo y por la colaboración con el equipo.

Los riesgos que casi nadie pregunta#

Estas cuatro preguntas son incómodas. Por eso funcionan.

11. ¿Cuál es el mayor problema técnico que tiene el sistema hoy y por qué no se ha arreglado todavía?

Esta pregunta filtra rápido. Un equipo honesto te va a nombrar un problema concreto: una base de datos sin índices que nadie se atreve a tocar, un servicio monolítico que frena a todo el mundo, una cola de mensajes que se satura cada Black Friday. Si te dicen que "no hay problemas grandes", o están mintiendo o no los están viendo.

12. ¿Por qué sigue abierto este puesto? ¿Qué pasó con la persona anterior?

Directa y necesaria. Si el puesto lleva seis meses abierto, algo está fallando en el proceso o en la oferta. Si la persona anterior se fue por conflicto con la dirección, mejor saberlo ahora.

Cómo leer las respuestas que recibes#

No vale solo con hacer las preguntas. Tienes que escuchar lo que se dice entre líneas.

• Si te responden con datos y ejemplos concretos, hay proceso y hay reflexión.
• Si todas las respuestas son genéricas y optimistas, probablemente no hay proceso definido.
• Si te describen un sistema perfecto, desconfía. Todo sistema tiene problemas.
• Si te nombran problemas con explicación y plan, es el mejor escenario posible.
• Si evitan preguntas sobre guardias o sobre la persona anterior, es una señal clara de alarma.

Un truco útil: pide que te enseñen algo real durante la entrevista. Un diagrama de arquitectura, un ejemplo de un ADR, la pantalla del sistema de monitorización. Si no pueden enseñarte nada, la realidad probablemente es más caótica de lo que te cuentan.

Qué preguntas evitar#

Hay preguntas que no aportan y algunas directamente restan puntos.

• "¿Qué hace la empresa?" Investiga antes. Esto lo deberías tener resuelto.
• "¿Cuánto pagan?" No es que esté mal preguntarlo, pero no es la primera pregunta. Espera a que ellos abran el tema o hazlo en la conversación con RRHH, no con el equipo técnico.
• "¿Puedo trabajar remoto desde cualquier país?" La respuesta depende de la normativa fiscal y de visados, y varía según el país y la empresa. Pregunta por la política concreta y verifica los requisitos legales actuales en la fuente oficial que te corresponda.
• Preguntas que se responden con una búsqueda rápida en internet. Restan credibilidad.

Antes de la entrevista, conviene tener claro qué pide realmente la oferta. Un lector de ofertas de empleo te puede ayudar a extraer los requisitos ocultos del anuncio y a enfocar tus preguntas hacia lo que de verdad importa para ese puesto concreto.

Preparar el terreno#

La entrevista técnica va a tocar tu experiencia concreta. Ten listos ejemplos reales de sistemas que has mantenido, de incidentes que has resuelto, de decisiones técnicas que tomaste y por qué.

Un ejemplo de cómo contar tu experiencia con peso:

Antes: "Trabajé en una API REST con Node.js y PostgreSQL."

Después: "Mantuve una API de Node.js con PostgreSQL que servía unas 200.000 peticiones diarias. Reescribí el acceso a datos para reducir la latencia de las consultas principales de 800 ms a 120 ms, añadiendo índices y separando las consultas pesadas a un servicio aparte."

La segunda versión dice qué hacía el sistema, qué problema tenía y qué hiciste al respecto. Eso es lo que un entrevistador técnico quiere oír.

Antes de mandar el CV, pasa un verificador de compatibilidad con ATS para asegurarte de que tu experiencia no se pierde por formato. Y cuando busques ofertas abiertas, filtra por tipo de contrato y modalidad, porque la realidad de "remoto" varía mucho entre empresas.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántas preguntas debo hacer en una entrevista técnica?

Con tres o cuatro preguntas bien elegidas es suficiente. Lo que importa es la profundidad, no el número. Elige las que más te afecten según tu situación: si tienes familia, las guardias pesan más que la arquitectura.

¿Es buena idea preguntar por el salario en la primera entrevista?

Depende del país y del proceso. En muchas empresas hispanohablantes el rango se habla con RRHH en la primera o segunda llamada, no con el equipo técnico. Deja que lo abran ellos o pregunta por el rango previsto para la posición sin entrar en negociación todavía.

¿Qué hago si no entiendo la respuesta técnica que me dan?

Pide que lo expliquen con otras palabras. Un buen equipo lo agradece y lo toma como curiosidad sana. Si te responden con condescendencia o evasiva, ya sabes qué tipo de equipo es.

¿Debo preguntar sobre la posibilidad de promoción si es mi primera entrevista?

Sí, pero encuádrala bien: pregunta por el camino de crecimiento técnico del equipo, no por tu ascenso concreto. Es información legítima que además demuestra que piensas a medio plazo.

¿Sirven las mismas preguntas para un puesto junior y para uno senior?

El contenido cambia. Para un puesto junior, prioriza preguntas sobre mentoría, formación y proceso de revisión de código. Para un puesto senior, pesan más las de arquitectura, guardias y toma de decisiones técnicas.