primeira semana como dev junior: o que fazer pra começar bem

Você passou pelo CV, entrevista, talvez teste técnico, silêncio, follow-up e ansiedade. Agora veio a oferta. A parte difícil acabou? Não exatamente.

A primeira semana como dev junior é onde muita gente troca o medo de não conseguir vaga pelo medo de ser descoberto como fraude. Você entra no Slack, vê siglas internas, repositórios enormes, reuniões que parecem começar no meio, sênior falando nome de serviço como se fosse óbvio e task no Jira com três linhas que dependem de cinco anos de contexto.

Isso não significa que você não serve. Significa que você é junior.

A empresa contratou você sabendo que você não conhece o sistema, o domínio, os atalhos, os incidentes antigos e as decisões técnicas que levaram o código até ali. O que ela espera na primeira semana não é produtividade de pleno. Ela espera comportamento de pessoa treinável: observar, perguntar bem, registrar contexto, reduzir ruído e entregar algum progresso pequeno sem fingir que entendeu tudo.

Este guia é sobre como atravessar a primeira semana sem virar personagem ansioso, sem sumir no remoto e sem tentar provar maturidade do jeito errado.

o objetivo da primeira semana

Seu objetivo não é “mostrar serviço” no sentido teatral. Não é abrir dez pull requests, corrigir arquitetura, reescrever componente antigo ou sugerir trocar a stack.

Seu objetivo é sair da semana sabendo quatro coisas:

1. Como rodar o projeto localmente.
2. Como o time se comunica e prioriza trabalho.
3. Quem responde cada tipo de dúvida.
4. Qual é sua primeira entrega pequena e segura.

Se você consegue isso, a semana foi boa. Depois, a próxima etapa é transformar onboarding em consistência; o guia de primeiros 30 dias como dev junior continua esse caminho.

A régua certa para dev junior no começo é: ficar operacional sem virar peso silencioso. Peso silencioso é a pessoa que não pergunta, não registra bloqueio, passa três dias travada e aparece na daily dizendo “continuo vendo”. Isso queima mais que fazer pergunta simples.

Se você ainda está antes da contratação, os guias de entrevista técnica júnior, teste técnico e follow-up depois da entrevista cobrem a fase anterior. Aqui o jogo é outro: virar parte do time.

dia 1: monte seu mapa de sobrevivência

No primeiro dia, você provavelmente vai receber acesso, convite de agenda, link de documentação, onboarding do RH e uma avalanche de mensagens. Não tente absorver tudo de cabeça.

Crie um documento pessoal chamado algo como onboarding-dev-junior.md. Pode ser Notion, Obsidian, Google Docs, arquivo local, tanto faz. O importante é escrever.

Divida em blocos:

Pessoas
- gestor direto:
- buddy/mentor:
- tech lead:
- pessoa de produto:
- suporte/devops:

Acessos
- email:
- Slack/Teams:
- GitHub/GitLab:
- Jira/Linear/Trello:
- staging:
- produção: não tenho / tenho só leitura / tenho restrito

Projetos
- repo principal:
- como rodar local:
- ambiente de teste:
- documentação útil:

Rituais
- daily:
- planning:
- review:
- retrospectiva:
- canal para dúvidas:

Esse documento não precisa ser bonito. Ele precisa evitar que você pergunte a mesma coisa cinco vezes.

No dia 1, pergunte explicitamente:

Existe algum documento de onboarding técnico que eu deveria seguir primeiro?

Quem é a melhor pessoa para dúvidas de setup?

Qual é a expectativa real para minha primeira semana?

Essas perguntas são maduras. Elas mostram que você quer alinhar ritmo, não adivinhar.

setup local: registre erro como adulto

Setup de projeto raramente funciona de primeira. Versão de Node errada, variável de ambiente faltando, Docker quebrando, banco local sem seed, VPN instável, permissão ausente, pacote privado sem acesso.

Junior costuma reagir de dois jeitos ruins:

• fica quieto porque acha que setup quebrado é incompetência dele;
• manda “não funcionou aqui” sem contexto.

O jeito bom é registrar tentativa.

Modelo de pergunta:

Tô tentando rodar o projeto local seguindo o README.

Ambiente:
- macOS/Linux/Windows
- Node 22.3 / Go 1.23 / Python 3.12
- comando: npm run dev

Erro:
[cole 10-20 linhas relevantes, não o log inteiro]

Tentei:
1. reinstalar dependências
2. conferir .env.example
3. rodar migration

Suspeito que falta acesso ao pacote privado X ou variável Y. Faz sentido?

Isso muda completamente a percepção. Você não parece perdido; parece alguém depurando.

Se o time usa uma stack que você ainda está consolidando, tudo bem. Você pode estudar por fora, mas não transforme a primeira semana em maratona secreta. Se precisar revisar base de Python, por exemplo, use material externo e prático; um bom caminho é consultar tutoriais de Python em português quando a stack do time passa por scripts, APIs ou automações simples. Só não finja fluência que você ainda não tem.

daily: fale pouco, mas fale certo

Daily não é palco. Também não é confissão.

Uma daily boa de junior tem três linhas:

Ontem: consegui configurar X e li a documentação de Y.
Hoje: vou pegar a task Z e tentar reproduzir o bug localmente.
Bloqueio: ainda falta acesso ao ambiente de staging; já pedi no canal A.

Pronto.

Não diga só “tô estudando” por vários dias. Estudar é meio, não entrega. Especifique o que você estudou e para quê.

Ruim:

Ontem estudei bastante o projeto. Hoje vou continuar estudando. Sem bloqueios.

Melhor:

Ontem li o fluxo de cadastro e rodei o backend local. Hoje vou reproduzir o erro do ticket 123 no ambiente de dev. Bloqueio: ainda não tenho acesso ao banco de staging, pedi para a Ana.

