Saltar al contenido
Aethel

Entrevista con IA para desarrolladores frontend

Actualizado en noviembre de 2026

Las entrevistas de frontend evalúan más que componentes. Una entrevista con IA le va a preguntar por qué una página se volvió lenta, cómo se desordenó el estado, qué se rompió para quienes usan teclado o lector de pantalla, y qué pasó cuando un diseño se encontró con datos reales. Aquí están las preguntas que puede esperar, dos ejemplos resueltos, los hábitos que debilitan las respuestas de frontend y práctica gratuita en su nivel.

Practicar preguntas de frontend 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 frontend

  1. Rendimiento que se nota

    “Cuénteme de una página o app que se sentía lenta. ¿Cómo lo midió y qué cambió?”

    Lo que se escucha: Una métrica real (Largest Contentful Paint, Interaction to Next Paint, tamaño del bundle) medida en dispositivos reales, la causa y el cambio que salió de ella.

  2. Un estado desordenado

    “Describa una vez que el manejo del estado en su app se volvió difícil de entender. ¿Qué hizo?”

    Lo que se escucha: El error o la confusión que causaba, las opciones que sopesó (subir el estado, un store, cachear datos del servidor) y por qué eligió una.

  3. Accesibilidad

    “Cuénteme de un problema de accesibilidad que encontró y corrigió.”

    Lo que se escucha: A quién afectaba, cómo lo encontró (una auditoría, un lector de pantalla, un reporte), el arreglo y cómo evitó que volviera.

  4. El diseño frente a datos reales

    “Un diseño se veía bien en el mockup pero se rompió con datos reales. ¿Qué pasó?”

    Lo que se escucha: Nombres largos, traducciones, estados vacíos, redes lentas, y cómo lo resolvió con la persona de diseño.

  5. Un navegador, un dispositivo

    “Describa un error que solo pasaba en un navegador o en un dispositivo.”

    Lo que se escucha: Cómo lo reprodujo, la causa y cómo probó el arreglo en varios dispositivos.

  6. Probar una interfaz

    “¿Cómo decide qué probar en una interfaz de usuario?”

    Lo que se escucha: Un caso donde una prueba atrapó algo real, y el equilibrio que eligió entre pruebas unitarias, de integración y de punta a punta.

  7. Lanzar un cambio grande

    “¿Cómo lanzó un cambio grande de interfaz sin romperle nada a los usuarios?”

    Lo que se escucha: Banderas de funcionalidad, un lanzamiento gradual, las métricas que vigiló y qué haría si empeoraban.

Ejemplo resuelto: filtros que congelaban la página

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 página que se sentía lenta. ¿Cómo lo midió y qué cambió?”

Respuesta débil

“Nuestra app estaba algo lenta, así que la optimicé. Usé memoización y carga diferida, achiqué el bundle y el puntaje de Lighthouse subió bastante. El rendimiento es muy importante para mí y siempre lo tengo en cuenta.”

Por qué es débil: No hay página, ni usuarios, ni punto de partida. Enumera tres técnicas sin conectarlas con una causa, y un puntaje de laboratorio medido en la laptop de quien desarrolla dice poco de lo que sintieron los usuarios. "Subió bastante" no es un resultado que se pueda evaluar.

Con las reglas de Aethel: Situación 0, razonamiento 0, resultado 1: 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

“Trabajé en el listado de productos de un supermercado en línea en Chile, con unas 250.000 visitas al mes, casi todas desde teléfonos Android de gama media y muchas con datos móviles. Los datos de campo mostraban un Interaction to Next Paint de unos 650 milisegundos al tocar los filtros, y la gente se quejaba de que la página "se congelaba". Una traza de rendimiento mostró que cada toque en un filtro volvía a renderizar los 120 productos de la página y recalculaba los precios con descuento en el hilo principal. Moví el cálculo de precios al servidor, que ya tenía esos datos, y separé la lista para que solo se renderizaran las tarjetas que cambiaban. Pensé en virtualizar la lista, pero con 120 productos el problema no era cuántos había en pantalla sino cuánto trabajo hacía cada uno, y la virtualización complicaba la navegación con lector de pantalla. Al mes siguiente, el INP en el percentil 75 bajó a unos 140 milisegundos, y el uso de filtros subió un 18 por ciento según los datos de analítica.”

Por qué es fuerte: Nombra la página, el tráfico, los dispositivos y la red, usa datos de campo y no un puntaje de laboratorio, y rastrea la lentitud hasta una causa. El arreglo sale de la causa, descarta una alternativa con una razón que incluye la accesibilidad, y el resultado está medido en usuarios reales.

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 se aseguró de que los precios del servidor y los de la pantalla no se desincronizaran? Tenga lista la parte de la API que garantiza que llegan juntos.

Ejemplo resuelto: tarjetas que no aguantaron los datos reales

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

Pregunta: “Un diseño se veía bien en el mockup pero se rompió con datos reales. ¿Qué pasó?”

