Perguntas de entrevista para pessoa desenvolvedora na rodada antes do código
Comece pelo que esta página não é. Em engenharia, o código é a avaliação — teste prático, pareamento ou entrevista técnica estruturada — e nenhuma resposta gravada substitui isso. Para o que a rodada gravada serve é justamente o que o teste prático nunca mostra e o currículo não conta: como a pessoa explica uma decisão técnica para quem não estava lá, o que ela faz quando discorda de quem revisou o código dela, e se ela consegue dizer que não sabe. Numa pilha de trezentos inscritos júnior, isso também é a forma mais barata de proteger o tempo de quem revisa.
O que o trabalho envolve de verdade
A pessoa desenvolvedora transforma requisito ambíguo em software que funciona e depois mantém funcionando. Escrever código novo ocupa menos da semana do que quem está de fora imagina; a maior parte é ler código existente, revisar o dos outros, investigar bug e negociar escopo com quem pediu.
O que separa gente de capacidade técnica parecida é comunicação sob discordância. Code review é negociação diária, incidente é problema de comunicação antes de ser técnico, e quem não consegue dizer 'não sei' vai chutar em produção. Nada disso aparece num teste prático.
As perguntas, e como soa uma boa resposta
Use as perguntas como estão. Cada uma vem com o que é uma resposta forte, para que duas pessoas avaliando o mesmo candidato cheguem à mesma conclusão pelo mesmo motivo.
1. Explique algo técnico que você construiu para alguém que não tem a sua formação.
Uma boa resposta: Escolhe o nível certo de abstração e confere se a pessoa acompanhou, em vez de palestrar. Resposta forte começa dizendo para que a coisa serve. É a pergunta mais útil da lista porque é amostra de trabalho da metade da vaga que teste prático não testa.
2. Alguém rejeita o seu pull request e você acha que a pessoa está errada.
Uma boa resposta: Pergunta o que ela está vendo, discute o mérito por escrito, e escala ou cede em vez de ficar um dia trocando comentário. O que se ouve é se a discordância é sobre o código ou sobre ter razão.
3. Me conta de algo que você subiu e quebrou.
Uma boa resposta: Incidente real, assumido, com a correção sistêmica e não só o hotfix. O detalhe é se o diagnóstico para em 'eu errei' ou chega em 'nada teria pego isso, então criamos algo que pega'.
4. Você recebe uma tarefa e o requisito está ambíguo.
Uma boa resposta: Pergunta antes de construir, com as interpretações nomeadas e uma recomendação. Quem constrói a coisa errada com confiança sai mais caro que quem é lento.
5. Como você decide que algo está pronto?
Uma boa resposta: Cita critérios além de 'funciona': teste, observabilidade, alguém depois conseguir mexer. Resposta forte menciona a próxima pessoa que vai tocar naquele código.
6. Você está no segundo dia de uma estimativa de cinco e já sabe que vai levar dez.
Uma boa resposta: Fala no segundo dia, com o que mudou. Mesmo comportamento que os guias de vendas e de contas testam com outro nome: notícia ruim cedo vale mais que estimativa precisa.
7. O que você acreditava sobre engenharia há dois anos e não acredita mais?
Uma boa resposta: Uma mudança específica, com motivo. É o melhor indicador disponível de que a pessoa continua aprendendo, e é muito difícil de preparar de forma convincente.
8. Como você começa a ler uma base de código que nunca viu?
Uma boa resposta: Um método (pontos de entrada, testes, seguir uma requisição inteira) em vez de ler de cima a baixo. A maior parte do trabalho é ler código, e quase ninguém é perguntado sobre isso.
Uma ficha de avaliação para pontuar
Dê de 1 a 4 em cada linha, e anote a nota antes de assistir ao próximo. A nota escorrega quando ela é dada em relação a quem você acabou de ver.
| Critério | Como é uma nota 4 |
|---|---|
| Explicar para não especialista | Escolhe a abstração certa e confere entendimento. Nota 2 palestra num nível só. |
| Discordância em review | Discute mérito e depois cede ou escala. Nota 2 insiste sem fim ou capitula na hora. |
| Assumir incidente | Cita correção sistêmica, não só o hotfix. Nota 2 para no erro. |
| Lidar com ambiguidade | Pergunta antes, com recomendação. Nota 2 constrói confiante em cima de suposição. |
| Honestidade de estimativa | Levanta o estouro no segundo dia. Nota 2 vira noite e reporta no prazo. |
Como rodar a triagem
- Tenha clareza do que essa rodada é. Ela filtra e protege tempo de revisão; ela não avalia capacidade de engenharia, e tratar como se avaliasse é como se reprova gente boa que entrevista mal.
- Coloque antes do teste prático, não depois. O argumento econômico inteiro é que revisar trezentos testes é impossível e assistir a trezentas respostas de dois minutos não é.
- Faça duas ou três perguntas só, e uma delas a de explicar. Pessoa desenvolvedora desconfia — com razão — de processo que desperdiça o tempo dela.
- Pontue comunicação explicitamente e separada de conteúdo técnico. Misturar as duas transforma a rodada numa entrevista técnica ruim.
- Nunca reprove por sotaque, hesitação ou nervosismo. Nada disso prevê capacidade técnica, e esse erro é bem documentado em contratação de tecnologia.
Rodar isso numa pilha grande de inscritos é onde a conta cresce. A VoxScreen manda essas perguntas num link só, transcreve e avalia cada resposta pelos critérios que você definiu e devolve a lista ranqueada — de graça para 50 candidatos por mês, sem cartão.
Erros comuns ao contratar para esta vaga
- Usar rodada gravada como triagem técnica. Ela não é. Pergunta de decoreba na frente da câmera mede memória e preparo, não engenharia.
- Pedir exercício de algoritmo em formato gravado. A pessoa não consegue fazer pergunta de esclarecimento, que é a única parte do exercício com sinal.
- Dar mais peso à fluência que ao conteúdo. É o jeito específico como rodada gravada dá errado em contratação de tecnologia.
- Pular o teste prático porque a gravação impressionou. Articulado e incapaz de construir é combinação real e sai caro.
- Fazer triagem longa. Cada pergunta a mais perde candidato forte com outros três processos rodando, e não é perda aleatória.
Perguntas frequentes
Vale usar entrevista gravada para contratar pessoa desenvolvedora?
Não como avaliação técnica — isso tem que ser código, seja teste prático, pareamento ou entrevista técnica estruturada. Uma rodada gravada curta é útil antes disso, pelo sinal de comunicação que o teste prático nunca mostra e para organizar uma pilha grande demais para revisar. Se estiver usando no lugar do código, está usando errado.
O que perguntar numa primeira rodada de engenharia?
Peça para explicar algo que construiu para alguém sem a mesma formação, pergunte o que faz quando rejeitam o pull request dela, e sobre algo que subiu e quebrou. Essas três cobrem comunicação, discordância e responsabilidade, sinais que avaliação de código não mostra, e levam uns seis minutos no total.
Como triar centenas de inscritos júnior em tecnologia?
O recurso escasso é o tempo de quem revisa, não o do candidato, então coloque uma rodada gravada curta antes do teste prático em vez de revisar tudo. Faça as mesmas duas ou três perguntas para todo mundo, pontue comunicação separada de conteúdo, e seja rígido consigo mesmo para não transformar aquilo numa entrevista técnica improvisada.
É justo avaliar pessoa desenvolvedora pelo jeito de falar?
Por comunicação, sim, explicar decisão e discordar de forma produtiva fazem parte da vaga. Por fluência, sotaque ou nervosismo, não, e a distinção importa porque é exatamente aqui que rodada gravada dá errado em tecnologia. Pontue se a explicação chegou, não se a entrega foi polida, e deixe essa diferença escrita nos critérios antes de começar a assistir.