Saltar al contenido
Aethel

Entrevista con IA para desarrolladores backend

Actualizado en noviembre de 2026

En una entrevista con IA, las preguntas de backend casi nunca son de sintaxis. Preguntan por sistemas que usted operó: una API bajo carga, una tabla que hubo que cambiar con usuarios encima, un pago que falló a mitad de camino. Aquí están los tipos de preguntas que puede esperar, dos ejemplos de respuestas débiles y fuertes con la explicación, los errores que más le cuestan a quien postula a backend y una forma gratuita de practicar en su nivel.

Practicar preguntas de backend gratis

Esta guía y la práctica para su rol están en español. La inscripción y la página de resultados de Aethel están en inglés, y la entrevista la puede hacer en español: lo elige justo antes de empezar.

Qué preguntan las entrevistas con IA a desarrolladores backend

  1. Un servicio a su cargo

    “Cuénteme de un servicio del que usted era responsable. ¿Qué hacía, cuánto tráfico recibía y qué lo hacía difícil de operar?”

    Lo que se escucha: Escala concreta (solicitudes por segundo, volumen de datos), su parte y una dificultad real, no un recorrido por la arquitectura.

  2. Un modelo de datos que tuvo que cambiar

    “Describa una vez que cambió el esquema de una tabla grande que estaba en uso. ¿Cómo evitó que el servicio se cayera?”

    Lo que se escucha: La migración por pasos, cómo convivieron el código viejo y el nuevo, y cómo revisó los datos después.

  3. Rendimiento bajo carga

    “Un endpoint se volvió lento cuando creció el tráfico. ¿Cómo encontró la causa y qué cambió?”

    Lo que se escucha: Una medición antes del arreglo (un perfil, un plan de consulta, una traza), la causa en una oración y números antes y después.

  4. Fallas a mitad de camino

    “¿Qué pasa en su sistema cuando una llamada a otro servicio falla a mitad de una solicitud?”

    Lo que se escucha: Tiempos de espera, reintentos con límite, idempotencia, lo que ve el usuario y un caso real donde importó.

  5. Seguridad y datos personales

    “¿Cómo manejó secretos, autenticación o datos personales en un servicio que construyó?”

    Lo que se escucha: Controles concretos que usted puso y por qué, no una lista de buenas prácticas.

  6. Una decisión que defendió

    “Cuénteme de una vez que eligió un diseño más simple en lugar de uno más escalable, o al revés.”

    Lo que se escucha: Las opciones, el costo de cada una y qué lo habría hecho elegir distinto.

  7. Explicar fuera de ingeniería

    “¿Cómo le explicaría a una product manager por qué una funcionalidad necesita dos semanas de trabajo de backend?”

    Lo que se escucha: Palabras simples, el riesgo dicho con honestidad y una opción que cambie alcance por tiempo.

Ejemplo resuelto: un historial de movimientos lento

Cada ejemplo muestra una respuesta débil y una fuerte a la misma pregunta. Las líneas “Con las reglas de Aethel” aplican las reglas de calificación publicadas de Aethel, un ejemplo concreto de cómo una entrevista con IA puede evaluar una respuesta.

Ejemplo inventadoEscrito por Aethel para mostrar la diferencia. No es una persona real y la IA no lo calificó.

Pregunta: “Un endpoint se volvió lento cuando creció el tráfico. ¿Cómo encontró la causa y qué cambió?”

Respuesta débil

“Teníamos un endpoint lento, así que lo revisé y vi que las consultas a la base de datos no eran eficientes. Agregué índices y caché y quedó mucho más rápido. Siempre trato de medir antes de optimizar, y creo que el rendimiento es muy importante para la experiencia del usuario.”

Por qué es débil: No hay un caso específico: ni producto, ni tráfico, ni números. La causa es genérica ("consultas no eficientes"), nombra dos arreglos sin decir cuál importó, y la última oración es una opinión sobre el rendimiento, no evidencia. Una repregunta como "¿cuánto más rápido?" no tiene de dónde agarrarse.

