Quarenta e cinco minutos, um editor partilhado, um desconhecido a observar cada tecla e um problema nunca visto: inverter uma lista ligada, encontrar o subarray com a soma máxima. Sem documentação, sem pesquisa, às vezes nem sequer autocompletar. E ainda te pedem para "pensar em voz alta". É o live coding, e em muitos processos de seleção continua a ser o momento que decide tudo.
Sou contra. Não por ser difícil, mas porque mede a coisa errada. Já fiz entrevistas dos dois lados da mesa e noutro artigo escrevi como mudaria as perguntas técnicas na era da IA. Aqui vou direto ao assunto: porque é que o live coding clássico não funciona, o que concedo a quem o defende e o que faria no seu lugar.
De que live coding estou a falar
Primeiro, uma distinção. Sou contra o exercício algorítmico cronometrado, observado em direto, sem ferramentas, sobre um problema sem relação com o trabalho, cujo resultado decide sozinho se avanças ou não. Não sou contra trabalhar em conjunto com um candidato numa tarefa realista, com documentação e ferramentas à disposição, para ver como raciocina. Parecem a mesma coisa, mas não são: volto a isto no fim.
Mede o stress, não a competência
Não é só uma impressão. Em 2020, investigadores da North Carolina State University e da Microsoft publicaram um estudo controlado com 48 estudantes de informática: metade resolveu um problema no quadro diante de um entrevistador, metade sozinha, numa sala privada. Quem estava a ser observado teve resultados mais de duas vezes piores. Os autores notam que o formato se parece de forma inquietante com o Trier Social Stress Test, um protocolo usado em psicologia precisamente para induzir stress.
O estudo é pequeno e foi feito com estudantes, por isso não o tomo como lei. Mas confirma o que qualquer pessoa que já passou por uma entrevista conhece bem: sob observação, a memória de trabalho encolhe, perde-se o fio, erram-se coisas banais que em condições normais nunca se errariam. O resultado não responde à pergunta "sabe programar?", mas a outra: "quão bem programa enquanto alguém o julga em direto?". E no trabalho real essa situação não existe.
O trabalho real não se parece com um live coding
| No live coding | No trabalho real |
|---|---|
| 45 minutos para um problema nunca visto | Horas ou dias, com tempo para perceber o problema |
| Sem documentação nem pesquisa | Documentação, pesquisa e exemplos sempre abertos |
| Assistente de IA proibido | Assistente de IA no editor, todos os dias |
| Um desconhecido a observar cada tecla | Concentração, e a review chega depois |
| Algoritmos de manual | Ler código existente, integrar APIs, corrigir bugs |
| Conta chegar a uma solução | Contam a legibilidade, os testes e a manutenção ao longo do tempo |
Quem for contratado vai passar os dias a ler código escrito por outros, a escolher uma biblioteca, a perceber porque é que um teste só falha em CI. Avaliá-lo pela capacidade de implementar de memória um algoritmo, em meia hora e debaixo dos olhos de alguém, é medir uma competência que vai usar raramente, nas condições em que nunca vai trabalhar.
Premeia quem treina para o formato, não quem trabalha bem
O live coding algorítmico tornou-se uma disciplina à parte, com plataformas, cursos e centenas de exercícios para repetir até os reconhecer à primeira vista. Quem tem semanas livres para treinar chega preparado. Quem trabalha a tempo inteiro, tem família ou simplesmente passa o tempo a construir software a sério em vez de resolver puzzles parte em desvantagem. No fim, a entrevista seleciona sobretudo a preparação para a entrevista.
E penaliza de forma sistemática algumas pessoas: quem sofre de ansiedade, quem é neurodivergente, quem faz a entrevista numa língua que não é a sua e tem de pensar em voz alta enquanto traduz na própria cabeça. Nada disto diz alguma coisa sobre como essa pessoa vai escrever código numa equipa.
Também custa à empresa
Normalmente fala-se do candidato, muito menos da empresa. Cada falso negativo é um programador competente rejeitado porque bloqueou durante dez minutos. E quem tem experiência e alternativas, muitas vezes, evita por completo um processo com live coding: a empresa nem chega a ver esses candidatos.
Há também um efeito menos visível. Ao observar alguém sob pressão, o entrevistador acaba por avaliar a segurança mais do que a substância: quem fala com desenvoltura parece melhor do que quem se cala e pensa. É um enviesamento que existe em qualquer entrevista, mas este formato amplifica-o.
O que concedo a quem o defende
- Verificar que uma pessoa sabe mesmo programar é legítimo. Um currículo pode ser inflacionado, e hoje até um exercício para fazer em casa pode ser resolvido por uma IA.
- Os trabalhos de casa longos têm um custo real: horas de trabalho não pago, muitas vezes desproporcionadas em relação à posição.
- O live coding é barato e uniforme: o mesmo exercício para todos, uma hora e está feito.
São objeções sérias. Mas a resposta a "temos de verificar as competências" não pode ser um formato que as mede mal. É preciso um formato que verifique a mesma coisa sem a parte que distorce o resultado.
O que faria no seu lugar
- Code review de código real. Um excerto plausível, com um bug e algumas escolhas discutíveis, para comentar como se fosse a pull request de um colega. Vê-se logo quem percebe o código, e ninguém tem de escrever sob ditado.
- O projeto do candidato. Um repositório, um trabalho anterior, um projeto pessoal: "explica-me esta escolha", "o que mudarias hoje?". Uma experiência vivida aguenta cinco perguntas de aprofundamento; uma história decorada cai à segunda.
- Uma tarefa curta para casa, seguida de uma discussão. Duas ou três horas no máximo, pagas se possível, e depois uma conversa em que o candidato explica e altera a própria solução. Se foi uma IA a escrevê-la e ele não a percebe, bastam poucos minutos de perguntas para o notar.
- Pair programming numa tarefa realista. Se se quer mesmo ver alguém a escrever código: um pequeno repositório real, documentação e IA permitidas, nenhum cronómetro sobre o resultado. O entrevistador trabalha com o candidato em vez de o vigiar.
- Uma sessão de debugging. Um teste que falha e o tempo para perceber porquê: é o mais próximo de um dia normal de trabalho.
Se o live coding fica, pelo menos assim
Percebo que nem todas as empresas mudem o processo de um dia para o outro. Se o live coding fica, há algumas regras mínimas que o tornam menos injusto:
- comunicar com antecedência o formato, a duração e a linguagem;
- escolher um problema ligado ao trabalho, não um quebra-cabeças de manual;
- permitir documentação e pesquisa, como em qualquer dia normal;
- avaliar o raciocínio, não só o resultado final;
- dar ao candidato alguns minutos para ler e pensar em silêncio antes de lhe pedir que fale.
E se o candidato és tu
Podes pedir, com delicadeza, uma alternativa: uma code review, a discussão de um projeto teu, uma tarefa curta para fazer em casa. Nem todas as empresas vão aceitar, mas pedir não custa nada. E a resposta já diz muito sobre a forma como trabalham: uma empresa que não sabe explicar porque usa um certo formato provavelmente nunca se fez essa pergunta.
Em resumo
Sou contra o live coding clássico porque mede como uma pessoa aguenta o stress de ser observada, não como trabalha. É um mau negócio para o candidato e também para a empresa, que rejeita pessoas competentes e seleciona quem treinou para o formato. As alternativas existem e verificam a mesma coisa, ou seja, se uma pessoa sabe programar, sem distorcer o resultado. Reuni mais ideias sobre como renovar as entrevistas técnicas neste artigo, e se estás a preparar uma entrevista encontras as perguntas técnicas organizadas por nível no guia das 25 perguntas de entrevista frontend/Angular.
