Desenvolvedor full stack Perguntas de Entrevista & Respostas

Resposta modelo

Desenvolvi um feed de atividades em tempo real para uma ferramenta de gestão de projetos. No backend, projetei um sistema de event sourcing usando PostgreSQL: cada ação no projeto (tarefa criada, comentário adicionado, status alterado) registrava um evento com timestamp, autor, tipo de ação e metadados. Construí um endpoint de API em Node.js com paginação baseada em cursor e canais WebSocket para atualizações em tempo real. No frontend, criei um componente React com uma lista virtualizada (react-window) para lidar com feeds com mais de 10 mil eventos sem problemas de desempenho no DOM. Novos eventos apareciam em tempo real via WebSocket com animações suaves de inserção. Também adicionei filtros por tipo de evento e por pessoa, que utilizavam um índice parcial dedicado no PostgreSQL. A funcionalidade foi entregue em 5 semanas e se tornou a página mais acessada da aplicação: 78% dos usuários ativos diários a visitavam pelo menos uma vez por sessão.

Resposta modelo

Precisávamos de cálculos de precificação para uma ferramenta de orçamentos. O PM queria que os preços fossem atualizados instantaneamente conforme os usuários alteravam quantidades e opções. A implementação inicial colocou toda a lógica de precificação no frontend React para feedback imediato. Funcionou até descobrirmos discrepâncias: o frontend calculava R$1.247, mas a API de confirmação do pedido retornava R$1.251 devido a abordagens diferentes de arredondamento. Movi a lógica canônica de precificação para a API backend e criei um estimador leve no frontend que usava regras simplificadas para feedback instantâneo, claramente rotulado como 'preço estimado'. Quando o usuário finalizava o orçamento, o backend calculava o preço exato. Esse padrão de 'frontend otimista, backend autoritativo' resolveu tanto os requisitos de velocidade quanto de precisão. A lição: cálculos críticos para o negócio precisam ter uma única fonte de verdade no backend. O frontend pode aproximar para a experiência do usuário, mas o servidor decide.

Resposta modelo

Nosso time tinha repositórios separados para frontend e backend com ciclos de deploy diferentes. Os desenvolvedores frontend ficavam esperando as APIs do backend ficarem prontas antes de conseguir integrar. Introduzi duas mudanças. Primeiro, implantei um fluxo de desenvolvimento com API orientada a contrato usando especificações OpenAPI: acordávamos o contrato da API antes de qualquer um dos lados começar a construir, e então os times de frontend e backend desenvolviam em paralelo usando a spec como fonte de verdade. Configurei servidores mock a partir da especificação OpenAPI para que o frontend pudesse desenvolver com respostas realistas antes do backend estar pronto. Segundo, criei uma configuração docker-compose que rodava toda a pilha localmente com um único comando, incluindo seed do banco de dados e mock de serviços externos. Problemas de integração que antes apareciam em staging passaram a aparecer nas máquinas dos desenvolvedores. O resultado: a taxa de conclusão de sprint melhorou de 68% para 91% porque as dependências entre times deixaram de bloquear o progresso.

Resposta modelo

Migramos dados de usuários do Firebase para o PostgreSQL mantendo o app React em funcionamento. O desafio: 200 mil usuários com estruturas de documentos aninhados que precisavam ser normalizados em tabelas relacionais. Construí um pipeline de migração em três fases. Fase 1: design do schema, onde mapeei as estruturas de documentos do Firebase para tabelas PostgreSQL, normalizando arrays aninhados em tabelas de junção. Fase 2: operação paralela, onde o app escrevia tanto no Firebase quanto no PostgreSQL simultaneamente usando uma camada de middleware. As leituras permaneceram no Firebase. Fase 3: validação e migração, onde escrevi um script de reconciliação que comparava 10 mil registros aleatórios entre os dois bancos diariamente. Após 2 semanas sem nenhuma discrepância, migramos as leituras para o PostgreSQL e desativamos as escritas no Firebase. Tempo total de migração: 4 semanas sem nenhuma indisponibilidade visível ao usuário. O script de reconciliação identificou 3 casos extremos na lógica de escrita dupla que teriam causado perda de dados em uma migração big-bang.

Resposta modelo