Con las reglas de Aethel: Situación 0, razonamiento 1, resultado 1: 2 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.

Respuesta fuerte

“En una billetera digital en Colombia, con unos 800.000 usuarios activos al mes, yo tenía a cargo el endpoint que muestra el historial de movimientos. Los días de pago de quincena, el p95 pasaba de unos 200 milisegundos a más de 6 segundos y la app mostraba errores. Revisé el registro de consultas lentas en lugar de adivinar: la consulta ordenaba todos los movimientos del usuario por fecha y después paginaba con OFFSET, así que a los usuarios con muchos movimientos les recorría miles de filas en cada página. Cambié la paginación a una basada en cursor, con la fecha y el id del último movimiento, y agregué un índice compuesto por usuario, fecha e id. Consideré guardar el historial en caché, pero justo en quincena los saldos cambian cada minuto, y en una app de dinero mostrar un movimiento viejo genera más reclamos que la lentitud. En la quincena siguiente, el p95 se mantuvo en unos 180 milisegundos con 30 por ciento más tráfico, y los reclamos a soporte por "no veo mi pago" bajaron de unos 400 a 60 ese día.”

Por qué es fuerte: Ubica el caso en una oración (el producto, los usuarios, el endpoint), muestra cómo encontró la causa (el registro de consultas lentas, no una suposición), nombra un arreglo preciso y explica por qué perdió la alternativa obvia. El resultado es un antes y un después con carga real, más un número de soporte que confirma el efecto.

Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 2: 6 de 8 puntos, que en la escala fija de Aethel son 87. Un puntaje real puede ser distinto.

Lo que viene después: Repregunta probable: ¿cómo creó el índice en una tabla tan grande sin bloquearla? Tenga esa respuesta lista. Nombrar una segunda opción que comparó, como una réplica de lectura, y por qué perdió, subiría el razonamiento.

Ejemplo resuelto: recargas que se aplicaban dos veces

Ejemplo inventadoEscrito por Aethel para mostrar la diferencia. No es una persona real y la IA no lo calificó.

Pregunta: “¿Qué pasa en su sistema cuando una llamada a otro servicio falla a mitad de una solicitud?”

Respuesta débil

“Me aseguro de tener reintentos y buen manejo de errores. Si una llamada falla, la reintentamos unas veces y guardamos el error en los logs para revisarlo después. También tenemos monitoreo y alertas, así que si algo sale mal, la persona de guardia recibe una alerta y lo arregla.”

Por qué es débil: Describe buenas intenciones, no un caso. Reintentar "unas veces" sin idempotencia puede cobrarle dos veces a un cliente, que es justo lo que preguntaría después un entrevistador cuidadoso. No hay sistema, ni falla, ni resultado.

Con las reglas de Aethel: Situación 0, razonamiento 0, resultado 0: 0 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.

Respuesta fuerte

“En una plataforma de recargas de celular en México, con unas 50.000 recargas al día, nuestro servicio llamaba al operador telefónico para aplicar el saldo y después confirmaba la venta. Una noche el operador empezó a responder después de nuestro tiempo de espera de 10 segundos, aunque la recarga sí se aplicaba, y nuestro sistema la reintentaba: en una hora, 340 clientes recibieron saldo doble y lo pagamos nosotros. Yo lideré el arreglo. Cada recarga ahora lleva un identificador único que el operador usa para rechazar duplicados, y la venta queda guardada como pendiente antes de llamar, para confirmarla con la consulta de estado del operador en lugar de reintentar a ciegas. Evalué subir el tiempo de espera a 30 segundos, que era un cambio de una línea, pero eso solo movía el problema y dejaba al cliente mirando una pantalla de carga. En los siete meses siguientes, con tres incidentes más del operador, no tuvimos ninguna recarga duplicada.”

