Desenvolvedor frontend Perguntas de Entrevista & Respostas

Resposta modelo

A equipe de design entregou mockups para uma tabela de dados com scroll infinito, ordenação em tempo real, edição inline e transições animadas nas linhas, tudo sobre um conjunto de dados com mais de 100 mil registros. Fiz um protótipo e descobri que a renderização do DOM combinada com as animações derrubava a performance para menos de 10fps em dispositivos intermediários. Em vez de simplesmente dizer que era impossível, criei duas alternativas: uma com renderização virtualizada (react-window), que mantinha o scroll fluido mas simplificava as animações, e outra com paginação que preservava todos os efeitos visuais. Apresentei as duas ao designer com métricas de performance. Escolhemos a abordagem virtualizada com transições simplificadas nas linhas. O designer valorizou ver a diferença de forma concreta em vez de receber um 'não' vago. A implementação final lidou com 100 mil linhas a 60fps com toda a funcionalidade principal preservada.

Resposta modelo

A página inicial de um e-commerce tinha um Largest Contentful Paint de 4,2 segundos, e os dados de conversão indicavam queda de 7% nas vendas a cada segundo adicional de carregamento. Identifiquei três gargalos: uma imagem hero de 2MB, 800KB de JavaScript síncrono e um arquivo CSS bloqueante que importava folhas de estilo não utilizadas. Converti a imagem hero para WebP com srcset responsivo, dividi o bundle JavaScript em partes menores com importações dinâmicas (reduzindo o carregamento inicial em 65%) e integrei o CSS crítico inline enquanto o restante era carregado de forma assíncrona. O LCP caiu para 1,1 segundo. No mês seguinte, a taxa de conversão aumentou 9% e a taxa de rejeição caiu 15%. O esforço total de engenharia foi de 4 dias, um dos projetos com maior retorno sobre investimento em que trabalhei.

Resposta modelo

Construí uma biblioteca de componentes React compartilhada para uma empresa com 4 equipes de produto, cada uma implementando seus próprios botões, modais e formulários. Comecei auditando os componentes existentes em todos os produtos: encontrei 12 variantes diferentes de botão. Consolidei em 4 (primário, secundário, ghost e de exclusão) com tamanhos e espaçamentos consistentes. Usei TypeScript para tipagem rigorosa das props, Storybook para documentação e testes visuais, e Chromatic para testes de regressão visual. Versionei a biblioteca com versionamento semântico e a publiquei em um registro npm privado. A adoção foi a parte mais difícil: realizei sessões de dúvidas semanais, criei um guia de migração para cada produto e abri pull requests mostrando como substituir os componentes customizados. Após 4 meses, todas as equipes usavam a biblioteca compartilhada, a consistência visual melhorou e o tempo de desenvolvimento de novas funcionalidades diminuiu porque os desenvolvedores pararam de recriar componentes comuns.

Resposta modelo

Recebemos relatos de bugs indicando que a validação de formulário não funcionava no Safari iOS. O problema: estávamos usando o método reportValidity() da Constraint Validation API, que o Safari suportava mas tratava de forma diferente. Ele exibia o tooltip de erro, mas não impedia o envio do formulário no iOS. Rastreei o bug até um problema de renderização do WebKit em que o tooltip aparecia atrás do teclado virtual. Minha solução teve três partes: substituí os tooltips nativos de validação por mensagens de erro inline customizadas (uma melhoria de UX de qualquer forma), adicionei uma camada de validação em JavaScript como fallback e configurei testes cross-browser com BrowserStack na pipeline de CI para detectar problemas específicos do Safari mais cedo. Também criei uma checklist de testes de compatibilidade para a equipe, cobrindo Safari iOS, Chrome Android, Firefox e Edge. A correção resolveu mais de 40 relatórios de bugs abertos relacionados ao Safari de uma só vez.

Resposta modelo

