Como criar um teste de programação

What you'll need

• Um espaço de trabalho SkillCort (ou uma demonstração)
• Um exemplo real do código que a sua equipa escreve — um erro, uma pequena funcionalidade, uma refactorização
• Um engenheiro sénior para definir a tarefa e a grelha
• Uma decisão sobre que linguagens vai aceitar

Step 1: Escolha uma tarefa realista em vez de um puzzle de algoritmos

Veja o último mês de pull requests e escolha uma tarefa com a forma das que se repetem: corrigir um erro a partir de um comportamento defeituoso, estender uma pequena função para tratar um novo caso, refactorizar um bloco confuso ou escrever uma transformação de dados. Estas predizem o desempenho do dia a dia muito melhor do que inverter uma árvore binária.

Dimensione-a para 30–45 minutos de trabalho concentrado de uma contratação competente. Um puzzle recompensa quem o ensaiou; uma pequena tarefa realista recompensa quem consegue ler a intenção existente, fazer uma alteração sólida e manter o código compreensível — que é para isso que está a contratar.

Retire o conhecimento específico de frameworks e da empresa, a menos que a função o exija mesmo, e forneça dentro do próprio enunciado todo o contexto de que a tarefa precisa. Um bom engenheiro que nunca tocou na sua stack deve ainda assim conseguir mostrar-lhe um juízo sólido. Teste a capacidade, não a familiaridade com as curiosidades do seu código.

• Repete-se no seu código real, não nos livros de preparação para entrevistas
• Tem mais do que uma solução razoável
• Cabe em 30–45 minutos sem heroicidades
• Legível por um avaliador em menos de dez minutos

Step 2: Crie o item de código na biblioteca de itens

Crie uma pasta para a função — Engenheiro de Backend, por exemplo — com etiquetas para a área de capacidade e a dificuldade, e depois crie um item com o tipo de item de código. Os candidatos escrevem e editam código diretamente na área de resposta, e os avaliadores revêem-no depois no mesmo sítio.

Prepare o item com código inicial em vez de um editor em branco. Uma função curta com um erro descrito, ou um esboço com um contrato claro, ancora todos os candidatos ao mesmo ponto de partida e torna as suas alterações diretamente comparáveis. O trabalho real quase nunca começa num ficheiro vazio, e o teste também não deve começar.

Step 3: Escreva o enunciado ao lado do editor

Use a disposição de estímulo lado a lado: o enunciado, os requisitos e os exemplos de entradas e saídas de um lado, o editor de código ao lado. O candidato nunca se afasta da especificação para escrever a solução — a mesma forma que trabalhar a partir de um ticket num IDE.

Escreva o enunciado como se lê um bom ticket: comportamento atual, comportamento esperado, restrições e dois ou três exemplos concretos. Indique explicitamente o que lhe interessa — «primeiro código a funcionar; também lemos em busca de clareza» — para que os candidatos otimizem aquilo que vai de facto pontuar. A ambiguidade no enunciado torna-se ruído nos resultados.

Step 4: Construa uma grelha que pontue mais do que a correção

O resultado correto é necessário, não suficiente. Construa uma grelha matricial por níveis com três ou quatro critérios — tipicamente correção, legibilidade e abordagem, opcionalmente o tratamento de casos-limite — cada um com descrições ancoradas do que é código forte, aceitável e fraco. «Os nomes revelam a intenção, não há código morto» é pontuável; «código limpo» não é.

Pondere a correção com o maior peso, mas mantenha os outros critérios reais: uma solução que mal funciona e que ninguém consegue manter não é um bom sinal de contratação. Quando associa a grelha, esta congela num instantâneo, pelo que todos os candidatos da execução são revistos segundo a mesma norma, mesmo que a versão do banco evolua mais tarde.

Step 5: Monte e limite o tempo no builder

Crie a avaliação em secções, páginas e blocos e importe o item de código através da janela de seleção. Muitas equipas acrescentam uma primeira secção curta de perguntas rápidas de juízo — ler um diff, detetar o erro num excerto, colado rapidamente como escolha múltipla — e colocam a tarefa de programação na sua própria secção.

Defina o limite de tempo total com folga para ler e pensar e use um limite por página na página de programação, para que a tarefa não engula a tentativa inteira. Pondere a secção de programação com o maior peso (por exemplo ×3), para que a adequação à função no Decision Board reflita o trabalho e não o aquecimento. Escreva instruções que indiquem as linguagens permitidas e o que acontece se o tempo acabar.

Step 6: Pré-visualize, cumpra a lista de verificação e publique

Use o Preview as candidate e faça você mesmo a tarefa ou, melhor ainda, peça a um engenheiro que não a escreveu que a faça sem preparação. Se terminar em dez minutos, é demasiado fácil; se não conseguir terminar dentro do limite, alargue o âmbito ou o relógio. Corrija o enunciado onde quer que tenha hesitado.

Depois cumpra a lista de verificação de publicação — ela bloqueia Publish até a pontuação, os tempos e as instruções estarem completos. Um teste de programação sem grelha ou com um limite de tempo por testar nunca deve chegar a um candidato, e a lista de verificação faz com que não chegue.

Step 7: Defina controlos de integridade proporcionais ao risco

Crie a aplicação com um nome e uma janela temporal e escolha depois os interruptores de segurança de forma deliberada. Para uma triagem normal de contratação, o bloqueio de copiar/colar e o bloqueio de ecrã inteiro com um limite de infrações sensato costumam bastar. A gravação de webcam, a gravação de ecrã, a deteção de segundo ecrã e as verificações de identidade existem para execuções de risco verdadeiramente elevado — certificações, rondas finais —, não como predefinições.

Tudo o que ativar é comunicado no ecrã de consentimento e de verificação prévia antes de o candidato começar. Os sinais de integridade são sinalizações para uma pessoa rever em contexto, nunca fundamento para rejeição automática — uma saída de ecrã inteiro pode ser uma notificação, não uma fraude. A proporcionalidade evita que bons candidatos desistam perante uma rede de vigilância.

Step 8: Reveja o código com a grelha, com a IA como apoio

Os avaliadores revêem cada submissão segundo a grelha partilhada, clicando no cartão de nível que corresponde ao código em cada critério — correção, legibilidade, abordagem. Colocar dois revisores nos casos limítrofes ou de risco elevado mantém a norma honesta e, como toda a gente pontua segundo o mesmo instantâneo congelado da grelha, as discordâncias surgem como lacunas concretas num critério, e não como diferenças vagas de intuição.

A IA pode esboçar um resumo da submissão e sugerir pontuações ao nível do critério — uma primeira passagem genuinamente útil sobre código, com o modelo e a versão registados para memória futura. Mas é um engenheiro identificado pelo nome que confirma ou substitui todas as pontuações. Aqui a IA é apoio à decisão, nunca quem decide: o juízo responsável sobre o código de um candidato é sempre humano.