Por qué es fuerte: Parte de una falla real con su tamaño (recargas al día, clientes afectados, el tiempo), y da el mecanismo: un identificador de idempotencia, un estado pendiente y una consulta de estado, cada uno atado a la falla que evita. Sopesa una alternativa más fácil y dice por qué perdió, y el resultado se sigue durante meses, con incidentes posteriores.

Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 3: 7 de 8 puntos, que en la escala fija de Aethel son 91. Un puntaje real puede ser distinto.

Lo que viene después: Prepárese para: ¿qué pasa si la consulta de estado del operador también falla? Una buena respuesta nombra el proceso que concilia las ventas que se quedan pendientes.

Errores comunes en las respuestas de backend

  • Recorrer el diagrama de arquitectura. Pasar por cada caja (balanceador, tres servicios, caché, base de datos) gasta su tiempo sin mostrar criterio. Elija la parte donde usted tomó una decisión y dedique la respuesta a eso.
  • Decir "escaló bien" sin un número. La escala es el contexto del backend. Solicitudes por segundo, filas, mensajes al día o el tamaño del equipo le permiten al entrevistador ubicar su caso. Los números redondeados sirven.
  • Reintentos sin idempotencia. Mencionar reintentos en pagos, correos o cualquier cosa con efectos, sin decir cómo evita duplicados, invita a la repregunta más difícil de una entrevista de backend.
  • Omitir cómo llegó el cambio a producción. Los cambios de backend fallan en el despliegue: migraciones, cargas de datos, escrituras dobles, banderas de funcionalidad. Diga cómo salió el suyo de forma segura.
  • Afirmar sin medir. "Quedó más rápido" es una afirmación. "El p95 bajó de 6 segundos a 180 milisegundos con 30 por ciento más tráfico" es un resultado.
  • Usar herramientas como razones. "Usamos Kafka porque es el estándar" no da ninguna razón. "Necesitábamos volver a procesar mensajes después de un error, y la cola anterior los borraba al leerlos" sí la da.

Números que conviene tener a mano

Un entrevistador ubica un caso por sus números. Búsquelos para cada uno de sus casos antes de la entrevista; redondeados sirven:

  • Solicitudes por segundo en el pico, y la latencia p50, p95 o p99 del endpoint del que habla
  • Tasa de errores o disponibilidad antes y después de un cambio
  • Filas, gigabytes o mensajes al día de los datos involucrados
  • Cuánto tardó una migración o una carga de datos, y si algo se cayó
  • Cuántos servicios o equipos dependían del suyo
  • Para un incidente: tiempo hasta detectarlo, tiempo hasta recuperarse y clientes afectados

Practique gratis

Elija un nivel, escriba una respuesta a cada pregunta y lea la revisión rápida después de cada una. Es gratis, no necesita cuenta, no se guarda nada y no es un puntaje.

Preguntas de desarrolladores backend

¿Una entrevista con IA me va a preguntar de diseño de sistemas?

Con frecuencia, sí. Puede ser sobre un sistema que usted construyó o uno hipotético. En la entrevista de Aethel es sobre sus propios sistemas, a veces seguido de un cambio realista como un pico de tráfico, y usted responde con palabras, sin pizarra.

¿Conviene nombrar bases de datos y frameworks?

Cuando explican una decisión. "Usé PostgreSQL" dice poco. "Dejé la búsqueda en PostgreSQL con un índice parcial en lugar de agregar un clúster de búsqueda, porque nadie del equipo podía operar uno más" muestra criterio.

Trabajo en una empresa pequeña con poco tráfico. ¿Mis casos sirven?

Sí, si son específicos: 3 ingenieros, 5.000 usuarios, 20 solicitudes por segundo en el pico. Lo que debilita una respuesta es no tener números, no tener números pequeños. Una buena decisión con poco tráfico vale tanto como una con mucho.

¿Qué nivel de práctica elijo?

El nivel del puesto al que postula, no su cargo actual. Si hoy es semi senior y postula a senior, practique las preguntas de senior: tratan de decisiones entre equipos y de resultados seguidos durante meses, y conviene encontrar esos casos antes de la entrevista.

Más guías

In English: AI interview prep for backend developers