Preguntas y respuestas de entrevista para desarrollador React 2026

Las entrevistas de React han cambiado sin hacer ruido. Una década de tutoriales enseñó a todo el mundo a recitar la diferencia entre props y estado, y a los entrevistadores eso dejó de parecerles útil por ahí en 2021. Lo que preguntan ahora es más difícil y más honesto: qué hace React de verdad cuando llamas a un setter, por qué se está re-renderizando esta lista, dónde debería vivir este dato y qué se rompe cuando lo pones en el sitio equivocado. Aquí están las preguntas a las que te vas a enfrentar de verdad, qué sondea cada una y cómo se construye una buena respuesta.

Estos son los patrones del puesto en general; si quieres la lista corta para una entrevista concreta, pega el anuncio real de la vacante en el Question Predictor gratuito y te devuelve las veinte preguntas que ese anuncio tiene más probabilidades de generar.

¿Qué evalúan de verdad las entrevistas de React en 2026?

Cuatro cosas, más o menos en este orden: si entiendes el modelo de renderizado y no solo la superficie de la API, si colocas el estado en sitios sensatos, si sabes encontrar un problema de rendimiento con evidencias en lugar de a ojo, y si escribes código que otra persona pueda testear. Las trivialidades han quedado en buena medida sustituidas por el razonamiento sobre contrapartidas, porque el código repetitivo lo escriben las herramientas de todas formas.

• Los hooks bajo lupa: el comportamiento de los closures que hace tropezar a la gente, y saber cuándo un efecto es la herramienta equivocada.
• El modelo de renderizado: qué dispara un render, qué hace la reconciliación con el resultado, por qué importan las keys.
• Arquitectura del estado: local frente a elevado frente a contexto frente a un store, y la separación entre estado de servidor y estado de cliente.
• Rendimiento con medición: diagnosticar en el Profiler en lugar de espolvorear memoización y cruzar los dedos.
• Criterio para testear: qué testeas, a qué nivel, y si manejas los estados de carga, vacío y error sin que te lo pidan.

La seniority cambia los pesos, no los temas. Los candidatos de nivel medio razonan bien sobre un componente. Los sénior razonan sobre un código base: convenciones, fronteras, rutas de migración y qué se negarían a hacer.

¿Cómo es el proceso de entrevistas de desarrollador React?

Cuatro o cinco etapas: un filtro con el reclutador, un filtro técnico con código en vivo, una ronda de construcción más larga, una inmersión profunda en React y una ronda conductual. Las empresas grandes añaden diseño de sistemas de frontend. La ronda de construcción y la inmersión profunda deciden la oferta, así que carga ahí la preparación en vez de repartirla por igual.

1. Filtro con el reclutador (20 a 30 minutos). Disponibilidad, salario, un resumen de tus dos últimos puestos.
2. Filtro técnico (45 a 60 minutos). Un editor compartido, un componente pequeño o un ejercicio de depuración, a veces JavaScript pelado para comprobar los cimientos que hay bajo el framework.
3. Ronda de construcción (60 a 90 minutos). Algo real: una tabla filtrable, un autocompletado, un formulario de varios pasos contra una API falsa. Se puntúa por dónde colocas el estado, los casos límite y si hablas mientras trabajas.
4. Inmersión profunda en React (45 a 60 minutos). Renderizado, interioridades de los hooks, decisiones de estado, rendimiento y, cada vez más, componentes de servidor.
5. Ronda conductual (45 minutos). Desacuerdos, revisión de código, mentoría y cómo manejas una especificación que no tiene sentido.

Los ejercicios para casa están en retroceso, en buena medida porque los entrevistadores saben que se completan con ayuda de IA. Donde sobrevive alguno, casi siempre va seguido de una sesión en vivo ampliando tu propia entrega, que es la parte que merece la pena preparar.

¿Qué preguntas sobre hooks de React salen en casi todas las entrevistas?

Cuatro se repiten sin parar: estado obsoleto dentro de un closure, qué controla el array de dependencias, la diferencia entre las herramientas de memoización, y escribir un hook personalizado sobre la marcha. Las cuatro evalúan lo mismo por debajo: si sabes que la función de un componente se ejecuta muchas veces y que cada ejecución captura sus propios valores.

1. "Este manejador de clic muestra el contador viejo. ¿Por qué?" Qué sondea: si entiendes que cada render encierra los valores de ese render, y que un setter no muta una variable en el sitio. Nombra el closure de forma explícita y luego enseña los dos arreglos: el actualizador funcional setCount(c => c + 1), y una ref cuando de verdad necesitas el valor más reciente dentro de un callback de larga vida.

