Rubrica de avaliação
Uma rubrica para entrevistas em que o candidato constrói com IA. Ela avalia o processo, não só o código: como o problema é enquadrado, como o modelo é conduzido, como o output é verificado e quem de fato é dono do resultado. Compartilhe com o candidato antes da entrevista.
Níveis
- 1
Operador
Usa um único estilo e aceita o output sem revisar de verdade.
- 2
Praticante
Alterna entre descrever e ditar, revisa o código e corrige os erros.
- 3
Engenheiro
Escolhe o estilo pelo risco e pela complexidade, usa testes e specs como contrato, gerencia o contexto.
- 4
Arquiteto
Define padrões para o time, sabe quando não usar IA, pesa custo, segurança e manutenção.
Dimensões
| Dimensão | 1 · Operador | 2 · Praticante | 3 · Engenheiro | 4 · Arquiteto |
|---|---|---|---|---|
| Enquadramento do problemaA pessoa entende e especifica o problema antes de gerar código? | Cola a tarefa no modelo do jeito que veio. | Reescreve a tarefa e adiciona os requisitos óbvios. | Define requisitos, restrições e casos de borda, e faz perguntas para esclarecer. | Questiona o próprio problema, encontra requisitos escondidos (segurança, escala, operação) e corta escopo de propósito. |
| Escolha de estiloA pessoa escolhe de propósito como conduzir o modelo? | Usa um estilo por hábito, qualquer que seja a tarefa. | Alterna entre descrever o resultado e ditar a implementação. | Escolhe o estilo de acordo com o risco e a complexidade, e consegue explicar a escolha. | Combina estilos com fluência, troca no meio da tarefa quando a situação muda e consegue ensinar os trade-offs. |
| VerificaçãoComo a pessoa confere se o output está correto? | Roda uma vez. Se parece certo, vai. | Lê o diff e corrige os erros visíveis. | Usa testes, specs ou tipos como contrato e confere casos de borda e modos de falha. | Planeja a verificação desde o início (testes, evals, monitoramento) e pega problemas sutis de segurança, performance e concorrência. |
| Gestão de contextoA pessoa dá ao modelo o que ele precisa, e só isso? | Não dá contexto nenhum, ou joga tudo. | Adiciona arquivos relevantes depois que o modelo erra. | Monta o contexto antes, com arquivos relevantes, convenções, restrições e exemplos. | Torna o contexto reutilizável para o time (arquivos de regras, docs, ferramentas) e mantém atualizado. |
| Domínio e julgamentoA pessoa é dona do resultado como se tivesse escrito cada linha? | Não consegue explicar partes do código gerado. | Explica o código e altera quando pedem. | Rejeita ou reescreve output fraco e defende as decisões de design com argumentos. | Sabe quando não usar IA e pesa custo, segurança e manutenção para o time. |
Como conduzir a entrevista
65 minutos no totalAlinhamento 5 min
Compartilhe sua política de IA e esta rubrica. Diga quais ferramentas são permitidas e que você avalia o processo, não só o resultado.
Enquadramento 10 min
Apresente um problema realista do seu domínio, não um puzzle. Peça para a pessoa reformular, fazer perguntas e esboçar um plano antes de escrever prompts.
Construção 30 min
A pessoa constrói com as ferramentas de IA que usa no dia a dia e pensa em voz alta. Observe as escolhas de estilo, o contexto que ela fornece e como revisa o output. Não ajude com prompts.
Mudança 10 min
Introduza um requisito novo ou um bug sutil. Observe como a pessoa verifica e se adapta.
Conversa final 10 min
Peça para a pessoa explicar o código, as escolhas e o que faria antes de ir para produção. As perguntas de entrevista de cada estilo ajudam aqui.
Como pontuar
- Dê de 1 a 4 em cada dimensão, com evidência escrita. Anote o que você viu, não o que sentiu.
- Não tire média no automático. Decida antes quais dimensões pesam mais para a vaga.
- Nota 1 em domínio é um não forte para vagas de produção, quaisquer que sejam as outras notas.
- Calibre. Os entrevistadores devem avaliar juntos a mesma sessão gravada pelo menos uma vez.
Sinais positivos
- Declara as suposições antes de escrever o prompt
- Rejeita output plausível mas errado
- Troca de estilo quando o risco muda, e diz por quê
- Escreve ou pede testes antes de confiar no código
Sinais de alerta
- Aceita diffs grandes sem ler
- Não consegue explicar o código gerado
- Fica em loop de "arruma isso" sem diagnóstico
- Esconde o uso de IA ou usa ferramentas que não foram permitidas
Como se preparar como candidato
- Escolha uma feature pequena e construa em cada estilo da taxonomia. Compare os resultados e quanto tempo cada um levou.
- Treine pensar em voz alta. Diga qual estilo está escolhendo e por quê.
- Leia todo diff antes de aceitar. Esteja pronto para explicar qualquer linha.
- Escreva testes ou critérios de aceite antes do prompt, pelo menos uma vez por dia.
- Mantenha um arquivo de regras (AGENTS.md, CLAUDE.md ou parecido) num projeto pessoal.
- Pergunte à empresa qual é a política de IA e a rubrica antes da entrevista. Por este manifesto, é uma pergunta justa.