como pedir mentoria sendo dev junior sem parecer perdido

Pedir mentoria sendo dev junior parece simples até você precisar fazer isso de verdade. Você olha para a pessoa sênior do time, vê agenda cheia, PR aberto, incidente antigo, reunião de produto, mensagem no Slack e pensa: “se eu chamar, vou atrapalhar”.

Do outro lado, ficar quieto também cobra preço. Você passa horas travado, tenta resolver no chute, abre PR sem entender regra de negócio, recebe review duro e começa a acreditar que pedir ajuda cedo teria sido menos caro.

Mentoria boa não é pedir aula particular para alguém mais experiente. Também não é transformar uma pessoa sênior em suporte 24h. Mentoria boa, para dev junior, é usar o tempo de alguém com mais contexto para tomar decisões melhores, destravar bloqueios reais e aprender como o time pensa.

Este guia é para pedir mentoria, buddy, pareamento ou orientação técnica sem parecer perdido, sem virar dependente e sem fazer teatro de autonomia. Se você acabou de entrar, leia junto com primeira semana como dev junior e primeiros 30 dias como dev junior. Se a conversa for recorrente com gestor, combine também com o roteiro de 1:1 como dev junior.

mentoria não é aula nem resgate

O primeiro ajuste é de expectativa. Mentoria no trabalho não funciona como curso. A pessoa mentora não precisa explicar toda a stack, revisar todos os seus passos ou decidir cada próxima ação.

O objetivo é menor e mais útil:

• entender contexto que não está claro na documentação;
• validar se sua leitura de uma tarefa faz sentido;
• descobrir um caminho seguro antes de mexer em código arriscado;
• receber feedback sobre um padrão que está se repetindo;
• aprender como uma pessoa mais experiente raciocina diante do mesmo problema.

Repare que quase tudo começa com você chegando com alguma tentativa. Mentoria boa usa sua tentativa como material. Se você chega só com “me ensina backend?”, a conversa fica grande demais. Se chega com “li o endpoint X, entendi que ele valida Y antes de salvar Z, mas não entendi onde entra a regra de permissão”, a pessoa consegue ajudar em minutos.

Mentoria também não substitui responsabilidade. Depois da conversa, você continua sendo dono do próximo passo: anotar, testar, aplicar, voltar com evidência e avisar se travar de novo.

quando vale pedir mentoria

Junior costuma errar nos dois extremos. Ou pede ajuda para cada detalhe, antes de tentar qualquer coisa, ou espera tempo demais para não parecer fraco.

Um bom critério é pedir mentoria quando a dúvida envolve contexto, risco ou padrão.

Peça ajuda quando:

• você já tentou entender a tarefa e ainda não sabe qual problema real ela resolve;
• existem dois caminhos técnicos e você não sabe qual é o padrão do time;
• a mudança encosta em produção, pagamento, dados sensíveis, permissão ou cliente importante;
• você repetiu o mesmo erro em mais de um review;
• a documentação existe, mas parece contradizer o código;
• você está travado há tempo suficiente para virar atraso se continuar sozinho.

Não precisa chamar alguém para tudo que o README responde, para erro de sintaxe que você ainda nem leu, para pedir validação emocional a cada commit ou para terceirizar decisão pequena. A régua é: tente o básico, forme uma hipótese e chame antes de transformar dúvida em prejuízo.

Se você trava muito para decidir quando pedir ajuda, o guia de como entender ticket como dev junior ajuda a separar problema, critério de aceite e fora de escopo antes da conversa.

chegue com contexto, tentativa e pergunta

O jeito mais simples de pedir mentoria sem parecer perdido é usar três blocos: contexto, tentativa e pergunta.

Modelo ruim:

Oi, você pode me ajudar com essa task? Não entendi nada.

Modelo melhor:

Oi, estou na task 123 sobre validar cupom no checkout.

Contexto que entendi:
- o cupom é validado no backend antes de fechar pedido
- existe uma regra antiga para cupom expirado
- agora precisamos bloquear cupom de campanha encerrada

Tentei:
- li o endpoint `POST /checkout`
- procurei testes com cupom expirado
- encontrei a tabela `campaigns`, mas não entendi se ela é fonte oficial da regra

Pergunta:
Você consegue me ajudar por 15 min a validar se estou olhando o lugar certo antes de eu implementar?

Essa mensagem muda tudo. Ela mostra esforço, delimita escopo e respeita o tempo da outra pessoa. A pessoa mentora não precisa descobrir do zero onde você está. Ela só precisa corrigir rota.

Se for algo rápido, peça uma resposta assíncrona. Se for nebuloso, peça 15 ou 25 minutos. Evite marcar uma hora quando você ainda não sabe a pergunta. Tempo curto força preparação.

perguntas boas para pessoa mentora

Mentoria boa depende da qualidade das perguntas. Pergunta ampla demais gera conselho genérico. Pergunta específica gera próximo passo.

Boas perguntas para tarefa:

• Estou entendendo corretamente o problema ou pulei algum contexto de produto?
• Qual parte dessa mudança tem mais risco?
• Existe algum padrão parecido no código que eu deveria seguir?
• Antes de abrir PR, que caso de teste você esperaria ver?
• Faz sentido quebrar essa tarefa em duas entregas menores?

