reunião como dev junior: como participar sem travar

Reunião assusta muita gente no primeiro emprego tech porque parece uma prova oral escondida.

Você entra na call com pessoas mais experientes, siglas do produto, ticket antigo, decisão de arquitetura, urgência de cliente, tela compartilhada e alguém pergunta: “faz sentido para você?”. A resposta automática vira “sim”, mesmo quando metade ainda está nebulosa.

O problema não é ser junior. O problema é não ter um método para participar.

Dev junior não precisa dominar todos os assuntos da reunião. Precisa chegar minimamente preparado, avisar o que entendeu, perguntar cedo quando o contexto está faltando, registrar decisão e sair com próximo passo claro. Isso vale para daily, refinamento, planning, 1:1, review de incidente, reunião com produto e call de pareamento.

Se você está começando agora, combine este guia com primeira semana como dev junior, daily standup para dev junior e anotações de trabalho para dev junior. Reunião boa não depende de carisma. Depende de preparação simples.

antes da reunião: descubra qual é o tipo de conversa

Nem toda reunião pede o mesmo comportamento.

Antes de entrar, olhe o convite, o canal ou a mensagem que originou a call e tente classificar:

Se você não sabe o tipo, pergunte antes ou no começo:

Só para eu me orientar: essa reunião é mais para decisão, alinhamento de contexto ou desbloqueio técnico?

Essa frase parece simples, mas evita muita ansiedade. Você para de tentar adivinhar se deveria opinar, apenas ouvir, trazer dado ou sair com tarefa.

prepare três coisas em cinco minutos

Você não precisa montar uma apresentação para toda call. Mas precisa entrar com algum contexto.

Cinco minutos antes, anote:

1. o assunto principal: ticket, PR, bug, demanda, decisão ou tema;
2. o que você já sabe: estado atual, tentativa feita, arquivo afetado, dúvida aberta;
3. o que você precisa sair sabendo: próximo passo, prioridade, responsável, critério de pronto.

Exemplo:

Ticket: ajuste no fluxo de cadastro. Sei: o erro acontece quando o usuário volta da etapa 2 para a etapa 1; reproduzi em local; ainda não entendi se o comportamento esperado é manter ou limpar os dados. Preciso: confirmar regra de produto antes de mexer no formulário.

Isso já é suficiente para falar com clareza quando alguém chamar seu nome.

Se a reunião envolve código, abra o PR, o ticket e o arquivo principal. Se envolve produto, abra a tela ou print. Se envolve carreira, abra suas anotações da semana. Entrar só com memória aumenta a chance de responder vago.

como falar sem discursar

Junior muitas vezes acha que precisa provar inteligência falando muito. O efeito costuma ser o contrário: a pessoa se perde, mistura contexto com justificativa e não entrega a informação que o time precisa.

Use este formato:

Contexto curto + estado atual + dúvida ou próximo passo.

Exemplos:

Peguei o ticket de validação do formulário. Consegui reproduzir o erro e achei que ele vem da regra de limpeza do estado. Minha dúvida é se a regra esperada é manter os dados ao voltar ou limpar tudo.

No PR do filtro, ajustei os testes unitários e falta validar no fluxo real. Depois da reunião vou rodar o caso de busca vazia e atualizar a descrição do PR.

Ainda estou sem clareza sobre a prioridade entre o bug do checkout e o ajuste visual. Posso seguir no bug primeiro e deixar o visual para depois?

Esse formato mostra maturidade porque separa fato, hipótese e pedido.

quando perguntar durante a reunião

A pergunta certa na hora certa economiza dias.

Pergunte quando:

• uma sigla impede você de entender a decisão;
• o critério de pronto ficou ambíguo;
• duas pessoas parecem discordar, mas ninguém nomeou a diferença;
• você recebeu uma tarefa sem saber prioridade;
• a discussão mudou de escopo e isso afeta seu ticket;
• você percebe que sairia da reunião sem próximo passo.

Perguntas úteis:

Quando vocês dizem “validar no legado”, é em qual tela ou fluxo?

O critério de pronto é só corrigir o erro atual ou também cobrir com teste?

Essa decisão vale só para este ticket ou vira padrão para casos parecidos?

Quem fica responsável por confirmar essa regra com produto?

Posso repetir o que entendi para ver se está certo?

A última é especialmente forte. Ela transforma confusão em alinhamento:

Entendi que eu vou ajustar o fallback no backend, manter a mensagem atual no frontend e abrir um PR pequeno até amanhã. É isso?

Se a resposta for “não”, ótimo. Você descobriu antes de implementar errado.

quando ficar em silêncio

Participar bem não significa falar em toda reunião.

Fique mais quieto quando:

• a discussão é entre pessoas responsáveis por uma decisão de produto que você ainda não conhece;
• a reunião é de incidente e você não tem dado novo;
• duas pessoas estão alinhando prioridade acima do seu escopo;
• você está ouvindo contexto pela primeira vez.

Mas silêncio bom não é ausência. É escuta ativa com anotação.