O DOM virtual é uma representação JavaScript leve do DOM real. Quando o estado muda, o React cria uma nova árvore de DOM virtual e a compara com a anterior: isso é a reconciliação. O React usa um algoritmo heurístico O(n): compara as árvores nível por nível, assume que elementos de tipos diferentes produzem árvores diferentes (e as desmonta completamente), e usa as props 'key' para identificar quais filhos em uma lista mudaram, foram movidos ou removidos. Quando o diff encontra uma diferença, o React agrupa o conjunto mínimo de operações reais no DOM. Isso é mais rápido do que manipular o DOM real diretamente porque operações no DOM são custosas (disparam recálculo de layout, pintura e composição), enquanto a comparação de objetos JavaScript é barata. A implicação prática: sempre use keys estáveis e únicas para itens de lista (nunca índices de array), evite criar novas referências de objetos e funções no render (isso anula a memoização) e use React.memo, useMemo e useCallback quando o profiling mostrar re-renderizações desnecessárias.

Resposta modelo

Flexbox é unidimensional: lida com layout em uma linha ou em uma coluna. Grid é bidimensional: gerencia linhas e colunas ao mesmo tempo. Uso Flexbox para layout em nível de componente: alinhar itens em uma navbar, espaçar botões em uma barra de ferramentas, centralizar conteúdo vertical e horizontalmente. O Flexbox se destaca quando o tamanho do conteúdo deve determinar o layout. Uso Grid para layout em nível de página: definir a estrutura geral da página, criar grids complexos de cards, construir layouts de dashboard com múltiplas regiões. O Grid se destaca quando você quer que o layout defina o posicionamento do conteúdo. Na prática, combino os dois: Grid para o macro layout (cabeçalho, barra lateral, conteúdo principal, rodapé) e Flexbox para o micro layout dentro de cada célula do grid. O erro comum é usar Grid para uma simples fileira de itens ou recorrer a gambiarras com Flexbox (margens negativas, pseudo-elementos) quando o Grid seria mais simples.

Resposta modelo

Categorizo o estado pela sua natureza e escolho as ferramentas adequadas. Estado local de UI (campos de formulário, toggles, visibilidade de modais): useState ou useReducer. Mantenho no componente que o possui e elevo apenas quando realmente necessário. Estado de servidor (dados de APIs): React Query ou SWR. Essas bibliotecas lidam com cache, refetching, atualizações otimistas e estados de carregamento e erro muito melhor do que padrões manuais com Redux. Nunca coloco dados de servidor em estado global. Estado global do cliente (tema, autenticação, preferências do usuário): React Context para atualizações pouco frequentes (tema, locale) ou Zustand para estado que muda com frequência e precisa de assinatura seletiva para evitar re-renderizações. Estado na URL (filtros, paginação, parâmetros de busca): useSearchParams do React Router. O estado fica na URL, permitindo favoritar e compartilhar. O antipadrão que evito: colocar tudo em um único store global. Isso cria acoplamento, dificulta os testes e geralmente faz com que componentes sejam re-renderizados quando um estado não relacionado muda. Cada categoria de estado tem a ferramenta certa; a arte está em escolher corretamente.

Resposta modelo

Uma closure é uma função que mantém acesso às variáveis de seu escopo externo mesmo após a função externa ter terminado de executar. A função interna 'fecha sobre' as variáveis que referencia. Um exemplo prático: a função debounce. Quando você escreve debounce(fn, delay), a função retornada tem acesso à variável timer definida no escopo de debounce. Cada vez que a função retornada é chamada, ela cancela o timer anterior e define um novo. A variável timer persiste entre chamadas por causa da closure: ela não é descartada pelo garbage collector enquanto a função retornada existir. Outro uso real: o hook useState do React. Quando você chama setCount(count + 1), o valor de count vem da closure criada quando o componente renderizou. Por isso, closures obsoletas (stale closures) são um bug comum no React: se você usar count dentro de um useEffect sem incluí-lo no array de dependências, o efeito fecha sobre o valor inicial e nunca vê as atualizações.

Resposta modelo

