período de experiência como dev junior: como passar sem viver em pânico

Período de experiência assusta porque parece uma prova silenciosa. Você entrou na vaga júnior, assinou contrato, ganhou acesso, conheceu o time, mas a cabeça continua repetindo: “e se me mandarem embora antes dos 90 dias?”.

Essa ansiedade é comum. Principalmente quando é primeiro emprego tech, estágio que virou efetivação, transição de carreira ou primeira vaga CLT depois de muito processo seletivo. Você passou por CV, entrevista, teste técnico, talvez indicação, talvez meses de candidatura. Agora parece que qualquer erro pequeno pode apagar tudo.

Calma.

O período de experiência não deveria ser um reality show corporativo. Na prática, ele é um trecho de calibração: a empresa observa se a contratação faz sentido, e você observa se o ambiente permite aprender, entregar e crescer sem virar refém de medo. O objetivo não é parecer pleno em três meses. É deixar evidências de que você aprende, comunica, corrige rota e fica mais útil a cada semana.

Se você ainda está no começo absoluto, leia também o guia de primeira semana como dev junior. Para organizar o mês inicial, use primeiros 30 dias como dev junior. Este texto foca no medo específico do contrato de experiência: como atravessar os 90 dias sem transformar tudo em ameaça.

entenda o que está sendo avaliado de verdade

Muita gente acha que o período de experiência mede velocidade técnica. Mede um pouco, mas não só isso.

Para uma pessoa júnior, o time costuma observar quatro coisas:

1. treinabilidade: você escuta, testa, pergunta e ajusta;
2. comunicação: você avisa bloqueio antes de virar atraso;
3. responsabilidade: você cuida do básico sem precisar de cobrança constante;
4. evolução visível: você não repete o mesmo erro do mesmo jeito por semanas.

Isso não significa que código não importa. Importa. Só que código de junior vem dentro de um pacote maior. Uma pessoa que demora um pouco mais, mas registra tentativa, pede review com contexto e melhora depois do feedback, passa mais confiança do que alguém que some por dois dias tentando provar genialidade.

O risco não é não saber. A empresa já sabia que você não sabia tudo. O risco é esconder o que não sabe até virar problema para o time.

troque medo por rastro

Ansiedade cresce no vazio. Quando você não registra nada, fica difícil mostrar progresso. Aí qualquer conversa com gestor parece julgamento total.

Monte um rastro simples desde a primeira semana:

Semana:
- tarefas entregues ou avançadas
- bloqueios que avisei cedo
- feedback recebido
- feedback aplicado
- dúvidas importantes respondidas
- coisa que entendo melhor agora
- próximo ponto de evolução

Isso não é relatório para encher agenda. É memória de trabalho. Se alguém perguntar “como você acha que está indo?”, você não responde só “acho que bem”. Você responde com evidência.

Exemplo:

Nas últimas duas semanas eu consegui abrir três PRs pequenos no fluxo de cadastro.
No primeiro, recebi comentário sobre validação duplicada.
No segundo, já evitei repetir isso e pedi review mais cedo.
Ainda estou lento para entender regra de negócio, então combinei de validar hipótese no ticket antes de codar.

Perceba a diferença. Você não está vendendo perfeição. Está mostrando processo.

Se você precisa de um sistema para isso, use o guia de anotações de trabalho para dev junior. Ele ajuda a transformar setup, tarefa, feedback e 1:1 em material útil.

peça feedback antes do susto

O pior momento para descobrir que algo incomoda o time é na semana 11.

Não espere a conversa formal do fim da experiência. Depois de duas ou três semanas, peça feedback curto. Não precisa ser dramático.

Script simples:

Queria calibrar como estou indo nesse começo.
Tem algum comportamento ou ponto técnico que você acha importante eu ajustar agora, antes de virar padrão?

Essa pergunta é melhor do que “estou indo bem?”. “Bem” gera resposta vaga. “O que ajustar agora?” convida a pessoa a ser específica.

Na 1:1, leve três blocos:

