A gente olha centenas de currículos de devs que se candidatam a posições remotas na Howdy, e o padrão se repete: React, Node, Docker, Kubernetes, AWS, 6 anos de experiência. Esse currículo é indistinguível do de outros 40 candidatos com o mesmo stack. O problema não é a experiência, é que a lista de ferramentas não diz nada sobre se você consegue trabalhar sem que alguém esteja revisando cada uma das suas decisões, que é exatamente o que uma equipe dos EUA precisa de um dev remoto sênior.
Um hiring manager que contrata pra trabalho remoto não está procurando o stack, está procurando o sinal de que você consegue operar com autonomia real: tomar uma decisão técnica diante da ambiguidade e responder pelo resultado sem ninguém olhando por cima do seu ombro. Esse sinal não está na lista de tecnologias. Está em como você conta o que fez.
A diferença entre listar tarefas e mostrar critério
Compare essas duas formas de descrever a mesma coisa. Versão um: "Desenvolvi APIs REST com Node.js e Express, trabalhei com bancos de dados PostgreSQL, participei de code reviews". Versão dois: "Desenhei a migração de um monólito pra três microsserviços quando a equipe determinou que os deploys semanais estavam gerando risco demais; separei primeiro o serviço de pagamentos porque era o que mais gerava incidentes, e reduzi o tempo de deploy de 40 minutos pra 6".
A segunda versão não menciona mais tecnologias do que a primeira. Menciona uma decisão, o motivo por trás dessa decisão, e um resultado mensurável. É isso que uma equipe remota dos EUA lê como "essa pessoa consegue operar sem que eu precise ficar explicando o que fazer".
Conte decisões, não responsabilidades
Pra cada experiência profissional que você colocar no currículo, se pergunte: que decisão eu tomei aqui que outra pessoa com menos critério não teria tomado do mesmo jeito? Se você programou uma feature seguindo um ticket detalhado passo a passo, essa não é a história que vale a pena contar. Se você teve que escolher entre duas arquiteturas possíveis, justificar por que escolheu uma, e assumir quando algo saiu diferente do esperado, essa sim.
Não precisa ter sido tech lead pra ter essas histórias. Um desenvolvedor pleno que decidiu como estruturar um módulo, ou que identificou e resolveu um gargalo de performance sem que ninguém tenha pedido, já tem material. A chave é nomear a decisão explicitamente, não escondê-la dentro de uma descrição genérica de tarefas.
Números que importam (e os que não importam)
Os anos de experiência importam bem menos pra uma equipe remota do que o tamanho do problema que você resolveu. "8 anos de experiência" é um dado demográfico. "Reduzi o tempo de carregamento de um app com 200 mil usuários ativos de 4,2 pra 1,1 segundo otimizando queries N+1" é evidência. Se você consegue quantificar o impacto do que fez (usuários afetados, tempo economizado, incidentes evitados, custo reduzido), faça isso. Se não tem o número exato, uma aproximação honesta vale mais do que omitir.
Cuidado com o extremo oposto: encher o currículo de métricas infladas é fácil de detectar numa entrevista técnica, assim que pedem pra você explicar como chegou naquele número. Um único exemplo bem explicado pesa mais do que cinco bullets de conquistas que você não consegue sustentar numa conversa de dez minutos.
O que uma equipe dos EUA precisa ver antes da entrevista
Antes de investir 45 minutos numa entrevista técnica, um hiring manager remoto quer reduzir o risco de que a comunicação assíncrona e a falta de supervisão direta virem um problema. Isso significa que seu currículo deveria responder, mesmo que implicitamente, três perguntas: você já trabalhou numa equipe distribuída ou com fusos horários diferentes?, você tomou decisões técnicas sem que alguém validasse em tempo real?, seu inglês escrito é claro o suficiente pra não gerar atrito numa thread do Slack?
Se você tem experiência remota anterior, mesmo que tenha sido parcial ou freelance, priorize ela. Se não tem, procure na sua experiência presencial os momentos em que você colaborou de forma assíncrona com outro escritório, coordenou com uma equipe distribuída, ou resolveu um problema técnico sem supervisão direta, e conte essa história com o mesmo nível de detalhe que usaria pra uma conquista técnica.
Formato: que dê pra escanear em 15 segundos, não que impressione
O design do seu currículo importa menos do que você imagina, mas não é irrelevante. Os sistemas ATS (Applicant Tracking Systems) filtram antes de um humano ver, então você precisa de uma estrutura simples: seções claras, sem tabelas aninhadas nem gráficos que o parser não consiga ler, e as palavras-chave da vaga integradas de forma natural nas suas descrições de experiência, não coladas no final numa lista separada.
Depois que você passa pelo filtro automático, tem entre 15 e 30 segundos de atenção real da pessoa que está lendo. Coloque o link do seu GitHub ou portfólio no topo, não no final. Se o seu repositório tem commits recentes e um README claro, isso vale mais do que qualquer certificação que você adicione ao currículo.
O erro que mais estraga currículos seniores: a humildade mal entendida
A gente já viu dezenas de currículos de devs com sete, oito anos de experiência que descrevem o trabalho com a mesma linguagem tímida que alguém usaria no primeiro emprego: "colaborei no desenvolvimento de", "participei da implementação de", "ajudei a melhorar". Essa linguagem esconde exatamente a informação que uma equipe remota precisa: quem decidiu o quê.
Também não é questão de exagerar seu papel: basta ser preciso sobre sua responsabilidade real. Se você liderou a decisão, diga assim: decidi, desenhei, implementei. Se você contribuiu pra decisão de outra pessoa, conte especificamente qual foi sua contribuição. A vagueza não te faz parecer modesto, te faz parecer substituível.
Um currículo que lista ferramentas te coloca na mesma pilha de centenas de candidatos com um stack parecido. Um currículo que mostra decisões, contexto e resultado te tira dessa pilha, porque dá ao recrutador o único sinal que realmente importa pra uma vaga remota: que você consegue operar com critério próprio sem que ninguém precise revisar seu trabalho linha por linha.