Primeiro verificaria meu entendimento tanto do requisito de design quanto da limitação da API. Às vezes o que parece uma limitação é na verdade um endpoint diferente ou um parâmetro de consulta que ainda não encontrei. Verificaria a documentação da API e conversaria com o desenvolvedor backend. Se a limitação for real, avaliaria três opções. Primeira: o frontend consegue derivar os dados necessários das respostas existentes da API? Às vezes um cálculo ou transformação no lado do cliente resolve sem precisar de mudanças no backend. Segunda: uma alteração na API backend é viável dentro do prazo? Se for uma adição simples, discutiria com a equipe backend e veria se conseguimos coordenar. Terceira: é possível ajustar o design para funcionar com os dados disponíveis sem comprometer a experiência do usuário? Apresentaria a restrição e as alternativas ao designer e ao gerente de produto com minha recomendação. O que eu não faria: contornar a limitação com múltiplas chamadas à API, joins no lado do cliente ou truques de cache que geram dívida técnica. Se a solução certa é uma mudança no backend, defendê-la faz parte do meu trabalho.

Resposta modelo

Evitaria jargão técnico por completo. Usaria uma analogia: 'É como pedir para adicionar uma porta em um cômodo. A porta em si é simples, mas significa mover a fiação elétrica e possivelmente ajustar uma parede estrutural.' Depois seria específico sobre o prazo: 'O botão em si são 30 minutos de trabalho. Mas os dados que ele precisa ainda não existem no sistema, e construir o pipeline para obtê-los leva cerca de 2 semanas.' Apresentaria também as opções: 'Podemos entregar uma versão mais simples usando dados existentes na semana que vem, ou a versão completa que você imagina em 3 semanas. Qual prefere?' O ponto central é ser honesto sobre a complexidade sem fazer o stakeholder se sentir mal por perguntar. Ele não precisa entender por que é complexo: precisa entender o prazo e as opções disponíveis.

Resposta modelo

Avaliaria em cinco dimensões, não pela hype. Primeira, prontidão da equipe: quanto tempo de aprendizado o novo framework exige? Se a equipe conhece React e estamos considerando Svelte, isso representa 4 a 6 semanas de produtividade reduzida. O prazo tem flexibilidade para isso? Segunda, maturidade do ecossistema: existem bibliotecas para roteamento, gerenciamento de estado, formulários e testes? Conseguimos encontrar respostas no Stack Overflow? Terceira, contratação: conseguimos encontrar engenheiros que conhecem esse framework? React tem um pool de talentos muito maior do que Solid ou Qwik. Quarta, performance: o novo framework resolve um problema real de performance que temos? Se a nossa aplicação React é suficientemente rápida, trocar por benchmarks é otimização prematura. Quinta, longevidade: é mantido por uma organização ou comunidade estável? Qual a frequência de commits, o número de contribuidores e a adoção corporativa? Criaria um protótipo de uma funcionalidade representativa nos dois frameworks, mediria a velocidade real de desenvolvimento e a performance, e apresentaria a comparação para a equipe. A decisão deve ser baseada em dados, não em tendências.

Resposta modelo

Abordaria o assunto de forma proativa em vez de esperar que se tornasse um problema. Montaria uma lista curta de problemas específicos de acessibilidade visíveis nos mockups: estados de foco ausentes, contraste de cor insuficiente, ícones sem rótulos de texto, campos de formulário sem labels visíveis. Em seguida, levantaria o assunto com o designer de forma construtiva: 'Percebi algumas lacunas de acessibilidade que devemos resolver antes do desenvolvimento. Aqui estão os itens específicos.' Proporia soluções, não apenas problemas: 'Este botão precisa de um anel de foco, veja como poderia ficar. Este texto tem contraste de 3,2:1, mas precisa de 4,5:1. Escurecer duas tonalidades resolve.' Se o designer reagir citando prazo, explicaria o risco legal e de negócio: o número de processos por falta de acessibilidade está crescendo, e corrigir acessibilidade após o desenvolvimento custa de 3 a 5 vezes mais do que construir corretamente desde o início. Também configuraria verificações automáticas de acessibilidade (axe-core no CI) para evitar regressões.