A diferença é visibilidade. Time remoto confia em quem deixa rastro.

Se você está começando remoto, releia o guia de rotina de trabalho remoto para junior. A primeira semana é quando os hábitos de comunicação se formam.

perguntas boas economizam reputação

Você vai perguntar muito. O problema não é perguntar. O problema é perguntar de um jeito que transfere trabalho mental para a outra pessoa.

Pergunta ruim:

Como funciona esse repo?

Pergunta melhor:

Vi que o repo tem api, worker e web. Pelo README, parece que api recebe as requisições e worker processa eventos assíncronos. É essa a leitura certa? Para minha primeira task, devo focar só no api?

Pergunta ruim:

O que eu faço agora?

Pergunta melhor:

Terminei o setup local e consegui rodar os testes. Posso pegar o bug 123 ou você prefere que eu comece pelo ajuste de texto 118 para entender o fluxo de PR?

Pergunta ruim:

Deu erro.

Pergunta melhor:

Ao rodar a migration 20260518_add_status, recebo erro de coluna duplicada. Parece que meu banco local já tinha a migration parcial. Posso resetar o banco local ou existe outro procedimento?

A fórmula é sempre a mesma: contexto, tentativa, hipótese, pergunta específica.

sua primeira task deve ser pequena

A primeira entrega ideal para dev junior não é “implementar feature importante”. É algo pequeno que atravessa o fluxo inteiro:

• alterar texto ou validação simples;
• corrigir bug reproduzível;
• adicionar teste para comportamento existente;
• atualizar documentação de setup;
• ajustar campo em tela interna;
• tratar mensagem de erro.

Por quê? Porque a primeira task serve para aprender o caminho: branch, commit, padrão de código, teste, PR, review, deploy, rollback. A tarefa é pretexto para entender o sistema de trabalho.

Se te oferecerem uma task enorme logo de cara, quebre:

Posso começar entregando uma parte menor disso primeiro, só para passar pelo fluxo de PR e receber feedback antes de mexer no restante?

Isso não é fraqueza. É controle de risco.

O guia de GitHub para junior fala do GitHub como vitrine antes da vaga. No emprego, Git vira ferramenta de colaboração. Commit pequeno, descrição clara e PR legível importam mais que heroísmo.

PR de junior: escreva para quem vai revisar

Seu primeiro pull request deve facilitar a vida do revisor.

Use descrição curta:

## o que muda
- corrige validação do campo telefone no cadastro
- adiciona mensagem de erro quando DDD está ausente

## como testei
- rodei `npm test`
- testei manualmente cadastro com telefone válido e inválido

## contexto
Primeira task de onboarding. Mantive a regra atual e só ajustei o caso descrito no ticket 123.

Não abra PR gigante sem necessidade. Não misture refactor que ninguém pediu. Não ajuste formatação em cinquenta arquivos. Não tente provar que você sabe mais que o código legado.

Se você viu problema real fora do escopo, anote e pergunte depois:

Percebi que esse componente tem repetição com outro arquivo. Preferi não mexer agora para manter o PR pequeno. Faz sentido abrir um ticket separado?

Essa frase compra confiança. Você viu melhoria, mas respeitou escopo.

o que evitar na primeira semana

1. sumir para “resolver sozinho”

Autonomia não é silêncio. Se você está bloqueado há mais de 30-60 minutos em algo de contexto interno, pergunte.

2. criticar arquitetura antes de entender história

Todo sistema tem cicatriz. Antes de dizer “por que vocês fizeram assim?”, prefira:

Tem algum contexto histórico para essa decisão?

3. prometer prazo heroico

Se perguntarem quando você entrega, não chute para agradar.

Ainda estou entendendo o fluxo. Posso te dar uma estimativa melhor depois de reproduzir localmente?

4. pedir desculpa por existir

“Desculpa incomodar” em toda mensagem cansa. Use “obrigado” e seja objetivo.

5. estudar escondido em vez de alinhar lacuna

Se você não conhece uma ferramenta central, diga:

Ainda não tenho prática com Docker além do básico. Vou seguir o README e registrar onde travar.

Honestidade calibrada é melhor que performance falsa.

checklist de sexta-feira

No fim da primeira semana, mande uma atualização curta para seu gestor ou buddy.

Modelo:

Resumo da primeira semana:

- consegui configurar o ambiente local e rodar testes
- entendi o fluxo básico de cadastro/pagamento/etc.
- abri o PR #123 para corrigir X
- ainda preciso ganhar contexto em Y e Z
- para semana que vem, pretendo pegar uma task pequena em [área]

Se tiver algum ajuste de prioridade ou forma de comunicação, quero corrigir cedo.

Isso é raro em junior. Mostra maturidade sem teatro.

Também atualize sua planilha de candidaturas ou registro pessoal: processo fechado, data de início, salário, contrato, contatos importantes. Parece detalhe, mas no futuro você vai querer lembrar como chegou ali.

a régua real

Primeira semana boa não é a semana em que você entende tudo. Isso não existe.

Primeira semana boa é a semana em que o time pensa:

Essa pessoa pergunta bem, registra contexto, aceita feedback e dá para treinar.

É isso que você precisa conquistar.

O primeiro emprego em tech não começa quando você assina contrato. Começa quando você aprende a ser confiável dentro de um sistema que já existia antes de você. Confiança, para junior, nasce de coisas pequenas: aparecer na daily, escrever bloqueio cedo, abrir PR pequeno, testar o que mexeu, agradecer review, anotar decisão, voltar com progresso.

Não tente parecer pleno na primeira semana. Tente parecer junior bom. É muito mais raro do que parece. Depois do primeiro mês, o guia de primeiros 90 dias como dev junior continua essa régua de crescimento sem pular etapa.