Live coding versus take-homes

De perguntas de conceito a trabalho de verdade

O curso anterior, "Perguntas de entrevista para Rails júnior", percorreu a conversa técnica. Alguém pergunta como é um ciclo de requisição, ou como uma validação impede uma linha ruim de chegar ao banco, e você já consegue sustentar essa conversa. A maioria dos processos seletivos de Rails acrescenta mais uma etapa depois dela. Em vez de falar de código, alguém te entrega uma tarefa e pede que você produza código.

Essa etapa tem dois formatos. Numa sessão de live coding, você escreve código em voz alta numa chamada enquanto alguém assiste. Num projeto take-home, você constrói algo no seu tempo e entrega para avaliação. Este curso cobre os dois, porque um processo para júnior de Rails pode te dar qualquer um deles, e os dois recompensam instintos quase opostos.

O que uma sessão de live coding testa

Uma rodada de live coding põe você num editor compartilhado, em geral no navegador e não na sua máquina, com alguém assistindo em tempo real. Às vezes há uma chamada de vídeo. Às vezes a pessoa só vê o código aparecer. O enunciado quase sempre cabe em 30 a 45 minutos: transformar uma coleção, interpretar uma string, implementar um algoritmo pequeno.

Raramente se mede se você chega à solução mais rápida. Mede-se se você pensa em voz alta enquanto digita, mantém a calma quando a primeira abordagem falha, testa o código com alguns exemplos antes de dar por terminado e aceita uma dica sem desmoronar. Quem escreve uma solução certa e calada em 40 minutos muitas vezes vai pior do que quem explica uma solução um pouco mais áspera. A pessoa que entrevista está imaginando como seria parear com você numa tarefa na próxima terça.

O que um projeto take-home testa

Um take-home tira a plateia e acrescenta escopo. Você recebe uma especificação escrita, às vezes um parágrafo e às vezes um documento inteiro com exemplos de entrada e saída, e alguns dias para construir algo. Pode ser uma feature pequena de Rails, um endpoint de API ou, de vez em quando, um app pequeno inteiro.

Ninguém vê você digitar, então o que uma sessão ao vivo não consegue medir vira o centro da avaliação. Você lê a especificação direito e constrói o que ela pede, e não o que você supôs? Você administra o próprio tempo sem um relógio correndo? Você escreve testes, ou a única prova de que o código funciona está na sua cabeça? O seu README diz a quem avalia o que você construiu e por quê, ou a pessoa precisa deduzir as suas decisões a partir de um diff? Um take-home é avaliado pela entrega, além da correção.

As mesmas habilidades, pressões diferentes

Dá vontade de tratar os dois como habilidades sem relação para estudar separado, mas eles têm a mesma espinha. Os dois começam com uma especificação que você não escreveu e precisa entender antes de mexer no código. Os dois recompensam uma fatia vertical pequena e funcionando em vez de uma grande pela metade. Os dois esperam que você teste o que construiu em vez de supor que funciona.

O que muda é a pressão. O live coding espreme tudo em meia hora visível, com alguém acompanhando o seu raciocínio. O take-home estica tudo em dias sem supervisão, e quem avalia só vê o resultado e o que você escreveu sobre ele. Fique bom em ler uma especificação e entregar uma fatia pequena e correta, e você cobre quase tudo o que qualquer formato pede. O resto é saber que comportamentos importam mais quando alguém está olhando e quando ninguém está.

Como se preparar para qualquer um dos dois

A preparação para os dois formatos se sobrepõe mais do que parece. Praticar problemas pequenos sem relógio cria a memória muscular que uma rodada ao vivo depois exige com o relógio correndo. Praticar os mesmos problemas contra uma contagem regressiva, mesmo uma que você mesmo define, cria a segunda habilidade: lidar com a pressão quando é o relógio, mais que o problema, que deixa você nervoso.

Para take-homes, a melhor prática não é resolver algoritmos sem parar. Construa uma feature pequena de ponta a ponta a partir de uma especificação que você mesmo escreve, e depois avalie o próprio README e os testes como um estranho faria. Eles convenceriam alguém que nunca falou com você de que você sabe o que está fazendo? Nenhum formato pune quem se preparou para o outro, porque a sobreposição é grande. Um hábito ajuda nos dois. Depois de terminar um problema de prática, escreva uma frase sobre o que você teria dito em voz alta ou posto num README. A maioria pula essa frase na prática e depois se atrapalha com ela de verdade, sob pressão.

Qual dos dois você vai encontrar

Se um processo usa live coding, take-home, os dois ou nenhum varia de empresa para empresa, e o tamanho da empresa não prevê isso. Uma startup de cinco pessoas pode pular os dois e conversar sobre o seu histórico no GitHub. Um time maior pode fazer uma rodada ao vivo e ainda pedir um take-home pequeno antes da oferta. O que não varia é o que cada formato checa quando aparece, e é por isso que este curso trata os dois lado a lado.

O que este curso cobre

Aula 2 - Construindo uma feature Rails com tempo limitado: scaffold ou
          escrito à mão, bin/rails g, migrations, params.expect, e uma
          checagem com Minitest, tudo sob um relógio visível ou
          autoimposto.
Aula 3 - Lendo a especificação de um take-home: transformar um enunciado
          escrito numa lista de tarefas curta, identificar ambiguidade,
          e decidir o que está dentro do escopo.
Aula 4 - Problemas com Enumerable e Hash: group_by, tally,
          each_with_object, sum, sort_by, transform_values, filter_map
          — mais um desafio de código que você entrega e recebe uma
          nota.
Aula 5 - Testes e um README que impressionam: o que quem revisa
          lê, e como escrever os dois para suas decisões
          sobreviverem sem você estar na sala.
Aula 6 - Entregando e a call de revisão: higiene de commits, como
          entregar, e a chamada em que alguém pede para você defender
          ou expandir o que você construiu.
Aula 7 - Take-home: juntando tudo, e o que vem depois.

No fim deste curso, você terá escrito uma feature pequena de Rails contra o relógio e resolvido um problema de Enumerable e Hash com o tipo de correção que uma plataforma de live coding usa. Também vai saber o que quem avalia procura nos seus testes e no seu README antes de você entregar um de verdade. Nada disso exige mais conhecimento de Rails do que os cursos anteriores deram. Exige usar bem um tempo limitado, que é a habilidade que os dois formatos testam.