primeiros 30 dias como dev junior: como ganhar confiança no time

A primeira semana como dev junior é sobre sobreviver ao onboarding sem fingir que entendeu tudo. Os primeiros 30 dias são outra fase: você precisa deixar de ser apenas “a pessoa nova” e começar a virar alguém confiável dentro do time.

Confiável não significa rápido. Não significa saber a arquitetura inteira. Não significa resolver sozinho um bug que até pleno evita.

Confiável, para dev junior, significa que o time consegue prever seu jeito de trabalhar: você comunica bloqueio cedo, pergunta com contexto, aceita review, fecha tarefas pequenas, registra decisão e melhora um pouco toda semana.

Esse é o objetivo dos primeiros 30 dias.

Se você ainda está no começo absoluto, leia primeiro o guia de primeira semana como dev junior. Aqui a conversa começa depois do setup local, da primeira daily e talvez do primeiro pull request.

a meta real dos primeiros 30 dias

Em 30 dias, ninguém espera que você vire especialista no produto. Mas dá para esperar quatro resultados claros:

1. você entende o fluxo básico do produto ou serviço onde está mexendo;
2. você já abriu pelo menos alguns PRs pequenos;
3. você sabe quem procurar para dúvidas de produto, código, infra e processo;
4. você recebeu feedback e ajustou comportamento.

O erro comum é achar que o mês 1 precisa provar genialidade. Não precisa. Precisa provar curva de aprendizado.

Uma boa pergunta para guiar o mês é:

O que eu faço hoje que deixa o time um pouco mais confortável em me passar a próxima tarefa?

Essa pergunta é melhor do que “como impressionar?” porque coloca foco em confiança, não em performance teatral.

semana 2: transforme contexto solto em mapa

Na segunda semana, você provavelmente já tem acessos, sabe onde ficam os canais e conseguiu rodar parte do sistema. Agora precisa organizar o contexto.

Crie um mapa pessoal com quatro blocos:

Produto
- que problema resolve?
- quem usa?
- quais fluxos principais?
- quais métricas importam?

Sistema
- repositórios principais
- serviços que conversam entre si
- banco/dados relevantes
- ambientes: local, staging, produção

Processo
- como ticket vira PR?
- quem revisa?
- como deploy acontece?
- como incidente é comunicado?

Pessoas
- gestor
- buddy
- tech lead
- produto/design
- pessoa de infra ou dados

Não é documentação oficial. É seu mapa de sobrevivência. Ele evita que cada tarefa pareça um universo novo.

Quando ouvir uma sigla, nome de serviço ou regra de negócio, anote. Depois pergunte:

Vi vocês falando de billing-worker e core-api. Minha leitura é que o worker processa eventos assíncronos depois que a API recebe a ação do usuário. É isso mesmo?

Esse tipo de pergunta mostra esforço. Você não está pedindo uma aula do zero; está validando uma hipótese.

escolha tarefas que ensinam o fluxo inteiro

Nos primeiros 30 dias, uma tarefa pequena que passa por todo o fluxo vale mais do que uma tarefa grande travada no meio.

Boas tarefas de começo:

• corrigir mensagem de erro;
• ajustar validação simples;
• escrever teste para comportamento existente;
• melhorar README de setup;
• adicionar campo pequeno em tela interna;
• resolver bug fácil de reproduzir;
• melhorar log ou tratamento de exceção.

O objetivo é aprender o caminho completo: branch, commit, teste, PR, review, ajuste, merge e deploy.

Se você pega uma tarefa gigante cedo demais, fica preso em contexto, insegurança e dependência de outras pessoas. Quando uma tarefa parecer grande, peça um recorte:

Posso começar com uma parte menor para passar pelo fluxo de PR e receber feedback antes de mexer no restante?

Isso é maturidade. Time bom prefere junior que reduz risco a junior que promete heroísmo.

peça feedback antes de virar problema

Muita gente espera a avaliação formal para descobrir se está indo bem. Isso é tarde demais.

Na segunda ou terceira semana, peça feedback curto para seu gestor ou buddy:

