Como Agir em Pair Programming sem Entrar em Pânico

O problema

Pair programming costuma assustar porque parece que você precisa pensar, codar, explicar e ainda manter conversa ao mesmo tempo.

Muita gente interpreta isso como obrigação de ser brilhante ao vivo.

Aí trava.

Ou fica muda demais.

Ou fala demais sem sair do lugar.

Modelo mental

Entrevista de pair programming não é show solo.

É uma simulação curta de trabalho conjunto.

O avaliador quer ver se você consegue raciocinar com outra pessoa na mesa sem perder clareza.

O modelo mental bom é:

Você não precisa parecer genial. Precisa parecer colaborável, estruturado e corrigível.

Isso alivia bastante.

Porque muda o foco de “acertar tudo sem hesitar” para “construir uma solução de forma legível e ajustável”.

Quebrando o problema

Comece alinhando o problema

Antes de sair digitando, vale confirmar:

• o que entra
• o que sai
• o que conta como solução válida
• o que pode ser assumido

Isso não é enrolação.

É proteção contra começar errado.

Pense em voz alta, mas com intenção

Falar ajuda o entrevistador a ver seu raciocínio.

Mas falar sem estrutura só aumenta ruído.

Um bom padrão é:

• dizer o caminho que você vai testar
• implementar um pedaço
• validar
• seguir

Trabalhe em incrementos pequenos

Em pair programming, passo pequeno é vantagem.

Você reduz risco de se perder e cria pontos naturais para alinhamento.

Também facilita receber intervenção sem ter que desfazer metade da solução.

Trate interação como parte da tarefa

Se o entrevistador perguntar algo, isso não significa que você falhou.

Muitas vezes ele quer ver:

• se você escuta
• se consegue reconsiderar hipótese
• se defende uma decisão com calma
• se muda de rota sem drama quando faz sentido

Exemplo simples

Imagine um exercício para encontrar o primeiro caractere não repetido de uma string.

Uma condução ruim seria:

• abrir o editor sem confirmar casos básicos
• ficar em silêncio por vários minutos
• escrever uma solução inteira
• perceber tarde que ignorou maiúsculas, vazios ou custo

Uma condução melhor seria:

• confirmar se diferencia maiúsculas de minúsculas
• dizer que vai começar com contagem de frequência
• implementar a contagem
• validar com um exemplo curto
• fazer a segunda passada
• comentar custo e possíveis ajustes

Mesmo que a solução final precise de correção, o sinal é muito melhor.

Erros comuns

• Tentar parecer rápido demais e pular alinhamento.
• Ficar em silêncio esperando acertar tudo sozinho.
• Tratar pergunta do entrevistador como ataque.
• Narrar cada linha irrelevante em vez de explicar decisões.
• Insistir num caminho ruim por apego.

Como um senior pensa

Quem tem mais maturidade costuma proteger três coisas ao mesmo tempo:

• entendimento compartilhado
• progresso visível
• capacidade de correção

O pensamento não é “preciso impressionar”.

É mais:

• qual menor passo útil eu consigo validar agora?
• o que a outra pessoa precisa saber para acompanhar minha linha?
• onde posso checar se ainda estamos resolvendo o problema certo?

Isso deixa a conversa mais estável e o código mais recuperável.

O que o entrevistador quer ver

Ele quer ver se você:

• alinha antes de executar
• comunica raciocínio sem ruído demais
• reage bem a feedback
• mantém progresso mesmo sob pressão
• separa hipótese, implementação e validação

Em pair programming, a entrevista não avalia só resposta.

Ela avalia convivência técnica em miniatura.

Pair programming forte parece colaboração real, não tentativa desesperada de acertar sozinho.

Clareza, adaptação e progresso visível quase sempre contam mais do que brilho performático.