Preguntas de entrevista para Desarrollador Frontend — Más de 30 preguntas y respuestas de expertos

El desarrollo frontend sigue siendo uno de los segmentos más competitivos del mercado laboral tecnológico. Según el Front End Interview Handbook, los candidatos en las principales empresas enfrentan de cuatro a seis rondas de entrevista que cubren fundamentos de JavaScript, dominio de frameworks, diseño de sistemas y evaluación conductual [1]. Solo el 3 % de los candidatos reciben invitaciones a entrevista, y la proporción de entrevistas a contratación se sitúa en aproximadamente el 27 % [2]. En 2025–2026, los responsables de contratación elevan el listón, evaluando no solo la competencia en React o Vue, sino también la experiencia en accesibilidad, optimización del rendimiento, adopción de TypeScript y la capacidad de colaborar con diseñadores e ingenieros backend en superficies de producto complejas [3]. Las preguntas a continuación reflejan lo que los equipos de ingeniería frontend realmente preguntan.

Puntos clave

• Las entrevistas frontend evalúan profundamente los fundamentos de JavaScript — closures, event loop, herencia prototipal — independientemente del framework que utilices [1].
• React sigue siendo dominante, pero los entrevistadores cuestionan cada vez más la comprensión de patrones de renderizado, Server Components y arquitectura de gestión de estado.
• La accesibilidad (conformidad con WCAG) y la optimización del rendimiento ya no son opcionales — son requisitos de entrevista para 2025–2026 [3].
• Los ejercicios de construcción de componentes UI evalúan habilidades de implementación práctica que las preguntas algorítmicas no pueden medir.
• Las preguntas conductuales se centran en la colaboración interfuncional con diseñadores, product managers y equipos backend.

Preguntas conductuales

Los desarrolladores frontend trabajan en la intersección de ingeniería, diseño y experiencia de usuario. Las preguntas conductuales evalúan cómo manejas prioridades en conflicto y colaboras entre disciplinas [4].

1. Describe una ocasión en la que te opusiste a un diseño técnicamente difícil de implementar o que perjudicaría el rendimiento. ¿Cómo manejaste la conversación?

Usa STAR: Situación (un diseñador propuso una galería de scroll infinito con animaciones complejas que causaría stuttering en dispositivos móviles), Tarea (encontrar una solución que preservara la intención del diseño mientras mantenía un rendimiento de 60 fps), Acción (perfilé el enfoque propuesto, demostré el impacto en el rendimiento con grabaciones de Chrome DevTools y propuse una alternativa usando Intersection Observers y optimización de will-change), Resultado (se entregó una experiencia visualmente equivalente que mantuvo un desplazamiento fluido en todos los tipos de dispositivos).

2. Cuéntame sobre una ocasión en la que mejoraste la accesibilidad de un producto existente.

Describe la auditoría de la aplicación con axe o Lighthouse, la identificación de problemas críticos (texto alternativo faltante, trampa de teclado en modales, contraste de color insuficiente), la priorización de correcciones por nivel de conformidad WCAG y la medición de la mejora. Cuantifica el impacto: «llevé el sitio de 47 a 94 en accesibilidad de Lighthouse, resolviendo 23 violaciones WCAG 2.1 AA» [3].

3. Describe una situación en la que tuviste que aprender un nuevo framework o biblioteca con un plazo ajustado. ¿Cómo te volviste productivo rápidamente?

Muestra aprendizaje sistemático: leer primero la documentación oficial, construir una pequeña prueba de concepto, estudiar el código fuente del framework para casos límite y aprovechar recursos de la comunidad. Menciona cómo documentaste patrones para tu equipo.

4. Cuéntame sobre una ocasión en la que tuviste que equilibrar el desarrollo de funcionalidades con la resolución de deuda técnica en un código frontend.

