Em resumo
- Confirme critérios, tempo disponível e ferramentas permitidas antes de começar.
- No live coding, esclareça o problema, implemente uma solução pequena e mostre como a verificou.
- No take-home, combine o limite de esforço e entregue algo que outra pessoa consiga executar e avaliar.
- Prepare-se para explicar decisões, limitações e o que mudaria com um requisito novo.
Neste artigo
O convite chega com uma frase curta: “A próxima etapa será um teste técnico”. Você abre o editor, separa exercícios e percebe que ainda falta a informação principal: haverá alguém acompanhando o código ou uma entrega para fazer em casa? Essa diferença muda o treino, o uso do tempo e a forma de mostrar seu trabalho.
Live coding é a programação realizada durante a avaliação, com acompanhamento em tempo real. Take-home challenge é um desafio assíncrono, feito no período combinado e entregue para revisão. Este guia mostra como se preparar para os dois: primeiro, com uma função pequena resolvida ao vivo; depois, com uma aplicação de chamados que cabe em um exercício de seleção. Os exemplos são didáticos e devem ser adaptados ao enunciado recebido.
Antes de estudar, confirme o que será avaliado
Uma avaliação pode pedir algoritmos, correção de um defeito, interface, consultas SQL ou implementação de uma API. O título da vaga ajuda a formular perguntas, mas não substitui a orientação da empresa. Solicite o formato, a duração, os critérios e o ambiente. Para uma entrega assíncrona, separe prazo de envio de esforço esperado: ter cinco dias no calendário não informa quantas horas a tarefa deveria consumir.
Mensagem para alinhar a etapa
“Obrigado pelo convite. Poderiam confirmar o formato, a duração ou esforço esperado e os critérios de avaliação? Há linguagem ou ambiente obrigatório? Posso consultar documentação, pesquisar e usar assistentes de IA? Para a entrega, qual é o prazo com fuso horário e como devo compartilhar o repositório?”
Se precisar de uma adaptação de acessibilidade, explique o recurso necessário com antecedência. Em chamada remota, confira microfone, compartilhamento de tela e como retomar o contato se a conexão cair. Se houver uma plataforma de código, use o ambiente de demonstração disponibilizado pela empresa para conhecer os controles antes da avaliação.
| Ponto | Live coding | Take-home challenge |
|---|---|---|
| Tempo | Uma sessão com duração definida | Prazo de envio e limite de esforço a combinar |
| Comunicação | Perguntas e decisões durante a resolução | Hipóteses, decisões e limitações registradas na entrega |
| Treino | Resolver e explicar usando o ambiente previsto | Construir, revisar e executar a partir das próprias instruções |
| Risco a observar | Programar antes de esclarecer a regra | Ampliar o projeto além do pedido e perder o prazo |
| Fechamento | Demonstrar comportamento, testes e pendências | Enviar acesso, instruções e um retrato fiel do que funciona |
Há formatos híbridos. O handbook de entrevistas técnicas do GitLab (abre em nova aba) descreve uma revisão prévia seguida de conversa e alterações no código. Já a orientação técnica da Microsoft (abre em nova aba) enfatiza esclarecer ambiguidades, planejar e testar. São exemplos de processos específicos: use as instruções da sua avaliação para definir o treino.
Live coding: transforme o enunciado em uma sequência de decisões
Considere este exercício: “Receba uma lista de itens de um pedido e devolva a quantidade total de cada produto”. Parece direto, mas faltam regras. O mesmo produto pode aparecer mais de uma vez? A chave é o nome ou o SKU, o código do produto? Quantidades negativas são válidas? A ordem de saída importa? Essas respostas determinam o comportamento que você precisa implementar.
Você pode propor um contrato simples: cada item contém um SKU textual e uma quantidade inteira positiva; SKUs iguais representam o mesmo produto; maiúsculas e minúsculas são diferentes; a saída preserva a ordem da primeira aparição. Entrada vazia produz saída vazia. Se um item for inválido, a função rejeita a entrada inteira com um erro. Confirme essas hipóteses antes de usá-las. Se o enunciado trouxer outras regras, elas têm prioridade.
| Entrada | Resultado esperado | O que verificar |
|---|---|---|
| A: 2, B: 1, A: 3 | A: 5, B: 1 | Soma por SKU e ordem da primeira aparição |
| Lista vazia | Lista vazia | Ausência de itens |
| A: 1, a: 2 | A: 1, a: 2 | Diferença entre maiúsculas e minúsculas |
| A: 0 | Erro de validação | Quantidade deve ser positiva |
| SKU ausente, quantidade 2 | Erro de validação | Identificador obrigatório |
Explique a estratégia em poucas frases: “Vou validar os itens e acumular as quantidades por SKU. Preciso manter também a ordem em que cada código aparece. No fim, monto a saída nessa ordem.” Um mapa com ordem de inserção pode atender às duas necessidades; em outra estrutura, uma lista auxiliar pode guardar a ordem. Confira o comportamento da linguagem usada, em vez de presumir que todo dicionário oferece as mesmas garantias.
Implemente o caminho principal e execute o primeiro exemplo. Depois verifique entrada vazia e erro. Se a função imprimir A: 3 em vez de A: 5, mostre a hipótese: “Estou substituindo o total quando encontro o SKU novamente. Vou conferir a atualização do acumulador.” Essa explicação permite acompanhar a investigação sem exigir que você narre cada tecla.
Na discussão de custo, uma passagem com consultas e atualizações de tempo constante esperado em uma tabela hash leva a O(n) operações esperadas para n itens, tratando o tamanho das chaves como limitado. O armazenamento depende de u SKUs distintos: O(u), além da saída. Se a solução escolhida procura cada SKU em uma lista crescente, o custo pode chegar a O(n²). Explique a hipótese por trás da análise e relacione a escolha ao volume informado.
Organize o tempo e torne o bloqueio específico
Em uma simulação de 45 minutos, você pode reservar 5 para esclarecer o contrato, 5 para exemplos e estratégia, 25 para implementar e 10 para testar e discutir limites. Essa divisão é uma sugestão de treino. Ajuste-a à duração real, ao tamanho do problema e à conversa; ela não é um critério de seleção da empresa.
Quando travar, reduza o caso. No agrupamento de itens, comece com dois registros do mesmo SKU e acompanhe o acumulador após cada passo. Diga qual informação está faltando: “Entendi a soma, mas preciso confirmar a ordem da saída”. Uma dúvida específica dá à pessoa entrevistadora uma oportunidade de orientar a conversa. Você também pode pedir um minuto para organizar o raciocínio antes de continuar.
Se o tempo acabar, apresente o estado real: “O agrupamento e a ordem estão funcionando nos exemplos executados. Falta validar quantidades inválidas. Eu começaria por um teste com zero e outro com número fracionário.” Evite anunciar uma solução completa quando uma regra ainda está pendente. A aprovação depende dos critérios do processo; essa forma de fechar permite avaliar o que você efetivamente entregou.
Quiz rápido
Faltam dez minutos e o exemplo principal funciona. A validação ainda não foi verificada. Qual é a melhor prioridade para este exercício?
Take-home: defina uma entrega que caiba no esforço combinado
Imagine um desafio para criar uma fila de chamados: cadastrar título e descrição, listar os registros, filtrar por status e concluir um chamado aberto. Antes de escolher bibliotecas, transforme o pedido em comportamentos verificáveis. Um título vazio será aceito? Concluir um chamado já concluído retorna sucesso ou erro? Os dados devem persistir ao reiniciar a aplicação? Se o enunciado não responder, pergunte ou documente uma hipótese quando não houver retorno a tempo.
| Parte | Entrega | Como conferir |
|---|---|---|
| Cadastro | Título obrigatório, descrição e status inicial aberto | Criar um chamado e tentar enviar título vazio |
| Listagem | Mostrar os registros e filtrar por status | Comparar o filtro com uma base pequena conhecida |
| Conclusão | Alterar aberto para concluído | Concluir, consultar de novo e repetir a ação |
| Persistência | Usar o mecanismo pedido ou a hipótese documentada | Reiniciar e verificar o comportamento declarado |
| Limites | Registrar decisões sobre autenticação e concorrência | Conferir se os limites respeitam o enunciado |
Se a tarefa pede apenas uma API, concentre o esforço em contratos, validação, persistência e testes. Se pede uma interface com API fornecida, cuide também dos estados de carregamento, erro e lista vazia. Recursos como notificações, anexos e painel administrativo podem esperar quando estiverem fora do enunciado. Se autenticação for obrigatória, ela faz parte da entrega: uma limitação no README não substitui um requisito solicitado.
Para um teto hipotético de quatro horas, uma organização possível é usar meia hora para ler e configurar, duas horas para o fluxo principal, uma hora para testes e correções e meia hora para revisar instruções e enviar. A proposta serve para planejar um treino com esse limite. Se os requisitos não couberem no esforço informado pela empresa, peça prioridade ou redução de escopo antes de começar.
Mantenha a entrega executável ao longo do trabalho. Conclua um caminho pequeno, confira o resultado e então avance. Antes de adicionar outra biblioteca, consiga explicar qual necessidade ela resolve e o que exige de quem vai rodar o projeto. Uma tecnologia conhecida costuma reduzir o tempo gasto com configuração; se a avaliação exigir uma ferramenta nova, reserve tempo para aprendê-la e confirme a profundidade esperada.
Escreva um README que permita revisar o projeto
A pessoa avaliadora abre o repositório e precisa descobrir como começar. A documentação do GitHub sobre README (abre em nova aba) destaca essa função de apresentar o projeto e orientar seu uso. No desafio, acrescente o contexto necessário para interpretar suas decisões. Escreva as instruções enquanto trabalha, para não tentar reconstruir a configuração nos últimos minutos.
| Seção | Conteúdo do exemplo |
|---|---|
| Objetivo | Fila de chamados com cadastro, filtro por status e conclusão. Exercício de seleção com dados fictícios. |
| Pré-requisitos | Informe versões, gerenciador de pacotes e serviços realmente necessários. |
| Execução | Liste os comandos exatos para instalar, configurar, preparar os dados e iniciar. Informe endereço e porta. |
| Configuração | Explique cada variável exigida e forneça um arquivo de exemplo sem credenciais reais. |
| Verificação | Informe o comando dos testes, os casos cobertos e um roteiro curto de uso manual. |
| Decisão | Exemplo: repetir a conclusão mantém o chamado concluído, conforme a hipótese adotada para a ação. |
| Limitação | Exemplo, se verdadeiro: atualizações concorrentes ainda não são tratadas. Descreva o efeito dessa restrição. |
| Próximo passo | Indique a primeira melhoria ligada a uma limitação concreta e como verificaria seu resultado. |
Os exemplos de decisão e limitação acima precisam corresponder ao código entregue. Se você escolheu retornar erro ao repetir uma conclusão, documente essa regra. Se tratou concorrência, explique a abordagem e como a verificou. O README deve permitir confrontar a descrição com o comportamento da aplicação.
Revise em uma cópia limpa do projeto, seguindo os próprios comandos. Confira se um arquivo local ignorado pelo Git era necessário, se a base precisa de preparação e se o repositório tem as permissões de acesso corretas. Um link de demonstração pode complementar a entrega; as instruções locais continuam úteis quando a hospedagem falha ou expira.
Escolha testes que respondam às regras do desafio
Na fila de chamados, criar um registro válido cobre o caminho principal. Título vazio, identificador inexistente e conclusão repetida verificam outros pontos do contrato. No filtro por status, use uma base com chamados abertos e concluídos e compare o resultado esperado. Se houver autenticação, confira também quem pode consultar ou alterar cada registro.
Distribua os testes conforme o risco: uma regra isolada pode ser verificada diretamente; a gravação e a leitura exigem conferir a integração com a persistência; uma interação essencial pode merecer teste de interface. Se a empresa especificar tipos de teste ou cobertura, siga o requisito. Sem essa exigência, explique quais comportamentos você protegeu e quais ainda não verificou.
Combine consulta, pesquisa e IA separadamente
Poder consultar documentação não significa poder pedir uma solução a um assistente. Confirme as regras para pesquisa, autocompletar e geração de código. No treino, use assistência para receber uma pergunta por vez ou encontrar um caso que seu teste deixou escapar. Depois resolva uma variação sem ajuda e confira se consegue explicar as escolhas.
Quando IA for permitida na avaliação, siga a forma de declaração solicitada e revise o resultado. Esteja pronto para explicar uma sugestão que aceitou, uma que rejeitou e como verificou o código final. Se a ferramenta estiver proibida, ajuste o editor antes da sessão. Evite enviar enunciados confidenciais, código privado ou dados de terceiros a serviços externos sem autorização.
Prepare a conversa sobre o que você entregou
Abra a apresentação com um fluxo curto: crie um chamado, filtre a lista e conclua o registro. Em seguida, mostre uma decisão e seu teste. “Repetir a conclusão mantém o estado atual; este caso verifica a regra” é uma explicação que pode ser conferida no projeto. Deixe a navegação por pastas para quando ela ajudar a responder uma pergunta.
Prepare-se para uma mudança de requisito: agora duas pessoas podem editar o mesmo chamado. O que precisaria mudar? Identifique o ponto afetado e discuta uma alternativa, sem afirmar que a solução já cobre o cenário. Também vale explicar por que adiou uma melhoria e qual evidência faria você retomá-la.
No envio, facilite a revisão: “Segue a entrega no repositório indicado. O README contém execução, testes e decisões. Implementei cadastro, filtro e conclusão. A limitação conhecida é descrita na seção correspondente.” Ajuste a mensagem ao que foi concluído e informe pendências relevantes. Depois da conversa, anote uma dificuldade técnica e uma de comunicação para trabalhar no próximo treino.
Escolha agora um dos exemplos deste artigo e simule o formato que você vai enfrentar. Ao terminar, verifique se outra pessoa conseguiria acompanhar o raciocínio ou executar a entrega pelas instruções. Para organizar as demais etapas do processo, continue no guia de entrevista técnica de desenvolvedor.
Perguntas frequentes
Como treinar live coding sem alguém para entrevistar?
Escolha um problema pequeno, defina um limite de tempo e explique em voz alta contrato, estratégia e verificação. Se ajudar, grave seu próprio treino e depois observe onde começou a programar sem esclarecer a regra ou deixou de testar. Refaça com uma mudança de requisito e compare o raciocínio.
Quanto tempo devo dedicar a um take-home challenge?
Use o esforço combinado com a empresa. O prazo de envio, por si só, não define horas de trabalho. Se o enunciado parecer incompatível com esse limite, peça prioridades ou proponha um recorte antes de começar. As quatro horas do exemplo deste artigo são uma hipótese de treino, não um padrão do mercado.
É melhor entregar incompleto ou perder o prazo tentando terminar?
Avise assim que identificar o risco e pergunte sobre extensão ou ajuste de escopo. Se o prazo permanecer, envie pelo canal combinado uma descrição fiel do que funciona e do que falta. Requisitos pendentes podem afetar a avaliação; esconder a incompletude impede uma revisão adequada.
O repositório do teste técnico deve ser público?
Siga a instrução da empresa. Um repositório privado exige conceder acesso à pessoa ou equipe indicada; um público pode expor enunciado e materiais que não deveriam ser divulgados. Confirme a permissão antes de publicar e revise arquivos, dados e credenciais antes do envio.