Como é uma entrevista em pair programming

O código de outra pessoa, numa chamada, com o relógio correndo

Uma entrevista pareada de nível pleno raramente te entrega um arquivo em branco. A Camila, uma desenvolvedora Rails pleno entrevistando para uma vaga remota numa empresa da Europa, recebe uma tela compartilhada em vez disso. Um repositório pequeno de faturamento, já clonado, com a suíte de testes já verde. O entrevistador diz algo perto de "aqui está o PriceCalculator: ele funciona, mas um novo tipo de cupom precisa entrar sem quebrar nada que já passa." Ninguém pede para ela inventar um algoritmo do zero. Eles entregam um sistema que já funciona e observam o que ela faz com ele.

# config/routes.rb
resources :invoices, only: [:show]

# app/controllers/invoices_controller.rb
class InvoicesController < ApplicationController
  def show
    @invoice = Invoice.find(params[:id])
    @total = PriceCalculator.calculate_price(@invoice.line_items, @invoice.coupon)
  end
end

O que o entrevistador está avaliando por baixo dos panos

Correção é o mínimo esperado: os testes ainda precisam passar no final. O que separa candidatos nesse nível é como eles leem código que não escreveram e como organizam a mudança depois de entendê-lo. Conta também quão claramente comunicam um plano antes de digitar, e como recebem uma dica ou uma correção sem perder o fio da meada. Casos extremos também importam: uma fatura vazia, um cupom que não corresponde a nenhum tipo conhecido, um desconto que empurraria o total abaixo de zero. Um bom candidato pleno nomeia essas coisas em voz alta antes que o entrevistador precise apontar.

O motorista, o navegador, e as perguntas no meio do caminho

Alguns entrevistadores te deixam como único motorista a sessão inteira. Outros trocam quem está digitando na metade, te colocando no banco de navegador enquanto eles escrevem o próximo pedaço. Os dois formatos testam a mesma coisa por ângulos diferentes: quando você está dirigindo, você consegue narrar uma decisão antes de se comprometer com ela. Quando você está navegando, você consegue ler uma mudança pela metade de outra pessoa e sugerir o próximo passo sem pegar o teclado de volta. De qualquer forma, espere um fluxo constante de perguntas do tipo "por quê". Por que um case em vez de outro elsif, por que extrair esse pedaço e não aquele, por que testar esse caso extremo primeiro. A pergunta não é uma pegadinha: é o entrevistador checando se sua escolha foi deliberada ou só a primeira coisa que veio à cabeça.

O formato varia, a substância continua a mesma

A configuração real muda de empresa para empresa: algumas rodam a sessão num editor compartilhado no navegador, sem nenhum ambiente local para configurar. Outras te mandam um repositório de verdade antes e pareiam numa videochamada enquanto cada um olha o próprio clone. Um editor compartilhado favorece a velocidade, já que não há nada para configurar. Um repositório clonado favorece o realismo, já que você trabalha com seu próprio terminal e seu próprio executor de testes, não com o sandbox de outra pessoa. Nenhum dos dois formatos muda o que está sendo medido por baixo disso. Esteja o código numa aba do navegador ou numa janela de terminal, as regras são as mesmas. O mesmo relógio, a mesma linha de base de testes verdes, e a mesma expectativa de que você narre seu raciocínio.

Duas fases: ler, depois mudar

A maioria das sessões se divide numa fase curta de leitura e numa fase mais longa de execução. Na fase de leitura, você faz perguntas e roda a suíte existente uma vez para confirmar que ela está verde antes de tocar em qualquer coisa. Depois passa os olhos pela estrutura ao redor: o que chama esse método, quais testes já existem para ele. Na fase de execução, você trabalha em passos pequenos, mantém a suíte verde entre cada um deles, e narra enquanto avança. Uma sessão de 45 a 90 minutos não deixa espaço para um trecho longo de silêncio em nenhuma das duas fases. Um entrevistador que vê você pensando por dois minutos inteiros sem dizer nada normalmente vai perguntar o que você está avaliando.

Quando o pedido muda no meio da sessão

Alguns entrevistadores introduzem um requisito novo no meio do caminho ("de agora em diante, o cupom pode ser uma porcentagem acima de 100, então limite em 100"). Eles querem ver se o seu design absorve essa mudança de forma limpa ou força uma reescrita. Um código que já foi refatorado em pedaços pequenos e nomeados absorve esse tipo de mudança numa linha só. Um código deixado como um único método emaranhado normalmente não absorve, e é essa diferença que o entrevistador está observando.

O tema que os entrevistadores continuam repetindo

Os debriefs de entrevista voltam sempre a um ponto. Candidatos que fazem os testes passarem mas deixam o código tão emaranhado quanto encontraram são avaliados para baixo no nível pleno, mesmo quando toda asserção está verde. O critério não é "funcionou": é "você deixou isso em melhor estado, ou pelo menos disse em voz alta quais costuras você extrairia se tivesse mais vinte minutos." Você não precisa extrair tudo no tempo que te deram. Mas precisa nomear o que extrairia.

Perguntas de design dentro da mesma sessão

Algumas sessões pareadas encaixam uma pergunta de design menor ("como você adicionaria uma preferência de notificação à conta de um usuário?") que testa algo um pouco diferente. Você consegue nomear as entidades envolvidas e decidir em voz alta se a lógica pertence a um model, a um service object ou a um controller? E dizer o que testaria primeiro e o que deixaria para depois? A aula 6 deste curso é construída inteiramente em torno desse tipo de pergunta. Por enquanto, só note que uma entrevista pareada e uma pergunta de design são primas próximas, não habilidades separadas.

Pareando em inglês, remotamente

A entrevista da Camila roda em inglês por padrão, como a maioria das vagas remotas, não importa onde cada pessoa mora. Narrar importa mais aqui do que o sotaque jamais vai importar. Talvez você já tenha feito o curso de nível estagiário "Live coding para iniciantes" ou o de nível júnior "Live coding e projetos take-home". Nesse caso, já praticou pensar em voz alta contra o relógio. Este curso presume esse hábito e passa o tempo em material mais difícil. Pedir trinta segundos de leitura silenciosa antes de começar a falar é completamente normal, em inglês ou em português.

Para onde este curso vai

Este curso constrói diretamente em cima de "Perguntas de entrevista para Rails pleno", o curso anterior. Ele presume que você já raciocina sobre trade-offs e consegue defender uma resposta. As aulas colocam isso em prática ao vivo, com um teclado na sua frente. A aula 2 cobre ler código desconhecido rapidamente. Começar pela rota, ler os testes como documentação, e escrever as perguntas que você faria antes de mudar qualquer coisa. A aula 3 cobre refatorar com os testes verdes: testes de caracterização, passos pequenos, e para onde a lógica extraída vai numa aplicação Rails de verdade. A aula 4 coloca as duas coisas em prática no próprio PriceCalculator, e carrega o único desafio de código deste curso. A aula 5 cobre explicar trade-offs em voz alta, e a aula 6 cobre desenhar uma feature pequena na hora. A aula 7, uma sessão pareada completa, junta tudo isso.