2. "¿Qué controla el array de dependencias, y cuándo no deberías usar un efecto en absoluto?" Qué sondea: si tratas los efectos como un hook de ciclo de vida genérico (la señal de júnior) o como sincronización con algo de fuera de React. El array decide cuándo se vuelve a ejecutar el efecto; la limpieza corre antes de la siguiente ejecución y al desmontar. Y luego nombra lo que no debería ser un efecto: los valores derivados (calcúlalos durante el render), el estado que se resetea al cambiar una prop (una key en el hijo) y las respuestas a eventos (manéjalas en el propio manejador).

3. "useMemo, useCallback, React.memo: ¿cuál es la diferencia?" Qué sondea: si tu memoización está medida o es superstición. useMemo cachea un valor, useCallback cachea una referencia a una función, React.memo se salta el re-render de un hijo cuando las props son iguales en comparación superficial, y los dos primeros no sirven de nada salvo que un hijo memoizado u otra lista de dependencias consuma la referencia. Añade que la memoización tiene su propio coste, así que primero perfilas.

4. "Escribe un hook que aplique debounce a un valor." Qué sondea: composición, limpieza y disciplina con las dependencias en unas diez líneas. Estado para el valor con debounce, un efecto que arranca un temporizador, una limpieza que lo cancela, dependencias del valor y del retardo. La parte que a la mayoría se le escapa: la limpieza es lo que lo convierte en un debounce y no en una cola de actualizaciones pendientes.

¿Cómo evalúan los entrevistadores el renderizado y la reconciliación?

Preguntando qué pasa después de una actualización de estado, no antes. Una buena respuesta separa tres fases: React vuelve a ejecutar el componente para producir un árbol de elementos, la reconciliación compara ese árbol con el anterior, y la fase de commit aplica el conjunto mínimo de mutaciones al DOM. Quien difumina esas fases no puede explicar las keys, ni el momento en que corren los efectos, ni las funciones concurrentes.

5. "Explícame qué pasa cuando llamo a un setter de estado." Qué sondea: la profundidad de tu modelo mental. La actualización se encola y se agrupa con otras del mismo tick, React programa un render, el componente y sus hijos se vuelven a ejecutar, el árbol nuevo se reconcilia con el viejo, se limpian los efectos anteriores, se aplican las mutaciones del DOM y luego corren los efectos de layout de forma síncrona y los efectos pasivos después del pintado. Añade que el Strict Mode invoca dos veces en desarrollo para exponer los efectos que no son limpiamente reversibles.

6. "¿Por qué importan las keys, y qué se rompe con los índices de array?" Qué sondea: si has depurado una lista de verdad. Las keys le dicen a la reconciliación qué elemento se corresponde con qué ítem entre renders. Con keys de índice, borrar o reordenar hace que React empareje los ítems equivocados, así que el estado del componente y el del DOM (un input con el foco, un valor a medio escribir) se pegan a la fila equivocada. Añade la otra cara: cambiar una key a propósito es una forma legítima de resetear un subárbol.

7. "¿Qué son useTransition y useDeferredValue y para qué sirven?" Qué sondea: si eres consciente de que el renderizado puede interrumpirse. Ambos mantienen ágil una actualización urgente (escribir) mientras una actualización pesada se renderiza con menos prioridad: useTransition marca la actualización de estado como no urgente y te da una bandera de pendiente, useDeferredValue deja que un valor vaya con retraso. Di claramente que ninguno de los dos hace rápido un renderizado lento, solo cambian lo que el usuario tiene que esperar.

¿Qué preguntas sobre gestión de estado debo esperar?

Dos, seguro: dónde pertenece un trozo de estado y cómo tratas los datos del servidor de forma distinta a los del cliente. La respuesta esperada arranca desde el estado local, trata el contexto como un mecanismo de reparto para valores de baja frecuencia y no como un store, y pone todo lo que venga de una API detrás de una capa de caché.

8. "¿Contexto o una librería de estado, y cómo eliges?" Qué sondea: si sabes lo que cuesta el contexto. Estado local primero, elevar solo hasta el padre común más cercano, contexto para valores que cambian poco y se leen mucho (tema, idioma, el usuario actual), y un store cuando las actualizaciones son frecuentes o se leen desde subárboles sin relación. El motivo importa: cada consumidor se re-renderiza cuando cambia el valor del contexto, así que un valor que se mueve rápido metido en contexto es un bug de rendimiento esperando a que lo abran.