Describe cómo propusiste un enfoque de «regla boy scout» (dejar cada archivo mejor de como lo encontraste), asignaste capacidad de sprint para deuda técnica o abogaste por una iniciativa dedicada de refactorización. Demuestra que cuantificaste el impacto de la deuda técnica — crecimiento del tamaño del bundle, inestabilidad de pruebas, velocidad del desarrollador.

5. Describe cómo has colaborado con un equipo backend en el diseño de API para una funcionalidad frontend.

Demuestra discusión proactiva de contratos de API — proponer esquemas de respuesta que minimicen la transformación de datos en el frontend, negociar estrategias de paginación y discutir formatos de respuesta de error. Menciona el uso de herramientas como especificaciones OpenAPI o esquemas GraphQL como contratos compartidos.

Preguntas técnicas

Las preguntas técnicas evalúan la profundidad en JavaScript, la comprensión de frameworks y los patrones de arquitectura frontend [5].

1. Explica el event loop de JavaScript y cómo maneja operaciones asíncronas.

El event loop procesa primero la pila de llamadas, luego verifica las colas de microtareas (Promises, queueMicrotask), luego las colas de macrotareas (setTimeout, setInterval, I/O). Cuando la pila de llamadas está vacía, todas las microtareas pendientes se ejecutan antes de la siguiente macrotarea. Esto explica por qué Promise.resolve().then(...) se ejecuta antes que setTimeout(..., 0). Comprender esto es esencial para depurar condiciones de carrera y el comportamiento de renderizado [5].

2. ¿Cuál es la diferencia entre null, undefined y undeclared en JavaScript?

undefined es una variable declarada a la que no se le ha asignado un valor — es el valor por defecto. null es un valor vacío asignado explícitamente. undeclared es una variable que no ha sido declarada — referenciarla lanza un ReferenceError en modo estricto. En comparación flexible null == undefined es verdadero, pero null === undefined es falso. Discute cómo las verificaciones estrictas de null de TypeScript ayudan a detectar estos problemas en tiempo de compilación.

3. Explica el algoritmo de reconciliación de React y cómo el Virtual DOM mejora el rendimiento.

React crea una representación en memoria de la interfaz de usuario (Virtual DOM). Cuando el estado cambia, React construye un nuevo árbol de Virtual DOM, lo compara con el anterior (reconciliación) y calcula el conjunto mínimo de mutaciones DOM reales necesarias. El algoritmo de diferenciación utiliza el tipo de componente y las props key para identificar cambios eficientemente. Discute cómo React.memo, useMemo y useCallback ayudan a prevenir re-renders innecesarios [1].

4. ¿Cómo implementarías un componente de búsqueda con debounce en React?

Crea un hook personalizado que envuelva useCallback con un timeout: limpia el timeout anterior en cada pulsación de tecla, establece un nuevo timeout (típicamente 300 ms) y llama a la función de búsqueda solo cuando se deja de escribir. Discute la diferencia entre debouncing (esperar hasta que la actividad se detenga) y throttling (limitar la frecuencia). Aborda la limpieza en useEffect para prevenir fugas de memoria cuando el componente se desmonta [5].

5. ¿Qué son los React Server Components y cómo difieren del renderizado tradicional del lado del servidor?

El SSR tradicional renderiza toda la página en el servidor y la hidrata en el cliente. Los React Server Components (RSC) se renderizan en el servidor sin enviar su JavaScript al cliente — reduciendo el tamaño del bundle. Los RSC pueden acceder directamente a los recursos del servidor (bases de datos, sistemas de archivos) y transmitir su salida al cliente. Los Client Components manejan la interactividad. Discute las compensaciones: los RSC reducen el JavaScript del lado del cliente pero requieren una arquitectura cuidadosa para separar los límites entre servidor y cliente [3].

6. ¿Cómo optimizas los Core Web Vitals (LCP, FID/INP, CLS) de una aplicación web?

