Primeiros 90 Dias em Empresa Americana Remota

No escritório, integração acontece por osmose: você ouve conversas, almoça com o time, percebe o humor da empresa caminhando pelos corredores. Remoto não tem nada disso. Cada informação que você não busca ativamente, você não tem. Cada relacionamento que você não constrói deliberadamente, não existe.

Para devs brasileiros em empresas americanas, o desafio é duplo: além da barreira do idioma, há uma barreira cultural. Americanos são diretos ao ponto e esperam comunicação frequente e proativa. Silêncio é lido como desengajamento — não como humildade ou respeito.

A boa notícia: empresas americanas que contratam devs remotos já têm processos de onboarding documentados. Sua missão é segui-los com disciplina, fazer as perguntas certas e aparecer mais do que você acha necessário.

• •Dado importante: 20% dos novos contratados em remote-first companies saem ou são desligados nos primeiros 90 dias — e a maioria dos casos não é por falta de habilidade técnica, mas por falha de comunicação ou alinhamento cultural.
• •Empresas que usam o framework "30-60-90 day plan" têm 2x mais retenção em contratações remotas do que empresas sem estrutura formal.
• •A média salarial para devs brasileiros em empresas americanas remotas em 2026 está entre US$ 5.800 e US$ 8.000/mês — o esforço de se integrar bem tem retorno direto na conta bancária.

A primeira semana não é sobre código. É sobre entender o terreno. Desenvolvedores que correm para abrir PRs no dia 2 quase sempre escrevem código que vai na direção errada — e perdem reputação tentando mostrar velocidade.

O checklist da semana 1

• •Configure o ambiente completamente no dia 1. Se o README de setup quebrar, abra um PR corrigindo-o. Isso mostra iniciativa e cria boa impressão antes da primeira daily.
• •Leia o handbook da empresa. Notion, Confluence, Google Docs — onde estiver. Policies de PTO, horários de reunião, como funciona o ciclo de performance, quem decide o quê.
• •Mapeie os stakeholders. Quem é o tech lead? Quem é o PM? Quem tem mais contexto do domínio? Quem você vai depender para deploys? Faça um mapa mental.
• •Marque 1:1s informais. Mande mensagem para cada membro do time: "Olá, sou [nome], acabei de entrar no time. Posso marcar 15 minutos para me apresentar?" 90% das pessoas aceitam e ficam felizes.
• •Entenda o produto pelo lado do usuário. Crie uma conta, use as features principais, pergunte qual é o maior problema que o time está resolvendo este trimestre.

No final da semana 1, você deve conseguir responder: qual é o maior problema que o time está resolvendo agora? Quem são as 3 pessoas que mais influenciam decisões técnicas? Onde fica a documentação de arquitetura?

A partir da segunda semana, você começa a pegar tarefas. O objetivo até o dia 30 é: entregar tasks de complexidade média com qualidade e sem precisar de muito suporte. Não precisa ser rápido — precisa ser confiável.

Como comunicar bloqueios do jeito americano

Este é o ponto onde devs brasileiros mais erram. No Brasil, é comum ficar parado por horas tentando resolver sozinho antes de pedir ajuda. Nos EUA, silêncio por mais de 2-3 horas numa task bloqueada é sinal de alarme para o tech lead.

O formato correto para comunicar bloqueio em Slack:

• •"Hey @tech-lead, estou travado em [problema específico]. Tentei [abordagem A] e [abordagem B]. Acho que pode ser [hipótese]. Pode me dar uma direção?" — Esse formato mostra que você tentou, economiza o tempo do outro e demonstra raciocínio estruturado.
• •Nunca mande só "estou com um problema" sem contexto — isso força o outro a pedir detalhes e dobra o trabalho de comunicação.
• •Use threads no Slack. Nunca responda em mensagem principal quando está em uma thread — americanos são religiosos com organização de conversas.

Postura em code reviews

Nos primeiros 30 dias, o objetivo no code review é aprender o estilo do time, não defender suas escolhas. Quando alguém comentar seu PR, agradeça e implemente. Só entre em debate quando tiver contexto suficiente para argumentar com dados — geralmente a partir do mês 2.

