Prova De Linguagens

Como montar e corrigir uma prova de linguagens de programação

A maioria dos processos seletivos técnicos hoje exige que você avalie candidatos em linguagens reais. Isso não é difícil quando você já passou por isso algumas vezes. O problema é que praticamente todo mundo começa da forma errada, e o resultado é um teste que leva três horas para corrigir e ainda assim não diz nada sobre o que o candidato sabe fazer. O que funciona na prática é criar uma prova de linguagens que isole competências específicas, em vez de pedir um projeto genérico completo. Você já viu aqueles testes onde pedem para construir uma API com autenticação, banco de dados e interface web. Quem entrega pior quase sempre é o mais qualificado, porque o teste premia quem tem mais tempo livre, não quem entende melhor o fundamento que você quer avaliar.

Prova de linguagens: o que realmente importa medir

Antes de escrever qualquer questão, defina o que vai medir. Isso é o que separa um teste útil de um que desperdiça o tempo de todos. Se o objetivo é verificar domínio de Python para automação, não coloque uma questão de recursão em C. A coerência entre o objetivo e a tarefa é mais importante do que a dificuldade em si. Eu montava testes que pareciam simples no papel e travavam na correção. Já perdi duas tardes corrigindo provas porque deixei passar um detalhe que parecia menor: não especificar a entrada esperada de forma exata. Um candidato podia ler um arquivo CSV com delimitador tab e outro com vírgula, ambos logicamente corretos, e você ficava na dúvida se errar o formato era falha de interpretação ou falha técnica. A solução foi escrever testes automatizados com entradas e saídas fixas, usando comparações byte a byte. Isso eliminou a subjetividade completamente e cortou o tempo de correção de duas horas para cerca de quinze minutos por candidato. O segredo que ninguém menciona é que a maior parte do valor de uma prova de linguagens está nos casos de borda que você inclui deliberadamente. Não os inclua como armadilha. Coloque-os como parte da especificação. Se você quer saber se o candidato lida com arquivos vazios, put that in the requirements and assign points accordingly. Candidatos bons lêem a especificação com cuidado. Candidatos ruins também, mas cometem erros diferentes.

Estrutura prática que funciona

Uma prova eficaz costuma ter três blocos, cada um com tempo e peso definidos. O primeiro bloco avalia fundamentos: sintaxe, estruturas de dados, manipulação básica. Duração de vinte a trinta minutos. O segundo bloco é o coração: um problema aplicado que exige leitura de especificação, planejamento e implementação. Quarenta a cinquenta minutos. O terceiro bloco é opcional mas recomendado: debug de um código funcional porém com bugs sutis. Vinte minutos. Para o segundo bloco, eu uso um padrão que aprendi na prática depois de ver muitos candidatos entregarem coisas completamente fora do que eu pedia. A tarefa deve ser autocontida. Nada de dependências externas, nada de APIs de terceiros, nada que exija configuração de ambiente. Se a linguagem for Python, o candidato deve conseguir rodar com python3 apenas. Se for JavaScript, node puro. Sem framework, sem package.json complicado. Um exemplo concreto que funcionou bem nos últimos meses: pedir para implementar um parser simples de logs em estrutura fixa. Cada linha tem data, nível, mensagem. O candidato deve ler um arquivo, filtrar por nível, agrupar por hora e produzir um resumo em JSON. A entrada é pequena, dez linhas no máximo nos testes, então performance não é preocupação. O que se avalia é se a pessoa lê o arquivo corretamente, trata campos ausentes, e estrutura o dado de saída como pedido. Já vi candidatos que não tratam linha vazia e quebram o script inteiro. Isso é informação valiosa.

Uma coisa contra-intuitiva que descobri: questões de debug no terceiro bloco revelam mais sobre o candidato do que a implementação do segundo bloco. Quem consegue encontrar três bugs em cinquenta linhas de código em vinte minutos geralmente tem mais experiência prática do que quem escreveu o código do zero rapidamente. O raciocínio de revertimento é diferente do raciocínio de construção, e ambos importam.

Correção automatizada e limites do método

Para corrigir rápido, você precisa de testes automatizados desde o começo. Não adianta criar a prova e só depois pensar em como corrigir. O processo inverso é muito mais eficiente. Escreva os casos de teste antes de escrever o enunciado. Se você não consegue testar algo automaticamente, provavelmente o enunciado também não está claro o suficiente. Eu uso uma estrutura simples com pytest no Python e mocha no JavaScript. Cada questão tem um arquivo de entrada, um arquivo de saída esperada, e um script de execução. A correção é rodar o script do candidato contra cada caso de teste e contar acertos. Leva cerca de dois minutos para rodar todos os casos de todos os candidatos em uma bateria de dez pessoas. Mas o método tem limitações claras. Prova automatizada não avalia estilo de código, não avalia arquitetura, não avalia se a pessoa escolheu a estrutura de dados errada por preguiça em vez de ignorância. Ela mede se o código passa nos casos que você definiu. Pontos fora desses casos são subjetividade pura, e subjetividade na correção é onde os vieses entram. Se você quer avaliar qualidade além da funcionalidade, precisa de uma etapa adicional de revisão humana, e isso volta a gastar tempo.

Outro problema real: candidatos em ambientes restritos. Já tive um cenário em que a empresa não permitia instalação de dependências e o teste exigia uma biblioteca que eu considerei padrão. O candidato competente ficou travado porque o ambiente corporativo bloqueava tudo. A correção disso é simples: documente claramente quais bibliotecas podem ou não ser usadas, e dê alternativas equivalentes. Não deixe o candidato adivinhar. Se o seu processo precisa avaliar mais do que capacidade técnica pura, considere combinar a prova de linguagens com uma revisão de código ao vivo ou uma discussão técnica de trinta minutos após a correção. A prova sozinha é um instrumento limitado. Ela responde a uma pergunta específica: o candidato consegue traduzir uma especificação em código funcional? A resposta para essa pergunta é importante, mas não é a única que importa. Na prática, o fluxo que mais funciona é: definir competência-alvo, escrever casos de teste primeiro, redigir enunciado a partir dos casos, rodar em lote com correção automática, revisar manualmente apenas as entregas borderline, e complementar com conversa técnica se necessário. Qualquer ordem diferente tende a gerar retrabalho.