• o que você entregou;
• onde você travou;
• que ajuste quer fazer na próxima semana.

Se a empresa não tem 1:1 formal, peça uma conversa curta. Dez ou quinze minutos bastam. O guia de 1:1 como dev junior aprofunda esse ritual.

Feedback cedo reduz surpresa. Também mostra maturidade: você não está esperando alguém te salvar, nem tentando adivinhar tudo sozinho.

cuidado com o teatro de produtividade

Medo de demissão faz junior tentar compensar com teatro.

Teatro de produtividade aparece assim:

• aceitar tarefa sem entender escopo;
• prometer prazo agressivo para parecer confiante;
• ficar online até tarde sem necessidade;
• abrir PR grande demais para “mostrar serviço”;
• esconder dúvida porque “já perguntei ontem”;
• responder tudo rápido e pensar pouco;
• estudar dez assuntos fora do trabalho para aliviar culpa.

Isso parece esforço, mas costuma gerar mais risco. Você se cansa, erra mais, comunica pior e cria expectativa falsa.

No período de experiência, o melhor sinal não é heroísmo. É previsibilidade.

Previsibilidade é dizer:

Minha leitura é que essa tarefa tem três partes: ajustar validação, atualizar teste e revisar mensagem de erro.
Consigo começar pela validação hoje e mando update no fim da tarde.
Se eu perceber que o teste exige mexer em outro módulo, aviso antes de seguir.

Isso passa mais segurança do que “deixo pronto hoje” quando você não sabe o tamanho real.

Se você ainda trava para falar progresso e bloqueio, leia daily standup para dev junior. Daily bem feita diminui a pressão acumulada no fim da semana.

aprenda a distinguir erro normal de sinal de risco

Erro no começo é normal. Sinal de risco é padrão repetido sem correção.

Erro normal:

• quebrar setup local e pedir ajuda com log;
• receber review sobre teste faltando;
• interpretar regra de negócio errado uma vez;
• demorar mais que o previsto na primeira tarefa parecida;
• precisar de explicação sobre fluxo do produto.

Sinal de risco:

• sumir quando trava;
• discutir todo feedback como se fosse ataque;
• repetir o mesmo comentário em PRs diferentes;
• não testar mudança básica;
• prometer entrega e não avisar atraso;
• não anotar decisão e perguntar a mesma coisa várias vezes;
• tratar tarefa pequena como favor pessoal do time.

Se aparecer um sinal de risco, não entre em modo desespero. Transforme em plano.

Exemplo:

Percebi que recebi comentário de teste em três PRs.
Vou criar um checklist antes de abrir review: cenário feliz, erro esperado, caso vazio e regressão principal.
No próximo PR, queria validar se esse checklist já melhora a qualidade.

Isso muda a conversa. Você não está negando o problema. Está mostrando que sabe converter crítica em comportamento.

O guia de code review como dev junior ajuda bastante aqui, porque review repetido é uma das fontes mais claras de sinal durante a experiência.

Se parte do risco vem de base técnica fraca, escolha estudo conectado ao trabalho real. Para quem está em stack com scripts, APIs ou automações em Python, por exemplo, materiais práticos em Python Brasil ajudam mais quando viram teste, bug corrigido, README melhor ou pergunta mais clara no PR. Estudo solto alivia ansiedade por uma noite; estudo aplicado muda a percepção do time.

se a empresa sinalizar dúvida, peça critério concreto

Às vezes a empresa dá um alerta: “precisamos ver mais evolução”, “sua autonomia ainda está abaixo”, “vamos acompanhar mais de perto”.

É ruim de ouvir. Mas ainda é melhor do que silêncio.

Não responda com defesa longa. Faça a conversa virar critério.

Perguntas úteis:

Quais comportamentos específicos vocês precisam ver mudar nas próximas semanas?

Que tipo de entrega mostraria que estou no caminho certo?

Existe algum exemplo recente em que minha comunicação ou execução ficou abaixo do esperado?

Podemos combinar um check-in em duas semanas para avaliar se ajustei esse ponto?