LCP (Largest Contentful Paint): optimiza la ruta de renderizado crítica, precarga imágenes hero, usa imágenes responsivas con srcset. FID/INP (Interaction to Next Paint): minimiza el bloqueo del hilo principal mediante code-splitting, difiriendo JavaScript no crítico y usando requestIdleCallback. CLS (Cumulative Layout Shift): establece dimensiones explícitas en imágenes e incrustaciones, evita insertar contenido por encima del pliegue después de la carga, usa font-display: swap con size-adjust para fuentes web [1].

7. Explica la especificidad CSS y cómo la cascada resuelve estilos en conflicto.

Jerarquía de especificidad: estilos en línea (1000) > selectores de ID (100) > selectores de clase/atributo/pseudo-clase (10) > selectores de elemento/pseudo-elemento (1). Cuando la especificidad es igual, la última regla en orden de origen gana. !important anula la especificidad pero debe evitarse en código de aplicación. Discute CSS Layers (@layer) como un enfoque moderno para gestionar la prioridad de cascada en grandes bases de código.

Preguntas situacionales

Las preguntas situacionales presentan desafíos frontend realistas para evaluar tu enfoque de resolución de problemas [4].

1. Los usuarios reportan que tu aplicación de página única se siente lenta en conexiones 3G. ¿Cómo diagnosticas y mejoras la experiencia?

Perfila con Chrome DevTools en red limitada: verifica el tamaño del bundle (¿estás enviando 2 MB de JavaScript?), identifica recursos que bloquean el renderizado y mide el Time to Interactive. Soluciones: code-splitting con import() dinámico, tree-shaking de dependencias no utilizadas, implementación de service workers para caché offline, carga lazy de componentes bajo el pliegue y compresión de assets con Brotli.

2. Tu equipo debate si usar una biblioteca de gestión de estado global (Redux, Zustand) o el Context y useState integrados de React. ¿Cómo evalúas la decisión?

Considera la complejidad de la aplicación: Context funciona bien para actualizaciones de baja frecuencia (tema, estado de autenticación) pero causa re-renders innecesarios cuando se usa para estado de alta frecuencia (entradas de formulario, datos en tiempo real). Las bibliotecas de estado global proporcionan suscripciones granulares. Evalúa la familiaridad del equipo, el costo de mantenimiento y si la gestión de estado del servidor (React Query, SWR) puede reemplazar la mayor parte de las necesidades de estado global.

3. Un product manager quiere hacer una prueba A/B de un nuevo flujo de pago, pero la base de código actual no tiene infraestructura de feature flags. ¿Cómo abordas esto?

Implementa un sistema ligero de feature flags: un proveedor de contexto que lee flags desde una API o variable de entorno, verificaciones de flags a nivel de componente y disciplina de limpieza para eliminar flags después de que los experimentos concluyan. Para validación rápida, usa un servicio de terceros (LaunchDarkly, Unleash). Discute cómo prevenir la deuda de flags y mantener la legibilidad del código.

4. Descubres que un script de analytics de terceros agrega 500 ms al tiempo de carga de tu página. El equipo de marketing insiste en que permanezca. ¿Qué haces?

Carga el script de forma asíncrona con defer o async. Si aún bloquea, cárgalo después de que el contenido principal se renderice usando inyección dinámica. Considera cargarlo solo después de una interacción del usuario (scroll, clic) si los analytics en tiempo real no son necesarios. Presenta datos al equipo de marketing mostrando el impacto de conversión de 500 ms adicionales de tiempo de carga para negociar un compromiso.

5. El equipo de diseño te entrega una biblioteca de componentes con 40 componentes. ¿Cómo arquitecturas la reutilización entre múltiples productos?

Construye una biblioteca de componentes con límites de API claros: interfaces TypeScript para props, Storybook para documentación y pruebas visuales, y patrones de componentes headless (lógica separada del estilo) para máxima flexibilidad. Discute estrategias de monorepo vs. paquete publicado, gestión de versiones y pruebas de regresión visual automatizadas.

Preguntas para el entrevistador

Las preguntas específicas de frontend demuestran madurez técnica y te ayudan a evaluar al equipo [1].

