Preguntas de entrevista para Desarrollador Frontend

Respuesta modelo

El más significativo fue la migración del portal de un marketplace inmobiliario con unos 9 millones de visitas mensuales. Partíamos de una SPA con Create React App donde toda la ficha de producto se renderizaba en cliente: el LCP móvil estaba en 4,2 s en el percentil 75 de CrUX y el SEO se resentía. Propuse migrar a Next.js con App Router en lugar de parchear el rendimiento, porque el problema era arquitectónico. Lo hicimos por fases, empezando por la ficha de producto, que era el 60 % del tráfico, con un test A/B al 10 % durante dos semanas para validar que no rompíamos la conversión. Terminamos con el LCP en 1,8 s, el JavaScript inicial de 410 kB a 178 kB y un 17 % menos de sesiones con rebote inmediato. Lo que más valoro no es el número, sino que dejamos un presupuesto de rendimiento en CI para que no volviera a degradarse.

Respuesta modelo

Empiezo siempre por datos de campo, no por Lighthouse en local: miro el percentil 75 de CrUX y nuestro RUM para saber qué métrica falla y en qué páginas y dispositivos. Si es LCP, el problema casi siempre está en el recurso más grande de la parte visible: imágenes sin formato moderno ni tamaño correcto, fuentes que bloquean el render o una cascada de peticiones antes de pintar. Si es INP, busco manejadores de eventos largos, renderizados masivos o listas sin virtualizar. Si es CLS, suelen ser imágenes sin dimensiones, anuncios insertados o fuentes con salto de estilo. Después priorizo por impacto y coste, no por lo que sea más divertido de arreglar, y cierro cada mejora con una regla en CI para que no se pierda: presupuesto de bundle, Lighthouse CI en las rutas críticas y una alerta si el LCP supera el umbral en producción.

Respuesta modelo

La trabajo desde el diseño, no como una revisión final. En el equipo anterior introduje tres controles: revisión de contraste y estados de foco en el propio Figma, axe-core ejecutado en las pruebas de componente y una lista de comprobación manual de teclado y lector de pantalla para los recorridos críticos, porque las herramientas automáticas detectan como mucho un tercio de los problemas reales. El proyecto más exigente fue el proceso de compra: cerramos 214 incidencias de nivel AA, sobre todo campos sin etiqueta asociada, errores que no se anunciaban y modales que perdían el foco. Lo validé con NVDA en Windows y VoiceOver en iOS. El argumento que convenció a negocio no fue técnico: desde el 28 de junio de 2025, la Ley 11/2023 obliga al comercio electrónico y a la banca en España, y el coste de corregirlo después de una reclamación es mucho mayor que hacerlo bien desde el principio.

Respuesta modelo

Intento entrar antes de que el diseño esté cerrado. En la revisión previa señalo tres cosas: estados que faltan (vacío, carga, error, foco), contrastes que no llegan a 4,5:1 y componentes nuevos que en realidad son una variante de algo que ya existe en el sistema de diseño. Eso último es lo que más discusiones ahorra a largo plazo. Trabajamos con tokens compartidos entre Figma y el código, de modo que un cambio de color o de espaciado no obliga a repasar cincuenta pantallas a mano. Cuando hay desacuerdo, no lo planteo como «no se puede», sino con una alternativa y su coste: «esta animación añade unos 40 kB y penaliza el INP en móviles de gama media; puedo hacerla en CSS puro y conseguimos el 90 % del efecto sin coste».

Respuesta modelo

Con un filtro deliberado, porque intentar seguirlo todo es agotador e inútil. Leo las notas de versión de lo que uso en producción (React, Next.js, TypeScript), sigo el blog de web.dev y las especificaciones de la plataforma, y una vez al trimestre dedico un fin de semana a probar algo nuevo en un proyecto pequeño y desechable: así probé Astro antes de proponer islas para nuestro blog corporativo. En el equipo mantengo una nota interna de decisiones técnicas, donde apuntamos qué evaluamos y por qué lo descartamos, para no repetir la misma discusión cada seis meses. No adopto nada nuevo en producción sin una razón de negocio: la moda no es un argumento de migración.

Respuesta modelo

En mi puesto actual he llegado al límite de lo que puedo mejorar: el sistema de diseño está estable y mi trabajo es cada vez más mantenimiento. Busco un producto con volumen de usuarios real donde el rendimiento y la accesibilidad se midan y se prioricen, no se mencionen en la oferta y luego se aparquen. De su empresa me interesa concretamente que el frontend tenga peso propio en las decisiones de producto y que trabajen con un modelo híbrido, porque me ayuda a mantener el ritmo de mentoría con perfiles junior, que es la parte del trabajo que más disfruto.

Respuesta modelo

Con tres capas y una regla. Pruebas unitarias y de componente con Vitest y Testing Library sobre el comportamiento visible, nunca sobre detalles internos de implementación; pruebas end to end con Playwright únicamente en los recorridos que generan ingresos, porque una batería lenta e inestable acaba ignorándose; y pruebas visuales con Chromatic para el sistema de diseño, donde una regresión de CSS no la detecta ningún test funcional. La regla es que todo entra por pull request con revisión, y en la revisión no discuto estilo (de eso se encargan ESLint y Prettier), sino accesibilidad, rendimiento y legibilidad. En mi último equipo pasamos del 24 % al 71 % de cobertura y las regresiones reportadas por soporte bajaron de once a dos por trimestre.