9. "¿Cómo manejas el estado de servidor?" Qué sondea: si has entregado algo con datos reales. Los datos del servidor son una caché de algo que no es tuyo, así que necesitan deduplicación, reglas de caducidad, revalidación en segundo plano e invalidación después de una mutación, y montarte eso a mano en efectos se tuerce poco a poco. Nombra el patrón y no solo la librería: haz fetch en el servidor donde el framework lo permita, cachea en el cliente, y mantén aparte el estado local de la interfaz.

¿Cómo se preguntan en la práctica las cuestiones de rendimiento de React?

Como un escenario con un síntoma, no como una definición. Te sueltan "escribir en esta caja de filtro va a tirones" o "esta página tarda cuatro segundos en volverse interactiva", y el entrevistador mira si mides antes de cambiar nada. Tirar directamente de useMemo es la apertura equivocada; abrir el Profiler y preguntar qué se está re-renderizando es la correcta.

10. "Escribir en una caja de búsqueda que filtra diez mil filas va a tirones. Diagnostícalo." Qué sondea: método. Graba con el Profiler de React y con el panel de rendimiento del navegador, y establece si el coste está en muchos componentes re-renderizándose o en un componente renderizando muchos nodos. Si es número de nodos, virtualiza; si es amplitud del re-render, coloca el estado del input junto a él para que el árbol de arriba se quede quieto y luego memoiza la fila; si lo caro es el propio filtro, memoízalo o difiérelo.

11. "El bundle es demasiado grande. ¿Qué haces?" Qué sondea: si has abierto alguna vez un analizador de bundles. Mide primero, y luego división a nivel de ruta con lazy y Suspense, importaciones dinámicas para widgets pesados (editores, gráficos, selectores de fecha), sustituir una dependencia sobredimensionada y mover trabajo al servidor donde el framework lo permita. Átalo a una métrica que le importe al negocio, normalmente LCP o latencia de interacción, y no a los kilobytes por sí mismos.

12. "¿El compilador de React deja obsoleta la memoización manual?" Qué sondea: si sigues el ecosistema y sabes sostener una postura con matices. La memoización automática elimina la mayor parte del ruido rutinario de useMemo y useCallback , lo que es una mejora genuina, pero no arregla el estado colocado demasiado arriba, un contexto demasiado amplio, una lista sin virtualizar ni un efecto caro. Di qué seguirías haciendo a mano y qué borrarías encantado.

¿Cómo son las preguntas de testing en React?

Normalmente un escenario más una pregunta sobre proporciones. Los entrevistadores quieren tests que ejerciten el comportamiento a través de la superficie que toca un usuario, la red mockeada en la frontera en lugar de sustituyendo tus propios módulos, y un reparto honesto: tests unitarios para la lógica pura, tests de integración a nivel de componente para el grueso de la interfaz, y una capa fina de tests de punta a punta sobre los flujos que cuestan dinero cuando se rompen.

13. "¿Cómo testeas un componente que carga datos y muestra una lista?" Qué sondea: si tus tests sobreviven a una refactorización. Renderiza el componente, mockea en la capa de red, consulta por rol accesible y nombre, y luego comprueba el estado de carga, las filas cargadas, el estado vacío y el estado de error. Evita comprobar props o interioridades de hooks, y menciona la inestabilidad: consultas con await en vez de timeouts arbitrarios.

¿Preguntan los entrevistadores por los React Server Components?

Cada vez más, sí, sobre todo para comprobar que entiendes la frontera, no para examinarte de trivialidades del framework. Deberías saber decir qué corre dónde, qué no puede hacer un componente de servidor, y de dónde salen los errores comunes de hidratación y de caché. Ser honesto sobre tu experiencia práctica limitada está bien; fingir, no, porque la repregunta te va a pillar.

14. "¿Cuál es la diferencia entre un componente de servidor y uno de cliente?" Qué sondea: la frontera. Los componentes de servidor corren en el servidor, esperan datos directamente, nunca envían su código al navegador y no pueden usar estado, efectos ni manejadores de eventos; los componentes de cliente se hidratan en el navegador y sí pueden las tres cosas. La directiva "use client" marca un punto de entrada al territorio de cliente, así que todo lo que se importe por debajo se va también al cliente, y por eso una directiva descuidada cerca de la raíz del árbol se carga el beneficio entero.

15. "¿Dónde haces el fetch de los datos, y cuáles son las trampas de la caché?" Qué sondea: cicatrices de producción. Haz fetch en el servidor, cerca de donde se renderizan los datos, y deja que el framework deduplique las peticiones idénticas dentro de un render. Las trampas que merece la pena nombrar: renderizar de forma estática por accidente algo que debería ser dinámico, datos caducados tras una mutación porque nada revalidó, y desajustes de hidratación por renderizar una marca de tiempo en la pasada del servidor.