1. ¿Cuál es tu arquitectura frontend actual — monolito, micro-frontends u otra cosa? — Revela la complejidad técnica y los planes de modernización.
2. ¿Cómo maneja el equipo la gobernanza del design system y el mantenimiento de la biblioteca de componentes? — Muestra si se prioriza la consistencia de la UI.
3. ¿Cuál es el enfoque del equipo respecto a pruebas — unitarias, integración, regresión visual y E2E? — Indica la cultura de calidad.
4. ¿Cómo miden y rastrean el rendimiento web (Core Web Vitals, tamaño del bundle)? — Revela si el rendimiento se monitorea o es aspiracional.
5. ¿Cuál es el proceso de despliegue para cambios frontend — feature flags, canary releases o despliegue directo? — Muestra la madurez de CI/CD.
6. ¿Cómo colaboran los equipos de frontend y backend en el diseño de API? — Revela patrones de comunicación entre equipos.

Formato de la entrevista y qué esperar

Las entrevistas frontend típicamente abarcan de cuatro a seis rondas con tipos de evaluación distintos [1].

Pantalla telefónica (30–45 minutos): Un reclutador o gerente de ingeniería evalúa tu experiencia, conocimiento frontend y motivación. Algunas empresas incluyen un breve cuestionario de JavaScript.

Ronda de codificación JavaScript (60 minutos): Resuelve problemas algorítmicos en JavaScript o implementa funciones utilitarias (debounce, throttle, deep clone, Promise.all). El enfoque está en JavaScript limpio e idiomático.

Construcción de componentes UI (60–90 minutos): Construye un componente UI funcional — dropdown autocomplete, tabla de datos con ordenamiento o sistema de modales. Se evalúa la organización del código, gestión de estado, manejo de eventos y accesibilidad.

Ronda de diseño de sistemas (45–60 minutos): Diseña una arquitectura frontend para una funcionalidad — galería de imágenes, dashboard en tiempo real o página de producto de e-commerce. Discute jerarquía de componentes, estrategia de obtención de datos, caché y rendimiento.

Ronda conductual (45–60 minutos): Preguntas sobre colaboración interfuncional, toma de decisiones técnicas y manejo de prioridades en conflicto.

Cómo prepararte

La preparación para entrevistas frontend debe cubrir fundamentos, patrones de frameworks y habilidades prácticas de construcción [5].

Domina los fundamentos de JavaScript: Closures, herencia prototipal, event loop, binding de this y características ES6+ (destructuring, spread, módulos, async/await). Estos aparecen en cada entrevista independientemente del framework.

Practica la construcción de componentes: Implementa patrones UI comunes desde cero: autocomplete, scroll infinito, drag-and-drop, modal con trampa de foco y dropdown accesible. Usa el componente como vehículo para demostrar gestión de estado, manejo de eventos y accesibilidad.

Estudia React en profundidad: Comprende el ciclo de vida de los componentes, hooks (especialmente la limpieza de useEffect), características de rendimiento del contexto y funcionalidades concurrentes. Si el rol usa Next.js, estudia Server Components y el App Router.

Aprende accesibilidad: Estudia las directrices WCAG 2.1, atributos ARIA, patrones de navegación por teclado y comportamiento del lector de pantalla. Las preguntas de accesibilidad son cada vez más comunes en entrevistas frontend [3].

Prepara historias de rendimiento: Ten ejemplos específicos de mejoras de rendimiento: reducción del tamaño del bundle, mejora de Core Web Vitals u optimización de renderizado con métricas medibles antes/después.

Practica la comunicación verbal: Las rondas de diseño de sistemas frontend requieren pensar en voz alta. Practica explicando tus decisiones de arquitectura, compensaciones y jerarquía de componentes a un compañero.

Errores comunes en la entrevista

Evita estos errores que descalifican a candidatos frontend [4].

