Perguntas e respostas de entrevista para desenvolvedor React 2026

As entrevistas de React mudaram de patamar sem alarde. Uma década de tutoriais ensinou todo mundo a recitar a diferença entre props e state, e os entrevistadores pararam de achar isso útil lá por 2021. O que eles perguntam agora é mais difícil e mais honesto: o que o React realmente faz quando você chama um setter, por que essa lista está re-renderizando, onde esse dado deveria morar e o que quebra quando você o coloca no lugar errado. Aqui estão as perguntas que você vai enfrentar de verdade, o que cada uma investiga e como se constrói uma boa resposta.

Esses são os padrões da vaga em geral; se você quer a lista curta de uma entrevista específica, cole o anúncio real da vaga no Question Predictor gratuito, e ele devolve as vinte perguntas que aquele anúncio tem mais chance de gerar.

O que as entrevistas de React realmente testam em 2026?

Quatro coisas, mais ou menos nesta ordem: se você entende o modelo de renderização em vez da superfície da API, se você coloca o estado em lugares sensatos, se você consegue achar um problema de performance com evidência em vez de chute, e se você escreve código que outra pessoa consegue testar. A trivia foi em grande parte substituída por raciocínio sobre trade-offs, porque o ferramental escreve o boilerplate de qualquer jeito.

• Hooks sob escrutínio: o comportamento de closure que derruba as pessoas e saber quando um efeito é a ferramenta errada.
• O modelo de renderização: o que dispara uma renderização, o que a reconciliação faz com a saída, por que as keys importam.
• Arquitetura de estado: local versus elevado versus contexto versus uma store, e a separação entre estado de servidor e estado de cliente.
• Performance com medição: diagnosticar no Profiler em vez de espalhar memoização e torcer.
• Senso de teste: o que você testa, em que nível e se você cobre os estados de carregamento, vazio e erro sem ninguém pedir.

A senioridade muda o peso, não os temas. Candidatos pleno raciocinam corretamente sobre um componente. Candidatos sênior raciocinam sobre uma base de código: convenções, fronteiras, caminhos de migração e o que se recusariam a fazer.

Como é o processo de entrevista para desenvolvedor React?

Quatro ou cinco etapas: uma triagem com o recrutador, uma triagem técnica com código ao vivo, uma rodada de build mais longa, um deep dive de React e uma rodada comportamental. Empresas maiores acrescentam design de sistemas de frontend. A rodada de build e o deep dive decidem a proposta, então concentre sua preparação ali em vez de espalhar por igual.

1. Triagem com o recrutador (20 a 30 minutos). Disponibilidade, salário, um resumo das suas duas últimas vagas.
2. Triagem técnica (45 a 60 minutos). Um editor compartilhado, um componente pequeno ou um exercício de depuração, às vezes JavaScript puro para checar a base por baixo do framework.
3. Rodada de build (60 a 90 minutos). Algo real: uma tabela com filtro, um autocomplete, um formulário de várias etapas contra uma API falsa. Avaliada pela colocação do estado, pelos casos de borda e por você falar enquanto trabalha.
4. Deep dive de React (45 a 60 minutos). Renderização, internals de hooks, escolhas de estado, performance e, cada vez mais, server components.
5. Rodada comportamental (45 minutos). Discordâncias, code review, mentoria e como você lida com uma especificação que não faz sentido.

Os take-homes estão em queda, em boa parte porque os entrevistadores sabem que eles são feitos com ajuda de IA. Onde um sobrevive, quase sempre vem seguido de uma sessão ao vivo estendendo a sua própria entrega, e é essa parte que vale preparar.

Quais perguntas sobre hooks aparecem em quase toda entrevista de React?

Quatro se repetem sem parar: estado obsoleto dentro de uma closure, o que o array de dependências controla, a diferença entre as ferramentas de memoização e escrever um hook customizado na hora. As quatro testam a mesma coisa por baixo: se você sabe que a função do componente roda muitas vezes e que cada execução captura os próprios valores.

1. "Esse handler de clique loga a contagem antiga. Por quê?" O que investiga: se você entende que cada renderização fecha sobre os valores daquela renderização e que um setter não muta uma variável no lugar. Nomeie a closure explicitamente e depois mostre as duas correções: o updater funcional setCount(c => c + 1), e uma ref quando você realmente precisa do valor mais recente dentro de um callback de vida longa.

