Saltar al contenido
Aethel

Entrevista con IA para desarrolladores full-stack

Actualizado en noviembre de 2026

Las entrevistas full-stack preguntan si usted puede llevar una funcionalidad desde la base de datos hasta el botón y mantenerla funcionando después del lanzamiento. Una entrevista con IA va a buscar las uniones: dónde debe vivir la lógica, qué pasa cuando la API y la pantalla no coinciden y cómo decidió qué construir primero. Aquí están las preguntas que puede esperar, dos ejemplos resueltos, los errores que hacen sonar débiles las respuestas full-stack y práctica gratuita en su nivel.

Practicar preguntas de full-stack 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 full-stack

  1. Una funcionalidad de punta a punta

    “Cuénteme de una funcionalidad que usted construyó en el frontend y en el backend. ¿Cuáles fueron las decisiones más difíciles?”

    Lo que se escucha: Decisiones en cada capa, no una lista de capas: el modelo de datos, la forma de la API, los estados de la pantalla y cómo encajan entre sí.

  2. Dónde vive la lógica

    “Describa una vez que tuvo que decidir si una regla iba en el navegador o en el servidor.”

    Lo que se escucha: Seguridad, consistencia y velocidad puestas en la balanza en un caso real.

  3. Un cambio de datos que llegó a la pantalla

    “Cuénteme de un cambio en el modelo de datos que obligó a cambiar la interfaz. ¿Cómo mantuvo funcionando a los clientes anteriores?”

    Lo que se escucha: Versionado, compatibilidad hacia atrás y cuánto tiempo tuvo que convivir el camino viejo con el nuevo.

  4. Depurar entre capas

    “Un usuario reportó datos incorrectos en pantalla. ¿Cómo encontró en qué capa estaba el problema?”

    Lo que se escucha: Un método: reproducirlo, seguir la solicitud, revisar cada frontera y decir la causa en una oración.

  5. Alcance con el plazo encima

    “Tenía dos semanas para una funcionalidad que necesitaba cuatro. ¿Qué dejó afuera?”

    Lo que se escucha: Qué necesitaban los usuarios primero, qué postergó y cómo se lo dijo a la product manager.

  6. Hacerse cargo después del lanzamiento

    “Después del lanzamiento, ¿cómo supo que la funcionalidad estaba funcionando?”

    Lo que se escucha: Logs, métricas o analítica que usted mismo configuró, y una cosa que le mostraron.

  7. Trabajar con especialistas

    “¿Cómo trabajó con alguien de backend, de diseño o de datos que no estaba de acuerdo con usted?”

    Lo que se escucha: Un desacuerdo real, qué aprendió de él y cómo se resolvió.

Ejemplo resuelto: pagos con código QR en una tienda en línea

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: “Cuénteme de una funcionalidad que usted construyó en el frontend y en el backend. ¿Cuáles fueron las decisiones más difíciles?”

Respuesta débil

“Hice toda la funcionalidad de pagos con QR yo solo, frontend y backend. Armé los componentes en React, la API en Node y las tablas en la base de datos, y después la subí a producción. Fue mucho trabajo, pero quedó muy bien y el cliente quedó contento.”

Por qué es débil: Enumera capas en lugar de decisiones. No dice qué fue difícil, qué eligió frente a qué ni cómo supo que funcionó. "El cliente quedó contento" es una sensación, no un resultado, y "yo solo" invita a una repregunta que la respuesta no puede sostener.

Con las reglas de Aethel: Situación 1, razonamiento 0, 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 tienda en línea de electrodomésticos en Argentina, con unos 9.000 pedidos al mes, agregué el pago con código QR de billeteras virtuales. Lo difícil era que el pago se confirma fuera de nuestra página: el cliente paga en su celular y la billetera nos avisa por un webhook, a veces con varios minutos de demora. Decidí que solo el servidor cambiara el estado del pedido, a partir del webhook verificado, y que la pantalla mostrara "esperando su pago" consultando ese estado cada pocos segundos, con el stock reservado durante 15 minutos. Evalué confirmar el pedido apenas el navegador volvía de la billetera, que era más simple, pero ese regreso se puede falsificar y a veces nunca llega. También registré cada pedido que vencía sin pago. En los primeros dos meses, el 18 por ciento de los pedidos se pagó con QR, no entregamos ningún pedido sin cobrar y los reclamos de "pagué y no se confirmó" bajaron de unos 120 a 15 por mes.”

Por qué es fuerte: Ubica el negocio, el tamaño y el problema real, y dedica la respuesta a una decisión que cruza todas las capas: un webhook verificado, un estado que solo cambia el servidor y una pantalla pensada para la espera. Descarta una alternativa más simple con una razón de seguridad, y el resultado se mide con datos de pedidos y de soporte.

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: ¿qué pasa si el webhook llega dos veces, o llega después de que venció la reserva? Tenga lista la regla que aplicó en cada caso.