Do dia 31 ao 60, o foco muda: você deve começar a contribuir para o time além das suas tasks. A forma mais rápida de ganhar visibilidade em empresa americana é virar referência em um assunto específico — mesmo que seja pequeno.

Como virar "a pessoa que sabe de X"

• •Escreva documentação. Encontrou algo não documentado enquanto fazia uma task? Documenta. Postou no canal #engineering-docs com "Adicionei doc sobre o módulo X que estava faltando" — isso é moeda social de altíssimo valor.
• •Revise PRs dos outros. Mesmo sendo novo, você pode revisar PRs. Comentários como "não entendi bem essa parte, pode adicionar um comentário explicando?" são bem-vindos e mostram engajamento.
• •Traga um insight externo. Viu um artigo sobre uma tecnologia que o time usa? Compartilha no Slack com uma nota de 2 linhas sobre por que é relevante. Devs que trazem conhecimento de fora são valorizados.
• •Peça e dê feedback regularmente. No 1:1 com o manager, pergunte: "O que eu poderia fazer diferente?" E quando tiver feedback positivo sobre um colega, fale — americanos adoram reconhecimento público no Slack.

O benchmark do dia 60: você deve estar contribuindo em code reviews de outros membros do time com comentários úteis. Se ainda não chegou lá, é hora de agir proativamente.

O dia 90 é o benchmark universal em empresas americanas: você deve ser capaz de trabalhar de forma autônoma em features de qualquer complexidade, mentorear colegas e participar ativamente de decisões técnicas. Quem chega lá com essa maturidade raramente é desligado — e quem não chega começa a entrar no radar negativo do manager.

O que fazer nas semanas 9–12

• •Proponha uma melhoria. Não reclamando, mas trazendo solução: "Percebi que o processo de deploy manual está causando X. Pensei em [solução Y], faz sentido discutirmos?" — Isso demonstra ownership.
• •Prepare o 90-day review. Muitas empresas americanas fazem uma conversa formal no fim do onboarding. Chegue com: o que aprendi, o que entrego, o que quero aprender nos próximos 90 dias, onde preciso de suporte.
• •Alinhe expectativas de carreira. Pergunte ao manager: "Qual é o perfil de alguém que performou bem aqui nos primeiros 6 meses? O que eu posso fazer para chegar lá?" Mostre que você está pensando em longo prazo.
• •Ajude o próximo contratado. Se um novo dev entrar no time, ofereça ajuda no setup e compartilhe dicas. Isso cria capital social e mostra maturidade.

O fuso horário como vantagem, não obstáculo

Devs brasileiros que trabalham com times na Costa Leste (EST) têm uma sobreposição de cerca de 4 horas por dia (13h–17h BRT). Em vez de tentar "imitar" o horário americano — o que leva ao esgotamento — use a sobreposição para reuniões e Slack síncrono, e as manhãs brasileiras para trabalho profundo sem interrupções. Você entrega mais código nas manhãs silenciosas do que qualquer dev americano que começa o dia em reuniões.

Cultura americana de trabalho tem diferenças reais em relação à brasileira. Conhecer essas diferenças antes de cair nelas vale meses de reputação.

• •"Sure, no problem" ≠ sim. Americanos usam frases positivas por padrão social, mesmo quando têm dúvidas. Aprenda a ler o contexto e confirme entendimento com "só para alinhar, você está dizendo que X, certo?".
• •Não discuta salário com colegas. Nos EUA isso é um tabu forte. Mesmo que a empresa tenha transparência salarial, evite o tema em conversas informais com colegas diretos.
• •Reuniões têm agenda — respeite. Trazer assuntos fora da agenda em reuniões americanas é mal-visto. Se tiver algo importante, manda no Slack antes e pede para incluir na pauta.
• •PTO é sério. Tire suas férias. Devs que nunca tiram PTO nos EUA são vistos como alguém que não sabe gerenciar limites — não como dedicados. Isso é o oposto do Brasil.
• •Feedbacks diretos na frente do time são normais. Um "acho que essa abordagem tem um problema" num canal público não é agressão — é colaboração. Não leve para o lado pessoal.

O VagaNaGringa tem um coach de carreira que ajuda devs a preparar exatamente esses cenários de comunicação antes de começar — simular reuniões, praticar como dar e receber feedback em inglês, e entender as nuances culturais que só aparecem no dia a dia.