2. "O que o array de dependências controla e quando você não deveria usar um efeito?" O que investiga: se você trata efeitos como um hook de ciclo de vida genérico (o sinal de júnior) ou como sincronização com algo fora do React. O array decide quando o efeito roda de novo; a limpeza roda antes da próxima execução e no unmount. Depois nomeie o que não deveria ser efeito: valores derivados (calcule durante a renderização), estado que reseta quando uma prop muda (uma key no filho) e respostas a eventos (trate no próprio handler).

3. "useMemo, useCallback, React.memo: qual é a diferença?" O que investiga: se a sua memoização é medida ou supersticiosa. useMemo guarda um valor em cache, useCallback guarda em cache a referência de uma função, React.memo pula a re-renderização de um filho quando as props são iguais em comparação rasa, e os dois primeiros são inúteis a menos que um filho memoizado ou outra lista de dependências consuma a referência. Acrescente que a memoização tem custo próprio, então você mede antes.

4. "Escreva um hook que faz debounce de um valor." O que investiga: composição, limpeza e disciplina de dependências em umas dez linhas. Estado para o valor com debounce, um efeito que cria um timer, uma limpeza que o cancela, dependências no valor e no delay. A parte que a maioria dos candidatos esquece: é a limpeza que faz disso um debounce em vez de uma fila de atualizações pendentes.

Como os entrevistadores testam renderização e reconciliação?

Perguntando o que acontece depois de uma atualização de estado, não antes. Uma boa resposta separa três fases: o React roda o componente de novo para produzir uma árvore de elementos, a reconciliação compara essa árvore com a anterior e a fase de commit aplica o conjunto mínimo de mutações no DOM. Quem borra essas fases não consegue explicar keys, timing de efeitos nem recursos concorrentes.

5. "Me explique o que acontece quando eu chamo um setter de estado." O que investiga: profundidade do modelo mental. A atualização é enfileirada e agrupada com outras no mesmo tick, o React agenda uma renderização, o componente e seus filhos rodam de novo, a nova árvore é reconciliada com a antiga, os efeitos anteriores são limpos, as mutações no DOM são commitadas, então os efeitos de layout rodam de forma síncrona e os efeitos passivos depois do paint. Acrescente que o Strict Mode invoca tudo duas vezes em desenvolvimento para expor efeitos que não são limpos de forma reversível.

6. "Por que as keys importam e o que dá errado com índices de array?" O que investiga: se você já depurou uma lista de verdade. As keys dizem à reconciliação qual elemento corresponde a qual item entre renderizações. Com keys de índice, apagar ou reordenar faz o React casar os itens errados, então o estado do componente e o estado do DOM (um input focado, um valor digitado pela metade) grudam na linha errada. Acrescente o outro lado: mudar uma key de propósito é uma forma legítima de resetar uma subárvore.

7. "Para que servem useTransition e useDeferredValue afinal?" O que investiga: consciência de que a renderização pode ser interrompida. Os dois mantêm uma atualização urgente (digitar) responsiva enquanto uma atualização pesada renderiza com prioridade menor: useTransition marca a atualização de estado como não urgente e te dá uma flag de pendente, useDeferredValue deixa um valor ficar para trás. Diga com todas as letras que nenhum dos dois torna rápida uma renderização lenta, eles só mudam o que o usuário espera.

Que perguntas sobre gerenciamento de estado eu devo esperar?

Duas, com confiança: onde um pedaço de estado mora e como você trata dado de servidor de forma diferente de dado de cliente. A resposta esperada começa no estado local, trata o contexto como um mecanismo de entrega para valores de baixa frequência em vez de uma store, e coloca qualquer coisa vinda de uma API atrás de uma camada de cache.

8. "Contexto ou uma biblioteca de estado, e como você escolhe?" O que investiga: se você sabe quanto o contexto custa. Estado local primeiro, eleve só até o pai comum mais próximo, contexto para valores que mudam raramente e são lidos em muitos lugares (tema, idioma, o usuário atual), e uma store quando as atualizações são frequentes ou lidas por subárvores sem relação entre si. O motivo importa: todo consumidor re-renderiza quando o valor do contexto muda, então um valor que muda rápido dentro do contexto é um bug de performance esperando para ser aberto.