Queria calibrar cedo meu onboarding.

Até agora, tem algo que eu deveria ajustar em comunicação, ritmo de entrega ou forma de pedir ajuda?

Se tiver um ponto pequeno para corrigir já, prefiro saber agora do que esperar a avaliação formal.

Essa mensagem é forte porque tira peso do feedback. Você não está pedindo validação emocional; está pedindo correção de rota.

Se o feedback vier genérico, peça exemplo:

Quando você diz que posso dar mais visibilidade, seria mandar atualização diária no canal da squad ou detalhar melhor o PR?

Feedback sem exemplo vira ansiedade. Exemplo vira ação.

use 1:1 sem desperdiçar a conversa

Se a empresa tem 1:1 com gestor, não use só para dizer “tudo certo”. Leve pauta.

Exemplo de pauta para os primeiros 30 dias:

1:1 - primeiros 30 dias

- O que estou entendendo bem: fluxo X, repo Y, processo de PR
- Onde ainda estou fraco: regra de negócio Z, testes, deploy
- Bloqueios: acesso A, contexto B
- Próxima meta: fechar uma task pequena sem ajuda direta
- Pergunta: o que você espera que eu esteja fazendo com mais autonomia no fim do mês?

Essa última pergunta é ouro. Ela transforma expectativa invisível em critério explícito.

Se não existe 1:1 formal, peça uma conversa curta de 15 minutos depois das primeiras semanas. Não precisa dramatizar:

Posso marcar 15 min para calibrar meu primeiro mês e entender onde focar mais?

crie um plano de estudos conectado ao trabalho

Junior costuma estudar errado no primeiro mês. Vê Docker no trabalho, abre curso de Kubernetes. Vê um erro de SQL, compra trilha completa de dados. Vê React, começa a estudar toda a história do frontend.

O estudo precisa seguir a demanda real do time.

Monte uma lista em três camadas:

Agora
- coisa que bloqueia minha task atual

Este mês
- ferramenta que aparece toda semana no trabalho

Depois
- assunto importante, mas não urgente

Exemplo:

Agora: entender migration do banco local
Este mês: escrever testes de integração do projeto
Depois: Docker Compose mais avançado

Se a stack usa Python para scripts, APIs ou automações, faz sentido revisar base com material prático em português, como guias de Python para desenvolvimento. Mas o estudo precisa voltar para o trabalho: melhorar um teste, entender uma função, depurar um erro real.

Estudar por vaidade dá sensação de progresso. Estudar conectado à task gera progresso visível.

comunique progresso pequeno

No remoto ou híbrido, o time não vê você pensando. Ele vê mensagens, PRs, comentários e entregas.

Uma atualização boa no fim do dia pode ser simples:

Update rápido:
- consegui reproduzir o bug 234 localmente
- descobri que acontece quando o usuário não tem telefone cadastrado
- amanhã vou ajustar a validação e adicionar teste
- sem bloqueio agora

Ou, se houver bloqueio:

Update:
- avancei até a chamada da API externa
- estou bloqueado porque meu token de sandbox retorna 403
- já pedi acesso no canal #infra
- enquanto isso, vou escrever o teste do caso local

Isso reduz ansiedade do gestor e mostra que você não sumiu.

O guia de trabalho remoto para junior aprofunda essa parte. No primeiro mês, comunicação vale quase tanto quanto código.

aprenda a receber review sem se defender

Review de código não é julgamento moral. É o jeito normal de código ficar melhor.

Resposta ruim:

Fiz assim porque no tutorial era assim.

Resposta melhor:

Boa. Eu não tinha considerado esse caso. Vou ajustar e adicionar teste.

Resposta ruim:

Mas funciona aqui.

Resposta melhor:

Entendi. Você quer que eu siga o padrão do arquivo X para manter consistência, certo?

Quando não entender o comentário, pergunte. Mas pergunte sem transformar tudo em debate:

Não entendi totalmente o risco desse null aqui. Pode me dar um exemplo de entrada que quebraria?