O desafio central é a resolução de conflitos: múltiplos usuários editando simultaneamente. Usaria Transformação Operacional (OT) ou CRDTs (Conflict-free Replicated Data Types). Os CRDTs são mais modernos e não exigem um servidor central para resolução de conflitos, tornando-os mais resilientes. Arquitetura: o frontend usa um editor de rich text (Tiptap/ProseMirror) com uma biblioteca CRDT (Yjs) que lida com edições locais de forma otimista. As mudanças se propagam via WebSocket para um servidor Node.js que as transmite para todos os clientes conectados. O servidor também persiste o estado do documento no PostgreSQL como um CRDT serializado a cada alteração (com debounce para evitar escritas excessivas). Para presença: cada cliente envia posição do cursor e seleção via canal WebSocket, e os outros clientes renderizam cursores coloridos. Para suporte offline: o Yjs lida com a mesclagem quando um cliente reconecta, aplicando as mudanças offline contra o estado atual do documento. Considerações de escalabilidade: usar Redis Pub/Sub para transmitir mudanças entre múltiplas instâncias de servidor, particionar conexões WebSocket por ID de documento e implementar carregamento progressivo para documentos muito longos.

Resposta modelo

Renderização no cliente (CSR): o servidor envia uma estrutura HTML mínima, o JavaScript faz o download e renderiza a página no navegador. Pontos positivos: transições de página fluidas, menor carga no servidor, bom para painéis autenticados. Pontos negativos: carregamento inicial mais lento (página em branco até o JS executar), SEO ruim (motores de busca podem não executar JS), Core Web Vitals piores. Renderização no servidor (SSR): o servidor renderiza o HTML completo para cada requisição. Pontos positivos: first contentful paint rápido, SEO excelente, funciona sem JavaScript. Pontos negativos: maior carga no servidor, recarregamentos completos de página parecem mais lentos, mais difícil implementar funcionalidades interativas. Escolho CSR para aplicações autenticadas (painéis, áreas administrativas, ferramentas SaaS) onde o SEO não importa e a interatividade é prioridade. Escolho SSR para conteúdo público (sites de marketing, blogs, páginas de produtos de e-commerce) onde SEO e tempo de carregamento inicial são críticos. Frameworks modernos (Next.js, Nuxt, Remix) permitem combinar os dois: SSR para o carregamento inicial com hidratação no cliente para interatividade. A Geração de Sites Estáticos (SSG) é ainda melhor para conteúdo que não muda por requisição.

Resposta modelo

Implemento autenticação baseada em JWT com uma estratégia específica de tokens. O token de acesso (JWT) tem vida curta (15 minutos), contém identidade e perfis do usuário e é enviado no cabeçalho Authorization. O token de refresh é de longa duração (7 dias), opaco (não é JWT), armazenado em um cookie HTTP-only Secure SameSite e mapeado para um registro no banco de dados para poder ser revogado. O fluxo: o usuário faz login, o servidor valida as credenciais, retorna o token de acesso no corpo da resposta e define o cookie de refresh. O frontend armazena o token de acesso na memória (não no localStorage, que é vulnerável a XSS). Quando o token de acesso expira, o frontend chama silenciosamente o endpoint de refresh, que valida o cookie e retorna um novo token de acesso. No logout, ambos os tokens são invalidados no servidor. Para OAuth (Google, GitHub), uso o fluxo de código de autorização: redireciono para o provedor, recebo o código no callback, troco o código pelos tokens do provedor no servidor, crio ou associo a conta do usuário e emito nosso próprio JWT. Nunca confio diretamente nos tokens do lado cliente provenientes de provedores OAuth.

Resposta modelo

Implemento tratamento de erros em quatro camadas. API backend: todos os erros retornam um formato JSON consistente com código de status, código de erro (legível por máquina), mensagem (legível por humano) e campo de detalhes opcional. Uso os códigos de status HTTP corretamente: 400 para validação, 401 para autenticação, 403 para autorização, 404 para não encontrado, 409 para conflitos, 500 para erros do servidor. Nunca exponho stack traces ou detalhes internos em respostas de produção. Camada de serviço backend: try/catch em chamadas externas e operações de banco de dados, com tipos de erro específicos (NotFoundError, ValidationError, ConflictError) que mapeiam para respostas HTTP. Erros não tratados chegam a um handler global que registra o erro completo e retorna um 500 genérico. Camada de API frontend: um cliente de API centralizado que trata erros comuns: 401 aciona o refresh do token, 403 exibe acesso negado, 429 exibe mensagem de limite de taxa, 500 exibe um erro genérico com opção de tentar novamente. Interface frontend: error boundaries capturam erros de renderização, notificações toast para erros não bloqueantes e validação inline para erros de formulário. Cada erro é registrado: erros do servidor em logging estruturado (Pino), erros do cliente em um serviço de rastreamento de erros (Sentry).

