--- title: "Onboarding remoto para dev junior: como não sumir no primeiro mês" url: "https://eu.dev.br/carreira/onboarding-remoto-dev-junior/" markdown_url: "https://eu.dev.br/carreira/onboarding-remoto-dev-junior.MD" description: "Entrar remoto como dev junior exige mais visibilidade do que presença. Veja como organizar onboarding, perguntas, anotações e primeiras entregas sem sumir." date: "2026-06-11" author: "" --- # Onboarding remoto para dev junior: como não sumir no primeiro mês Entrar remoto como dev junior exige mais visibilidade do que presença. Veja como organizar onboarding, perguntas, anotações e primeiras entregas sem sumir. Entrar remoto como dev junior parece confortável até a primeira dúvida sem rosto. No escritório, você escuta conversa paralela, vê quem pergunta para quem, percebe quando alguém está disponível e entende parte do contexto só por estar perto. No remoto, quase tudo precisa virar mensagem, documento, call, comentário no ticket ou update na daily. Isso não é ruim. Só é menos automático. O problema é que muita pessoa junior interpreta silêncio como autonomia. Passa horas tentando resolver setup, fica com vergonha de perguntar no Slack, espera a daily para avisar bloqueio e termina a primeira semana parecendo invisível. Não porque não quer trabalhar, mas porque ainda não entendeu que remoto exige visibilidade deliberada. Este guia é para atravessar o onboarding remoto sem virar peso silencioso: como montar rotina, registrar contexto, pedir ajuda, mostrar progresso e identificar quando a empresa está deixando você solto demais. ## onboarding remoto não é só receber acessos Onboarding remoto bom precisa responder quatro perguntas: 1. o que eu preciso acessar? 2. o que eu preciso entender? 3. quem me destrava em cada tipo de dúvida? 4. como o time percebe meu progresso? Acesso é só a primeira camada. GitHub, Slack, email, VPN, Jira, Figma, banco de staging e ferramenta de ponto não fazem você entender produto. Eles só abrem a porta. Depois vem a parte que realmente importa para dev junior: descobrir como o sistema funciona, qual pedaço do produto o time cuida, quais tarefas são seguras para começar, como pedir review e qual é o padrão de comunicação. Se você ainda está negociando ou avaliando proposta, vale voltar no guia de [perguntas para entrevista dev junior](/carreira/perguntas-entrevista-dev-junior/) e no checklist de [avaliar proposta do primeiro emprego tech](/carreira/avaliar-proposta-primeiro-emprego-tech/). Onboarding fraco costuma aparecer antes da contratação, em respostas vagas como "a pessoa corre atrás" ou "aqui é bem dinâmico". ## dia 1: crie seu centro de comando No primeiro dia remoto, não confie na memória. Crie um documento pessoal com nome simples: ```text onboarding-remoto-dev-junior.md ``` Pode ser Notion, Obsidian, Google Docs, arquivo local ou caderno. O formato importa menos que a disciplina. Separe em blocos: ```text acessos - email: - Slack: - GitHub/GitLab: - Jira/Linear/Trello: - VPN: - staging: pessoas - gestor(a): - buddy/par: - produto: - design: - infra: - RH: rotina - daily: - planejamento: - review: - canal de dúvida: - horário do time: setup - repositórios: - comandos: - variáveis: - erros encontrados: ``` Isso não é burocracia. É proteção contra o caos. No remoto, você recebe links em lugares diferentes: email, Slack, mensagem privada, reunião gravada, documento antigo. Se não centralizar, vai perguntar a mesma coisa duas vezes ou perder contexto importante. O guia de [primeira semana como dev junior](/carreira/primeira-semana-dev-junior/) aprofunda esse momento. Aqui a diferença é o recorte remoto: como ninguém vê sua tela, seu documento precisa virar o lugar onde você enxerga o próprio avanço. ## peça um mapa antes de pedir tarefa Uma pergunta boa no início não é: ```text Qual task eu pego? ``` É: ```text Antes de pegar a primeira task, você consegue me ajudar a entender o mapa básico do produto e do time? Quero saber quais repositórios importam, onde vejo decisões recentes e quais fluxos eu devo conhecer primeiro. ``` Isso mostra intenção de trabalhar, mas evita cair direto num ticket sem contexto. Peça um mapa com: - principal fluxo do produto; - repositórios que você provavelmente vai tocar; - ambiente local, staging e produção; - canal certo para dúvida técnica; - canal certo para dúvida de produto; - exemplos de PRs bons do time; - documento de arquitetura ou onboarding, se existir. Se a empresa tiver buddy, combine um check-in curto. Se não tiver, peça uma pessoa de referência temporária: ```text Existe alguém que eu possa acionar primeiro nas dúvidas de setup e contexto durante as primeiras semanas? Assim evito jogar pergunta solta no canal errado. ``` Não é carência. É gestão de entrada. ## use pergunta assíncrona com contexto No remoto, pergunta ruim custa mais caro porque interrompe sem contexto. Compare: ```text Não consegui rodar o projeto. Alguém ajuda? ``` Com: ```text Estou tentando rodar o `api` localmente. Segui o README até o passo `docker compose up`, mas o container `postgres` sobe e o `api` quebra com `DATABASE_URL missing`. Já procurei no `.env.example` e no documento de onboarding, mas não achei o nome esperado da variável. Alguém sabe se existe um `.env` interno para dev ou se devo copiar de outro lugar? ``` A segunda pergunta facilita resposta. Ela mostra: - o que você tentou; - onde travou; - qual erro apareceu; - que documentação leu; - qual decisão precisa. Essa estrutura evita o medo de parecer perdido. Você não está dizendo "não sei nada". Está dizendo "isolei o problema até aqui". Use o mesmo padrão em ticket, PR e daily. O guia de [como entender ticket como dev junior](/carreira/entender-ticket-dev-junior/) ajuda a transformar dúvida vaga em pergunta que o time consegue responder. ## não espere a daily para avisar bloqueio Daily é resumo. Não é botão de emergência. Se você travou às 10h e só avisa às 17h ou no dia seguinte, perdeu horas de onboarding. No remoto, ninguém necessariamente percebe que você está parado. Sua luz verde no Slack não conta como progresso. Use uma regra simples: - 20 a 30 minutos tentando sozinho em problema de setup; - 45 a 60 minutos tentando sozinho em problema de código com documentação; - depois disso, pedir ajuda com contexto. Isso não significa chamar alguém a cada tropeço. Significa não passar meio dia preso em algo que uma pessoa do time resolveria em três minutos porque conhece a senha, o script ou o histórico. Mensagem possível: ```text Estou bloqueado no setup do serviço X há 40 min. Já tentei A e B, li o README e confirmei que o erro é Y. Vou seguir investigando mais 20 min, mas deixo aqui caso alguém já reconheça esse problema. ``` Perceba o tom: você continua responsável, mas dá visibilidade. Para melhorar esse hábito, combine com o roteiro de [daily standup para dev junior](/carreira/daily-standup-dev-junior/). Daily boa nasce de update durante o dia, não de memória improvisada na chamada. ## transforme call em nota e combinado Call de onboarding remoto é perigosa porque parece compreensão. Você sai da reunião achando que entendeu. Duas horas depois, lembra de metade. No dia seguinte, não sabe se a decisão era "fazer agora" ou "ver depois". Durante a call, anote: ```text call onboarding api - 2026-06-11 contexto - api recebe cadastro e dispara evento para worker - worker processa email e integra com CRM - frontend consome endpoint /accounts decisões - primeira task fica só no api - não mexer no worker neste PR - usar branch chore/onboarding-setup dúvidas abertas - confirmar se staging usa banco compartilhado - pedir acesso ao dashboard de logs próximo passo - rodar api local - abrir PR pequeno atualizando README se encontrar passo faltando ``` Depois, mande um resumo curto se fizer sentido: ```text Resumo do que entendi: vou focar só no `api` nesta primeira task, sem alterar o `worker`. Vou validar setup local e, se achar passo faltando, abro PR pequeno no README. Se entendi algo errado, me avisem. ``` Isso é muito forte para junior remoto. Mostra escuta, reduz ruído e dá chance de correção cedo. O guia de [anotações de trabalho para dev junior](/carreira/anotacoes-trabalho-dev-junior/) existe para esse músculo. Em remoto, ele deixa de ser vantagem e vira sobrevivência. ## primeira task: pequena, visível e reversível A primeira entrega remota não precisa ser impressionante. Precisa ser rastreável. Boas primeiras tarefas: - ajustar texto ou validação pequena; - corrigir bug simples com teste; - atualizar README de setup; - adicionar log em fluxo seguro; - melhorar mensagem de erro; - escrever caso de teste para comportamento existente; - tratar estado vazio em tela interna. Tarefas ruins para começar: - refatorar módulo central; - mexer em pagamento; - alterar permissão; - trocar biblioteca importante; - assumir bug intermitente sem contexto; - pegar integração crítica sem par. Se o primeiro ticket parece grande, quebre com o time: ```text Acho que esta tarefa tem três partes: entender regra atual, ajustar validação e cobrir com teste. Para meu primeiro PR, faz sentido eu limitar ao teste + validação do caso X e deixar Y para outro ticket? ``` Esse tipo de pergunta mostra maturidade. Junior bom não é quem aceita escopo nebuloso para parecer forte. É quem reduz risco. Quando abrir o PR, use o guia de [primeiro pull request como dev junior](/carreira/primeiro-pull-request-dev-junior/) e depois o de [code review](/carreira/code-review-dev-junior/). No remoto, PR é uma das principais formas de o time enxergar como você pensa. ## rotina mínima para não sumir Uma rotina remota de onboarding pode ser simples: ```text 09:00 - ler mensagens, agenda e tickets 09:20 - escolher foco do bloco da manhã 11:30 - atualizar nota com progresso/bloqueio 14:00 - bloco de execução ou estudo do sistema 16:30 - pedir ajuda se algo ficou parado 17:30 - registrar fechamento do dia ``` O fechamento do dia pode ser privado ou público, dependendo da cultura do time: ```text Hoje consegui rodar o `api`, entendi o fluxo básico de cadastro e comecei o ticket ABC-123. Fiquei com dúvida sobre o evento disparado para o worker; deixei pergunta no ticket. Amanhã sigo pela validação e teste. ``` Isso evita o buraco clássico: trabalhar oito horas e ninguém saber se você avançou, travou ou desapareceu. Se a empresa usa Slack, Teams ou Discord, respeite o canal certo. Não precisa narrar cada passo. Mas precisa deixar progresso verificável. Para rotina completa, leia [trabalho remoto para junior](/carreira/trabalho-remoto-rotina/) e [primeiros 30 dias como dev junior](/carreira/primeiros-30-dias-dev-junior/). Onboarding remoto é a ponte entre esses dois temas. ## sinais amarelos no onboarding remoto Nem todo onboarding fraco é culpa sua. Fique atento se: - ninguém sabe quem deve te orientar; - não existe README nem alguém disponível para explicar setup; - o time espera que você mexa em produção sem par; - perguntas simples recebem ironia; - a vaga foi vendida como junior, mas as tarefas exigem autonomia de pleno; - não há daily, 1:1, review ou feedback; - você só descobre regra importante depois de errar. Um pouco de bagunça é normal. Empresa pequena, startup e time em crescimento têm documentação incompleta. O alerta não é faltar documento. O alerta é faltar disposição para orientar. Se isso acontecer, registre fatos, não drama: ```text - 3 dias sem pessoa de referência definida - setup local bloqueado por falta de variável interna - pedi acesso ao log em 11/06 e 12/06 - primeiro ticket envolve fluxo de pagamento sem par técnico ``` Essas notas ajudam na 1:1, no feedback e, se necessário, na decisão de continuar ou procurar outra oportunidade. O guia de [primeiro feedback negativo](/carreira/primeiro-feedback-negativo-dev-junior/) também serve quando a conversa é sobre desalinhamento, não só desempenho. ## se você ainda está procurando vaga remota Use onboarding como critério antes de aceitar. Em entrevista, pergunte: ```text Como funciona o onboarding remoto nos primeiros 30 dias? ``` ```text A pessoa junior tem buddy ou referência técnica? ``` ```text Quais são exemplos de primeiras tarefas para quem entra junior? ``` ```text Como o time percebe bloqueio no remoto? ``` Resposta boa não precisa ser perfeita. Pode ser simples: > Temos um checklist de acessos, uma pessoa buddy, primeira task pequena, daily e 1:1 semanal no primeiro mês. Resposta perigosa: > Aqui a pessoa precisa ser dona, correr atrás e se virar. Não temos muito processo. "Se virar" pode ser saudável para senior. Para junior remoto, muitas vezes é abandono com frase bonita. Ao filtrar vagas em [/vagas/](/vagas/), combine modelo remoto com sinais de suporte: descrição clara, stack coerente, nível real, processo proporcional e menção a mentoria, code review ou onboarding. O guia de [como filtrar vaga remota junior](/carreira/filtrar-vaga-remota-junior/) ajuda nessa triagem. ## checklist do onboarding remoto junior Antes de terminar a primeira semana, tente ter isto: - [ ] documento pessoal de onboarding criado; - [ ] acessos principais mapeados; - [ ] pessoa de referência definida; - [ ] rotina de daily/update entendida; - [ ] repositório principal rodando ou bloqueio registrado; - [ ] primeiro ticket pequeno definido; - [ ] canal de dúvida técnica conhecido; - [ ] exemplo de PR bom salvo; - [ ] dúvidas abertas escritas; - [ ] próximo passo claro para amanhã. Antes de terminar o primeiro mês: - [ ] alguns PRs pequenos enviados; - [ ] pelo menos um feedback específico recebido; - [ ] mapa básico do produto entendido; - [ ] padrão de code review do time observado; - [ ] notas de setup e decisões organizadas; - [ ] 1:1 usada para calibrar expectativa. Se você quer reforçar base técnica enquanto entra no time, escolha uma trilha prática e documente o que aprendeu. Para backend, por exemplo, materiais de Go Brasil podem ajudar a estudar API, concorrência e produção, mas o valor no emprego aparece quando você transforma estudo em pergunta melhor, PR menor e documentação mais clara. ## resumo operacional Onboarding remoto para dev junior não é provar que você consegue sozinho. É provar que você aprende com pouco ruído. Faça o básico muito bem: - anote tudo que não é óbvio; - peça mapa antes de correr para task; - pergunte com contexto; - avise bloqueio cedo; - transforme call em combinado; - comece por entrega pequena; - mostre progresso antes que alguém precise caçar você. Remoto não perdoa invisibilidade. Mas também recompensa quem comunica bem. Se o time consegue enxergar seu raciocínio, seus bloqueios e sua evolução, você deixa de ser apenas "a pessoa nova na call" e começa a virar alguém confiável.