--- title: "Primeiros 90 dias como dev junior: como crescer sem pular etapa" url: "https://eu.dev.br/carreira/primeiros-90-dias-dev-junior/" markdown_url: "https://eu.dev.br/carreira/primeiros-90-dias-dev-junior.MD" description: "Depois do primeiro mês, o desafio muda: ganhar autonomia sem tentar parecer pleno. Veja como usar os primeiros 90 dias como dev junior para crescer com segurança." date: "2026-05-20" author: "" --- # Primeiros 90 dias como dev junior: como crescer sem pular etapa Depois do primeiro mês, o desafio muda: ganhar autonomia sem tentar parecer pleno. Veja como usar os primeiros 90 dias como dev junior para crescer com segurança. Os primeiros 90 dias como dev junior são o trecho em que a empolgação da contratação vira rotina. O setup já aconteceu, a primeira task já saiu, você já entendeu quem é quem no time e provavelmente já levou alguns reviews que doeram um pouco. Agora aparece uma pressão diferente: provar que a contratação valeu a pena. Essa pressão pode ajudar ou atrapalhar. Ajuda quando vira consistência: entregar pequeno, pedir feedback, entender contexto, corrigir comportamento. Atrapalha quando vira teatro: pegar tarefa grande demais, estudar dez assuntos ao mesmo tempo, falar como pleno sem ter repertório, esconder bloqueio para parecer autônomo. Os primeiros 90 dias não são sobre virar pleno rápido. São sobre deixar claro que você aprende com previsibilidade. Se você ainda está no começo absoluto, leia antes o guia de [primeira semana como dev junior](/carreira/primeira-semana-dev-junior/) e depois o roteiro de [primeiros 30 dias como dev junior](/carreira/primeiros-30-dias-dev-junior/). Aqui a conversa começa depois que você já saiu do modo sobrevivência inicial. ## a diferença entre 30 e 90 dias No dia 30, o time quer saber se você é treinável. No dia 90, o time começa a observar se você está ficando previsível. Treinável é a pessoa que pergunta bem, aceita review, registra contexto e não some. Previsível é a pessoa que, mesmo sendo junior, já dá menos trabalho invisível para o time: - avisa bloqueio antes de virar atraso; - quebra tarefa grande em passos menores; - entende parte do produto sem pedir explicação do zero toda vez; - escreve PR com contexto; - testa o básico antes de pedir review; - lembra feedback anterior e aplica no próximo trabalho; - sabe dizer o que ainda não sabe. Repare que ainda não é autonomia total. É autonomia assistida. Você continua precisando de orientação, mas o time consegue confiar no seu processo. Essa é a meta dos 90 dias. ## meses 2 e 3: troque ansiedade por sistema Depois do primeiro mês, junior costuma cair em dois erros. O primeiro erro é relaxar demais: "já entrei, agora é só ir fazendo". A pessoa para de registrar aprendizado, começa a atrasar update, deixa 1:1 virar conversa solta e perde a chance de calibrar cedo. O segundo erro é acelerar demais: "preciso mostrar que sou acima da média". A pessoa pega task sem entender, promete prazo agressivo, estuda assunto que não conversa com o trabalho e tenta parecer mais sênior do que é. O caminho bom é montar um sistema simples para os meses 2 e 3: ```text Toda semana - fechar pelo menos um avanço visível - pedir contexto quando a tarefa estiver nebulosa - registrar o que aprendi e onde travei - atualizar PR/ticket antes de alguém cobrar Todo mês - pedir feedback curto - revisar plano de estudos - escolher uma habilidade técnica principal - identificar um pedaço do produto que entendo melhor ``` Isso parece básico porque é básico. Carreira junior cresce no básico repetido. ## escolha uma área para ganhar profundidade inicial Nos primeiros 90 dias, você não precisa entender a empresa inteira. Precisa escolher uma área pequena para começar a ficar menos perdido. Exemplos: - fluxo de cadastro; - tela de pagamento; - pipeline de dados; - sistema de notificações; - testes de uma API; - integração com um parceiro; - documentação de setup; - triagem de bugs de suporte. Escolha uma área que aparece nas suas tarefas reais. Não escolha pela moda. Se sua task toda semana encosta em SQL, estude SQL antes de abrir curso de Kubernetes. Se seus PRs sempre recebem comentário de teste, estude teste antes de estudar arquitetura limpa. Uma boa pergunta para o gestor ou buddy: > Qual parte pequena do produto faria sentido eu entender melhor nos próximos 60 dias? Essa pergunta mostra direção sem arrogância. Você não está pedindo para virar dono do sistema. Está pedindo um recorte onde pode acumular contexto. Quando você começa a reconhecer padrões em uma área, sua qualidade sobe. Você pergunta melhor, erra menos, entende review mais rápido e consegue sugerir pequenas melhorias com base real. ## transforme review em plano de evolução Review de código é uma das fontes mais honestas de aprendizado no começo. O problema é que muito junior lê review como nota: aprovado ou reprovado. Leia review como mapa. Depois de alguns PRs, procure padrões: - sempre pedem teste que você esqueceu? - sempre corrigem nome de variável? - sempre apontam falta de caso de erro? - sempre pedem para seguir padrão do arquivo? - sempre falta explicar o contexto no PR? - sempre tem ajuste de formatação ou lint? Um comentário isolado é detalhe. O mesmo comentário três vezes é plano de estudos. Exemplo: ```text Padrão percebido: meus PRs voltam com comentário sobre teste. Ação para as próximas 2 semanas: - ler testes existentes antes de codar - copiar estrutura do teste mais parecido - abrir PR só depois de testar caso feliz e caso de erro - pedir para buddy revisar minha estratégia de teste antes de implementar tudo ``` Isso é muito mais útil do que "preciso melhorar em testes". Melhorar em testes é abstrato. Mudar seu ritual antes do PR é concreto. Se você trabalha com Python, scripts internos, APIs ou automações, revise fundamentos aplicados com material prático em português, como Python Brasil. Mas use o estudo para resolver problema real: escrever um teste, depurar uma exceção, entender uma função, ler uma API. ## peça feedback com pergunta melhor Depois de 60 ou 90 dias, "estou indo bem?" fica amplo demais. A resposta tende a ser genérica: "sim, continua assim". Pergunte melhor: ```text Queria calibrar minha evolução dos primeiros 90 dias. Onde você já percebe mais autonomia em mim? E qual seria o principal comportamento técnico ou de comunicação que eu deveria melhorar no próximo mês? ``` Essa pergunta separa reconhecimento de próximo passo. Você descobre o que está funcionando e o que ainda trava confiança. Outra boa versão: ```text Pensando nas próximas tarefas, o que eu poderia começar a fazer com menos acompanhamento? ``` Essa pergunta é forte porque não pede promoção, aplauso nem validação emocional. Pede escopo de autonomia. Se a resposta for "ainda nada", não entre em pânico. Peça critério: > O que você precisaria ver nos próximos PRs para confiar em me passar uma tarefa um pouco menos guiada? Critério visível reduz ansiedade. ## aprenda a estimar sem fingir certeza Junior não precisa acertar estimativa com precisão. Mas precisa parar de responder prazo no impulso. Resposta ruim: > Acho que entrego hoje. Sem ler código, sem reproduzir bug, sem entender dependência, isso é chute. Resposta melhor: > Quero investigar por uma hora para entender o tamanho. Depois volto com uma estimativa mais honesta. Ou: > Pelo que vi até agora, parece pequeno, mas ainda preciso validar impacto em teste e deploy. Posso te atualizar até 15h? Estimativa boa para junior tem três partes: 1. o que você já sabe; 2. o que ainda falta descobrir; 3. quando você vai atualizar o time. Isso protege você de prometer heroísmo e protege o time de silêncio. ## comece a revisar trabalho de outras pessoas Você talvez ainda não tenha repertório para aprovar arquitetura. Tudo bem. Revisar PR não significa bancar sênior. No mês 2 ou 3, comece com leitura ativa: - leia PRs pequenos do time; - tente entender o problema antes de olhar a solução; - veja que comentários os sêniores fazem; - rode localmente um PR simples quando fizer sentido; - pergunte em privado quando não entender um padrão. Comentários seguros para junior: - "A descrição do PR poderia citar o ticket X? Fiquei em dúvida do contexto." - "Esse caso precisa de teste para entrada vazia ou já está coberto em outro lugar?" - "Vi que esse arquivo usa o padrão Y em outro ponto. Faz sentido manter aqui também?" Você não precisa comentar em todo PR. O objetivo é aprender como o time pensa. Ler review dos outros acelera muito porque mostra erro sem você precisar cometer todos. ## não confunda autonomia com isolamento Autonomia não é sumir e voltar com a tarefa pronta. Isso é aposta. Autonomia junior é saber quando seguir sozinho e quando sincronizar. Siga sozinho quando: - o escopo está claro; - o padrão existe no código; - você consegue testar localmente; - o risco é pequeno; - você sabe reverter. Sincronize quando: - a regra de negócio está ambígua; - a mudança encosta em produção, pagamento, dados sensíveis ou infra; - você achou duas soluções com trade-offs reais; - está há mais de algumas horas sem avançar; - a task cresceu além do combinado. Frase útil: > Consegui avançar até aqui. Tenho duas opções: A é menor e mantém o padrão atual; B limpa mais coisa, mas aumenta o escopo. Minha sugestão é A agora e abrir issue para B. Faz sentido? Isso é comportamento de alguém crescendo. Você não joga a decisão no colo do sênior; leva leitura e recomendação. ## cuide da energia antes de quebrar Primeiro emprego em tech consome energia porque tudo parece avaliação. Daily parece prova oral. Review parece julgamento. 1:1 parece boletim. Slack parece plateia. Se você trabalha remoto, esse desgaste pode ficar invisível. O guia de [rotina remota para junior](/carreira/trabalho-remoto-rotina/) existe por isso: sem rotina, pausa e contato humano, você começa a virar fantasma dentro da própria casa. Nos primeiros 90 dias, trate energia como parte do trabalho: - durma em horário minimamente estável; - não transforme toda noite em curso; - faça pausa longe da tela; - fale com gente fora do trabalho; - não leia Slack como se fosse rede social; - anote progresso para não depender da memória ansiosa. Burnout no começo não vem só de excesso de tarefa. Vem de tentar provar valor 24 horas por dia. Você precisa aprender rápido, mas não precisa viver em modo emergência. ## sinais de que o ambiente não está ajudando Às vezes o problema não é você. Alguns times contratam junior, mas operam como se tivessem contratado pleno barato. Sinais de alerta nos primeiros 90 dias: - ninguém explica prioridade; - você recebe tarefa crítica sem revisão; - PR fica parado por dias e depois cobram velocidade; - pergunta vira piada; - não existe ambiente de teste; - não há 1:1, buddy, pareamento nem canal claro de dúvida; - todo feedback é genérico ou agressivo; - a empresa promete formação, mas só joga demanda; - você aprende a esconder erro para não apanhar. Um sinal isolado pode ser fase ruim. Vários sinais repetidos são informação. Nesse caso, registre evidências, converse com calma e mantenha seu plano B vivo. Não precisa sair correndo no primeiro desconforto, mas também não romantize ambiente que te impede de aprender. Se você veio de estágio, o guia de [efetivação no estágio tech](/carreira/efetivacao-estagio-tech/) também ajuda a separar aprendizado real de promessa vaga. A lógica é parecida: confiança precisa de critério, feedback e evidência. ## checklist do dia 90 No fim dos 90 dias, faça um resumo para você e, se fizer sentido, leve para 1:1. ```text Resumo dos primeiros 90 dias Entregas: - PRs/tickets principais: - bugs corrigidos: - documentos ou testes criados: Contexto ganho: - parte do produto que entendo melhor: - fluxo técnico que consigo explicar: - pessoas/canais que sei acionar: Feedback aplicado: - ponto recebido: - mudança feita: - evidência de melhora: Próximo foco: - habilidade técnica: - tipo de tarefa para ganhar autonomia: - comportamento de comunicação: ``` Esse resumo não é autopromoção. É memória operacional. Ele ajuda seu gestor a enxergar evolução e ajuda você a parar de medir carreira só por sensação. Se quiser mandar uma versão curta: ```text Fechando meus primeiros 90 dias, fiz um resumo das entregas, aprendizados e pontos de evolução. Queria usar nossa próxima 1:1 para calibrar: onde já posso ganhar mais autonomia e qual foco faria mais diferença no próximo mês? ``` Pouca gente junior faz isso. Quem faz parece mais madura não porque fala bonito, mas porque facilita a conversa certa. ## a régua dos 90 dias No fim dos primeiros 90 dias, você não precisa saber tudo. Você precisa ser nitidamente melhor do que no dia 1. Melhor em perguntar. Melhor em escrever update. Melhor em abrir PR. Melhor em testar. Melhor em receber review. Melhor em entender o produto. Melhor em dizer "não sei ainda, mas vou descobrir assim". Essa evolução é o que transforma vaga junior em começo de carreira. O objetivo não é pular etapa. É atravessar a etapa certa com evidência. Se o time olha para você no dia 90 e pensa "essa pessoa ainda é junior, mas está ficando mais confiável todo mês", você está construindo a reputação que importa.