1. Ignorar la accesibilidad. Construir un componente que no sea navegable por teclado ni amigable con lector de pantalla en 2025–2026 es una señal de alerta significativa. La accesibilidad es una expectativa base, no un bonus.

2. Depender excesivamente del conocimiento de frameworks sin dominar los fundamentos de JavaScript. Los candidatos que pueden construir componentes de React pero no pueden explicar closures o el event loop carecen de la base necesaria para depuración compleja.

3. No considerar dispositivos móviles. El código frontend debe funcionar en diferentes tamaños de pantalla y condiciones de red. Los candidatos que solo prueban en escritorio durante las entrevistas parecen limitados.

4. Omitir el manejo de errores en ejercicios de código. Estados de carga, error boundaries y casos límite (datos vacíos, fallos de red) distinguen el código listo para producción del código de demostración.

5. No discutir las compensaciones de rendimiento. Cada decisión arquitectónica tiene implicaciones de rendimiento. Los candidatos que proponen soluciones sin considerar el tamaño del bundle, el costo de renderizado o la sobrecarga de red no alcanzan lo que los responsables de contratación evalúan.

6. No tener preguntas sobre las prácticas frontend del equipo. Esto sugiere que aceptarás cualquier entorno de ingeniería sin evaluar la calidad, lo cual no es lo que buscan los equipos senior [1].

Puntos clave

Las entrevistas para desarrolladores frontend evalúan una combinación de profundidad en JavaScript, experiencia en frameworks, conciencia de accesibilidad y habilidades de colaboración interfuncional. Prepárate dominando los fundamentos, practicando la construcción de componentes y estudiando la optimización del rendimiento. Los candidatos que reciben ofertas demuestran que pueden construir interfaces que no solo son visualmente correctas sino también accesibles, performantes y mantenibles.

¿Quieres asegurarte de que tu currículum destaque tu experiencia frontend? Prueba el verificador gratuito de puntuación ATS de ResumeGeni para optimizar tu currículum de desarrollador frontend antes de postularte.

Preguntas frecuentes

¿Qué temas de JavaScript aparecen con más frecuencia en entrevistas frontend? Closures, el event loop, binding de this, promises y async/await, y características ES6+ (destructuring, módulos, arrow functions) se evalúan en prácticamente todas las entrevistas frontend [5].

¿Debería aprender TypeScript para entrevistas frontend? Sí. La adopción de TypeScript en bases de código frontend supera el 80 % en muchas empresas. Demostrar competencia en TypeScript señala práctica moderna y detecta problemas relacionados con tipos que las entrevistas de JavaScript pasan por alto [3].

¿Qué tan importante es el conocimiento de CSS en entrevistas frontend? Muy importante. Espera preguntas sobre especificidad, flexbox, grid, diseño responsivo y arquitectura CSS (BEM, CSS Modules, CSS-in-JS). Algunas entrevistas incluyen ejercicios de codificación centrados en CSS.

¿Las entrevistas frontend incluyen preguntas algorítmicas? Sí, aunque típicamente más ligeras que las entrevistas backend o de ingeniería de software general. Espera manipulación de arrays y strings, recorrido básico de árboles/grafos (para operaciones DOM) e implementación de funciones utilitarias [1].

¿Cómo me preparo para la ronda de construcción de componentes UI? Practica construyendo de 5 a 7 componentes comunes desde cero, primero sin framework y luego en React. Enfócate en la navegación por teclado, atributos ARIA y casos límite (estado vacío, carga, error).

¿Cuál es la habilidad más importante para entrevistas frontend de nivel senior? El diseño de sistemas y la toma de decisiones arquitectónicas. Los candidatos senior deben explicar cómo estructurar una aplicación frontend para escalar — bibliotecas de componentes, gestión de estado, code splitting y patrones micro-frontend [4].

¿Debería aprender Next.js para entrevistas frontend? Si la empresa lo utiliza, definitivamente. El conocimiento de Next.js (App Router, Server Components, middleware) es un diferenciador significativo para roles enfocados en React en 2025–2026 [3].