Decido según tres factores: si el contenido es público e indexable, con qué frecuencia cambia y cuánto pesa la personalización. Para un blog o unas páginas legales uso generación estática (SSG), que es lo más rápido y barato. Para un catálogo con precios y stock cambiantes uso regeneración incremental (ISR) con revalidación cada pocos minutos, o renderizado en servidor si el dato debe ser exacto en cada visita. El renderizado en servidor (SSR) es la opción para contenido indexable y personalizado, como una ficha de producto con precio por región, asumiendo el coste de TTFB. Y dejo el renderizado en cliente (CSR) para zonas privadas tras un login, como un panel de administración, donde el SEO no importa. En Next.js con App Router lo interesante es que la decisión ya no es por aplicación sino por segmento de ruta, y los Server Components permiten que buena parte del árbol nunca llegue como JavaScript al navegador.

INP (Interaction to Next Paint) es la métrica de interactividad de Core Web Vitals que sustituyó a FID en marzo de 2024. FID solo medía el retraso de entrada de la primera interacción, es decir, cuánto tardaba el navegador en empezar a procesar el primer clic, y por eso casi todas las páginas lo aprobaban. INP mide todas las interacciones de la sesión y toma prácticamente la peor: desde que el usuario actúa hasta que se pinta el siguiente fotograma, incluyendo el procesamiento y el renderizado. El umbral bueno está en 200 ms o menos. Las causas habituales de un INP malo son tareas largas en el hilo principal, renderizados en cascada por estados mal aislados, listas sin virtualizar y scripts de terceros. Para corregirlo troceo tareas largas, aíslo el estado que cambia con frecuencia, uso useDeferredValue o useTransition en React para lo no urgente y muevo el cálculo pesado a un Web Worker.

CLS (Cumulative Layout Shift) mide cuánto se mueve el contenido visible sin que el usuario lo provoque, y penaliza cuando supera 0,1. Las causas más frecuentes en una ficha de producto son imágenes sin width y height o sin aspect-ratio, banners de cookies o de promoción insertados encima del contenido, fuentes web que cambian de métrica al cargar y contenido que aparece de forma asíncrona, como un bloque de valoraciones. La solución es reservar espacio siempre: dimensiones explícitas en imágenes y vídeos, contenedores con altura mínima para lo que llega tarde, font-display: optional o size-adjust para reducir el salto tipográfico, y nunca insertar elementos por encima de lo que el usuario ya está mirando. Los banners de consentimiento deben superponerse como overlay, no empujar el layout.

Los uso cuando hay una medición que lo justifique, no por defecto. useMemo tiene sentido para un cálculo realmente costoso, como filtrar y ordenar miles de elementos, o para mantener la identidad de un objeto que se pasa a un hijo memorizado o a un array de dependencias. useCallback, para funciones que se pasan a componentes memorizados o a un efecto. Y memo, para componentes que renderizan mucho y reciben las mismas props. No los uso para operaciones triviales, porque memorizar tiene su propio coste de memoria y comparación y suele ensuciar el código sin beneficio medible. Antes de memorizar reviso siempre si el problema se resuelve mejor con composición: bajar el estado al componente que realmente lo usa, o pasar children para que la parte estática del árbol no se vuelva a renderizar. Con el compilador de React esta discusión pierde peso, pero el criterio de medir primero con el Profiler sigue siendo el mismo.

Cinco requisitos. Uno: el contenedor lleva role="dialog" y aria-modal="true", con aria-labelledby apuntando al título. Dos: al abrirse, el foco se mueve al modal, normalmente al título o al primer control interactivo, nunca se queda detrás. Tres: el foco queda atrapado dentro mientras esté abierto, de modo que el tabulador cicle entre sus elementos, y el resto de la página queda oculta para lectores de pantalla con inert o aria-hidden. Cuatro: la tecla Escape lo cierra, igual que el clic fuera si es descartable. Cinco: al cerrarse, el foco vuelve exactamente al elemento que lo abrió, para que quien navega con teclado no se pierda. Siempre que puedo uso el elemento nativo dialog o un primitivo probado como Radix UI, porque reimplementar esto a mano es la forma más habitual de introducir errores de accesibilidad.

JavaScript ejecuta en un solo hilo con una pila de llamadas. Cuando la pila se vacía, el bucle de eventos vacía primero por completo la cola de microtareas (promesas resueltas, queueMicrotask, MutationObserver) y después toma una macrotarea (un setTimeout, un evento de usuario, una respuesta de red). El renderizado ocurre entre tareas, así que cualquier función que ocupe el hilo más de unos 50 ms bloquea la respuesta visual: eso es exactamente lo que penaliza el INP y lo que produce la sensación de interfaz congelada. Importa en la práctica para tres decisiones: trocear cálculos largos cediendo el hilo, saber que un bucle infinito de microtareas puede bloquear el render aunque no haya ninguna macrotarea pendiente, y decidir cuándo el trabajo pesado debe salir a un Web Worker en lugar de intentar optimizarlo en el hilo principal.

