Perguntas de entrevista para Desenvolvedor: o que cai e como responder

Profundidade e honestidade sobre autoria. Ele vai puxar os fios da sua resposta ("por que essa arquitetura?", "o que você faria diferente?") para descobrir se você construiu ou assistiu — então o projeto precisa ser um que você conheça até o porão.

Estruture: o problema em uma frase de negócio (não de tecnologia), sua parte específica, uma decisão técnica que você tomou e o resultado medível. Termine com o que faria diferente hoje — essa autocrítica espontânea costuma ser o melhor momento da resposta.

Se você entende trade-off. Não existe escolha técnica só com vantagens; ele quer ouvir o que você sacrificou conscientemente (prazo, performance, simplicidade, custo) e como envolveu o time na decisão.

Apresente as alternativas que existiam de verdade, o critério de decisão (não "achei melhor" — qual restrição pesou), o que você abriu mão de ganhar e como validou depois. Uma decisão que se provou errada, contada com o aprendizado, vale tanto quanto uma acertada.

Método de investigação, não o tamanho do monstro. Ele observa se você forma hipóteses e as elimina com evidência (logs, bisect, reprodução mínima) ou se tenta coisas ao acaso até funcionar.

Conte como uma investigação: o sintoma, a primeira hipótese e por que caiu, o que o log ou o teste mostrou, o momento do "ah!". Feche com a correção E a prevenção — o teste ou alerta que você deixou para o bug não voltar em silêncio.

Se dá para trabalhar com você. Times quebram menos por técnica e mais por gente que não sabe discordar — ou que concorda por fora e sabota por dentro. Ele quer ver argumento com evidência, e capacidade de aceitar a decisão final e seguir.

Descreva sua régua: discordância se apresenta com dado ou exemplo (um benchmark, um caso que quebra), em conversa e não em guerra de comentários; decisão tomada é decisão que você executa como se fosse sua. Um caso real em que você foi convencido pelo outro lado mostra mais maturidade que um em que você venceu.

Comportamento sob incidente: prioridade em restaurar (não em achar culpado), comunicação durante a crise e o que aconteceu depois — post-mortem, correção de causa raiz, não só o band-aid.

Ordene a resposta como o incidente: detecção (como souberam — alerta ou cliente?), mitigação rápida (rollback, feature flag), comunicação com quem era afetado, e o depois: a causa raiz e o que mudou para não repetir. Se nunca viveu um, diga como seu time se preparava para isso — mas não invente cicatriz.

Critério, não dogma. "Teste em tudo" é resposta de quem nunca teve prazo; "não dava tempo de testar" é de quem gera incidente. Ele quer ouvir onde você investe teste primeiro e por quê.

Explique sua hierarquia: o que sempre tem teste (regra de negócio, dinheiro, o caminho que quebrou antes), o que se cobre com revisão e monitoramento, e como você decide. Cite a prática do seu último time (revisão obrigatória, CI, cobertura) e o que você acrescentou a ela.

Se o seu aprendizado é ativo e recente. A área muda rápido; ele quer evidência de que você aprende fazendo (um projeto, uma migração, uma contribuição) e não só colecionando cursos que não terminou.

Conte o caso mais recente de verdade: por que precisou, como começou (documentação, um projeto pequeno, o código de outros), quanto tempo até produzir algo real, e onde isso está rodando hoje. Um exemplo concreto de três meses atrás vale mais que uma teoria de aprendizado perfeita.

Pragmatismo. Os dois extremos reprovam: quem quer reescrever tudo sempre, e quem empilha gambiarra sem registro. Ele quer ver que você sabe contrair débito de propósito, documentar e negociar o pagamento.

Defina com um exemplo seu: um atalho que o time tomou conscientemente, como ficou registrado, e quando (e se) foi pago. Explique seu critério de priorização — débito que dói em quem desenvolve todo dia paga-se antes do que é apenas feio — e como você o torna visível para quem prioriza o backlog.

Sinal de risco e de fit. Ele aceita bem "busco escopo que lá não existe"; desconfia de "lá é tudo ruim" — porque quem só culpa o ambiente costuma levar o problema junto na mudança.

Uma frase honesta e sem veneno sobre a saída ("o produto estabilizou e o desafio técnico diminuiu"), e o peso da resposta no destino: o que desta vaga conecta com o que você quer construir. Se foi demissão, diga sem rodeio e siga para o que aprendeu — naturalidade aqui desarma a pergunta.