¿Qué errores hacen que rechacen a un candidato de React?

Sobre todo fallos de proceso, no huecos de conocimiento. Los entrevistadores rara vez rechazan a alguien por no saberse un hook; rechazan al candidato que trabajó en silencio, adivinó un arreglo y dejó el estado de error sin manejar. Estos seis explican la mayor parte del feedback negativo en los procesos de React.

• Programar en silencio. En la ronda de construcción, el comentario en voz alta es casi toda la señal.
• Tirar de un efecto lo primero. Hacer fetch, derivar y sincronizar estado dentro de efectos cuando existe algo más simple es la señal arquitectónica más común.
• Memoizar sin medir. Los entrevistadores preguntan "¿y eso qué mejoró?" precisamente porque la mayoría de los candidatos no sabe responder.
• Ignorar el camino infeliz. Los estados de carga, vacío y error son justo lo que van a picar. Cúbrelos sin que te lo pidan.
• Quedarte en la definición. "useCallback memoiza una función" es donde empieza la mitad interesante de la respuesta.
• Exagerar tu experiencia con los componentes de servidor. Tropezar con la frontera del cliente cuesta más caro que admitir que solo has entregado un proyecto.

¿Cómo deberías prepararte para una entrevista de React?

Construye dos cosas en lugar de leer sobre diez. Una tabla filtrable y ordenable con paginación en el servidor te obliga a pasar por la colocación del estado, la caché, las keys y la virtualización. Un formulario de varios pasos con validación y un envío real te obliga a pasar por inputs no controlados, manejo de errores y gestión del foco. Entre las dos generan respuestas honestas a casi todas las preguntas de arriba, y las respuestas honestas sobreviven a las repreguntas.

Luego perfila algo real. Abre el Profiler en una app en la que trabajes, encuentra el componente que más se re-renderiza y arréglalo como es debido, porque eso te da una historia con números dentro. Para los fundamentos que hay debajo del framework, la guía de preguntas de entrevista para desarrollador frontend cubre el material de JavaScript y de navegador con el que el filtro técnico sigue haciendo de puerta, y en una empresa grande su banco de preguntas por empresa merece un vistazo rápido para pillar los patrones de la casa.

Luego ensaya contra la lista correcta: pasa el anuncio de la vacante por el Question Predictor gratuito, para que las veinte preguntas que practiques en voz alta sean las que ese equipo probablemente hará, y no un set genérico.

Dónde encaja un copiloto en vivo

La preparación cubre casi todo, y entonces en el minuto cuarenta cae una pregunta de lado y la cabeza se te queda plana. GhostPilot AI es un copiloto en tiempo real para ese momento: corre en el panel lateral de una extensión de Chrome o como app de escritorio para Windows, escucha la llamada, caza la pregunta y tiene una respuesta estructurada lista unos dos segundos después, que suele bastar para convertir una pausa en blanco en una primera frase limpia. El plan gratuito incluye 10 minutos de sesión en vivo a la semana, sin tarjeta. Es una red de seguridad para un fallo de memoria, no un sustituto de conocer tu propio trabajo.

FAQ

¿Cuánto tiempo debería prepararme para una entrevista de desarrollador React? De dos a tres semanas de práctica enfocada si escribes React a diario. Si has estado manteniendo un código base heredado de componentes de clase, cuenta con cuatro a seis semanas, sobre todo para coger soltura con los patrones de la era de los hooks, el estado de servidor y el vocabulario actual de renderizado.

¿Las entrevistas de React siguen incluyendo preguntas de algoritmos? Algunas sí, sobre todo en empresas grandes con un proceso estandarizado. La tendencia en las empresas de producto va claramente hacia construir y depurar componentes reales. Mantén calientes las estructuras de datos básicas, pero dedica el grueso del tiempo al trabajo práctico de interfaz.

¿Cuánto necesito saber de React Server Components? Lo suficiente para explicar la frontera con seguridad y nombrar los errores comunes. La experiencia práctica profunda es un plus en la mayoría de los puestos más que un requisito, salvo que la oferta gire en torno a un framework construido sobre ellos.

¿Debería mencionar que uso herramientas de IA para escribir React? Sí, si te preguntan, y di cómo revisas lo que sale. Los entrevistadores lo dan por hecho. Lo que comprueban es si sabes defender y depurar ese código, que es exactamente por lo que las repreguntas de la inmersión profunda se han puesto más duras.