Anote termos, decisões, dúvidas e nomes. Se algo ficou obscuro, pergunte no final ou mande follow-up no canal:

Saí com uma dúvida sobre o fluxo de cancelamento. Pelo que entendi, a regra nova vale para cliente ativo e trial. Confere?

Isso é melhor do que interromper toda frase para provar presença.

como discordar sendo junior

Você pode discordar. Só precisa separar observação de conclusão.

Ruim:

Acho que isso está errado.

Melhor:

Posso estar deixando passar contexto, mas no teste local esse caminho quebra quando o usuário não tem endereço cadastrado. Faz sentido validar esse caso antes de fechar a abordagem?

Ruim:

Não acho que dá para fazer hoje.

Melhor:

Pelo que entendi, tem ajuste no backend, frontend e teste de regressão. Eu consigo começar hoje, mas tenho dúvida se cabe completo até o fim do dia sem cortar validação. Qual parte é prioritária?

Discordância boa traz evidência, limite e pergunta. Não traz ego.

Isso vale ainda mais em remoto. Tom curto demais pode soar seco. Texto longo demais pode parecer defesa. Se você quer melhorar essa parte, leia também rotina de trabalho remoto para junior e como pedir mentoria sendo dev junior.

cuidado com o “sim” automático

O “sim” automático nasce do medo de parecer perdido.

Ele parece educado na hora, mas cria três problemas:

1. você sai sem entender;
2. o time acha que houve alinhamento;
3. o erro aparece depois, no PR ou na entrega.

Troque por respostas mais honestas:

Entendi a ideia geral, mas ainda não entendi o detalhe da regra.

Preciso olhar o código antes de confirmar prazo.

Acho que consigo, mas quero validar a dependência com o backend primeiro.

Posso anotar como hipótese e confirmar depois no canal?

Isso não diminui você. Pelo contrário: pessoa confiável não finge certeza quando ainda está descobrindo.

registre decisão, não só conversa

Depois da reunião, escreva o que ficou decidido.

Pode ser no ticket, no PR, no canal do time ou nas suas anotações. O importante é não depender da memória.

Modelo simples:

Resumo da call:

• vamos manter os dados do formulário ao voltar da etapa 2 para 1;
• erro de validação aparece só depois do primeiro submit;
• eu fico com ajuste frontend + teste do fluxo principal;
• dúvida separada sobre analytics fica para outro ticket.

Esse hábito evita retrabalho e mostra profissionalismo. Dev junior que registra decisão parece mais organizado, mesmo quando ainda está aprendendo a parte técnica.

Se a reunião gerou tarefa para você, coloque uma próxima ação visível:

Próximo passo: abrir PR pequeno até amanhã com a regra confirmada e teste do caso de retorno.

Se gerou bloqueio:

Bloqueio: preciso da resposta de produto sobre comportamento para conta sem endereço antes de finalizar.

Não espere alguém pedir relatório. Dê visibilidade antes do ruído.

erros comuns em reunião de dev junior

Alguns erros aparecem muito no começo:

• dizer “sim” sem entender;
• ficar calado por medo e depois trabalhar no escuro;
• transformar atualização curta em monólogo;
• pedir desculpa antes de toda pergunta;
• discutir solução antes de entender problema;
• não anotar decisão;
• sair sem dono, prazo ou próximo passo;
• esconder bloqueio para parecer autônomo;
• levar feedback técnico como ataque pessoal.

O antídoto é menos dramático do que parece: preparar contexto, falar curto, perguntar cedo e registrar depois.

um roteiro para sua próxima reunião

Use este roteiro na próxima call:

Antes:

• Qual é o assunto?
• Qual é meu papel?
• O que já tentei ou preciso saber?

Durante:

• Fale em contexto + estado + dúvida.
• Peça definição de termos que bloqueiam entendimento.
• Repita decisões importantes para confirmar.
• Anote dono, prazo e critério de pronto.

Depois:

• Escreva resumo curto.
• Atualize ticket ou PR.
• Faça follow-up da dúvida aberta.
• Transforme aprendizado recorrente em anotação reutilizável.

Reunião não é palco. É ferramenta de coordenação.

Quando você entende isso, para de tentar parecer experiente e começa a parecer confiável. Para dev junior, confiabilidade é vantagem enorme: o time sabe o que você está fazendo, onde travou, o que entendeu e o que vai entregar em seguida.

Se a reunião foi ruim, não conclua que você é ruim. Faça debrief: qual contexto faltou, qual pergunta você deveria ter feito, qual decisão não ficou registrada e como evitar isso na próxima. O guia de debrief de teste técnico junior usa a mesma lógica para processos seletivos: menos culpa, mais ajuste.

E se você quer treinar comunicação sem esperar uma call importante, escreva um resumo assíncrono por dia. Uma boa atualização de texto vira boa fala ao vivo. O site Golang Brasil também tem tutoriais úteis para transformar decisões técnicas em código pequeno, testável e revisável.