Desarrollador frontend: preguntas de entrevista y consejos

Las preguntas de entrevista para desarrollador frontend evalúan si puedes construir interfaces que carguen rápido, funcionen para todas las personas y sigan siendo mantenibles a medida que el producto crece. Te preguntarán por rendimiento, accesibilidad, manejo de estado, comportamiento del navegador y colaboración con diseño; responde con resultados que el usuario pueda notar, no con una lista de frameworks.

¿Dónde ponen el foco las entrevistas de frontend?

La Oficina de Estadísticas Laborales de Estados Unidos (BLS) agrupa este trabajo en la categoría de desarrolladores web y diseñadores digitales, que “crean y mantienen sitios web” y prueban la usabilidad de las interfaces (la fuente está en inglés; la traducción es nuestra). Para ese grupo proyecta que el empleo en Estados Unidos crecerá un 5% entre 2025 y 2035. Los gerentes de contratación (hiring managers) de estos puestos suelen explorar tres capas:

• El navegador. Cómo cargan, se renderizan y responden las páginas, y por qué una página se siente lenta.
• El código. Estructura de componentes, estado, arquitectura de CSS y pruebas.
• Las personas. Cómo trabajas con diseñadores, gerentes de producto e ingenieros de backend.

La accesibilidad aparece más seguido de lo que muchos candidatos esperan. Las Pautas de Accesibilidad para el Contenido Web (WCAG) del W3C son el estándar que la mayoría de los equipos toma como referencia, y la versión vigente es WCAG 2.2. No hace falta que recites los criterios de conformidad, pero sí deberías poder describir cómo resolviste en tu propio trabajo el uso con teclado, el manejo del foco y el contraste de color.

Para el proceso completo de entrevistas de ingeniería, con sus preguntas sobre incidentes y sobre diseño, revisa las preguntas de entrevista para ingeniero de software y nuestra guía del sector tecnología.

¿Cómo responder una pregunta sobre rendimiento en el frontend?

Diagnostica antes de recetar. Una buena respuesta a “esta página está lenta” sigue este orden:

1. Mide donde lo sienten los usuarios. Primero los datos de campo; después, una traza de laboratorio en un perfil móvil con throttling.
2. Separa el costo. ¿Viene de la red (imágenes pesadas, demasiadas peticiones), del renderizado (layout thrashing) o de los scripts (un bundle pesado que bloquea el hilo principal)?
3. Corrige primero el costo más grande y vuelve a medir.
4. Protege la mejora. Un presupuesto de rendimiento en CI o una alerta, para que la regresión no vuelva.

Los candidatos que arrancan con “yo agregaría lazy loading” antes de medir suelen perder puntos, incluso cuando el lazy loading es la respuesta correcta.

Respuesta STAR de ejemplo: arreglar un checkout lento

Respuesta de ejemplo de una desarrolladora frontend de nivel intermedio a la pregunta “Háblame de una ocasión en la que lograste que una página web fuera más rápida y pudiste medirlo”.

Situación

Tarea

Acción

Resultado

1. Situación

   Nuestra página de pago (checkout) tardaba más de cuatro segundos en mostrar el formulario de pago en teléfonos Android de gama media, y la proporción de compras completadas desde celulares estaba muy por debajo de la de escritorio.

2. Tarea

   Me pidieron mejorar el tiempo de carga en celulares sin rediseñar la página y dentro de un solo sprint.

3. Acción

   Analicé la página con el profiler en un dispositivo con throttling y encontré que una librería grande de selector de fechas y un bundle de analítica se cargaban antes que el formulario. Separé el selector de fechas en un chunk con carga diferida, diferí la carga del script de analítica y ajusté el tamaño de las imágenes de producto. También agregué en CI una verificación del tamaño del bundle, para que cada dependencia nueva tuviera que justificarse.

4. Resultado

   El tiempo hasta que el formulario de pago se podía usar bajó de unos 4.2 a 1.9 segundos en nuestro dispositivo de prueba, y las compras completadas desde celulares subieron varios puntos durante el mes siguiente. Desde entonces, la verificación de CI ha bloqueado dos dependencias pesadas.

Qué la hace buena: parte de un problema del usuario, muestra mediciones, atribuye el resultado a cambios concretos y termina con prevención.

¿Qué historias conductuales deberías tener listas?

El trabajo de frontend deja resultados a la vista, y por eso sus historias son más fáciles de cuantificar. Prepara una para cada caso:

• Una mejora de rendimiento con cifras de antes y después.
• Una corrección de accesibilidad y lo que cambió en tu proceso.
• Un desacuerdo con tu jefe o con un diseñador, resuelto con evidencia.
• Un bug que llevaste a producción, contado como un error y lo que aprendiste.
• Un componente reutilizable o un aporte al sistema de diseño.

Estructura cada una con el método STAR y no le dediques más de dos oraciones a la Situación.

¿Qué vale la pena preguntarle al entrevistador?

• “¿Hay un sistema de diseño compartido? ¿Quién lo mantiene?”
• “¿A qué navegadores y dispositivos les dan soporte oficial?”
• “¿Cómo se detectan y se priorizan hoy los problemas de accesibilidad?”
• “¿Cómo se revisan y se publican los cambios de frontend?”
• “¿Qué tan de cerca trabajan los desarrolladores con los diseñadores durante el descubrimiento (discovery)?”

Hay más ideas en nuestra guía de preguntas para hacer al entrevistador.

¿Cómo practicar para una entrevista de frontend?

Responde en voz alta tres de las preguntas técnicas de arriba, como si se las explicaras a un compañero de equipo que no ha visto el código. Cronométrate: la mayoría de las respuestas debería durar entre uno y dos minutos. Después elige una historia conductual y comprueba que mencione al menos un número que le importaría a un usuario. Si tu primera ronda es una entrevista grabada, nuestros consejos para entrevistas por video cubren la cámara, el ritmo y las repeticiones.