Minha primeira semana num emprego gringo (e o que eu faria de novo)

Passei vinte minutos escolhendo entre "Hi everyone" e "Hello team" na mensagem de apresentação. Depois de quase 10.000 currículos e mais de 100 entrevistas, quem quase me derrubou foi uma caixa de texto do Slack. Primeira semana de emprego gringo mexe com a cabeça. Segue o que funcionou na minha.

A síndrome do impostor chega junto com o notebook

Nos primeiros dias eu tinha certeza de que tinham contratado a pessoa errada. Reli a oferta procurando pegadinha. Eu nunca me achei fora da curva (na real me sinto abaixo dela), então parti do princípio de que confiança não ia aparecer sozinha. Precisava de método.

O método foi o mesmo caderno das entrevistas: anotar. Cada tarefa entregue, cada pergunta respondida, cada "thanks, that helps" que eu recebia. Na sexta, relia a lista. A sensação de fraude não some com anotação, mas perde a discussão: a lista dizia que eu estava entregando, e contra fato registrado a cabeça argumenta menos.

Outra coisa que ajuda é saber, desde o dia 1: todo mundo chega sem saber nada. O time espera semanas de ramp-up. A pressa era só minha.

Semana 1 não é pra brilhar

A tentação de chegar sugerindo refatoração pra provar valor é grande. Segura. Você ainda não sabe por que o código é daquele jeito, e sugestão precoce erra muito mais do que acerta.

Metas realistas pra primeira semana:

• Rodar o projeto localmente, do zero, seguindo a documentação.
• Entender o fluxo principal do produto: o que o usuário faz, por onde o dado passa.
• Ler os últimos PRs mergeados do time: tamanho, tom de review, padrão de descrição. Isso ensina a cultura mais rápido que qualquer wiki.
• Abrir um primeiro PR pequeno: typo na doc, ajuste mínimo. O objetivo não é impacto: é destravar o circuito inteiro de branch, CI, review e merge com risco zero.

Marca 1:1 com todo mundo

Nas duas primeiras semanas, chamei cada pessoa do time pra 30 minutos. Roteiro de três perguntas:

• O que você faz e em que parte do sistema mexe?
• O que eu deveria ler ou estudar primeiro?
• O que você gostaria de ter sabido quando entrou?

Ninguém achou estranho. Onboarding remoto é rotina pra eles, e a maioria das pessoas gosta de explicar o próprio trabalho. O que mais me travava eram os primeiros minutos de conversa fiada antes do assunto. small talk com gringos tem truque pra isso.

Pergunta cedo, e por escrito

Existe uma janela em que pergunta básica é grátis: as primeiras semanas. Depois ela vai fechando. Usa a janela enquanto está aberta.

Minha regra: tento sozinho por 30 a 45 minutos, anoto o que tentei, e pergunto no canal público do time, não em DM. Perguntar em público parece mais exposto e é melhor: a resposta ajuda o próximo que chegar e vira documentação de graça.

Detalhe que joga a nosso favor: por escrito, você tem tempo de pensar o inglês. Call ao vivo é outro esporte. reuniões em inglês me custaram mais suor que qualquer PR da primeira semana.

Pequenas vitórias que contam

O que eu anotei como vitória nos primeiros dias, e recomendaria perseguir:

• Primeiro PR mergeado, de qualquer tamanho.
• Doc de onboarding corrigida por você. Achou passo quebrado no setup? Conserta e manda PR. É a melhor primeira contribuição que existe. Você é a última pessoa que vai ver aquela doc com olhos de novato.
• Uma pergunta sua no canal que acabou ajudando outra pessoa.
• Na sexta, mensagem curta pro gestor: o que fiz, o que aprendi, o que planejo pra semana que vem. Três linhas. Sem cerimônia, sem pedir permissão pra existir.

O que eu faria diferente

• Menos "sorry", mais "thanks". "Sorry for the dumb question" vira "thanks for the context". Mesmo conteúdo, outra postura.
• Câmera ligada desde o dia 1. Rosto constrói confiança mais rápido quando ninguém te encontra no corredor, e o equipamento pra isso não precisa ser caro, listei tudo em o setup que importa pra calls.
• Aceitar desde cedo que entender o codebase leva semanas e que ninguém espera diferente. A cobrança de entender tudo em três dias era invenção minha.