Review é onde junior aprende padrão real do time. Leia comentários em PRs de outras pessoas também. Você vai descobrir estilo, preferências, armadilhas e decisões que nunca aparecem no README.

não tente virar dono de tudo no mês 1

Existe uma ansiedade específica de junior bom: querer compensar insegurança pegando tudo.

Cuidado com frases como:

• “pode deixar comigo” para tarefa sem entender escopo;
• “eu resolvo isso hoje” sem reproduzir bug;
• “posso pegar mais uma” quando a primeira ainda não fechou;
• “deixa que eu refatoro” antes de saber por que o código está daquele jeito.

Ambição é boa. Falta de controle de escopo não é.

A frase madura é:

Consigo pegar, mas quero primeiro confirmar o tamanho. Vou investigar por uma hora e volto com estimativa.

Ou:

Prefiro fechar esse PR e receber review antes de abrir outro, para não espalhar contexto.

Isso mostra prioridade.

acompanhe suas próprias evidências

Mantenha um log pessoal simples. Não para se vigiar. Para não esquecer progresso.

Semana 1
- setup local funcionando
- primeiro PR aberto
- entendi fluxo de login

Semana 2
- corrigi bug 123
- aprendi padrão de teste X
- recebi feedback para atualizar daily com mais detalhe

Semana 3
- peguei task com menos ajuda
- revisei PR de documentação
- entendi deploy de staging

Esse log ajuda em 1:1, avaliação, currículo futuro e LinkedIn. Ele também combate a sensação de “não fiz nada” que aparece quando tudo ainda parece difícil.

Se você ainda está buscando a primeira vaga, use a mesma lógica na planilha de candidaturas: evidência, status, próximo passo. Depois que entra, a planilha vira log de evolução.

sinais de alerta no primeiro mês

Nem todo desconforto é problema. Começar é desconfortável mesmo. Mas alguns sinais merecem atenção:

• ninguém sabe dizer o que você deve fazer;
• você fica dias sem feedback em PR;
• só recebe tarefa urgente e mal explicada;
• perguntas são tratadas como incômodo;
• não existe ambiente para testar;
• o time espera autonomia de pleno pagando e contratando como junior;
• toda dúvida vira humilhação.

Se aparecer um ou dois sinais, tente resolver com comunicação: peça prioridade, contexto, pareamento, feedback. Se o padrão persistir, registre. Junior também precisa avaliar empresa.

O guia sobre fake junior fala disso antes da contratação, mas alguns sinais só aparecem depois.

checklist do dia 30

No fim do primeiro mês, mande um resumo objetivo para gestor ou buddy:

Resumo dos primeiros 30 dias:

- Entregas: PRs #12, #18 e #21
- Contexto entendido: fluxo de cadastro e painel interno
- Ainda preciso evoluir: testes de integração e regra de negócio de cobrança
- Feedback recebido: comunicar bloqueio mais cedo; já ajustei nas dailies
- Próximo foco sugerido: pegar uma task pequena em [área] com menos acompanhamento

Se fizer sentido, queria alinhar o que seria uma boa evolução para os próximos 30 dias.

Pouca gente faz isso. E é exatamente por isso que funciona.

Você não está pedindo aplauso. Está mostrando gestão de si mesmo.

a régua certa

Os primeiros 30 dias como dev junior não são sobre provar que a empresa não errou ao contratar você. Esse pensamento coloca você em modo defesa o tempo inteiro.

A régua melhor é: ao fim do mês, o time consegue confiar que você aprende em público, comunica cedo e entrega pedaços pequenos com cuidado?

Se sim, você está no caminho.

O primeiro emprego em tech é menos sobre saber tudo e mais sobre virar uma pessoa com quem dá para construir. Código importa, claro. Mas no começo, reputação nasce de previsibilidade: aparecer, perguntar bem, testar, registrar, corrigir, agradecer review e voltar melhor no próximo PR.

Você não precisa parecer pleno em 30 dias. Precisa mostrar que, daqui a 90, vai ser muito mais útil do que era no dia 1. O próximo passo é usar os primeiros 90 dias como dev junior para ganhar autonomia sem pular etapa.