Respuesta débil

“Eso pasa mucho con los diseñadores. Los mockups siempre tienen datos perfectos y después en producción todo se ve mal. Yo arreglo el CSS para que se adapte y les aviso para que lo tengan en cuenta la próxima vez.”

Por qué es débil: Habla de los diseñadores en general, no de un caso, y deja a la otra persona como el problema. No hay pantalla, ni dato que rompió el diseño, ni una decisión compartida, y una entrevista atenta a la colaboración lo nota.

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 app de reservas de canchas de fútbol en Argentina, con unos 300 clubes, el rediseño de la tarjeta de cada club venía con nombres como "Club Norte" y una foto perfecta. Cuando lo conecté con los datos reales, encontré nombres de hasta 60 caracteres, como "Asociación Deportiva, Cultural y Recreativa de Villa del Parque", 40 clubes sin foto y precios en dos monedas en los clubes de frontera. Antes de tocar el CSS, armé una página con las 30 tarjetas más difíciles de los datos reales y se la mostré a la diseñadora. Decidimos juntos cortar el nombre en dos líneas con el nombre completo disponible para lectores de pantalla, usar un fondo con las iniciales cuando no hay foto, y mostrar el precio en una sola moneda con la otra en el detalle. Ella propuso achicar la letra para que entraran los nombres largos, lo probamos, y en teléfonos chicos quedaba ilegible. Desde ese cambio, la página de casos difíciles es parte de nuestra revisión de diseño, y en los dos rediseños siguientes no tuvimos que volver a abrir tarjetas después del lanzamiento.”

Por qué es fuerte: Convierte un choque con diseño en un caso con datos: cuántos clubes, qué nombres, qué casos raros. La decisión se toma con la diseñadora, se prueba la propuesta de ella y se dice por qué no funcionó, y el resultado incluye un cambio de proceso que se mantuvo en los rediseños siguientes.

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: ¿cómo eligió esas 30 tarjetas? Decir que las sacó con una consulta a los datos reales, y no a mano, hace la respuesta más creíble.

Errores comunes en las respuestas de frontend

  • Citar un puntaje de laboratorio como resultado. Un puntaje de Lighthouse en su laptop es un punto de partida. Los entrevistadores confían en datos de campo de usuarios reales: LCP, INP, errores, conversión.
  • Enumerar hooks y librerías. Nombrar memoización, una librería de estado o un framework nuevo no es una razón. Diga qué problema resolvió y qué dejó a cambio.
  • Reducir la accesibilidad al texto alternativo. Hable de una tarea que una persona real no podía completar, de cómo la probó con teclado o lector de pantalla y de qué cambió.
  • Dejar afuera a diseño y a los usuarios. El frontend se trabaja junto con diseño y producto. Una respuesta sin ninguna conversación se pierde la parte de colaboración de la pregunta.
  • Pensar solo en escritorio y wifi. Si la mayoría de sus usuarios usa teléfonos de gama media con datos móviles, dígalo, y diga en qué dispositivos y redes probó.
  • Ninguna historia de lanzamiento. Los cambios grandes de interfaz necesitan banderas, lanzamientos por etapas y métricas que vigilar. Diga cómo habría sabido que el cambio estaba perjudicando a los usuarios.

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:

  • LCP, INP y CLS en el percentil 75, con datos de campo si los tiene
  • El tamaño del JavaScript antes y después, en kilobytes
  • Qué parte de sus usuarios entra desde el teléfono, y los dispositivos o redes más lentos que soportaba
  • La tasa de errores de su monitoreo de frontend
  • Conversión, tareas completadas o reclamos de soporte ligados a la página
  • Cuántas pantallas, componentes o equipos compartían el código que cambió

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 frontend

¿El entrevistador con IA me va a pedir que programe un componente en vivo?

Algunas herramientas incluyen una tarea de programación, así que pregunte antes. La entrevista de Aethel no: usted habla de componentes y páginas que construyó, y de por qué los hizo así.

¿Cómo hablo de trabajo visual sin mostrarlo?

Descríbalo con palabras: qué hace la pantalla, quién la usa, qué cambió y por qué. Nombre la restricción que le dio forma, como un nombre muy largo o una red lenta. El entrevistador no ve su pantalla, así que la restricción hace el trabajo de una captura.

Trabajo en una agencia y cambio de proyecto cada pocos meses. ¿Qué caso elijo?

El proyecto donde usted tomó más decisiones y donde sabe qué pasó después del lanzamiento. Si no tiene datos de uso, diga quién confirmó el resultado: el cliente, el equipo de soporte o una prueba con usuarios.

¿Hablo de CSS o solo de JavaScript?

De cualquiera de los dos. Un layout que se rompió con textos largos en español, o un cambio en el sistema de diseño que tocó 200 pantallas, puede ser mejor material que una historia de manejo de estado.

Más guías

In English: AI interview prep for frontend developers