Como se Comportar durante Live Coding: o que Falar e quando Pausar

O problema

Live coding costuma deixar a pessoa presa entre dois medos ruins:

• ficar em silêncio e parecer perdida
• falar sem parar e parecer caótica

Os dois geram sinal ruim.

No primeiro, o entrevistador não sabe o que você está pensando.

No segundo, o entrevistador até sabe, mas preferia não saber tanto.

Modelo mental

Live coding não é podcast.

Também não é prova escrita em silêncio.

É colaboração com ritmo.

O modelo melhor é:

alternar alinhamento, pensamento curto, implementação e validação.

Esse ritmo passa três sinais bons ao mesmo tempo:

• você sabe enquadrar
• você sabe pausar sem sumir
• você sabe sair da pausa com direção

Quebrando o problema

O que falar no começo

No começo, o ideal é verbalizar só o suficiente para construir chão comum:

• o que entra
• o que sai
• qual caminho inicial você quer testar
• qual baseline parece mais segura

Isso evita abrir o editor no escuro.

Quando pausar

Pausa é boa quando você precisa:

• escolher entre duas abordagens
• organizar estado
• pensar no caso de borda
• decidir estrutura de dados

Mas a pausa forte é curta e anunciada.

Algo como:

“Vou parar 20 segundos para organizar a abordagem e já volto com o plano.”

Isso é muito melhor do que desaparecer em silêncio absoluto.

O que falar depois da pausa

O ideal não é voltar com uma tese.

É voltar com direção.

Por exemplo:

• “Vou começar com a solução simples para validar o caminho”
• “Acho que aqui um Hash Map resolve o lookup sem segunda passada”
• “Vou separar parsing de regra para não me perder na função principal”

Perceba a diferença.

Você não voltou só para preencher o ar.

Você voltou com uma decisão.

O que não vale a pena narrar

Muita coisa é barulho:

• “agora vou abrir uma chave”
• “agora vou declarar uma variável”
• “agora vou descer a linha”

Isso não mostra julgamento.

Só mostra que você está digitando.

O que vale narrar é:

• mudança de estratégia
• hipótese
• trade-off
• validação
• risco percebido

Como validar durante

Esperar o final para testar tudo é arriscado.

Melhor fazer checkpoints pequenos:

• caso simples
• caso de borda
• custo principal
• ajuste rápido se algo quebrou

Isso faz a sessão parecer controlada.

Exemplo simples

Imagine um live coding de busca em lista com filtro e paginação.

Uma condução fraca seria:

• começar a escrever UI e fetch sem alinhar fluxo
• falar cada linha que digita
• perceber tarde que esqueceu debounce, cancelamento ou reset de página

Uma condução melhor seria:

1. alinhar rapidamente o fluxo
2. dizer que vai montar primeiro a baseline funcional
3. pausar 20 segundos para decidir estado mínimo
4. implementar busca e paginação
5. validar o reset da página quando o filtro muda
6. comentar onde colocaria cancelamento ou debounce se sobrasse tempo

O código pode até acabar parecido.

O sinal não.

Erros comuns

• Tentar preencher cada segundo com fala.
• Ficar em silêncio longo sem avisar.
• Narrar teclado em vez de narrar decisão.
• Perceber bug e fingir que não percebeu.
• Insistir em fluxo confuso em vez de parar e reorganizar.

Como um senior pensa

Quem tem mais maturidade costuma proteger o ritmo da sessão.

O pensamento é mais ou menos:

• o que o entrevistador precisa saber agora?
• isso pede fala ou pede 20 segundos de silêncio útil?
• qual é o menor checkpoint que me devolve controle?

Esse é um ponto importante.

Live coding forte não parece improviso frenético.

Parece progresso administrado.

O que o entrevistador quer ver

Ele quer ver se você:

• alinha antes de sair digitando
• sabe pausar sem evaporar
• volta da pausa com decisão concreta
• valida cedo
• reage bem quando algo falha

Uma frase simples costuma ajudar muito:

“Vou pensar em silêncio por alguns segundos para não começar num caminho ruim.”

Isso transmite autocontrole, não fraqueza.

Em live coding, silêncio curto com intenção vale mais do que fala constante sem direção.

O objetivo não é parecer rápido o tempo todo. É parecer legível sob pressão.