9. "Como você lida com estado de servidor?" O que investiga: se você já colocou algo no ar com dados reais. Dado de servidor é um cache de algo que não é seu, então precisa de deduplicação, regras de obsolescência, revalidação em segundo plano e invalidação depois de uma mutação, e fazer isso na mão dentro de efeitos dá errado devagar. Nomeie o padrão em vez de só a biblioteca: busque no servidor onde o framework permitir, faça cache no cliente, mantenha o estado de UI local separado.

Como as perguntas de performance em React são feitas na prática?

Como um cenário com um sintoma, não como uma definição. Você recebe "digitar nesse campo de filtro está travando" ou "essa página leva quatro segundos para ficar interativa", e o entrevistador observa se você mede antes de mudar qualquer coisa. Correr direto para o useMemo é a abertura errada; abrir o Profiler e perguntar o que está re-renderizando é a certa.

10. "Digitar numa caixa de busca que filtra dez mil linhas está travando. Diagnostique." O que investiga: método. Grave com o React Profiler e com o painel de performance do navegador e determine se o custo é muitos componentes re-renderizando ou um componente renderizando muitos nós. Se for quantidade de nós, virtualize; se for amplitude de re-renderização, coloque o estado do input junto dele para que a árvore acima fique parada, depois memoize a linha; se o filtro em si for caro, memoize ou adie.

11. "O bundle está grande demais. O que você faz?" O que investiga: se você já abriu um analisador de bundle. Meça primeiro, depois divisão por rota com lazy e Suspense, imports dinâmicos para widgets pesados (editores, gráficos, date pickers), troca de uma dependência grande demais e mover trabalho para o servidor onde o framework suportar. Amarre a uma métrica que interessa ao negócio, normalmente LCP ou latência de interação, em vez de a kilobytes por si só.

12. "O compilador do React torna a memoização manual obsoleta?" O que investiga: se você acompanha o ecossistema e consegue sustentar uma posição com nuance. A memoização automática remove a maior parte do barulho rotineiro de useMemo e useCallback no código, o que é uma melhoria de verdade, mas não conserta estado colocado alto demais, um contexto amplo demais, uma lista não virtualizada nem um efeito caro. Diga o que você ainda faria na mão e o que apagaria feliz.

Como são as perguntas sobre testes em React?

Normalmente um cenário mais uma pergunta sobre proporção. Os entrevistadores querem testes que exercitem comportamento pela superfície que o usuário toca, a rede mockada na fronteira em vez de stub nos seus próprios módulos, e uma divisão honesta: testes unitários para lógica pura, testes de integração no nível de componente para o grosso da UI e uma camada fina de testes ponta a ponta sobre os fluxos que dão prejuízo quando quebram.

13. "Como você testa um componente que carrega dados e mostra uma lista?" O que investiga: se os seus testes sobrevivem a refatorações. Renderize o componente, mocke na camada de rede, consulte por papel e nome acessíveis, depois verifique o estado de carregamento, as linhas carregadas, o estado vazio e o estado de erro. Evite verificar props ou internals de hooks, e mencione a flakiness: consultas com await em vez de timeouts arbitrários.

Os entrevistadores perguntam sobre React Server Components?

Cada vez mais, sim, na maioria das vezes para checar se você entende a fronteira, não para testar trivia de framework. Você deve conseguir dizer o que roda onde, o que um server component não pode fazer e de onde vêm os erros comuns de hidratação e de cache. Ser honesto sobre pouca experiência prática é aceitável; fingir não é, porque a pergunta seguinte vai te pegar.

14. "Qual é a diferença entre um server component e um client component?" O que investiga: a fronteira. Server components rodam no servidor, dão await em dados diretamente, nunca enviam o código deles para o navegador e não podem usar estado, efeitos ou handlers de evento; client components hidratam no navegador e podem fazer as três coisas. A diretiva "use client" marca um ponto de entrada no território do cliente, então tudo que é importado abaixo dela também vai para o cliente, e é por isso que uma diretiva descuidada no topo de uma árvore acaba com o benefício.

15. "Onde você busca os dados e quais são as pegadinhas de cache?" O que investiga: cicatrizes de produção. Busque no servidor, perto de onde o dado é renderizado, e deixe o framework deduplicar requisições idênticas dentro de uma renderização. As pegadinhas que vale nomear: renderização estática acidental de algo que deveria ser dinâmico, dado desatualizado depois de uma mutação porque nada revalidou, e mismatches de hidratação por renderizar um timestamp na passagem do servidor.

