Como fazer perguntas que aceleram sua carreira
Fazer perguntas é uma maneira subestimada sobre como achar bons mentores e melhorar sua reputação.
Engenheiros de Software ganham bem porque lidamos com informações quase infinitas. Tecnologias mudam. Requisitos mudam. Frameworks, linguagens, pessoas, times, stakeholders, usuários - tudo muda.
Pra ser eficiente como engenheiro, você precisa conseguir informação de forma rápida. O melhor jeito? Fazendo perguntas. MUITAS perguntas.
Perguntas têm boas intenções. Mas quando são mal-feitas, as pessoas criam uma percepção ruim sobre você. E vão se perguntar: "por que ele me perguntou isso?"
Quando a pergunta é bem formulada, a pessoa fica feliz em responder. Isso melhora seu relacionamento com ela e toda a cultura do time sobre compartilhar conhecimento.
"There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question." - Carl Sagan
✨ O que esperar do artigo
O princípio da empatia: como se colocar no lugar de quem responde pra criar perguntas que respeitam o tempo das pessoas
Os 4 níveis de perguntas: desde perguntas ruins que destroem reputação até perguntas incríveis que fazem pessoas quererem te mentorar
Quando e como pedir ajuda: o timing certo pra não parecer dependente nem teimoso demais
O princípio que transforma suas perguntas
Empatia.
Fazer perguntas é igual ser um bom comunicador. Você precisa se colocar no lugar da pessoa que vai responder. Se você fizer isso, sua pergunta será excelente.
Mas como isso funciona na prática?
Como aplicar empatia nas suas perguntas
Antes de enviar qualquer pergunta, pare e pense:
"Se eu fosse a pessoa recebendo essa pergunta, que informações eu precisaria pra dar uma resposta útil?"
Exemplo prático:
❌ Pergunta sem empatia: "Oi, o deploy tá dando erro. Você pode me ajudar?"
✅ Pergunta com empatia: "Oi! Estou tentando fazer deploy da feature X no ambiente staging. O erro é 'connection timeout' na linha 42 do script. Já tentei reiniciar o container e checar os logs - attached. Você já viu algo assim?"
A diferença? Na segunda versão você:
Deu contexto específico (feature X, staging)
Mostrou o erro exato com localização
Explicou o que já tentou
Facilitou pra pessoa te ajudar rapidamente
Por que tantas perguntas falham
Perguntas são uma troca de tempo. A resposta é mais valiosa que a pergunta, então o peso de responder está em quem foi perguntado.
Uma pergunta ruim rouba tempo. Uma pergunta boa respeita ele.
Empatia significa: que contexto, screenshots, logs, links essa pessoa precisa pra me ajudar da melhor forma?
Como perguntas se tornam seu superpoder
Quando você consegue fazer boas perguntas, o crescimento da sua carreira vem junto. Essa é uma das habilidades com mais leverage que você pode aprender.
Perguntas ruins destroem reputação. Você rouba tempo das pessoas.
Mas o contrário acontece com boas perguntas.
Existem 4 níveis diferentes:
Nível 0: Não fazer perguntas Aprendizado mais lento, mas nada de ruim acontece.
Nível 1: Perguntas ruins Perde reputação. Ganha zero respostas ou respostas ruins.
Nível 2: Perguntas boas Ganha boas respostas e melhora sua reputação.
Nível 3: Perguntas incríveis Ótimas respostas. As pessoas querem te mentorar.
Por que boas perguntas constroem confiança
Fazer perguntas de qualidade demonstra conhecimento. Mostra pras pessoas: "eu sei o que estou fazendo, só preciso de um pouco de ajuda".
Quando você documenta as respostas, seniors valorizam isso. Você não só resolve seu problema - cria valor pro time todo.
Demonstra humildade. Você admite em público que não sabe algo. Essa transparência constrói confiança.
Perguntas como veículo de energia positiva
Aqui está um insight que pouca gente percebe: boas perguntas irradiam energia positiva.
Quando você faz uma pergunta bem estruturada, você está comunicando várias coisas implicitamente:
"Eu me importo o suficiente com esse projeto pra investir tempo formulando uma boa pergunta"
"Eu respeito seu tempo e expertise"
"Eu quero aprender e crescer"
Compare estas duas abordagens:
❌ Energia baixa: "Não tô conseguindo fazer isso funcionar, me ajuda aí?"
✅ Energia alta: "Olha, tentei implementar aquela validação que discutimos ontem. Seguindo a doc que você me passou, mas tô travado numa parte específica. Você teria uns 5 minutos pra me dar uma força?"
Na segunda versão você mostrou:
Que tomou ação baseada numa conversa anterior
Que seguiu orientações prévias
Que respeita o tempo da pessoa (pediu 5 minutos)
Que está empolgado pra resolver e seguir em frente
O poder da gratidão nas perguntas
Gratidão não é só sobre dizer "obrigado" no final. É sobre reconhecer o valor que a pessoa está agregando.
Experimente isso:
Antes da pergunta: "Sei que você manja muito de performance, por isso estou vindo falar contigo..."
Depois da resposta: "Cara, isso fez total sentido! Vou implementar e te mando feedback"
Follow-up: "Opa, deu super certo aquela sua sugestão. Performance melhorou 40%. Muito obrigado!"
Quando você fecha o loop assim, a pessoa fica feliz em te ajudar de novo. Você não é só alguém que pergunta - é alguém que executa e valoriza ajuda.
Quando você deve pedir ajuda
A pergunta que todo engenheiro começando faz: "eu devo descobrir sozinho ou perguntar alguém?"
Cenário 1: Nunca fazer perguntas Qualquer dúvida, você persiste sozinho. Passam dias. Você perde deadline. Não tem updates pra dar.
Cenário 2: Perguntar demais Qualquer sinal de dúvida, você pergunta. Não tenta pensar. Com o tempo, vira um peso no time.
Queremos evitar ambos.
O objetivo é encontrar o meio termo saudável. Peça ajuda quando faz sentido e você realmente precisa. Tenha persistência, mas conheça seus limites.
Quando esgotar seus caminhos viáveis, aí você pede ajuda. Explicando o que já tentou.
A regra das 2 horas
Se você precisa de ajuda com algum produto interno da empresa:
Leia a documentação
Procure no Slack/Teams/Drive/plataforma de conhecimento da empresa
Tente resolver em 1 hora. Se não conseguir, peça ajuda. Mas nunca passe mais de 2 horas na mesma etapa
Você deve pedir ajuda mais cedo se:
Tiver deadline urgente
For novo na empresa
For júnior (início de carreira)
Estiver em time distribuído globalmente (sua pergunta pode demorar horas pra ser respondida)
Faça perguntas em público
Seja transparente com o que você não sabe.
Muitos engenheiros tentam esconder o que não sabem. Um sinal disso: perguntas feitas do jeito mais privado possível, em 1:1s.
Faça o oposto.
Pergunte em canais públicos. Maximize a audiência que pode responder.
Experiências raramente são únicas. Quando você tem uma dúvida, há uma chance enorme de outra pessoa ter a mesma dúvida, ou vai ter no futuro.
Ao fazer perguntas em público, você cria um artefato permanente desse conhecimento.
Você se torna um líder
Muitas pessoas têm medo de perguntar em público.
Quando você faz uma pergunta em público, cria um espaço seguro pra compartilhar conhecimento. Outras pessoas com a mesma dúvida vão aparecer!
Apenas por ter coragem de perguntar, você já se mostra como líder nesse grupo.
Crie artefatos com o que aprendeu
Primeiro benefício: você sempre terá isso como referência.
Seu artefato também serve pro seu eu do futuro e outras pessoas da equipe.
Da mais simples pra mais efetiva:
A mensagem no Slack/Teams já é suficiente
Adicione na descrição do seu PR
Anuncie num canal com mais pessoas
Crie um arquivo CONTRIBUTING.md no repositório
Adicione na documentação interna
Quanto maior a audiência, maiores os benefícios pra você e sua equipe.
Se você construir um banco de perguntas e respostas de qualidade e se tornar conhecido por isso, só tem a ganhar.
Comunicação virtual: mate o "oi tudo bem?"
Vamos falar de um assunto sensível na nossa cultura brasileira.
É hora de matar o "oi tudo bem?".
Por que essa prática é prejudicial
Mensagens como "oi tudo bem?" criam atrito desnecessário na comunicação:
1. Força uma conversa síncrona A pessoa precisa responder primeiro pra depois saber do que se trata. Em times remotos, isso pode significar horas de delay.
2. Cria ansiedade "Será que é algo urgente? Problemático? Vou ter que parar tudo pra responder?"
3. Quebra o flow A pessoa interrompe o que está fazendo pra responder um "oi", só pra descobrir que podia ter esperado.
4. É ineficiente Transforma 1 mensagem em 3-4 mensagens pra chegar ao ponto.
Outros exemplos problemáticos:
"Olá, está por aí?"
"Oi Sophie, pergunta rápida"
"Tem um minutinho?"
"Tá aí?"
"Ei"
"Posso te fazer uma pergunta?" (mas já não está fazendo?)
Em contexto internacional, isso é ainda mais problemático. Diferentes timezones significam que seu "oi" pode ficar 8 horas sem resposta.
Perguntar diretamente o que você quer não é falta de educação!
Se quiser cumprimentar (virtualmente), faça isso direto na pergunta:
✅ "Opa mano, tudo jóia? Você tem ideia de qual o prazo daquela feature?"
✅ "Olá, tudo bem? Quando tiver um minutinho, eu estava precisando daquele último design"
✅ "Oi, quando puder, você pode atualizar aquelas NFRs?"
Esses exemplos foram inspirados no nohello.net, site dedicado a isso. Conheço pessoas que até colocam "nohello" como status no Slack. 😅
🌟 Resumo
Empatia é o princípio: se coloque no lugar de quem responde, forneça contexto suficiente
Perguntas são investimento: boas perguntas constroem reputação e relacionamentos, ruins destroem
Regra das 2 horas: tente resolver sozinho primeiro, mas não passe disso pra não travar
Público > privado: maximize quem pode responder e crie conhecimento permanente pro time
Mate o "oi tudo bem?": vá direto ao ponto respeitando o tempo das pessoas
Agora vá fazer bom uso do seu superpoder de fazer boas perguntas. Se ficou alguma dúvida, pode deixar nos comentários!
Volte pra me contar como foi sua experiência fazendo perguntas depois de ler esse artigo.
Fico feliz que você leu o artigo até o final! 🙏
Você também pode clicar no botão de curtir ❤️ e compartilhar este artigo com outras pessoas. Me ajuda muito!
Olá Lucas. Excelente artigo. Obrigado por nos ensinar isso.
Muito útil! Publicação salva para compartilhar sempre que tiver a oportunidade :D
Confesso que o 'nohello' me pegou um pouco, sou adepta mas entendo algumas pessoas que não são, tenho um certo dilema rsrs