Boas perguntas para evolução:

• Que padrão dos meus últimos PRs mais gera retrabalho?
• Qual habilidade técnica faria mais diferença para eu ganhar autonomia neste time?
• Em que tipo de tarefa você acha seguro eu tentar ir mais longe sozinho?
• O que eu deveria parar de fazer porque passa uma imagem ruim?
• Que evidência mostraria que melhorei nesse ponto daqui a um mês?

Boas perguntas para rotina:

• Estou avisando bloqueio cedo o bastante?
• Minha daily dá visibilidade ou parece vaga demais?
• Minhas mensagens chegam com contexto suficiente?
• Quando eu pedir ajuda, você prefere mensagem no canal, DM ou pauta para 1:1?

Essas perguntas são fortes porque transformam mentoria em comportamento observável. Não ficam no “quero evoluir”. Mostram onde evoluir.

use a conversa para sair com próximo passo

Uma conversa de mentoria sem próximo passo vira sensação boa e pouca mudança. Antes de encerrar, confirme o combinado.

Exemplo:

Então meu próximo passo é:
- seguir o padrão do arquivo `coupon_validator`
- cobrir cupom válido, expirado e campanha encerrada
- abrir PR pequeno só com backend
- chamar você no PR se a regra de campanha ficar ambígua

Isso evita mal-entendido. Também facilita a pessoa mentora perceber que o tempo ajudou de verdade.

Depois da conversa, anote em algum lugar. Pode ser seu documento de onboarding, sua planilha de PDI ou uma nota simples:

Mentoria 01/06
Tema: validação de cupom
Aprendi: regra de campanha vem da tabela X, mas fallback antigo ainda existe
Aplicar: teste de campanha encerrada + descrição clara no PR
Próxima dúvida: confirmar regra de timezone se aparecer diferença em staging

Se a mentoria virou ação concreta, ela também pode virar evidência para seu PDI de dev junior: menos retrabalho, PR mais claro, bloqueio avisado cedo, teste melhor ou tarefa entregue com menos dependência.

não transforme mentor em gargalo

Um risco real é virar dependente de uma pessoa só. No começo, é normal ter buddy ou pessoa de referência. Mas se todo problema passa pelo mesmo sênior, você cria gargalo para o time e limita seu próprio aprendizado.

Evite isso de três formas.

Primeiro, registre respostas recorrentes. Se alguém explicou como rodar teste, onde fica a documentação ou qual canal pedir acesso, anote. Não peça a mesma coisa três vezes.

Segundo, aprenda a escolher canal. Dúvida de regra de produto talvez seja com PM. Dúvida de deploy talvez seja com infra. Dúvida de padrão de frontend talvez seja com outra pessoa do time. Mentoria não é sempre “chamar o sênior mais famoso”.

Terceiro, devolva valor. Depois de entender algo que estava confuso, melhore um README, comente no ticket, deixe uma nota no PR ou ajude outra pessoa nova. Junior também pode reduzir ruído do time.

Uma frase boa depois de receber ajuda:

Valeu, isso destravou. Vou registrar esse passo no README de setup porque acho que outra pessoa pode cair no mesmo ponto.

Isso mostra maturidade. Você não só consumiu contexto; ajudou a preservar contexto.

quando a empresa não oferece mentoria formal

Nem toda empresa tem programa de buddy, trilha de onboarding ou mentoria clara. Isso não significa que você precisa esperar.

Peça algo pequeno:

Oi, estou fechando meu primeiro mês e queria calibrar minha evolução técnica. Você teria 20 min essa semana para eu te mostrar dois padrões que apareceram nos meus PRs e pedir orientação de foco para o próximo mês?

Ou:

Estou começando a pegar tarefas nesse fluxo e queria evitar retrabalho. Posso te mandar uma leitura curta do que entendi antes de implementar a próxima mudança?

Isso não exige programa formal. Exige respeito pelo tempo da pessoa e clareza sobre o objetivo.

Se ninguém consegue orientar, se feedback nunca aparece, se você fica sem tarefa clara por semanas ou se a empresa trata pedido de ajuda como fraqueza, o problema talvez não seja só seu. Use o guia de sair de estágio ruim em tech para separar dificuldade normal de ambiente sem suporte.

sinais de que a mentoria está funcionando

Mentoria funcionando não significa que você parou de ter dúvida. Significa que suas dúvidas melhoraram.

Sinais bons:

• você chega com hipótese antes de pedir ajuda;
• seus PRs voltam com menos comentário repetido;
• você sabe explicar por que escolheu um caminho;
• bloqueios aparecem mais cedo;
• você começa a reconhecer padrões do produto;
• a pessoa mentora precisa corrigir menos contexto básico e mais detalhe de decisão;
• você consegue ajudar outra pessoa nova em algo que aprendeu.

Esse é o ponto. Mentoria não serve para provar que você já sabe. Serve para acelerar o caminho entre não saber e trabalhar com mais previsibilidade.

Dev junior bom não é o que nunca pede ajuda. É o que pede ajuda com contexto, aprende com a resposta e volta mais preparado na próxima vez.