Você precisa sair da conversa com algo mais concreto que “melhorar autonomia”. Autonomia pode significar mil coisas: quebrar tarefa, avisar bloqueio, testar antes de review, entender produto, escrever update, reduzir dependência do buddy.

Critério concreto permite ação concreta.

Depois da conversa, mande um resumo curto por escrito:

Obrigado pela conversa de hoje.
Minha leitura dos pontos combinados:
- avisar bloqueio no mesmo dia;
- abrir PRs menores;
- validar regra de negócio antes de implementar;
- usar checklist de teste antes do review.

Vou aplicar isso nas próximas duas semanas e levo evidências no próximo check-in.

Isso protege você de interpretação solta e mostra seriedade.

não ignore o seu lado da avaliação

Período de experiência não é só a empresa avaliando você. Você também avalia a empresa.

Observe:

• existe alguém para tirar dúvida sem humilhar?
• feedback vem com exemplo ou só com julgamento?
• o escopo é compatível com junior?
• a empresa cumpre o combinado de contrato, horário e salário?
• erro vira aprendizado ou ameaça?
• você tem acesso ao contexto necessário para entregar?

Primeira vaga boa não é vaga perfeita. Mas precisa ter alguma condição de aprendizado. Se todo erro vira bronca, toda dúvida vira ironia e toda tarefa vem sem contexto, talvez o problema não seja só você.

Nesse caso, não peça demissão no impulso. Registre fatos, converse, tente recuperar o ambiente se for seguro e mantenha sua busca organizada. O guia de como sair de um estágio ruim em tech fala de estágio, mas vários princípios valem para primeira vaga ruim: preservar reputação, não explodir ponte e preparar saída com clareza.

prepare a conversa final dos 90 dias

Perto do fim da experiência, faça um resumo. Mesmo que ninguém peça.

Modelo:

Resumo do período de experiência

Entregas:
- PRs, tarefas, bugs, documentação ou suporte em que atuei

Aprendizados:
- produto, stack, processo, testes, deploy, comunicação

Feedback aplicado:
- comentários que recebi e como ajustei

Pontos em evolução:
- o que ainda preciso melhorar nos próximos 60 dias

Próximo foco:
- área pequena onde quero ganhar mais autonomia assistida

Leve isso para a 1:1 ou para a conversa com gestor. Não precisa parecer apresentação de promoção. Precisa mostrar que você acompanhou a própria evolução.

Se a conversa for positiva, ótimo. Pergunte qual deve ser o foco dos próximos meses. O guia de primeiros 90 dias como dev junior ajuda a continuar depois dessa etapa.

Se a conversa for incerta, peça critério, prazo e check-in. Se for negativa, respire antes de concluir que sua carreira acabou. Uma experiência que não encaixa não define sua capacidade inteira. Atualize CV, registre aprendizados, revise onde houve sinal real e volte para busca com mais informação. O guia de reprovação em processo seletivo junior também serve para lidar com esse tipo de fechamento: transformar dor em ajuste, não em identidade.

a régua final

Você não controla tudo no período de experiência. Não controla orçamento, política interna, maturidade do gestor, urgência do produto, comparação com outras pessoas ou ruído da empresa.

Mas controla bastante coisa pequena:

• aparecer;
• perguntar com contexto;
• avisar bloqueio cedo;
• registrar decisão;
• pedir feedback específico;
• aplicar review;
• entregar pequeno;
• testar o básico;
• resumir evolução;
• não fingir senioridade.

Para dev junior, isso já é muita coisa.

Passar pelo período de experiência não é vencer uma prova secreta. É construir confiança em público, semana por semana. Menos pânico, mais rastro. Menos teatro, mais ajuste. Menos tentativa de parecer pronto, mais evidência de que você aprende rápido o suficiente para valer a próxima tarefa.

Quando uma vaga boa aparecer em /vagas/, lembre disso antes mesmo de entrar: contrato importa, mas comportamento no começo também. O objetivo não é chegar perfeito. É chegar treinável e sair dos primeiros 90 dias nitidamente melhor do que entrou.