Ejemplo resuelto: cupones recortados antes del Buen Fin

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

Pregunta: “Tenía dos semanas para una funcionalidad que necesitaba cuatro. ¿Qué dejó afuera?”

Respuesta débil

“Eso pasa seguido. Normalmente hablo con la product manager y vemos qué es lo más importante. Después me concentro en lo principal y dejo los detalles para más adelante. La comunicación es clave en esas situaciones.”

Por qué es débil: Describe un hábito en general, así que no hay funcionalidad, ni recorte, ni consecuencia. El entrevistador solo se entera de que usted habla con la product manager, algo que casi todos dicen.

Con las reglas de Aethel: Situación 0, razonamiento 1, resultado 0: 1 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 startup de 20 personas en México que vende un sistema de punto de venta para restaurantes, tenía dos semanas antes del Buen Fin para lanzar cupones de descuento. El diseño incluía cupones por porcentaje y por monto, límites por cliente, un reporte de uso y la carga masiva desde Excel. Listé lo que un restaurante necesitaba el primer día: crear un cupón y que el mesero lo aplicara en la cuenta sin errores. Mantuve los dos tipos de descuento y el límite total de usos, que se valida en el servidor para que dos cajas no gasten el último cupón al mismo tiempo. Dejé para después el límite por cliente, el reporte y la carga desde Excel; en lugar del reporte, agregué una exportación a CSV desde una consulta que ya existía, que me tomó una tarde. Anoté cada recorte en el ticket con su razón y una fecha, y lo revisé con la product manager. Lanzamos a tiempo, 140 restaurantes crearon cupones esa semana y el límite por cliente llegó en la versión siguiente, cuando 11 restaurantes lo pidieron.”

Por qué es fuerte: La lista de recortes es concreta y cada uno tiene una razón ligada a lo que el restaurante necesitaba el primer día. La regla que no podía fallar queda en el servidor, una solución barata reemplaza al reporte postergado, la product manager es parte de la historia y el resultado muestra que postergar fue la decisión correcta.

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 evitó que dos cajas aplicaran el último cupón disponible al mismo tiempo? Nombre la transacción o el bloqueo que usó.

Errores comunes en las respuestas full-stack

  • Enumerar el stack. "React, Node, PostgreSQL y una nube" es su currículum, no una respuesta. El entrevistador quiere la decisión en la unión entre dos de esas piezas.
  • Atribuirse todo. Quien postula a full-stack suele decir "lo hice todo yo". Si un compañero armó la infraestructura, dígalo: las partes que sí fueron suyas se vuelven más creíbles.
  • Olvidar los caminos tristes. Los estados de carga, vacío, error y conflicto son donde se rompen las funcionalidades full-stack. Cuente cómo los resolvió.
  • Confiar en el navegador. Si un precio, un permiso o el stock se valida solo en el cliente, espere una repregunta sobre seguridad. Diga dónde ocurre la validación real.
  • Nada después del lanzamiento. Una funcionalidad que lanzó y nunca midió es media historia. Nombre el log, la métrica o el reporte de usuarios que le dijo que funcionaba.
  • Profundidad en ninguna parte. La amplitud es parte del rol, pero en cada respuesta baje a fondo en una capa. Su amplitud se nota a lo largo de toda la entrevista.

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:

  • Usuarios o cuentas que usaron la funcionalidad en sus primeras semanas
  • Tiempo desde el primer commit hasta el lanzamiento, y cuántas personas trabajaron en ella
  • Latencia y tasa de errores de los endpoints que agregó
  • Filas o volumen de datos de las tablas que cambió
  • Conversión, tickets de soporte o trabajo manual que la funcionalidad eliminó
  • Cuántas veces pasaron los casos tristes después del lanzamiento: conflictos, pagos fallidos, reintentos

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 full-stack

¿El entrevistador con IA me va a preguntar de frontend o de backend?

Normalmente de los dos, muchas veces en la misma pregunta. Si usted se inclina hacia un lado, dígalo al principio y elija casos donde tomó decisiones a ambos lados de la API.

¿Cómo muestro profundidad si mi trabajo es la amplitud?

Elija una decisión por respuesta y sígala hasta el fondo: por qué ese tipo de columna, por qué ese código de estado, por qué ese mensaje en pantalla. Un camino profundo muestra más que cuatro superficiales.

Trabajo como freelancer para clientes pequeños. ¿Mis proyectos cuentan?

Sí, si son específicos: el tipo de negocio, cuántos usuarios o pedidos, qué decidió usted y cómo supo que funcionó. No hace falta nombrar al cliente; "una cadena de 4 farmacias" alcanza.

¿Conviene hablar de infraestructura siendo full-stack?

Si usted configuró el despliegue, los respaldos de la base de datos o las alertas de su propia funcionalidad, sí. Hacerse cargo de una funcionalidad en producción es parte del rol. Limítese a lo que hizo usted.

Más guías

In English: AI interview prep for full-stack developers