O que acontece numa sessão de live coding

Imagine uma prova de culinária. Ninguém te entrega uma prova escrita sobre técnica de faca. Colocam você na frente de um fogão com uma receita curta e observam você cozinhar enquanto explica o que está fazendo e por quê. Isso está muito mais perto do live coding que qualquer prova de escola. Você não está provando que decorou um livro. Está mostrando, em tempo real, como pensa quando constrói algo pequeno e ele não funciona de primeira.

Esta aula percorre uma dessas sessões do começo ao fim, para o formato em si não surpreender. O curso anterior tratou da triagem técnica em geral. Este foca nos quinze a trinta minutos dentro dela em que você escreve código enquanto alguém observa.

O cenário: um editor compartilhado no navegador

A maioria das rodadas de live coding de nível inicial acontece num editor compartilhado no navegador: uma ferramenta que abre por um link, não precisa de instalação e mostra o seu código aos dois enquanto você digita. Há uma área de texto, um botão "Run" e um painel de saída que mostra o que o código imprimiu ou devolveu. O entrevistador vê cada tecla, e muitas dessas plataformas gravam a sessão para ela ser vista de novo depois.

Isso importa por dois motivos. Primeiro, você não consegue colar uma solução pronta e fingir que escreveu ao vivo; um bloco grande de texto aparecendo de uma vez é o que essas ferramentas destacam. Segundo, o ambiente costuma ser mínimo: sem gems, sem bibliotecas externas, às vezes sem busca na web, só a biblioteca padrão. Se o enunciado diz "Ruby", conte com Array, Hash, String e afins, e nada além disso, a menos que digam o contrário.

Layout típico de um editor compartilhado
-------------------------------------
| Enunciado / descrição do problema  |
|-------------------------------------|
| def solve(input)                    |
|   # seu código aqui                 |
| end                                  |
|-------------------------------------|
| [ Rodar ]         Saída:             |
|                   (aparece aqui)     |
-------------------------------------

O formato do exercício

No nível de estágio e de primeira vaga júnior, os enunciados de live coding são pequenos: inverter uma string, contar a frequência de palavras, conferir se um número é primo, achar a palavra mais longa de uma frase. Ninguém espera uma aplicação completa em vinte minutos. O entrevistador testa três habilidades. Você transforma uma descrição em português simples em poucas linhas corretas? Explica o seu raciocínio o tempo todo? E, só em terceiro lugar, sabe a sintaxe?

Um exercício costuma chegar em etapas. Primeiro vem uma versão inicial ("escreva um método que inverta uma string"). Quando ela funciona, uma continuação acrescenta um detalhe ("agora faça sem o reverse embutido" ou "agora trate entrada nil"). Esse aumento é proposital. Testa se você entendeu a primeira solução ou teve sorte.

O que o entrevistador observa

Quatro coisas, e nenhuma é "a resposta certa no menor número de linhas":

1. Você narra enquanto trabalha? Dois minutos digitando em silêncio é o motivo mais comum de uma solução correta parecer uma entrevista fraca. A próxima aula trata disso a fundo.
2. Você esclarece antes de mergulhar? Começar a programar num enunciado ambíguo ("a string tem pontuação? diferencia maiúsculas?") diz mais que qualquer erro de sintaxe.
3. Você testa o que escreveu? Rodar o código em alguns exemplos, inclusive um caso-limite como string vazia, antes de dar por terminado é um hábito que os entrevistadores procuram.
4. Como você reage quando algo quebra? Quase todo mundo esbarra num bug ou num caminho errado. Manter a calma, dizer "isso não está certo, deixa eu ver por quê" e resolver vale mais que nunca ter errado.

O que uma rodada de live coding não é

Não é um teste de múltipla escolha cronometrado nem um take-home que você termina sozinho. Ninguém espera que o primeiro rascunho rode limpo; código real raramente roda, e entrevistadores também erram na digitação. Neste nível também não é uma maratona de algoritmos. É muito improvável você implementar uma árvore rubro-negra ou raciocinar sobre Big O na primeira triagem de estágio. Se acontecer, isso diz que o processo da empresa não combina com a vaga, e não que você está atrasado.

Uma linha do tempo realista

Num trecho de quinze a vinte e cinco minutos, espere uns dois minutos para o entrevistador apresentar o enunciado e para as suas perguntas de esclarecimento. Depois, dez a quinze minutos programando com conversa, e alguns minutos no fim para rodar a solução em exemplos e talvez estendê-la. É uma janela curta. Trinta segundos em silêncio no começo custam uma parte visível do tempo que você tem para mostrar o seu raciocínio.

Para onde este curso vai

Esta aula deu o mapa: um editor compartilhado, um enunciado pequeno em etapas e quatro coisas observadas: narração, esclarecimento, testes e calma diante de um bug. O resto do curso transforma cada uma numa habilidade:

• Aula 2: pensar em voz alta, o hábito que muda como todo o resto é lido.
• Aula 3: esclarecer o problema antes de escrever uma linha.
• Aula 4: os aquecimentos clássicos com strings e arrays, resolvidos em Ruby.
• Aula 5: testar o próprio código ao vivo, como o entrevistador espera.
• Aula 6: o que fazer no momento em que você trava.
• Aula 7: uma sessão simulada completa que junta tudo, mais um desafio de código.

Na aula 7, o formato vai parecer uma conversa ensaiada, e não uma prova a que você torce para sobreviver.