Resposta modelo

Começaria com um monólito, a menos que haja uma razão convincente para não o fazer. Microsserviços adicionam complexidade operacional (rede, deploy, monitoramento, depuração de sistemas distribuídos) que só se justifica em determinados tamanhos de time e requisitos de escala. Escolheria um monólito quando: o time tem menos de 10 engenheiros, o produto ainda está buscando product-market-fit (iteração rápida importa mais do que escalabilidade) e não há necessidade imediata de escalar ou fazer deploy independente de componentes específicos. Escolheria microsserviços quando: componentes diferentes têm necessidades de escalabilidade muito distintas (um processador de imagens intensivo em CPU versus uma API leve), os times precisam fazer deploy de forma independente (mais de 10 engenheiros, múltiplos squads) ou o domínio se decompõe naturalmente em contextos delimitados distintos. O meio-termo pragmático: construir um monólito modular com fronteiras internas claras. Se um módulo precisar se tornar um serviço no futuro, a separação já está limpa. Isso evita a complexidade de sistemas distribuídos enquanto mantém a opção de dividir quando a necessidade for real.

Resposta modelo

Eu criaria um protótipo antes de especular. Construiria a animação usando CSS transforms e opacity (que são acelerados por GPU e não disparam reflow de layout) e testaria em um dispositivo Android intermediário representativo, não no meu MacBook Pro. Se rodar a 60fps nesse dispositivo, publicaria. Se não, diagnosticaria o gargalo usando o painel Performance do Chrome DevTools: é layout thrashing, operações de paint ou bloqueio da thread principal? Depois proporia alternativas com base no problema específico. Talvez possamos usar a Web Animations API para melhor agendamento de frames. Talvez reduzamos o número de elementos animados. Talvez usemos will-change para promover camadas à GPU. Talvez a animação execute apenas uma vez em vez de continuamente. Apresentaria ao designer um espectro: 'Aqui está a animação completa a 30fps no mobile. Aqui está uma versão simplificada a 60fps. Aqui está um fallback estático.' Que ele escolha o trade-off. Muitas vezes os designers preferem a versão simples e fluida à versão complexa e travada.

Resposta modelo

Primeiro entenderia o porquê: essas chamadas são independentes ou têm dependências? Todas são necessárias para o render inicial? Minhas estratégias de otimização em ordem de impacto: Primeiro, identificar chamadas que não são necessárias para o render inicial e adiá-las: carregar dados abaixo da dobra no scroll, carregar painéis secundários na interação. Isso pode reduzir as chamadas iniciais de 15 para 5. Segundo, agrupar chamadas relacionadas: se estamos buscando perfil do usuário, configurações do usuário e notificações do usuário separadamente, criar um endpoint BFF (Backend for Frontend) que retorne todos os dados do usuário em uma única chamada. Terceiro, usar GraphQL ou um padrão de API composta se a fragmentação for um problema sistêmico: deixar o frontend solicitar exatamente os dados que precisa em uma única chamada. Quarto, cache agressivo: usar o padrão stale-while-revalidate do React Query para dados que não mudam com frequência. Quinto, prefetch: se o usuário provavelmente vai navegar da página A para a página B, começar a buscar os dados da página B ao passar o mouse. Eu mediria o impacto: tempo total de carregamento da página, Time to Interactive e número de requisições de rede.

Resposta modelo

Eu quantificaria a dívida em vez de simplesmente rotulá-la como 'dívida técnica'. O que especificamente quebraria ou se tornaria mais difícil? Quantas funcionalidades futuras são afetadas? Qual é o custo de manutenção ao longo de 12 meses? Depois proporia alternativas. Opção A: construir do jeito correto, leva mais tempo, mas não adiciona dívida. Opção B: construir a versão do cliente por trás de uma feature flag como extensão personalizada, com um plano para generalizá-la quando outros clientes precisarem de funcionalidade similar. Opção C: construir a versão rápida com um item de dívida documentado, prazo comprometido para refatoração e aceitação do responsável pelo produto de que isso cria um custo de manutenção. Apresentaria o trade-off claramente: 'Podemos entregar em 2 semanas com a abordagem C, mas isso vai desacelerar a Feature X no próximo trimestre em 1 semana e a Feature Y em 3 dias.' Geralmente, quando você quantifica o custo downstream, a decisão fica óbvia. Se o negócio decide que a velocidade vale a dívida, isso é uma decisão legítima, mas deve ser explícita.