Nombres de archivo con hash de contenido para JavaScript, CSS, fuentes e imágenes, servidos con Cache-Control: public, max-age=31536000, immutable, porque si cambia el contenido cambia la URL y no hay riesgo de servir algo antiguo. El documento HTML, en cambio, nunca se cachea de forma agresiva: usa no-cache o un max-age muy corto con validación por ETag, ya que es el que apunta a los recursos con hash. Para respuestas de API que toleran algo de desfase uso stale-while-revalidate, que sirve la copia guardada al instante y refresca en segundo plano. Y separo las dependencias estables del código de aplicación en el bundling, para que un despliegue normal no invalide toda la caché del usuario.

El primero es XSS: nunca inserto HTML de origen no confiable, y si un caso lo exige, como un texto enriquecido de un CMS, lo saneo con DOMPurify antes de usar dangerouslySetInnerHTML o v-html. El segundo es la Content Security Policy: una CSP con nonce que impida scripts en línea reduce muchísimo la superficie de ataque, aunque obliga a disciplinar las etiquetas de terceros. El tercero es el almacenamiento de tokens: prefiero cookies con HttpOnly, Secure y SameSite antes que localStorage, precisamente porque un XSS deja localStorage al descubierto. A eso añado no exponer nunca secretos en variables de entorno del cliente, validar siempre en servidor aunque la validación de formulario ya exista en cliente, y revisar las dependencias con npm audit y Dependabot, porque el mayor riesgo de una aplicación frontend moderna suele estar en su árbol de dependencias.

No lo bloqueo con un «no cumple la norma» y ya está, porque eso genera enfrentamiento y no soluciona nada. Le enseño la medición concreta: ese gris da 2,8:1 y el mínimo AA para texto normal es 4,5:1. Después llevo una alternativa preparada, normalmente dos o tres tonos que mantienen la jerarquía visual y sí cumplen, para que la conversación sea sobre cuál elegir y no sobre si hacerlo. Si aun así hay resistencia, aporto el argumento de negocio: desde junio de 2025 la Ley 11/2023 nos aplica y una reclamación cuesta más que cambiar un token de color. En el último equipo esto dejó de ser una discusión recurrente cuando metimos la comprobación de contraste en la propia biblioteca de Figma.

Primero cuantifico antes de alarmar a nadie: qué métrica se degrada, cuánto y para qué porcentaje de usuarios. Con el dato voy al product owner con tres opciones y su coste, no con un problema. Normalmente son: cargar la funcionalidad de forma diferida para que no afecte a la carga inicial, que suele costar un día; lanzarla activada solo para un porcentaje de usuarios con un feature flag y medir en producción; o posponerla. Recomiendo una y explico por qué. Lo que no hago es callarme y lanzar, ni bloquear el lanzamiento unilateralmente: la decisión de negocio es suya, pero con la información delante. En un caso real elegimos la carga diferida y salimos en fecha con el LCP intacto.

Confirmo primero con datos que la caída coincide con el despliegue y aíslo la causa comparando una carga con y otra sin el contenedor de GTM en WebPageTest. Si el culpable es un script de terceros, mido su coste concreto en milisegundos de bloqueo del hilo principal, porque una cifra convence más que una opinión. Luego negocio con marketing sin plantearlo como quitar o dejar: propongo cargar las etiquetas no críticas después de la interacción o con partytown en un worker, aplicar Consent Mode para que nada se cargue antes de la aceptación de cookies, y establecer una regla de gobierno para que ninguna etiqueta nueva entre sin revisión de rendimiento. Cierro el caso con una alerta automática que avise si el LCP de campo supera el umbral, para que la próxima vez lo detectemos nosotros y no el informe mensual.

No espero de brazos cruzados ni me quejo en la retro. Acuerdo el contrato de la respuesta cuanto antes, aunque sea sobre un documento, y trabajo contra un mock con MSW para no bloquear mi parte: así el día que la API esté lista solo cambio la URL base. Si el desajuste es estructural, por ejemplo tres peticiones donde la pantalla necesita una sola respuesta agregada, lo planteo con el impacto medido en tiempo de carga y propongo un BFF o un endpoint agregado, no lo resuelvo escondiéndolo con bucles de peticiones en el cliente. Y documento el desajuste en el ticket, para que la decisión quede registrada y no parezca una preferencia personal.

Separo lo objetivo de lo subjetivo. Si señala un fallo real, lo agradezco y lo corrijo sin más. Si es cuestión de estilo o de preferencia personal, respondo en el hilo con el motivo de mi decisión y pregunto si hay algún criterio del equipo que yo desconozca. Cuando el intercambio pasa de dos o tres mensajes, propongo una llamada de diez minutos: el texto escrito amplifica cualquier fricción y en voz se resuelve en un momento. Si la discrepancia es recurrente y de fondo, la llevo a la retrospectiva como norma de equipo, no como conflicto entre personas, y propongo dejarla escrita en la guía interna para no repetirla en cada revisión.