Que erros reprovam candidatos de React?

Na maioria, falhas de processo e não lacunas de conhecimento. Entrevistadores raramente reprovam alguém por não saber um hook; eles reprovam o candidato que trabalhou em silêncio, chutou uma correção e deixou o estado de erro sem tratamento. Estes seis respondem pela maior parte do feedback de não contratar em processos de React.

• Codar em silêncio. Na rodada de build, o comentário em voz alta é a maior parte do sinal.
• Apelar primeiro para um efeito. Buscar, derivar e sincronizar estado dentro de efeitos quando existe algo mais simples é o sinal arquitetural mais comum.
• Memoizar sem medir. Os entrevistadores perguntam "o que isso melhorou" justamente porque a maioria dos candidatos não sabe responder.
• Ignorar o caminho de erro. Os estados de carregamento, vazio e erro são o que vai ser cutucado. Cubra sem esperar que peçam.
• Parar na definição. "useCallback memoiza uma função" é onde começa a metade interessante da resposta.
• Exagerar sobre server components. Tropeçar na fronteira do cliente custa mais caro do que admitir que você entregou um projeto só.

Como devo me preparar para uma entrevista de React?

Construa duas coisas em vez de ler sobre dez. Uma tabela filtrável e ordenável com paginação no servidor te obriga a passar por colocação de estado, cache, keys e virtualização. Um formulário de várias etapas com validação e envio real te obriga a passar por inputs não controlados, tratamento de erro e gerenciamento de foco. Juntos, eles geram respostas honestas para a maioria das perguntas acima, e respostas honestas sobrevivem aos aprofundamentos.

Depois perfile algo real. Abra o Profiler num app em que você trabalha, ache o componente que mais re-renderiza e conserte direito, porque isso te dá uma história com números dentro. Para os fundamentos por baixo do framework, o guia de perguntas de entrevista para desenvolvedor frontend cobre o material de JavaScript e navegador que a triagem técnica ainda usa como filtro, e, num empregador grande, o banco de perguntas da empresa vale uma olhada para pegar os padrões da casa.

Depois ensaie contra a lista certa: passe o anúncio da vaga pelo Question Predictor gratuito, para que as vinte perguntas que você pratica em voz alta sejam as que aquele time provavelmente vai fazer, em vez de um conjunto genérico.

Onde um copiloto ao vivo encaixa

A preparação cobre a maior parte, e aí uma pergunta chega de lado no minuto quarenta e a sua cabeça apaga. O GhostPilot AI é um copiloto em tempo real para esse momento: roda num painel lateral de extensão do Chrome ou como app de desktop para Windows, escuta a chamada, captura a pergunta e tem uma resposta estruturada pronta cerca de dois segundos depois, o que normalmente basta para transformar uma pausa em branco numa primeira frase limpa. O plano gratuito inclui 10 minutos de sessão ao vivo por semana, sem cartão. É uma rede de segurança para um branco de memória, não um substituto para conhecer o seu próprio trabalho.

FAQ

Quanto tempo devo me preparar para uma entrevista de desenvolvedor React? De duas a três semanas de prática focada se você escreve React todo dia. Se você vem mantendo uma base legada de componentes de classe, reserve de quatro a seis semanas, principalmente para ficar confortável com os padrões da era dos hooks, estado de servidor e o vocabulário atual de renderização.

As entrevistas de React ainda incluem perguntas de algoritmos? Algumas incluem, principalmente em empresas grandes com processo padronizado. A tendência nas empresas de produto é firmemente construir e depurar componentes reais. Mantenha as estruturas de dados básicas aquecidas, mas gaste o grosso do seu tempo em trabalho prático de UI.

Quanto eu preciso saber sobre React Server Components? O suficiente para explicar a fronteira com confiança e nomear os erros comuns. Experiência prática profunda é um bônus na maioria das vagas, não um requisito, a menos que o anúncio gire em torno de um framework construído sobre isso.

Devo mencionar que uso ferramentas de IA para escrever React? Sim, se perguntarem, e diga como você revisa a saída. Os entrevistadores já assumem isso. O que eles estão checando é se você consegue defender e depurar o código, que é exatamente por que os aprofundamentos ficaram mais difíceis.