São 18h de uma terça. Você ouve o terminal apitar. Claude Code acaba de abrir um PR de 800 linhas que inclui testes, atualiza o CHANGELOG e marca dois reviewers. Você lê o diff. Está bom. Não é excelente, mas é bom o suficiente para entrar em produção amanhã.

Aí bate aquele pensamento: “se a IA escreve o PR, o que sobra para mim?”

Eu entendo essa ansiedade.

Nos últimos anos, trabalhando em times de produto pequenos, eu percebi uma coisa meio desconfortável: as melhores oportunidades que tive não vieram quando eu escrevi mais código.

Vieram quando eu entendi melhor o problema.

Quando eu parei de perguntar só “como implemento isso?”

E comecei a perguntar “por que isso merece existir?”

A resposta certa não passa por aprender mais frameworks ou virar especialista em IA.

Você precisa parar de competir com a parte que a IA faz bem.

Escrever código ainda importa. Mas deixou de ser suficiente.

Quem decide o que codar, para quem e por quê é o novo gargalo. E é exatamente quem as empresas estão pagando mais.

Esse cargo já tem nome em vários lugares: Product Engineer. Vagas abertas em empresas como PostHog, Linear, WorkOS, Kraken. Está começando a aparecer em empresas brasileiras. É a melhor notícia que você recebeu sobre sua carreira nos últimos cinco anos.

Esse artigo é um mapa de como chegar lá em 2026. Sem hype, sem “todo mundo virou full-stack agora”, sem “o programador morreu”. Com dados de fontes recentes, vagas reais que você pode aplicar amanhã, e uma autoavaliação honesta de onde você está hoje.

✨ O que esperar do artigo

• Por que codar virou commodity em 2026 e o que isso significa para a sua carreira

• O cargo de Product Engineer que está aparecendo nas vagas de Linear, PostHog, e startups BR de série B+

• As 4 habilidades que separam programador de Product Engineer, com framework do Marty Cagan e exemplos reais

• Por que o trabalho de engenharia está ficando mais divertido, não menos

• 3 ações concretas para começar segunda de manhã

O que mudou (e por que agora)

A frase mais importante de 2026 sobre engenharia veio da Andressa Chiara, na masterclass que publicamos em março: “codar virou commodity.”

Em março de 2026, a IA já escreve a maior parte do código novo em times competitivos. O Luca Rossi, no Refactoring, publicou ontem (29 de abril) que times com boa Developer Experience estão hoje, no 90º percentil, entregando mais que 2x mais rápido do que entregavam três anos atrás. Esse número vem da medição direta do trabalho desses times.

Os números do mercado parecem contraditórios à primeira vista. Vagas de software engineer subiram 30% em 2026, segundo o levantamento da Metaintro, com mais de 67 mil posições abertas globalmente. Maior demanda em três anos.

Mas no primeiro trimestre de 2026 também aconteceram 52 mil layoffs em tech, segundo o mesmo levantamento, e quase metade deles foram atribuídos diretamente a IA.

A leitura honesta dos dois números juntos:

Empresas estão demitindo engenheiro que só executa backlog. E contratando engenheiro que sabe trabalhar com IA, decidir o que construir e entregar valor de produto.

É a mesma profissão dividida em dois universos diferentes.

Aqui no Brasil, isso já está nos processos seletivos. A DoorDash, na masterclass que publicamos em abril, revelou que adicionou uma quarta entrevista, focada em IA, no processo. A justificativa do próprio time foi direta: “se 50% do código interno já é gerado por IA, entrevistar sem IA produz sinal falso.”

A Andressa coloca de outro jeito. Quem só executa backlog vira commodity. Quem entende o problema do cliente, prioriza trade-offs e valida hipóteses antes de construir, fica exponencialmente mais valioso.

A lógica é simples. Quando o input fica barato (escrever código), o gargalo migra para cima da cadeia (decidir o que merece ser escrito). Quem está no novo gargalo, ganha. Quem está no antigo, fica de fora.

O teste honesto. Se você consegue resumir o seu trabalho como “pego o ticket e implemento”, você está descrevendo um trabalho que IA vai fazer melhor que você, eventualmente.

Product Engineer: o cargo que captura essa mudança

Tem um padrão claro nas empresas que mais entendem essa transição. Elas não estão sumindo com PMs e designers. Estão criando um quarto papel ao lado deles: o Product Engineer.

Empresas como Linear, Vercel, Stripe, Anthropic e PostHog têm vagas com esse nome explícito hoje. Os papéis tradicionais não sumiram, PMs e designers continuam existindo. O que mudou é que agora tem um cargo de engenharia em que produto não é tarefa de outra pessoa.

A Linear deixou explícito num post publicado dia 28 de abril os critérios que usam para contratar nesse modelo. Vale ler de perto, porque é o estado da arte de como empresas top contratam Product Engineers em 2026:

“We value slope over credentials. Someone growing fast and thinking clearly will often outperform someone with more years and logos on their resume.”

“We don’t use OKRs or run A/B tests. Decisions get made with taste, customer insight, and direct judgment.”

“You shape direction, make decisions, talk to users when needed, and communicate progress. It’s a full-stack way of working, and it requires someone who doesn’t need a lot of process to stay oriented.”

Repare nos quatro pilares: slope, taste, judgment, ownership. Todos são habilidades que se desenvolvem trabalhando próximo de produto. Nenhuma delas tem a ver com qual linguagem você sabe.

Outra versão desse modelo está numa empresa onde eu trabalho hoje: a PostHog. A operação é organizada em Small Teams: times de 2 a 6 pessoas em que os engenheiros têm responsabilidade direta sobre a área de produto que constroem. No handbook público:

“With our engineering-led culture, the engineers on the small team are normally responsible for their area of the product.”

“The engineers should be the experts of the product they are building and their customers.”

“A small team has the final call in which of its features get into production, with no need for external QA/control.”

A vaga oficial é literalmente “Product Engineer”. Cada projeto tem um único dono dentro de um único time pequeno. PMs existem na empresa, mas atuam como suporte multi-time, ajudando com priorização, dashboards e pesquisa competitiva. Não como decisores do que construir.

A Anthropic, com o cargo de Forward Deployed Engineer, leva a ideia para outra ponta: combina engenharia, consultoria de produto e domínio profundo de LLM, alocado direto em clientes estratégicos.

E aqui no Brasil, o movimento já chegou. Várias startups de série B+ estão abrindo posições com perfil similar, mesmo quando o título oficial ainda é “engenheiro de software sênior”.

O que pesa na entrevista mudou.

O que um Product Engineer faz de diferente

Andressa resumiu na masterclass com a melhor comparação que já vi sobre o tema:

Repare: nenhuma das diferenças é técnica. O que define um Product Engineer é o jeito de pensar: começar pelo problema antes de propor a solução.

Que é exatamente a parte que a IA não faz por você.

A pergunta da promoção. Você está esperando ser tratado como parceiro de produto, ou está demonstrando que merece estar nessa conversa? Essa é a diferença entre Senior e Staff+ na maioria das empresas competitivas.

Como isso aparece numa entrevista

Você não precisa ter “Product Engineer” no título do LinkedIn.

Você precisa mostrar sinais.

Quando perguntarem sobre um projeto, não responda só:

“Implementei X usando React, Node e PostgreSQL.”

Responda:

“O problema era X. Afetava o usuário Y. A gente considerou A, B e C. Escolhemos C porque era o jeito mais barato de validar a hipótese. Depois medimos Z.”

Isso muda completamente o sinal que você passa.

Você deixa de parecer alguém que só executa ticket.

E começa a parecer alguém que entende produto, trade-off e impacto.

As 4 habilidades de um Product Engineer

Se Product Engineer é o cargo, quais skills você precisa desenvolver para chegar lá? Quatro, na minha leitura.

1. Taste

Taste é a habilidade de olhar para um produto e saber o que está quebrado, o que está medíocre e o que está com cara de coisa bem feita. Sem essa habilidade, você fica refém do que outras pessoas acham bom.

A Linear, no post de hiring de abril, lista craft como um dos cinco atributos que avaliam ao contratar. Sobre ele, escrevem: “You care about doing work well and have built real depth in your domain. You notice details that matter. You know the difference between extra effort and meaningful quality.”

Taste não vem de MIT nem de diploma. Vem de quanto produto bom você consumiu, com atenção, e de quanto produto ruim você consumiu sentindo o porquê de ser ruim.

Ações concretas:

• Mantenha uma pasta de screenshots de UI que te emocionou, positiva ou negativamente. Volte nela toda semana.

• Compare três produtos que resolvem o mesmo problema. Anote o que cada um faz melhor e por quê.

• Aprenda os princípios de afordância. A forma do botão sugere “clique”. O campo de texto sugere “digite”. O toggle sugere “ligue ou desligue”. Comece a notar onde produtos rompem com isso e por que dói.

Engenheiro com taste participa de decisões de design sem virar designer, e melhora a experiência do produto sem ficar dependente da próxima sprint do time de design.

2. Product thinking

A skill de transformar “vamos implementar feature X” em “qual problema queremos resolver e quais são as três formas mais baratas de testar isso?”.

Andressa apresenta dois frameworks na masterclass de março da NaGringa: as 4 hipóteses do Marty Cagan (problema existe? solução resolve? viável? escala?) e a Opportunity Solution Tree da Teresa Torres.

O exercício mais útil dela é o template de hipótese:

“Acreditamos que [ação] vai [resultado mensurável], porque [evidência ou premissa].”

Pegue qualquer feature do seu backlog hoje. Reescreva nesse formato. Você vai descobrir, em 30 segundos, se a feature tem evidência por trás ou se é chute.

3. Compound leverage com IA

O Luca Rossi descreveu, no artigo publicado dia 29 de abril, o caminho de como times de engenharia tiram alavancagem real de IA: specs → rules → modules. O engenheiro deixa de ser quem escreve código, e passa a ser quem captura decisões em formato que a IA pode reaplicar.

Em 2026, esse é o trabalho de fato:

• Capturar o que existe. Recap docs, ADRs, PRDs versionados.

• Definir como as coisas devem ser feitas. Rules, skills, lints.

• Criar checks que forçam o agente a respeitar essas regras.

• Reaproveitar o trabalho via módulos prontos.

Engenheiro que faz isso bem amplifica tudo que entrega. Engenheiro que ainda trata cada feature como se fosse a primeira fica para trás.

A skill por trás disso é organizar conhecimento de um jeito que máquina entende, mais próxima de design de sistema de informação do que de programação tradicional. E é ela que separa quem vira 10x daqui dois anos de quem virou estagiário do Cursor.

4. Liderança técnica sem precisar do título

Felipe Adamoli e Waldemar Neto explicaram bem na masterclass de fevereiro: a passagem de Senior para Staff acontece quando “como eu entrego mais?” vira “como faço o time entregar mais?”.

Para Product Engineer, o salto é parecido. Você deixa de só implementar e começa a influenciar o que o time decide construir. Sem precisar do título, sem precisar pedir reorg.

O processo de quatro passos que eles propõem:

1. Conheça suas forças. Em que você é objetivamente melhor que a média do time?

2. Leia o ambiente. Que dores ninguém está olhando hoje?

3. Encontre oportunidade não-vista. Conecte sua força com uma dor real.

4. RFC antes de executar. Documente sua proposta antes de fazer.

Esse padrão é o motor por trás de quase toda promoção de Senior para Staff que vi acontecer nos últimos doze meses.

O trabalho que sobra é mais divertido

Tem uma narrativa pessimista circulando na comunidade brasileira que diz: “engenharia tá virando aplicação de IA para problema chato. Adeus arte de programar.”

Discordo.

Talvez eu esteja enviesado, porque essa sempre foi a parte que mais gostei da profissão.

Eu gosto de programar. Muito.

Mas a parte mais viciante nunca foi escrever a função perfeita. Foi pegar um problema ambíguo, conversar com pessoas, entender as restrições e transformar aquilo em algo real.

Código é o meio.

O produto é o jogo.

A parte do trabalho que vai para IA é justamente a parte chata.

Configurar webpack. Escrever boilerplate. Implementar 40 endpoints CRUD parecidos. Atualizar dependência. Renomear variável em dezenas de arquivos.

E o que sobra para o humano?

A parte interessante. Conversar com usuário. Decidir o que vale a pena resolver. Definir o produto. Garantir que a coisa funciona no mundo real. Cuidar das partes que pedem julgamento, gosto, política organizacional, criatividade.

A parte chata vai para IA. A parte boa fica com você.

Quem gostava de programar pelo desafio de resolver problema vai encontrar mais espaço para isso, com IA tirando da frente o trabalho mecânico. Quem gostava de programar só pelo ato de digitar código talvez precise descobrir o que mais te empolga na profissão.

O que fazer segunda de manhã

Esse artigo vale zero se você fechar a aba e voltar para o Jira. Três ações para começar amanhã:

1. Pegue a feature mais importante do seu sprint atual e reescreva como hipótese. “Acreditamos que [ação] vai [resultado], porque [evidência].” Se você não consegue preencher os colchetes, pare e descubra antes de codar uma linha.

2. Descubra quem é o usuário final do que você está construindo. Nome, cargo, o problema dele. Se você não sabe, pergunte amanhã no standup. Se ninguém do time sabe, esse é o problema número um.

3. Marque uma conversa de 30 minutos com o PM, designer ou líder de produto do seu time. Pergunta única: “qual decisão de produto que você tomou esse mês você gostaria de ter discutido com a engenharia antes?” Anote a resposta. Esse é o seu mapa de onde tem espaço para você crescer.

Essas três ações, feitas de verdade, mudam o jogo em 90 dias. Não é exagero. Já vi acontecer com membros da NaGringa que estavam travados há ano e meio.

Falando pessoalmente: foram exatamente essas três coisas que me ajudaram a ser visto como alguém high agency na Brex.

Não porque eu codava mais.

Mas porque eu chegava nas conversas com mais clareza sobre problema, trade-off e impacto.

🌟 Resumo

• Escrever código deixou de ser suficiente. O gargalo migrou para quem decide o que construir, para quem e por quê.

• Product Engineer não substitui PM nem designer. É um quarto papel ao lado deles, em que produto não é tarefa de outra pessoa. Os papéis tradicionais continuam existindo, as fronteiras é que ficaram porosas.

• Quatro habilidades compõem um Product Engineer: taste, product thinking, compound leverage com IA, e liderança técnica sem precisar do título.

• A parte chata do trabalho vai para IA. A parte boa fica com você. Conversar com usuário, decidir o que vale a pena resolver, definir o produto. É a engenharia que você sempre quis fazer.

• Comece segunda. Reescreva uma feature como hipótese, descubra quem é o usuário final, e marque uma conversa de 30 minutos com o PM ou líder de produto do seu time.

Hoje é o último dia da promoção da NaGringa

A gente segurou o preço da NaGringa pelo período de construção da plataforma. A ideia era simples: o valor entra primeiro, o reajuste depois. O reajuste é amanhã.

A partir de 01/05, à meia-noite (BRT), os valores sobem:

• Anual à vista (recomendado): R$ 997 → R$ 599 hoje com cupom ATE25

• Anual em 12x: R$ 1.668 → R$ 697 (R$ 58/mês) com cupom ATE25

• Mensal: R$ 197/mês → R$ 99/mês com cupom ATE25

O cupom ATE25 aplica automaticamente no link /assine?coupon=ATE25. Se você é assinante anual atual e quer estender mais um ano no preço de hoje, o mesmo cupom funciona.

O que tem dentro

• Masterclasses práticas. Product Engineering, pós-sênior, LinkedIn, carreira internacional, DoorDash e mais 10+ sessões.

• Análise de currículo 24h com o Gringo. Revisão e reescrita com foco no funil internacional.

• Mocks comportamentais. Simulações customizadas para sua entrevista, com feedback gravado.

• English classes semanais com a Andressa. Foco em entrevista.

• Acesso prioritário a vagas internacionais. Curadoria e feedback personalizado.

• Gringo sob demanda. Nosso AI agent treinado com tudo que publicamos.

• 1:1 com a equipe. Quinze minutos com Lucas, Laura ou Andressa

Por que vale a pena pelo preço de hoje

Argumento sem hype. Uma oferta internacional comum representa de R$ 10 mil a R$ 30 mil a mais por ano em comparação com uma vaga local equivalente. R$ 599 anuais é menos do que o custo de um jantar para dois em São Paulo. A matemática é absurda no nosso favor enquanto o preço estiver baixo.

A partir de amanhã ainda vale a pena, mas o desconto sai de cena.

Promo termina hoje, 30/04, à meia-noite (BRT).

→ Entrar agora com o cupom ATE25

Sem letra miúda. Sem extensão. Sem “deixa eu pensar até amanhã”. Amanhã o preço é outro.

📚 Recursos citados no artigo

• De Software Engineer a Product Engineer (masterclass com Andressa Chiara, março de 2026)

• A Engenharia Depois do Sênior (Felipe Adamoli e Waldemar Neto, fevereiro de 2026)

• Como Entrar na Engenharia da DoorDash Brasil (abril de 2026)

• The Compounding Software Factory (Luca Rossi, Refactoring, 29 de abril de 2026)

• How we hire at Linear (Doug Parker, Linear, 28 de abril de 2026)

• PostHog Small Teams handbook e Product Engineer JD

Novidade: lançamos o banco de perguntas de entrevistas reais do NaGringa. Já tem 1130+ perguntas de empresas internacionais, filtrável por empresa, senioridade e tipo. Você também pode contribuir com perguntas que recebeu em processos seletivos. Dá uma olhada nos filtros completos aqui.

Você ouviu que IA ia tornar todo engenheiro 10x mais produtivo.

Seu chefe leu que o Stripe está shippando 1300 PRs por semana1.

A empresa agora investiu: assinaturas de IA para todo mundo, Copilot em cada IDE, agentes no CI, Claude Code rodando automaticamente.

Três meses depois, o time está produzindo mais código do que nunca. Mais PRs, mais deploys, mais features.

E os mesmos problemas de antes. Ou piores: mais bugs, mais incidentes, mais retrabalho.

O código ficou mais rápido. O resultado, não.

Eu não precisei de IA para cometer esse erro. Fiz isso sozinho, antes de IA sequer existir do jeito que existe hoje.

Na Brex, passei semanas refatorando um componente de UI. Organizei o código, escrevi os testes, abri o PR. Tudo passou.

O resultado pro produto? Zero. Ninguém pediu aquela refatoração, e ela não resolveu nenhum problema real.

Refatoração não é desperdício por definição, mas aquela não tinha critério de sucesso. Não era “reduzir tempo de build de 8 para 2 minutos” ou “desbloquear o time Y para lançar feature Z”. Era código mais bonito sem um porquê.

Alguns meses depois, olhei para um dado diferente: 40% dos usuários abandonavam o fluxo de Bill Pay antes de completar.

Ninguém tinha me pedido para investigar isso. Instrumentei os eventos por conta própria porque queria entender se havia problemas no fluxo.

E havia. Vários campos tinham taxas de erro altíssimas. Usuários esqueciam de preenchê-los ou colocavam valores errados. A validação do backend falhava silenciosamente, travando o processo.

A solução não foi complexa: criei o conceito de campos “inteligentes”.

• Pré-preencher com o último método de pagamento usado

• Mostrar as últimas 3 contas pagas para o usuário poder copiar valores

• Se um campo não mudou nas últimas 3 transações (como a conta de destino), já vem preenchido

• Se havia apenas uma opção para o campo, selecionar automaticamente

Tudo sobre empurrar a complexidade para o código e simplificar a vida do usuário. Conversão subiu 26%, cerca de 160 usuários a mais por dia completando o fluxo.

Mesma habilidade técnica nas duas situações. A diferença foi que no Bill Pay eu tinha um sinal claro de que algo estava errado e uma definição de sucesso antes de abrir o editor.

Essa diferença ficou ainda mais clara quando a IA entrou de vez no meu trabalho. IA acelera execução: você escreve, refatora, testa em uma fração do tempo.

Mas IA não muda a pergunta que você faz antes de abrir o editor. E é essa pergunta que decide se o trabalho importa.

Um problema mais antigo do que você pensa

O problema de construir a coisa errada não é novo.

Marty Cagan já dizia em Inspired: “O maior risco é sempre construir algo que ninguém quer.” Donald Reinertsen mostrou em The Principles of Product Development Flow que reduzir tempo de execução sem melhorar a qualidade das decisões pode aumentar o desperdício.

Essa tensão entre velocidade e clareza existe há décadas.

O que mudou é que o custo natural do desenvolvimento costumava funcionar como um freio. Quando escrever código era caro, times eram forçados a pensar antes de construir. Havia uma pressão de seleção que filtrava ideias ruins antes delas virarem código.

IA removeu esse freio. Execução ficou barata, mas o custo de estar errado continua o mesmo.

Luca Rossi, da Refactoring.fm, tem uma analogia que captura bem essa dinâmica: desenvolvimento de software é um jogo de telefone sem fio2.

Tudo começa com a intenção de alguém. Essa intenção vira um documento de produto. Que vira um design. Que vira uma spec técnica. Que vira código. Que vai para produção. Cada etapa é uma chance da mensagem original se distorcer.

IA acelerou as etapas mais próximas do código. As primeiras etapas da cadeia, onde a intenção original se define, seguem sendo lentas, humanas e propensas ao erro.

Mike Krieger, co-fundador do Instagram, colocou isso de forma direta3: “Os modelos são bons em adicionar features. Eles não são necessariamente bons em descobrir o que cortar do produto.”

Ele foi além. Na Anthropic, construiu um produto inteiro com Claude antes do lançamento e percebeu que tinha adicionado funcionalidade demais. “Criamos uma matriz de funcionalidades que era difícil de testar e difícil de explicar para as pessoas.”

É o que ele chama de construir a árvore dentro de casa, sem exposição ao vento: ela cresce, mas não tem a estrutura que vem do contato com o mundo real.

Com IA, a tentação de adicionar “só mais uma feature” ficou ainda maior, porque o custo percebido de cada adição caiu perto de zero.

O problema não está onde você pensa

Luca Rossi publicou uma pesquisa com 340 times de engenharia4 que traz dados sobre onde exatamente a cadeia quebra. E o resultado foi contraintuitivo.

A maioria das pessoas assume que o problema começa na definição do problema, na falta de clareza sobre o “por quê”. Mas os dados sugerem o oposto: os engenheiros geralmente acreditam que entendem o porquê. O que eles não sabem é o que significa “feito”.

Vale uma ressalva: são dados auto-reportados. Há uma diferença entre acreditar que você entende o problema e realmente entendê-lo.

Mas mesmo com essa limitação, o gap entre “entendo o porquê” e “sei o que feito significa” é grande demais para ignorar.

Um tech lead que respondeu à pesquisa resumiu bem: “Os desenvolvedores não fazem perguntas suficientes durante o refinamento, o que leva a tickets incompletos. Ao mesmo tempo, os POs fornecem critérios de aceite muito genéricos.”

E aqui está a ironia: o investimento de IA está desalinhado com o problema.

A maioria usa IA para escrever código. Faz sentido, já que é onde IA é mais capaz hoje.

Mas os problemas que causam retrabalho, requisitos vagos e definição de “feito” incompleta, continuam intocados. Conforme IA ficar melhor em ajudar com discovery e requisitos, essa distribuição deveria mudar. Por enquanto, o gap existe.

A pergunta certa antes de uma linha de código

Voltando ao PostHog: quando comecei a trabalhar no Surveys, o onboarding era confuso. Formulários grandes, campos desconexos, customização demais exposta de uma vez.

Ninguém me pediu para mexer nisso. Era minha área de responsabilidade, então fui investigar. Instrumentei para entender quantas pessoas desistiam do fluxo de criação.

Tentei uma abordagem: menos campos visíveis, um wizard guiado, menos opções por etapa. A definição de sucesso era clara: mais surveys sendo criadas.

A taxa de conversão do onboarding melhorou 93%. Hoje, mais de 40% de todas as surveys são criadas por aquela tela.

O padrão é o mesmo nos dois casos, Brex e PostHog. O trabalho que gerou impacto foi o trabalho com uma definição clara de sucesso. O trabalho que sumiu foi o trabalho bem executado sem saber o que “feito” significava.

Isso é o que engenheiros de produto fazem diferente: eles não esperam o ticket chegar perfeito. Eles constroem a clareza que precisam antes de abrir o editor.

Luca Rossi chama isso de “ficar na altitude certa” no processo de desenvolvimento^[1-1]. Cada etapa da cadeia exige um tipo diferente de artefato, e você precisa inspecionar a coisa certa em cada ponto.

Se você está inspecionando código mas o problema está na definição do que deveria ser construído, nenhum code review vai resolver.

O engenheiro que Gergely Orosz descreveu como top 3% na Uber5 tinha um método específico. Assim que entendia o que precisava ser feito, quebrava tudo em partes no papel ou no quadro branco. Identificava os trade-offs e comunicava os stakeholders.

Não para pedir permissão, mas para alinhar o que “feito” significava antes de começar. Quando havia atrasos, comunicava como trade-offs, não como problemas.

O resultado dessa postura: uma reputação tão forte que empresas criam posições só para ele.

Como operar assim no dia a dia

Saber que o gargalo mudou é uma coisa. Mudar a forma de trabalhar é outra.

Isso não se aplica a todo tipo de trabalho. Um hotfix ou um bug de uma hora não precisa de uma sessão de discovery. Mas para qualquer trabalho que vai consumir mais do que um ou dois dias, esses hábitos fazem diferença.

John Ousterhout, em A Philosophy of Software Design, faz a distinção entre programadores “táticos” e “estratégicos”. O tático quer fazer a coisa funcionar o mais rápido possível. Cada tarefa é um sprint para o próximo commit.

O estratégico investe tempo entendendo a forma do problema antes de escrever código. Os três hábitos abaixo são o que programação estratégica parece na prática:

Defina o critério de sucesso antes de abrir o editor. A pergunta certa é “como vou saber se funcionou?”. Um número, um comportamento do usuário, uma métrica.

Se você não consegue responder isso antes de começar, o ticket está incompleto. E você vai descobrir isso no pior momento: no meio do sprint.

No Bill Pay, o critério era “reduzir a taxa de abandono do fluxo”. No Surveys, “aumentar a taxa de criação de surveys no onboarding”. Sem esses critérios, eu teria feito melhorias genéricas que talvez não mudassem nada.

Use o produto que você constrói. A tela do PostHog só existiu porque eu usava o Surveys e via o problema com meus próprios olhos. Nenhum ticket ia me dizer aquilo.

No Bill Pay, instrumentei os eventos por conta própria porque queria ver onde o fluxo travava. Engenheiros que usam o produto que constroem encontram problemas que PMs não conseguem articular, porque não dá para articular o que você não viu.

Questione o ticket, não apenas execute. Se o ticket diz “melhorar performance da página”, pergunte: qual métrica? LCP? Tempo de interação? Para qual threshold?

Se o requisito está vago, complete. Se a solução pedida resolve um sintoma em vez do problema, proponha outra.

O engenheiro da Uber fazia exatamente isso: comunicava trade-offs, não objeções. Objeção trava. Trade-off informa e dá opções para quem decide.

Se o seu trabalho é infraestrutura, plataforma ou SRE, o critério de sucesso não vai ser uma taxa de conversão. Mas a pergunta é a mesma: “como vou saber se funcionou?”

Pode ser latência p99 abaixo de 200ms. Tempo de deploy caindo de 15 para 3 minutos. Número de incidentes por semana. O formato muda, a postura não.

Esses três hábitos não exigem mais habilidade técnica. Exigem uma mudança de postura: de executor de tarefas para co-responsável pelo resultado.

🌟 Resumo

• O problema de construir a coisa errada sempre existiu. O que IA fez foi remover o freio natural: quando execução era cara, times eram forçados a pensar. Agora, construir errado ficou tão barato quanto construir certo

• Dado da pesquisa (auto-reportado, mas revelador): engenheiros acreditam entender o porquê de uma feature, mas não sabem o que significa “feito”. Esse gap é o maior gargalo de times hoje

• Mike Krieger (co-fundador do Instagram): IA é boa em adicionar, não em cortar. Construir demais antes de lançar é agora o erro mais fácil de cometer

• 95% dos times usam IA para código, 9% para requisitos. Faz sentido dado as capacidades atuais, mas é exatamente onde os problemas reais estão

• Três hábitos para trabalho que importa: definir critério de sucesso antes de começar, usar o produto que você constrói, e comunicar trade-offs em vez de só executar

Se quiser se aprofundar nas skills que complementam esse julgamento de produto, veja também:

Se você quer entender como as melhores empresas internacionais pensam sobre engenharia de produto, a NaGringa tem vagas curadas e um banco com 1.000 perguntas reais de entrevistas para você explorar.

📖 Leitura adicional

• John Ousterhout, A Philosophy of Software Design. Programadores táticos vs. estratégicos e o custo de não investir em entender o problema.

• Marty Cagan, Inspired / Empowered. Discovery antes de delivery e o risco de construir o que ninguém quer.

• Donald Reinertsen, The Principles of Product Development Flow. Como acelerar execução sem melhorar decisões pode aumentar o desperdício.

Mas os números contam uma história mais complexa.

Laura Tacho, ex-CTO da DX (plataforma de developer intelligence vendida para a Atlassian por $1 bilhão), apresentou dados de mais de centenas de milhares de desenvolvedores. Algo que poucos estão falando: algumas empresas reduziram incidentes em 50% com IA, enquanto outras estão enfrentando o dobro de incidentes em produção. Mesmas ferramentas. Resultados opostos.

O motivo? IA é um amplificador. Se você tem boas práticas, IA as torna excelentes. Se você tem processos quebrados, IA os quebra mais rápido. A pergunta que importa não é “você usa IA?”, mas sim o que você está amplificando.

Existem 3 skills que determinam essa capacidade.

O que realmente mudou

O mercado de engenharia de software mudou mais nos últimos 24 meses do que nos 10 anos anteriores.

A mudança óbvia é que IA acelerou o ato de escrever código. Features que antes levavam semanas agora levam dias. Em muitos cenários, horas. Na minha própria experiência, features que levavam uma semana hoje saem em uma única sessão de 2-3 horas com Claude Code.

Mas a mudança não-óbvia é mais importante: o gargalo mudou de lugar.

Luca Rossi, da newsletter Refactoring, publicou uma pesquisa com 340 times de engenharia. O resultado? 59% dos times descobrem trabalho faltando no meio do sprint. Toda sprint. O motivo #1 de atraso e retrabalho? Critérios de aceite ambíguos. 50% dos times sofrem com isso. Não é falta de velocidade. É falta de clareza.

Quando você acelera a execução sem melhorar a definição do problema, você não fica mais produtivo. Você produz lixo mais rápido. Ou, como o Luca colocou: “Garbage in, garbage out. Com IA, é mais garbage, mais rápido.”

A mesma pesquisa mostra que o tempo médio economizado com IA está em torno de 4 horas por semana. Esse número estagnou. O teto é muito mais alto. Mas alcançá-lo exige investimento nas skills certas.

É nesse contexto que as 3 skills se encaixam.

1. Inglês: a skill de maior ROI, agora mais do que nunca

Você já sabe que inglês importa para carreira e aprendizado. Todo conteúdo técnico relevante chega primeiro em inglês. As empresas que pagam R$30-50k+ por mês exigem inglês. Isso não é novidade.

O que é novidade: inglês virou skill técnica por causa da IA.

No meu artigo sobre Claude Code, uma das minhas dicas foi: escreva prompts sempre em inglês. A maior parte do material de treino dessas IAs é em inglês. Os resultados são mensuravelmente melhores. Não é opinião. É como os modelos funcionam.

Context engineering (a disciplina de passar o contexto certo para uma LLM, no formato certo, no momento certo) é feita em inglês. Os melhores CLAUDE.md, Cursor rules e system prompts que eu já vi? Todos em inglês. Se você não escreve prompts em inglês, está deixando performance na mesa.

Inglês não é mais só comunicação. É skill técnica, educacional e de carreira. Tudo ao mesmo tempo.

Ação concreta: Instale um app de speech-to-text como o WhisperFlow e comece a falar seus prompts em inglês em vez de digitar. Você já está fazendo prompts o dia inteiro. Use isso como prática. Além de melhorar seu inglês falado, os resultados da IA vão ser melhores. Dois ganhos com o mesmo hábito.

2. AI Engineering: o novo multiplicador

A maioria dos engenheiros pensa em IA como uma ferramenta para escrever código mais rápido. Isso é verdade, mas é só metade da história.

Existem duas dimensões de AI Engineering que todo engenheiro precisa entender:

Usar IA para ser um engenheiro melhor

Essa é a dimensão que a maioria conhece. Copilot, Cursor, Claude Code. Ferramentas que aceleram o que você já faz.

Mas mesmo aqui, a maioria está subaproveitando. Apenas 9% dos times usam IA para gerar requisitos e critérios de aceite. É o caso de uso com maior alavancagem possível, dado que requisitos ruins são a causa #1 de retrabalho. E 52% dos times não têm nenhum contexto compartilhado de IA. Cada desenvolvedor gerencia seus próprios prompts, sem infraestrutura comum.

A diferença entre uso casual e domínio está em context engineering: montar o contexto certo, com as informações certas, para que a IA produza resultados de alta qualidade.

Na prática: estruturar um CLAUDE.md, usar TDD como rede de segurança para agentes, organizar código em módulos isolados (eu chamo de leaf nodes) para que agentes trabalhem com eficiência.

Um dado que me chamou a atenção: 44% dos times não têm nenhum tempo dedicado para experimentação com IA. Os que têm? Reportam melhores resultados e são mais otimistas sobre o futuro. Prática deliberada gera retornos compostos.

Gergely Orosz, do Pragmatic Engineer, publicou um deep dive sobre como a Uber usa IA internamente. Os números impressionam: 84% dos engenheiros usam agentic coding, e power users geram 52% mais PRs que não-usuários.

A Uber investiu pesado em infraestrutura: CLAUDE.md padronizados, gateways de contexto, ambientes otimizados. A skill individual importa, mas a infraestrutura que amplifica essa skill importa ainda mais.

Construir com IA

Essa é a dimensão que poucos estão desenvolvendo, mas que vai definir carreiras nos próximos anos.

Saber usar IA como ferramenta é necessário. Mas saber construir sistemas que usam IA como componente é o que vai separar engenheiros que lideram de engenheiros que seguem.

Um exemplo prático: o Gringo, nosso mascote-bot no WhatsApp. Ele começou como um RAG bot simples. Você fazia uma pergunta, ele buscava na nossa base de artigos e masterclasses usando embeddings, e respondia. Funcionava, mas era limitado.

Recentemente, reestruturei o Gringo para ser um agente completo. Hoje ele tem 17 ferramentas especializadas. Busca de vagas com match score contra o currículo do usuário. Calculadoras financeiras no chat. Classificação de rota por LLM. Sliding window de 30 mensagens. Proteção contra prompt injection. Controle de budget diário.

A evolução de “bot que busca texto” para “agente que toma decisões e executa ações” exigiu conhecimento real. Orquestração de agentes. Embeddings. Gerenciamento de contexto. Integração com APIs externas.

Isso é AI Engineering. Não é sobre se tornar um pesquisador de ML. É sobre entender o suficiente para tomar decisões arquiteturais inteligentes quando IA é parte do sistema.

Só sabe usar IA para escrever código? Você é um consumidor. Sabe construir com IA? Você é um criador.

Ações concretas:

• Usar IA melhor: Crie um CLAUDE.md para o seu projeto principal esta semana. Defina arquitetura, convenções, comandos de teste. Dê ao agente o contexto que ele precisa.

• Construir com IA: Pegue uma funcionalidade simples do seu produto e adicione IA. Não precisa ser um agente com dezenas de ferramentas. Uma busca semântica, um chatbot interno, uma automação com LLM. O importante é construir, não só consumir.

3. Pensamento sistêmico e arquitetura de software

Esse é o mais contraintuitivo dos três.

Em um mundo onde IA escreve código cada vez melhor, por que arquitetura importaria mais, não menos?

Como vimos, o gargalo é clareza, não velocidade. O que muda não é a ferramenta. É a fundação sobre a qual ela opera.

Arquitetura como fundação para agentes

No mesmo artigo do Gergely sobre a Uber, um detalhe me chamou a atenção. O Minion, a plataforma interna de agentes deles, tem um resultado curioso: desenvolvedores têm mais sucesso rodando prompts pelo Minion do que nos próprios laptops. O motivo? Good defaults. O monorepo já está compilado, as ferramentas já estão instaladas, o CLAUDE.md já está configurado. O ambiente é otimizado para agentes antes do desenvolvedor digitar uma linha sequer.

Isso é pensamento sistêmico aplicado à IA. O ganho não veio de prompts melhores. Veio da arquitetura que sustenta os prompts.

Eu chego na mesma conclusão por outro caminho. No meu artigo sobre Claude Code, falei sobre leaf nodes: partes isoladas do código que nada crítico depende. Contextos focados onde agentes trabalham com segurança e eficiência. No frontend: quebrar componentes grandes em pedaços menores. No backend: dividir APIs em módulos independentes.

Quanto melhor a arquitetura, melhor a performance dos agentes. Isso inverte a sabedoria convencional. Muita gente pensa: “se IA escreve código, arquitetura importa menos.” O oposto é verdade. Boa arquitetura é o que permite que IA seja eficiente.

A pesquisa do Luca Rossi reforça isso: times que tinham bons processos antes da IA são os que estão colhendo os melhores resultados agora.

Pensamento sistêmico como skill de liderança

Para líderes de engenharia, essa skill é ainda mais crítica. As barreiras para adoção eficaz de IA não são técnicas. São organizacionais. Falta change management. Falta sponsor executivo. Expectativas confusas.

Empresas com postura clara e comunicada sobre IA performam melhor do que as que simplesmente distribuem licenças. Spray and pray não funciona.

O papel do líder de engenharia em 2026 é pensar em sistemas: como a organização produz software, onde estão os gargalos, como IA pode resolver problemas sistêmicos (CI lento, reuniões excessivas, documentação fragmentada). Não apenas tasks individuais de codificação.

Ação concreta: Pegue o último sprint do seu time. Conte quantos tickets precisaram de esclarecimento depois de começarem. Mais de 30%? O gargalo não é velocidade. É clareza. Para o codebase: rode um agente de IA em uma task real. Se ele não entender a arquitetura sem 20 minutos de contexto manual, sua estrutura precisa melhorar. Nenhuma ferramenta de IA vai resolver isso por você.

🌟 Resumo

• Inglês virou skill técnica. Seus prompts, seu acesso a informação e suas oportunidades dependem dele.

• AI Engineering tem duas dimensões: usar IA melhor e construir com IA. A maioria só conhece a primeira.

• Pensamento sistêmico é a fundação. Sem boa arquitetura, IA amplifica problemas, não resultados.

IA é um amplificador. Essas três skills determinam o que você está amplificando.

📚 Referências

• The State of Product Development 2026 — Luca Rossi

• How Uber uses AI for development — Gergely Orosz

• Data vs Hype: How Orgs Actually Win with AI — Laura Tacho

Gostou? Compartilha com um amigo engenheiro que precisa ler isso.

O primeiro candidato sabia as técnicas certas. Mencionou OLAP, filas, as peças que a arquitetura precisava. Mas era difícil acompanhar o raciocínio. Ele pensava em voz alta sem estrutura e não escrevia nada no quadro. Quando questionei a diferença entre OLAP e OLTP, travou. Em nenhum momento considerou quem iria usar o sistema.

O segundo não mencionou OLAP sequer. Desenhou uma solução com PostgreSQL e read replicas. Mais simples, mas resolvia o cenário. Quando questionei a abordagem de AI (busca gerada por agente vs. SQL pré-definido), ele explorou os trade-offs dos dois lados, pesou, e decidiu. Tinha pesquisado o PostHog antes, olhado os perfis de quem ia entrevistar.

O primeiro sabia mais. O segundo passou.

Minha impressão do primeiro: “Would lower the bar for someone joining.” Do segundo: “Would raise the average level of the team.”

Esse artigo é sobre o que separou os dois.

✨ O que esperar do artigo

Vou usar dois candidatos reais que entrevistei para a mesma vaga, um passou e outro não, para mostrar o que fez a diferença.

• O que entrevistadores realmente avaliam, e por que raramente é o que você imagina

• Como estruturar os primeiros 5 minutos: a parte que define se você passa ou não

• Como navegar pushback e incerteza: o momento que transforma “hire” em “strong hire”

A pergunta que ninguém te conta

Quando entrevisto, não estou verificando se o candidato sabe o que é Kafka.

Estou tentando responder perguntas diferentes:

• “Eu gostaria de discutir um problema de produção com essa pessoa às 2h da manhã?”

• “Se a gente discordar, a gente chega num consenso e sai da conversa melhor?”

• “Eu confiaria nessa pessoa para tomar decisões sozinha? E ela sabe quando pedir ajuda?”

System Design é, tecnicamente, uma entrevista técnica. Mas é a mais comportamental das entrevistas técnicas. É uma simulação de colaboração.

É por isso que é minha entrevista favorita. É a mais próxima do trabalho real de engenharia. Não é uma prova com respostas certas. É uma conversa onde os dois lados exploram um problema juntos.

A diferença entre quem passa e quem não passa raramente é técnica. É sobre como a pessoa navega a conversa.

Em um artigo anterior, mostrei os 7 padrões técnicos que cobrem 90% das entrevistas:

Aquilo te dá o vocabulário. Hoje vou falar sobre como usar esse vocabulário numa conversa.

Comece pelo ser humano, não pela arquitetura

A maioria dos candidatos recebe “Design X” e já começa a desenhar caixas. Servidores, bancos de dados, filas. Red flag imediato.

Eu já escrevi sobre o que faz um engenheiro de produto. A ideia central é simples: “O código é o meio pelo qual alcançamos o sucesso do usuário.”

No artigo sobre o segredo dos produtos que encantam, abri com a história do engenheiro que implementou uma arquitetura impecável de microserviços. Os usuários continuaram exportando tudo para Excel, porque a solução não resolvia o problema real deles.

System Design interview é a mesma coisa. O sistema existe para servir alguém. Se você não sabe quem, tudo que vem depois é chute.

Antes de desenhar qualquer componente, entenda:

• Quem é o usuário?

• Onde ele está? (um país? global? rural com 3G?)

• O que ele está fazendo enquanto usa?

• Quando ele usa? (uma vez por dia? a cada segundo?)

• Por que ele usa?

Essas perguntas mudam o design inteiro.

“Design WhatsApp” com todos os usuários nos EUA é um problema diferente de WhatsApp global. Se seus usuários logam uma vez por dia, você não precisa de refresh em tempo real entre acessos. Se estão em áreas rurais com 3G, cada byte que você envia importa.

O candidato que não passou? Passou a entrevista inteira falando de arquitetura sem considerar o usuário uma única vez. O que pensei na hora: “Did not consider the user. Spent most of the time talking about the problem, not really considering who it’s for.”

Perguntas que separam pleno de sênior

Existe uma diferença enorme entre:

Pleno: “Qual é a escala?”

Sênior: “Qual é a relação read/write? Que garantias de consistência os usuários esperam? Qual latência é aceitável para as operações críticas?”

A primeira é genérica. A segunda revela que você já está pensando em trade-offs antes de tocar no quadro. Como entrevistador, eu consigo saber nos primeiros 5 minutos se o candidato vai passar ou não. É quase sempre aqui que se decide.

Faça as contas: para decidir, não para impressionar

Back-of-the-envelope calculations não são teatro para mostrar que você sabe multiplicar.

São a ferramenta que decide qual arquitetura faz sentido.

Se você descobre que o sistema vai lidar com 10 QPS, o problema inteiro muda. Você não precisa de Kafka. Talvez nem precise de microserviços. Um monólito com PostgreSQL resolve, e propor isso mostra maturidade, não falta de ambição.

Se são 100k QPS, agora sim: filas, sharding, cache externo. Mas você precisa saber disso ANTES de desenhar.

Os números não precisam ser perfeitos. Use potências de 10 e pense no que muda com 10x de crescimento. Mas eles precisam existir. Quem chuta durante System Design me dá medo.

O candidato que passou? Escolheu PostgreSQL com read replicas. Sem OLAP. Mais simples. Resolvia o cenário. E ele sabia explicar exatamente por que aquela complexidade era suficiente. Deixe o entrevistador pedir mais complexidade. Isso é colaboração, não fraqueza.

Pensando em voz alta (e desenhando)

O entrevistador não avalia o que não vê.

Se você fica 2 minutos em silêncio pensando, eu não sei se você está tendo uma ideia brilhante ou completamente travado. O que pensei sobre o candidato que não passou: “Hard to follow the reasoning. Was thinking out loud without structure and didn’t write anything down.”

Ele sabia as coisas. Eu só não conseguia ver que ele sabia.

Pensar em voz alta não é monologar

É estruturar seu raciocínio de forma que o entrevistador consiga acompanhar e contribuir:

• “Estou considerando X porque...” → mostra raciocínio

• “Uma alternativa seria Y, mas o trade-off é...” → mostra que pensa em opções

• “Faz sentido priorizar Z aqui?” → mostra colaboração

O equilíbrio: narrar demais vira ruído. Narrar de menos vira silêncio. A regra prática: verbalize as decisões e os porquês. Não cada micro-pensamento.

Desenhar é uma skill separada

O quadro (Excalidraw, whiteboard, papel) não é decoração. É ferramenta de comunicação.

O que desenhar: Comece com o usuário. Depois o fluxo de dados. Depois os componentes. Cada elemento no quadro deveria responder uma pergunta.

Quando desenhar: Quando a explicação verbal fica confusa. Um diagrama de 30 segundos substitui 3 minutos de explicação.

O que NÃO desenhar: Não encha o quadro de caixas e setas sem propósito. Quadro com 15 componentes onde 5 bastavam é tão ruim quanto nenhum quadro.

Quadro organizado = pensamento organizado. Quadro bagunçado = red flag.

Seu diagrama conta uma história. O entrevistador deveria conseguir olhar para ele e entender seu design sem você precisar explicar tudo de novo. Se não consegue, o quadro não está fazendo seu trabalho.

Navegando a conversa

Esse é o momento que separa “hire” de “strong hire.”

Pushback não é ataque

Quando eu questiono a decisão de um candidato, geralmente estou fazendo uma de três coisas:

1. Guiando para uma solução melhor (quero ver se você segue a dica)

2. Testando se você sabe defender suas decisões com argumentos

3. Verificando se você sabe mudar de ideia quando faz sentido

As três são sinais positivos. Pushback significa que o entrevistador está engajado. Silêncio é pior.

Quando questionei o candidato que passou sobre a abordagem de AI (agente gerando busca vs. SQL pré-definido), ele não cedeu nem cavou trincheira. Explorou os trade-offs dos dois lados, pesou as implicações, e tomou uma decisão. Me convenceu. Eu aprendi algo com a resposta dele.

Isso é o que colaboração real parece.

Os três erros fatais

1. Cavar trincheira. “Não, minha solução está certa.” Defensividade mata. Mesmo que você esteja certo, a forma importa mais que o conteúdo nesse momento.

2. Ceder imediatamente. “Ah, ok, vou mudar.” Sem entender por quê. Mostra que não tem convicção. Ou que a decisão original não tinha raciocínio por trás.

3. Entrar em pânico. Achar que pushback = reprovação. Você paralisa. Começa a duvidar de tudo que disse até agora.

O que fazer em vez disso

Ouvir completamente antes de responder. Depois:

Se você concorda: “Entendo o ponto. Posso ver por que Z seria melhor aqui dado [contexto]. Vou ajustar o design.”

Se você discorda: “Meu raciocínio foi X por causa de Y. Mas entendo a preocupação com Z. O trade-off que estou aceitando é...”

Se você não sabe: “Honestamente, não tenho certeza. Minha intuição é X, mas eu investigaria Y antes de commitar.”

A terceira opção, admitir que não sabe, é a mais subestimada.

“Eu não sei” é um sinal positivo

No mundo real, você quer que a pessoa peça ajuda quando precisa. Admitir os limites do seu conhecimento mostra maturidade. Muito melhor do que inventar e ser pego.

O candidato que não passou? Quando perguntei a diferença entre OLAP e OLTP, ele travou. Se tivesse dito “não tenho certeza da distinção exata, mas entendo que uma é otimizada para queries analíticas e a outra para transações”, teria sido infinitamente melhor que o silêncio.

Perguntas não significam que você está falhando

Se você resolve tudo de forma limpa, eu vou adicionar requisitos até você chegar num ponto que não resolve de forma limpa. Isso é by design.

Querem ver como você lida com incerteza. Chegar num ponto difícil e navegar bem é mais impressionante do que nunca chegar lá.

O mesmo vale para frameworks. HelloInterview, delivery frameworks. São ótimos para dar estrutura. Mas quando o entrevistador desvia do script, não entre em pânico. Se você só funciona dentro do framework, não praticou o suficiente. O objetivo é que a estrutura vire natural, não decorada.

Seja você, não o ChatGPT

Eu escrevi um artigo inteiro sobre como IA multiplica expertise:

A tese central: “LLMs não eliminam a necessidade de aprender profundamente. Elas multiplicam o valor de ter fundamentação sólida.”

Eu uso IA para tudo. Construí a plataforma inteira do Na Gringa com ajuda de LLMs. Mas o motivo de funcionar é que eu sei o que pedir e consigo avaliar o que recebo de volta.

Numa entrevista de System Design, isso se inverte. Se você usa LLM como muleta durante a conversa (e sim, entrevistadores percebem), o que você está sinalizando é que não tem a fundamentação. Que sem o modelo, você não chega em soluções originais. É como ter um assistente extremamente capaz sem saber o que delegar.

O entrevistador quer ouvir você. Sua forma de ver problemas. Suas experiências reais, mesmo que limitadas. Suas opiniões, mesmo que imperfeitas.

Na preparação? LLMs são o melhor tutor que já existiu. Use para estudar conceitos, entender sistemas que você nunca usou, simular entrevistas, praticar explicações em voz alta. Mas na hora, as ideias precisam ser suas.

Pesquise a empresa (de verdade)

Uma coisa que fez diferença com o candidato que passou: ele tinha pesquisado o PostHog. Olhou nossos perfis. Sabia o que a gente fazia. Isso mudou a dinâmica inteira. Não era mais entrevistador avaliando candidato, eram duas pessoas discutindo um problema real. O que pensei na hora: “Clearly did the homework, looked up PostHog and even saw our profiles.”

Pesquisar a empresa não é só para impressionar. Te beneficia: filtra mismatches de valores e te dá contexto para fazer perguntas melhores durante a entrevista.

Como praticar de verdade

Não vou te dizer para “ler mais engineering blogs.” Vou te dizer o que realmente funciona.

Mock interviews com colegas. A prática mais efetiva que existe. Combine com um amigo e alternem candidato e entrevistador. Você aprende dos dois lados. Eu aprendi mais sobre System Design entrevistando outros do que sendo entrevistado.

Uma dica de como eu faço: coloque um timer de 5 minutos para o requirements gathering. Se o candidato não perguntou sobre o usuário, não fez uma conta de padeiro, e já está desenhando caixas, isso já é feedback valioso. Na entrevista real, esses 5 minutos definem quase tudo.

Grave você mesmo. Escolha um problema do HelloInterview. Ou um capítulo Designing Data-Intensive Applications. Fale sobre em voz alta, grave, assista depois. Você vai perceber coisas que não percebe ao vivo: silêncios longos demais, monólogos sem estrutura, quadro vazio quando deveria ter diagrama.

Lidere design discussions no trabalho. Design docs, tech talks, facilitação de reuniões técnicas. A skill de System Design é a mesma skill de liderar uma discussão técnica. Cada design doc que você escreve é prática de entrevista.

Use HelloInterview para estrutura. Bom framework tático para organizar seus 45 minutos. Mas pratique até desviar dele ser confortável, não assustador.

🌟 Resumo

• System Design é a entrevista mais comportamental das técnicas. O entrevistador quer saber se confiaria em você para resolver um problema de produção às 2h da manhã, não se você sabe o que é Kafka.

• Os primeiros 5 minutos definem quase tudo. Pergunte quem é o usuário, faça as contas, e só depois toque no quadro. Começar desenhando caixas é red flag imediato.

• Pense em voz alta com estrutura, e desenhe. O entrevistador não avalia o que não vê. Verbalize decisões e porquês, não cada micro-pensamento. Quadro organizado = pensamento organizado.

• Pushback é sinal positivo. Não cave trincheira, não ceda sem pensar, não entre em pânico. Explore os trade-offs e tome uma decisão. Admitir que não sabe é melhor do que inventar.

• Seja você, não o ChatGPT. Use IA para estudar, mas na hora as ideias precisam ser suas. Pesquise a empresa. Mude a dinâmica de “avaliação” para “conversa entre colegas.”

System Design é a etapa que mais me diverte. Não porque eu sei todas as respostas. Porque cada conversa me ensina algo novo.

O candidato que passou? Eu aprendi com ele também. Saí da entrevista com uma perspectiva diferente sobre o trade-off de agent vs. SQL pré-definido. Isso é o que uma boa conversa de System Design faz. Os dois lados saem melhores.

Os 7 padrões te deram o vocabulário. Este artigo te deu as skills de performance. Os dois juntos = você sabe o que dizer e como dizer.

📚 Para aprofundar

O vocabulário técnico que complementa este artigo:

A outra metade da equação, entrevistas comportamentais:

Dicas para entrevistas de live coding:

• HelloInterview.com: prática estruturada com feedback

• Designing Data-Intensive Applications de Martin Kleppmann (segunda edição sai em março 2026)

Se esse artigo te ajudou, compartilha com alguém que está se preparando para entrevistas. É o tipo de conteúdo que eu queria ter lido antes de falhar em 2021.

Compartilhar

Uma nova parceria para o NaGringa

Semana passada, o Matheus Nasser foi contratado pela Amber, startup americana de PLM. Foi a primeira contratação direta do NaGringa. O diferencial dele? Tratou o take-home como produto real. Pesquisou todo mundo que ia entrevistá-lo. Mostrou que pensa como dono. Tudo que eu falei nesse artigo, ele fez na prática.

Essa vaga veio pela Laura Oliveira, minha nova sócia no NaGringa. Com anos de experiência em recrutamento, ela traz o lado que eu sozinho não consigo dar: o de quem contrata. Negocia direto com empresas, conecta membros com oportunidades exclusivas, e participa ativamente da comunidade ajudando na preparação de entrevistas e estratégia de carreira. Quem já interagiu com ela sabe.

Se você quer acesso a vagas exclusivas, simulados diários de entrevista, aulas de inglês e uma comunidade onde pessoas como a Laura e eu estamos ativamente investidos no seu crescimento:

Ver planos e benefícios →

Nossa próxima vaga exclusiva

A Laura já trouxe a próxima vaga que estamos publicando exclusivamente para os membros pagantes da comunidade.

A remuneração vai de $90k a $200k USD (R$39k até R$87k por mês) dependendo da experiência. Confira todos os detalhes da vaga aqui.

Essa é uma das perguntas que mais vejo online. No LinkedIn, em comunidades de desenvolvedores, no Reddit. A frustração é real: a pessoa quer trabalhar pra fora, sabe que existem salários altos, mas não consegue achar essas vagas.

E a resposta mais comum que vejo é: “Espera alguém te chamar no LinkedIn.”

Deixa eu te contar por que essa resposta está te custando dinheiro. Muito dinheiro.

Quando eu estava procurando minha primeira vaga internacional, cometi esse erro. Fiquei esperando. Otimizei meu LinkedIn, coloquei “Open to Work”, e aguardei. As mensagens chegaram - de consultorias. Empresas com nomes que eu nunca tinha ouvido, oferecendo salários que pareciam bons na época.

O que eu não entendia é que essas empresas são intermediárias. Elas faturam contratando engenheiros para outras empresas. E por definição, elas sempre vão pagar menos - porque existe um intermediário tirando uma fatia.

Hoje, olhando nosso job board, vejo os números de forma diferente. 838 vagas pagando $90k+/ano estão ativas agora. O problema não é que as vagas não existem. É a estratégia de como você está procurando.

✨ O que esperar do artigo

• A matemática cruel das consultorias (e quanto você está perdendo)

• Os dados reais do nosso job board: quantas vagas de $90k+ existem agora

• Como funciona o tier system e por que ele importa para sua estratégia

• Por que AI vai aumentar (não diminuir) a demanda por engenheiros

• O caminho para aplicar diretamente e maximizar seu potencial

O trade-off das consultorias: quando fazem sentido (e quando não)

Vou ser honesto: eu comecei minha carreira internacional através de uma consultoria. A G2i me ajudou a dar o primeiro passo, e sou grato por isso. Consultorias não são vilãs - elas resolvem um problema real.

Mas é importante entender a matemática por trás do modelo.

Uma empresa - vamos chamá-la de TechCorp - precisa de um engenheiro sênior. Ela tem duas opções:

Opção 1: Contratar direto
TechCorp paga $10k/mês para você. Você recebe $10k.

Opção 2: Contratar via consultoria
TechCorp paga $15k/mês para a ConsultoriaX. A ConsultoriaX paga $7k/mês para você. A consultoria fica com $8k de diferença - esse é o modelo de negócio delas.

Mesmas skills. Mesmo trabalho. Diferença significativa no que você leva pra casa.

Quando consultorias fazem sentido

Para começar sua carreira internacional, consultorias são excelentes:

• Elas já têm relacionamento com empresas gringas

• O processo seletivo costuma ser mais rápido

• Você ganha experiência internacional no currículo

• Menos burocracia - elas cuidam de contrato, pagamento, etc.

Se você nunca trabalhou para uma empresa de fora, uma consultoria pode ser o caminho mais rápido para entrar no jogo.

Quando você deveria buscar contratos diretos

Conforme você ganha experiência e confiança, a equação muda. Com 1-2 anos de experiência internacional, você já tem:

• Currículo comprovado com empresas gringas

• Inglês afiado no contexto de trabalho

• Network de ex-colegas que podem te indicar

• Confiança para passar em processos seletivos

Nesse ponto, aplicar diretamente te dá acesso ao valor total que a empresa está disposta a pagar por você.

O medo de aplicar diretamente

Medo de rejeição.

“Será que eu passo numa entrevista de uma empresa gringa de verdade?” Esse medo é real. Processos seletivos de empresas tier S e A são desafiadores - entrevistas técnicas, system design, behavioral. Dá medo de tentar e não passar.

Mas deixa eu te mostrar como repensar isso.

O que acontece se você aplicar para uma empresa tier S e não passar?

• Você conheceu pessoas interessantes que trabalham numa empresa que te atrai

• Você aprendeu sobre o processo seletivo deles - o que cobram, como funciona

• Você identificou gaps no seu conhecimento que pode trabalhar

• Você ganhou experiência de entrevista que vai te ajudar na próxima

E o que acontece se você passar?

• Todos os benefícios acima

• Mais uma oferta de emprego - que é exatamente o que você quer

Ou seja: aplicar diretamente tem upside nos dois cenários. O pior resultado ainda te deixa melhor do que antes.

Consultorias também têm processos desafiadores - não é que seja “fácil” passar por elas. A diferença é que o processo delas é mais rápido, o que dá a sensação de ser mais acessível. Mas velocidade não significa facilidade.

E os processos de empresas tier S são treináveis. Escrevi um guia completo sobre entrevistas comportamentais que cobre exatamente o que essas empresas esperam:

Sim, são difíceis, mas não impossíveis. E cada entrevista te prepara melhor para a próxima.

A crença de que as vagas não existem

“Vagas de $9k+ não existem para brasileiros.” Essa é a crença mais perigosa. Porque ela te faz aceitar menos antes mesmo de tentar.

Deixa eu te mostrar por que essa crença está errada.

Os dados reais: 838 vagas pagando $90k+/ano

Rodei uma query no nosso banco de dados hoje. Esses são os números reais do nosso agregador de vagas:

882 vagas ativas em 121 empresas.

Dessas 882 vagas:

• 560 são Tier S - pagam $120k+ para sênior, 100% remoto

• 278 são Tier A - pagam $90-120k+ para sênior

• 44 são Tier B - pagam $50-89k, benchmarkado para LATAM

Ou seja: 95% das vagas no nosso board pagam $90k+/ano. Isso é mais de $7.500/mês.

E o salário médio das vagas que divulgam compensação? Entre $153k e $183k de base salary. Isso é $12.700 a $15.200 por mês - só de salário base.

Mas em empresas tier S e A, a compensação total vai além do salário:

• Base Salary: O que você recebe todo mês, garantido

• Bonus: Geralmente 10-20% do base, pago anualmente baseado em performance

• RSUs/Stock Options: Ações da empresa que vestem ao longo de 4 anos. Em empresas como PostHog, Supabase e Linear, isso pode representar 30-100%+ do base salary

Ou seja: uma oferta de $150k de base pode facilmente virar $200k+ em compensação total.

761 dessas vagas são 100% remotas. 361 são especificamente para engenharia de software.

Nas últimas semanas, adicionamos 120 novas vagas. Isso não é um mercado morto. É um mercado que a maioria das pessoas não sabe como acessar.

As empresas que estão contratando

Não vou listar todas - essa é justamente uma das razões para assinar. Mas deixa eu te dar alguns exemplos do tipo de empresa que está no nosso board.

PostHog - onde eu trabalho - tem 33 vagas abertas agora. Somos uma empresa de product analytics, 100% remota, que paga salários tier S. Já escrevi sobre o processo seletivo do PostHog e por que decidi trabalhar aqui. O que me atraiu foi a cultura de autonomia radical - algo que discuti no artigo sobre high agency.

Supabase - o “Firebase open source” - tem 36 vagas abertas. Empresa remote-first, produto que desenvolvedores amam, salários competitivos globalmente.

Linear - ferramenta de gestão de projetos que virou referência em UX - tem 23 vagas. Eles são conhecidos por contratar “product engineers”, aquele perfil que expliquei neste artigo.

Essas não são empresas obscuras. São algumas das startups mais inovadoras do mundo. E todas contratam brasileiros remotamente.

A lista completa, categorizada por tier e com filtros por área, está disponível para assinantes no nosso job board.

Por que criamos o tier system (e como usar)

Quando comecei a construir nosso agregador de vagas, tinha um problema: nem toda “vaga internacional” é igual.

Uma vaga remota numa empresa que paga benchmark LATAM é muito diferente de uma vaga remota numa empresa que compete globalmente por talento. Colocar as duas na mesma lista confunde mais do que ajuda.

A inspiração veio do , autor do The Pragmatic Engineer. Ele mostrou que salários de engenheiros seguem uma distribuição trimodal - três picos distintos baseados no tipo de empresa. Eu já tinha escrito sobre isso usando dados do levels.fyi.

Adaptei o conceito para criar nosso tier system:

Em resumo: Tier S paga $120k+ para sênior e é 100% remoto. Tier A paga $90-120k+ mas pode exigir híbrido. Tier B paga $50-89k, benchmarkado para LATAM (ainda assim R$23-41k/mês - excelente para o Brasil).

As definições completas estão aqui. O que importa agora é como USAR isso na sua estratégia.

Como usar o tier system na prática

O erro mais comum é achar que você deve mirar só no tier S desde o início. Não funciona assim.

Se você é júnior ou busca primeiro emprego internacional:

Foca 80% no Tier B. Sério. Seu objetivo agora não é maximizar salário - é entrar no jogo. Uma vaga tier B te dá experiência internacional, inglês no dia a dia, exposição a práticas de empresas modernas. Como o Yuri discutiu no artigo sobre quando trocar de empresa, às vezes o ambiente de crescimento importa mais que o salário imediato.

Se você tem 1-2 anos de experiência internacional:

Divide esforço entre Tier B e A. Você já tem o “pé na porta”. Agora pode ser mais seletivo. Prioriza indicações de ex-colegas - networking é a estratégia mais poderosa nesse estágio.

Se você é sênior com histórico forte:

Foca 70% em Tier A e S. Você tem leverage. Contribuições open source, conteúdo público, referências de empresas conhecidas - tudo isso te destaca. Como escrevi sobre senioridade, o que importa não é tempo de experiência, é impacto demonstrável.

A tier list completa está aqui. O Tier B está gratuito - mais de 40 empresas que você pode começar a explorar agora.

Por que AI vai aumentar a demanda por engenheiros (não diminuir)

“Mas Lucas, AI não vai substituir programadores?”

Essa é a narrativa popular. E está errada. Deixa eu explicar por quê.

O Gergely Orosz publicou uma análise extensa sobre isso recentemente no Pragmatic Engineer. O ponto central:

O desenvolvedor médio gasta apenas 16% do tempo codando.

Isso vem de um estudo da Atlassian com 3.500 desenvolvedores. O resto do tempo é: ajudando outros, fazendo code review, discutindo design, debugando, em reuniões, planejando, recrutando.

Mesmo que AI escreva 100% do código, ela só libera uma fração do trabalho.

Mas o mais importante é o que se torna MAIS valioso com AI:

1. Especificar o que construir (e validar que funciona)

Quando AI pode implementar qualquer ticket bem definido, quem vai escrever o ticket perfeito? Alguém que entende requisitos de usuário E requisitos técnicos - performance, segurança, edge cases.

E depois que o código é gerado, quem valida? Eu uso Claude Code diariamente no PostHog:

Mas o agente só funciona bem porque temos testes sólidos. Sem feedback loops - testes automatizados, CI/CD - seria impossível confiar no output.

2. Arquitetura e visão de produto

Com mais código sendo gerado mais rápido, a estrutura do software importa MAIS. Monolito ou microserviços? Quais interfaces? Como escala? AI gera código que “funciona” - mas código que funciona em produção com milhões de usuários precisa de alguém que entenda as implicações.

É por isso que startups como PostHog e Linear contratam “product engineers” - pessoas que são um mix de mini-PM e engenheiro. Expliquei esse perfil aqui. Alguém com high agency que especifica O QUE construir, não só COMO.

A oportunidade para brasileiros

O resume assim:

“Haverá mais demanda por profissionais de software em cinco anos do que hoje, em parte graças à explosão na quantidade de software que AI cria.” Tradução e ênfase por mim. Artigo original.

Empresas vão contratar MAIS engenheiros porque cada um produz mais. E engenheiros com fundamentos sólidos + fluência em AI serão extremamente valiosos.

As empresas no nosso tier list estão contratando agressivamente. Elas precisam de pessoas que:

• Pensam criticamente sobre o que construir

• Validam código gerado por AI

• Mantêm qualidade em escala

• Tomam decisões de arquitetura

Se você desenvolver essas skills, o mercado vai te querer. E não através de consultorias - diretamente.

O caminho para aplicar diretamente

Ok, você entendeu o problema. Consultorias pagam menos. Vagas diretas existem. AI vai aumentar demanda por bons engenheiros. E agora?

Passo 1: Pare de esperar ser encontrado

A estratégia passiva de “otimizar LinkedIn e esperar” te coloca na mão de intermediários. Você precisa ir atrás das empresas que te interessam.

Isso não significa aplicar em 100 vagas aleatórias. Significa escolher 5-10 empresas do seu tier e fazer aplicações de qualidade. Como escrevi sobre como se destacar, qualidade bate quantidade.

Passo 2: Use seu network estrategicamente

Indicação é o atalho mais poderoso. Quando alguém de dentro te indica:

• Seu currículo vai direto pro gerente de contratação

• Você pula a fila de centenas de candidatos

• Sua chance de entrevista aumenta drasticamente

“Mas eu não conheço ninguém em empresa internacional.”

Provavelmente conhece. Ex-colegas que foram trabalhar fora. Pessoas de comunidades técnicas. Desenvolvedores que você interagiu em projetos open source.

O processo é simples: identifica quem você conhece em empresas que te interessam, pesquisa se tem vaga aberta na sua área, manda mensagem contextualizada pedindo indicação.

O artigo completo sobre networking está aqui:

Passo 3: Prepare-se para processos mais rigorosos

Empresas tier S e A têm processos seletivos sérios. Entrevistas técnicas, system design, behavioral. Não é pra assustar - é pra filtrar.

A boa notícia: esses processos são treináveis. Já escrevi guias detalhados sobre:

• Entrevistas comportamentais

• System design

• Por que seu currículo não passa da triagem

Se você quer um caminho estruturado do zero até uma oferta em empresa tier S, criamos um curso completo sobre isso.

Passo 4: Entre numa comunidade de pessoas no mesmo caminho

Uma das coisas que mais me ajudou foi ter pessoas ao redor passando pelo mesmo processo. Trocar experiências sobre vagas, processos seletivos, negociação.

Nossa comunidade de assinantes tem mais de 500 engenheiros buscando ou já trabalhando na gringa. Mentoria em grupo, networking, e acesso completo ao job board com todas as vagas filtradas.

🌟 Resumo

• 838 vagas pagando $90k+/ano existem agora - o problema não é escassez de vagas

• Consultorias são ótimas para começar, mas conforme você ganha experiência, aplicar diretamente te dá acesso ao valor total

• O tier system te ajuda a focar - não aplique para todas, aplique nas certas para seu momento de carreira

• AI vai aumentar demanda por engenheiros que sabem especificar, validar e arquitetar - não diminuir

• Pare de esperar ser encontrado - vá direto às empresas, use networking estratégico, prepare-se para processos rigorosos

Ação concreta para esta semana:

1. Acesse a tier list e explore as empresas do seu tier

2. Liste 3 pessoas do seu network que trabalham em empresas internacionais

3. Escolha 2-3 empresas e comece a preparar aplicações customizadas

📚 Para aprofundar

• High Agency: a skill que o CTO da Brex mais valorizava em mim

• O guia definitivo de entrevistas comportamentais

• Os 7 Padrões de System Design que Aparecem em Toda Entrevista

• Quando trocar de empresa: jornada de R$2.5k até R$25k

P.S.: Se você quer acesso às 882 vagas com filtros avançados, análise de currículo com AI, e mentoria em grupo com outros engenheiros na mesma jornada:

O investimento se paga na primeira oferta que você conseguir.

Essa foi a resposta que mais gerou discussão na mentoria de janeiro. Todo mês faço uma sessão ao vivo com assinantes, respondendo perguntas abertas sobre carreira.

Agora as mentorias ficam gravadas no Dngflix, com capítulos por pergunta e um resumo escrito. Quem prefere assistir, assiste. Quem prefere ler, lê.

A versão completa dessa mentoria (conteúdo rico + gravação) está aqui.

No site você tem o vídeo com navegação por capítulos. Abaixo, o resumo escrito.

Pergunta 1: Como Fazer Pitch com Carreira Não-Linear

“Eu fiz transição de carreira, vim da academia (engenharia mecânica, mestrado, doutorado), e meu currículo é todo ‘esquisito’. Como me vender na entrevista?” — Vinícius

Existem dois momentos distintos: conseguir ser chamado para a entrevista e a entrevista em si.

A partir do momento que você foi chamado, o currículo não importa mais. O que importa é como você vai responder e se portar na entrevista.

Os 3 pilares de qualquer entrevista:

1. Demonstrar entusiasmo. Mostrar que você gosta do que faz e está afim de fazer

2. Mostrar que você trabalha bem com pessoas. Que você colabora bem com colegas

3. Vir preparado. Pesquisar a empresa, saber o nome das pessoas, testar o produto

Nunca se coloque pra baixo. Não chegue na entrevista falando “eu não sou tão bom porque estou em transição”. Você tem que querer se elevar. Fale o que você pensa e deixe eles avaliarem seu nível.

Para conseguir ser chamado (a parte mais difícil de controlar):

• Fazer networking e conversar com pessoas da comunidade

• Criar conteúdo online (LinkedIn, Substack)

• Mostrar que você sabe fazer as coisas

Eu escrevi um guia completo sobre networking:

Read more

O problema: esse conhecimento fica enterrado. Quando alguém pergunta “como é a entrevista da Brex?”, a resposta existe em algum artigo que ninguém lembra.

Então construí o Gringo, um assistente de IA no WhatsApp que responde perguntas usando minha base de conhecimento. Menciona @Gringo no grupo, faz uma pergunta, e ele responde em segundos.

Esse artigo é um deep-dive técnico em como construí isso. Não é um tutorial passo-a-passo. É uma explicação dos padrões de engenharia que usei e por que funcionam.

Gringo em ação

Antes de entrar nos detalhes técnicos, veja o sistema funcionando:

Alguém pergunta sobre entrevistas na Brex. O Gringo busca nos artigos relevantes, encontra informações de 2-3 fontes diferentes, e responde em ~3 segundos com links para os artigos originais.

Agora vamos ver como isso funciona por baixo.

O que esperar

• RAG (Retrieval-Augmented Generation): como funciona busca semântica e por que é diferente de busca por palavras-chave

• Embeddings: o que são, como gero, e por que escolhi Voyage AI

• Classificação de intenção: como reduzo custos filtrando mensagens antes do pipeline pesado

• Padrões de produção: cache, separação de responsabilidades, servidor não-bloqueante

RAG: o coração do sistema

RAG (Retrieval-Augmented Generation) é o padrão que permite um LLM responder perguntas usando uma base de conhecimento específica. Em vez de depender só do que o modelo aprendeu no treinamento, você busca informação relevante e passa como contexto.

A arquitetura tem duas partes:

Preparação: transformando artigos em vetores

Antes de qualquer pergunta, preciso preparar a base de conhecimento. O processo roda uma vez (e novamente quando publico artigos novos):

1. Buscar artigos do Substack

Uso a API do Substack para puxar todos os artigos publicados. Cada artigo vem com título, slug, URL, e conteúdo em HTML.

2. Converter para markdown

HTML é ruído para o modelo. Converto para markdown limpo, só o texto que importa.

3. Gerar resumos com IA

Cada artigo recebe um resumo de 2-3 frases gerado por LLM. Isso melhora a qualidade da busca: o resumo captura a essência do artigo em linguagem densa.

const { text: summary } = await generateText({
  model: getModel("google:gemini-3-flash-preview"),
  prompt: `Resumo de 2-3 frases que capture:
1. O problema/tema principal
2. Insights chave
3. Pra quem é útil

Escreva em português. Seja direto.

Artigo: ${title}
${content}`,
});

4. Dividir em chunks

Um artigo de 3000 palavras não cabe inteiro no contexto. Divido em pedaços de 200-1500 caracteres, respeitando quebras de parágrafo:

const chunks = defaultChunker(content, {
  minCharsSoftLimit: 200,   // mínimo por chunk
  maxCharsSoftLimit: 1500,  // alvo
  maxCharsHardLimit: 3000,  // máximo absoluto
  delimiter: "\n\n",        // quebra em parágrafos
});

Por que esses números? Chunks muito pequenos perdem contexto. Muito grandes diluem a relevância na busca. 200-1500 é o sweet spot para artigos técnicos em português.

5. Gerar embeddings

Cada chunk é convertido em um vetor de 1024 dimensões usando Voyage AI:

export const rag = new RAG(components.rag, {
  textEmbeddingModel: voyage.textEmbeddingModel("voyage-3.5-lite"),
  embeddingDimension: 1024,
});

O que são embeddings?

Embeddings são a tecnologia fundamental por trás de como LLMs processam texto. Cada token que entra em um modelo como GPT ou Gemini é convertido em um vetor de embedding antes de qualquer processamento. Sem embeddings, LLMs não existiriam.

A ideia: transformar texto em números de uma forma que capture significado. Imagine um espaço de 1024 dimensões (difícil de visualizar, mas a matemática funciona igual). Cada palavra, frase, ou parágrafo vira um ponto nesse espaço. O truque: textos com significados similares ficam próximos.

Por exemplo:

• “negociação salarial” e “como pedir aumento” ficam próximos

• “entrevista técnica” e “coding interview” ficam próximos

• “receita de bolo” fica longe de todos esses

Antes de embeddings, métodos como TF-IDF comparavam texto palavra por palavra, sem entender significado. “Carro” e “automóvel” eram vetores completamente diferentes. Com embeddings, o modelo entende que são sinônimos porque aparecem em contextos similares durante o treinamento.

E aqui está o pulo do gato para RAG: se LLMs já usam embeddings internamente para “entender” texto, podemos usar a mesma técnica para conectar nosso próprio conhecimento ao modelo. Gero embeddings dos meus artigos, e quando alguém pergunta “como ganhar mais”, encontro artigos sobre “negociação salarial” mesmo sem as palavras exatas. É como dar memória extra ao LLM sobre um domínio específico.

Por que 1024 dimensões?

Voyage 3.5-lite usa vetores de 1024 dimensões. Mais dimensões significa melhor separação semântica, mas mais custo de storage e busca.

Para minha base (~80 artigos, ~400 chunks), 1024 é confortável. Poderia usar 256 e economizar 4x em storage, mas não é o gargalo. A latência vem do LLM, não da busca vetorial.

Por que Voyage AI?

A resposta honesta: velocidade para validar a ideia.

Existem alternativas open source excelentes. Modelos como intfloat/multilingual-e5-large ou BAAI/bge-m3 performam bem em português e rodam localmente. Mas exigem setup: infra pra hospedar, GPU, gerenciar deploys.

Voyage é uma API. Em 30 minutos eu tinha embeddings funcionando. Isso me permitiu colocar o bot no ar e começar a coletar feedback real.

Por que Voyage especificamente (e não OpenAI ou Cohere)?

1. Foco em multilingual: Voyage foi treinado com ênfase em idiomas além do inglês. Para uma base de conhecimento em português, isso importa

2. Custo competitivo: $0.02 por milhão de tokens, igual ao OpenAI text-embedding-3-small

3. Reputação em benchmarks: consistentemente bem avaliado para retrieval tasks, especialmente multilingual

Ainda não fiz testes comparativos rigorosos. O bot está no ar há poucos dias. Se os resultados de busca não estiverem bons, vou testar alternativas. Por enquanto, está funcionando.

A lição: para MVPs, otimize para ciclo de feedback rápido. A melhor arquitetura é a que te deixa aprender mais rápido.

Busca: encontrando informação relevante

Quando uma pergunta chega, o processo é:

1. Converter pergunta em embedding

A pergunta passa pelo mesmo modelo Voyage, gerando um vetor de 1024 dimensões.

2. Busca por similaridade

Comparo o vetor da pergunta com todos os chunks usando similaridade de cosseno. Chunks com score > 0.5 são considerados relevantes:

const { results, entries } = await rag.search(ctx, {
  namespace: "articles",
  query: question,
  limit: 9,  // busca mais, depois filtra
  vectorScoreThreshold: 0.5,
});

3. Agrupar por artigo

Se 3 chunks do mesmo artigo são relevantes, não quero repetir. Agrupo por fonte e pego os 2 melhores chunks de cada artigo:

const articles = Array.from(articleMap.values())
  .sort((a, b) => b.bestScore - a.bestScore)
  .slice(0, 3);  // top 3 artigos

4. Montar contexto para o LLM

Formato os chunks relevantes com título, resumo, e URL do artigo:

const context = articles.map(article => `
*${article.title}*
${article.summary}
Link: ${article.url}

Trechos relevantes:
${article.chunks.slice(0, 2).join("\n\n")}
`).join("\n\n---\n\n");

5. Gerar resposta

O contexto vai pro Gemini Flash junto com a pergunta. O modelo responde baseado nos artigos, citando as fontes.

O prompt de geração é onde a personalidade do Gringo vive. Uma versão simplificada:

const systemPrompt = `Você é o Gringo, o mascote da Na Gringa.
Um cachorro caramelo que ajuda devs brasileiros com carreiras.

PERSONALIDADE:
- Caloroso, brincalhão, genuinamente quer ajudar
- Usa humor brasileiro naturalmente
- Direto e honesto, mas sempre com carinho
- Às vezes faz referências a coisas de cachorro

COMO FALAR:
- Português brasileiro natural, como papo no WhatsApp
- Expressões: "bora", "manja", "show", "firmeza"
- Respostas curtas pro casual, completas pra técnico
- Use **negrito** pra destacar pontos importantes`;

const prompt = `Artigos relevantes encontrados:
${context}

Pergunta: ${question}

Use as informações dos artigos como base.
Ao final, liste os links dos artigos que você usou.`;

O prompt real tem ~200 linhas com repositório de piadas, referências do Remote Defender (nosso jogo), e instruções de segurança. Mas a essência é essa: personalidade definida + contexto dos artigos + pergunta.

Quando RAG não encontra nada

Nem toda pergunta tem resposta nos artigos. “Como configurar Kubernetes?” provavelmente não está na minha base de conhecimento sobre carreiras.

Quando nenhum chunk passa do threshold de similaridade (0.5), o sistema não inventa. O prompt muda: em vez de “responda baseado nesses artigos”, vira “não encontrei artigos específicos, mas posso ajudar com conhecimento geral de engenharia”.

Isso evita alucinações. O modelo sabe quando está respondendo com contexto da base vs. conhecimento geral.

Por que busca semântica > busca por palavras-chave?

Busca tradicional (Elasticsearch, Algolia) encontra documentos que contêm as palavras da query. Funciona bem quando o usuário sabe os termos exatos.

Busca semântica encontra documentos com significado similar. Funciona quando:

• Usuário usa sinônimos (”aumento” vs “negociação salarial”)

• Conceito está implícito (”como me destacar” → artigos sobre networking, currículo, visibilidade)

• Pergunta é conversacional (”o que fazer quando meu chefe não reconhece meu trabalho”)

Para um assistente de IA, busca semântica é essencial. Usuários não perguntam com keywords. Perguntam com linguagem natural.

Arquitetura completa

Com RAG explicado, aqui está o fluxo completo:

A stack:

• Baileys: biblioteca que conecta no WhatsApp Web (não oficial, mas funciona)

• Express: camada HTTP que expõe o serviço de WhatsApp (health checks, API)

• Convex: backend que orquestra tudo (banco, actions, cron jobs), o mesmo que uso no agregador de vagas

• Gemini Flash: LLM rápido e barato para classificação e geração

• Voyage AI: embeddings otimizados para português

Se você quiser ver outro exemplo de arquitetura similar (scraping + processamento + API), escrevi sobre como construí o agregador de vagas:

Classificação de intenção: otimizando custos

RAG é poderoso, mas caro. Cada pergunta envolve:

1. Gerar embedding da pergunta (Voyage API)

2. Buscar no banco vetorial

3. Gerar resposta (Gemini API)

Quando alguém manda “oi” pro bot, não faz sentido rodar esse pipeline. É só responder “Oi! No que posso ajudar?”

Então classifico a intenção antes de decidir o que fazer:

const IntentSchema = z.object({
  intent: z.enum(["greeting", "attack", "casual", "question"]),
  casualResponse: z.string().optional(),
});

greeting (”oi”, “eai”, “bom dia”)
→ Resposta estática aleatória. Custo: R$0.

attack (tentativas de prompt injection, pedir tokens secretos)
→ Resposta com rickroll. Custo: R$0.

casual (piadas, agradecimentos, papo informal)
→ LLM gera resposta curta. Custo: ~R$0,0003.

question (perguntas reais sobre carreira, entrevistas, vagas)
→ RAG completo. Custo: ~R$0,001.

A ordem importa

1. Verifica cache      ← Hit? Retorna (R$0)
2. Classifica intenção ← Não é question? Resposta simples
3. Roda RAG            ← Só quando necessário

Cache vem primeiro porque é O(1). Se a mesma pergunta foi feita nas últimas 24h, retorno a resposta cacheada sem gastar nada.

Classificação vem segundo porque é barato (~R$0,0001) e filtra a maioria das mensagens. Só perguntas reais chegam no RAG.

Personalidade através de variação

Bots que respondem igual toda vez parecem robôs. Tenho dezenas de variações para cada tipo:

const GREETING_RESPONSES = [
  "Opa! No que posso ajudar?",
  "Fala! Tô aqui, abanando o rabo virtual",
  "Au au! Quer dizer... oi! Como posso ajudar?",
  "Salve! Esse caramelo aqui tá pronto pra ajudar",
  // ... dezenas mais
];

Para ataques (tentativas de prompt injection), deflecto com humor. Rickrolls, memes, respostas que não engajam com a tentativa. O importante é não executar o que o atacante pediu e não revelar informação sobre o sistema.

Separação de responsabilidades

Um padrão que facilita muito: o serviço de WhatsApp sabe como receber e enviar mensagens. O backend (Convex) sabe o que responder.

WhatsApp: "Alguém perguntou: 'como negociar salário?'"
Convex:   "Responde isso: '...baseado nos artigos...'"
WhatsApp: "OK, enviei."

Isso permite:

• Testar o backend sem WhatsApp real (simulo chamadas HTTP)

• Trocar WhatsApp por Telegram/Discord sem mudar a lógica de IA

• O “cérebro” (RAG, cache, LLM) fica isolado do “corpo” (transporte)

Custos e latência

Números reais do sistema em produção:

• Custo médio por pergunta: ~R$0,001

• Latência (cache hit): ~200ms

• Latência (RAG completo): ~2-3s

• Infraestrutura: VPS $5/mês

O bot está no ar há poucos dias. Quando tiver mais dados, compartilho métricas detalhadas.

Estimativa mensal: 1000 perguntas/mês = ~R$1 de APIs + R$30 de infra = ~R$31/mês para um assistente de IA em produção.

Próximos passos

O sistema atual só busca em artigos. A próxima versão é um agente que escolhe qual ferramenta usar:

• “Quais vagas de React estão abertas?” → busca no portal de vagas

• “Quantas empresas Tier S tem no site?” → consulta estatísticas

O código existe. Falta testar em produção.

Conclusões

Algumas coisas que aprendi construindo isso:

Prompts complexos não são melhores. A primeira versão do classificador de intenção tinha um prompt elaborado com muitos exemplos. Funcionava mal. Simplifiquei para algo direto e a acurácia melhorou. Às vezes menos contexto é mais.

Personalidade importa mais do que você imagina. Quando tirei as variações de resposta pra simplificar, o bot ficou sem graça. Voltei atrás. A variação (”abanando o rabo virtual”) faz diferença na experiência.

WhatsApp é cheio de pegadinhas. O formato de identificação de usuários mudou (JID vs LID). Tive que corrigir a detecção de menções múltiplas vezes. Se você for integrar com WhatsApp, prepare-se para debugging de formatos obscuros.

Cache desde o dia 1 valeu a pena. Implementei cache de 24h junto com o MVP. Não custou muito a mais e já economiza chamadas de API quando as mesmas perguntas se repetem.

O gargalo nunca é onde você espera. Minha latência é 2-3s. O LLM é 95% disso. Otimizar o servidor (Express → Fastify) economizaria 10ms. Não vale o esforço ainda.

O padrão mais importante: filtre antes de processar. Nem toda mensagem precisa do pipeline completo.

Se você está construindo algo com IA, comece pelo filtro de intenção. É o padrão com melhor ROI que descobri.

Se você curtiu esse deep-dive técnico, talvez goste de como estou usando IA no meu workflow de desenvolvimento:

Quer ver o Gringo em ação? Ele está ativo na comunidade do Na Gringa. Assinantes podem entrar no grupo e testar.

Manda um “@Gringo” e faz uma pergunta.

Mas o momento que mais ficou comigo em 2025 não foi um número.

Foi quando minha primeira mentorada individual passou na Microsoft. Depois de um ano conversando, preparando, torcendo junto. Quando ela me mandou a mensagem, eu fiquei super emocionado. Ela tinha tentado tanto.

Isso é o que essa newsletter é pra mim. Não são os views. São as pessoas e a comunidade que estamos formando.

O que Vocês Mais Leram

Os 5 artigos que mais ressoaram em 2025:

O padrão é claro: vocês queriam clareza. Como usar IA, como se preparar, como se destacar. Menos teoria, mais “me diz o que fazer”.

3 Artigos para Revisitar Antes de 2026

Se você só tiver tempo pra 3 artigos antes do ano acabar, leia esses.

Não são os mais populares. São os que eu acredito que vão fazer mais diferença na sua carreira.

Promoção, entrevistas, saber se você tá no projeto certo. Tudo depende de conseguir articular o impacto do que você faz. A maioria dos engenheiros não sabe fazer isso. Esse é o artigo que eu gostaria que alguém tivesse me dado 5 anos atrás.

Quando saí da Brex, o CTO James Reggio me disse que minha saída foi uma das que ele mais queria reverter. O motivo? High agency. A capacidade de fazer as coisas acontecerem sem esperar permissão. Essa é a skill que separa quem espera oportunidade de quem cria.

Esse framework eu uso toda semana no PostHog. Quando você tem 10 coisas pra fazer e todas parecem importantes, como decidir? Se você começa 2026 sobrecarregado, esse é o artigo.

O que os Membros Conquistaram em 2025

O que mais me motiva são as conquistas de vocês.

Um membro entrou na Circle, a primeira contratação da comunidade numa empresa Tier S. Ele me disse:

“Estava num momento complicado da minha carreira quando entrei na comunidade e ter esse contato com tantas pessoas FODAS abriu minha mente para muitas coisas que eu não estava prestando atenção. O contato diário que temos nos grupos, insights e todo o resto são coisas muito positivas e que agregam muito para nossa carreira.”

Outro descobriu uma vaga pelo job board e virou offer.

Outro se recolocou numa empresa gringa e disse que está “muito mais feliz e alinhado com seus objetivos”.

E outro resumiu em uma frase: “Me deu um norte quando eu não tinha nenhum.”

Isso é o que faz valer a pena.

Quer ver mais histórias? Confira as avaliações dos membros.

Uma Coisa Nova para Fechar 2025

Antes de falar de 2026, quero te mostrar algo que estou lançando hoje.

Nos últimos meses, organizei todo o conteúdo do NaGringa num mapa de jornada. Um passo a passo visual que te guia desde a preparação até construir reputação na sua nova empresa.

6 fases. Dezenas de etapas. Todo o conteúdo organizado na ordem certa.

• Preparação → Mindset, inglês, currículo, LinkedIn, projetos

• Hunting → Estratégia, referrals, outreach, vagas

• Entrevistas → Recruiter, take-home, live coding, system design, behavioral

• Oferta → Negociação, CLT vs PJ, equity, compensação

• Onboarding → Primeiros 90 dias

• Reputação → Networking, visibilidade, carreira de longo prazo

Chega de ficar perdido em qual artigo ler primeiro. Agora você tem o mapa completo.

O que Vem em 2026

Três coisas que estou trabalhando:

1. Referências diretas para vagas

Chega de mandar currículo. Quero melhorar o processo de triagem da Na Gringa para conectar membros diretamente com empresas. Conexão direta.

2. Mais ferramentas gratuitas

Vocês conheceram o Gringo esse ano, nosso mascote que aparece nos cursos. Em 2026, vou expandir as ferramentas gratuitas: mais calculadoras, mais recursos, mais formas de ajudar engenheiros brasileiros. Mesmo quem não é assinante.

3. YouTube e eventos presenciais

Mais conteúdo em vídeo. E pra quem está em Belo Horizonte: eventos presenciais. Nada substitui conhecer pessoas cara a cara. Fizemos isso algumas vezes esse ano com os assinantes da newsletter e toda vez foi muito especial.

Feliz 2026

Obrigado por lerem toda semana. Por compartilharem suas vitórias e desafios. Por fazerem parte disso.

Nos vemos em 2026.

Me conta: qual é sua meta principal pra 2026? Responde esse email, leio todas as respostas.

Sobre este artigo: Este é um dos nossos artigos mais longos. A ideia é que seja uma referência completa que você pode consultar antes de entrevistas. Não precisa ler tudo de uma vez. Escolha um padrão, estude, pratique. Volte quando precisar de outro.

Retrospectiva salarial: 5 anos trabalhando remoto

O artigo dessa semana é patrocinado pela TechFX.

Meu salário cresceu 30x de 2020 a 2025. De R$2.200 da bolsa de mestrado para R$60k+.

As mudanças que fizeram diferença:

Mudei de mercado, não só de empresa. Tier 1 BR paga R$12k. Tier 3 internacional paga R$40k+. Mesmo trabalho, mercado diferente.

Negociei todo ano. No Brasil, 5-10% é “bom aumento”. Lá fora é parecido, porém, esses 5-10% você acaba sentindo muito mais (pois é em dólar).

Otimizei recebimentos. Payoneer me custava R$510/mês em taxas. TechFX custa R$135/mês. Diferença de R$4.500/ano que fica comigo.

Trabalhar remoto não garante salário alto. Mas te dá acesso a um mercado onde seu trabalho vale mais.

Conheça a TechFX e faça seu primeiro saque pagando apenas 0,1% de taxa.

Como eu cheguei aqui

Em 2021, fiz minha primeira entrevista de System Design. Falhei.

Achei que nunca ia conseguir passar nessa etapa. Parecia que todo mundo sabia coisas que eu não sabia, tinha experiências que eu não tinha.

Mas eu queria entrar em uma empresa melhor. Então comecei a estudar de verdade: ler engineering blogs, entender como sistemas reais funcionavam, praticar deliberadamente.

Com o tempo, System Design virou a etapa técnica que mais aparecia nos meus processos seletivos. Comecei como fraqueza, mas fui melhorando com prática e orientação de quem já tinha passado por isso.

Ano passado, passei como Senior Engineer no PostHog depois de uma das entrevistas de System Design mais difíceis (e mais divertidas) que já fiz.

A diferença não foi que eu fiquei mais inteligente. Foi que aprendi a reconhecer padrões.

E são sempre os mesmos 7 padrões.

Os 7 padrões

1. Scaling Reads

O problema: A maioria dos sistemas tem muito mais leituras do que escritas. Um post no Instagram é escrito uma vez, mas lido milhões de vezes. Uma URL encurtada é criada uma vez, mas redirecionada milhares de vezes por dia.

Quando você tem 100 leituras para cada escrita, seu banco de dados pode virar o gargalo. Mas antes de sair adicionando camadas de infraestrutura, entenda: bancos de dados modernos são bem mais capazes do que muita gente assume. A solução certa depende de onde está o gargalo.

A solução tem uma progressão natural. Comece pelo mais simples:

1. Otimize o banco que você já tem

Antes de pensar em cache ou réplicas, garanta que seu banco está sendo usado corretamente. Parece básico, mas é o erro mais comum que eu vejo.

Índices corretos: A diferença entre uma query com e sem índice pode ser de 500ms vs 2ms. Um SELECT * FROM urls WHERE short_code = 'abc123' sem índice faz full table scan. Com índice, é um B-tree lookup instantâneo.

Connection pooling: Cada nova conexão ao PostgreSQL custa ~5-10ms e consome memória. Sem connection pooling, sua aplicação abre e fecha conexões a cada request. Com PgBouncer na frente, você reutiliza conexões e pode multiplicar o throughput por 5-10x sem mudar mais nada.

Números reais: Um PostgreSQL bem configurado, com índices corretos e connection pooling, consegue 50-100k+ queries simples por segundo em hardware moderno. Isso é muito mais do que a maioria dos sistemas precisa. Não subestime seu banco.

2. Read Replicas: Múltiplas cópias do banco para leitura

Se um banco otimizado não aguenta, multiplique. O banco primário recebe todas as escritas e replica para bancos secundários. Leituras são distribuídas entre as réplicas.

Escritas → Banco Primário → Replica para → Banco Secundário 1
                                        → Banco Secundário 2
                                        → Banco Secundário 3
Leituras → Distribuídas entre todas as réplicas

Números reais: 3 réplicas = ~4x a capacidade de leitura (primário + 3 réplicas). Para a maioria dos sistemas, incluindo muitos com milhões de usuários, isso é suficiente. Cada réplica faz as mesmas queries com a mesma eficiência do primário.

Trade-off: Replicação leva tempo (milissegundos a segundos). Você pode ler dados que ainda não refletem a última escrita. Isso é eventual consistency. Para um feed do Instagram, aceitável. Para saldo bancário, não.

Quando réplicas são suficientes: Quando suas queries são simples (key lookups, filtros indexados), o tráfego é distribuído de forma razoável entre os registros, e latência de 5-20ms é aceitável. Isso cobre a grande maioria das aplicações.

3. Cache externo: Para hot spots e queries caras

Réplicas multiplicam capacidade, mas não resolvem tudo. Cache externo (Redis, Memcached) resolve problemas que réplicas não conseguem:

Hot spots: O perfil de uma celebridade no Instagram é lido 50.000 vezes por segundo. Não importa quantas réplicas você tenha. Todas estão servindo a mesma query para o mesmo registro. Cache absorve essa duplicação. Uma única entrada no Redis serve todos esses requests sem tocar no banco.

Queries caras: Se o resultado exige joins de 5 tabelas ou agregações pesadas, cada execução custa CPU significativa. Réplicas fazem o mesmo trabalho caro, só que em máquinas diferentes. Cache guarda o resultado computado e evita refazer o trabalho.

Latência sub-milissegundo: Quando 5-10ms de uma réplica não é rápido o suficiente (real-time bidding, trading, gaming) Redis entrega em <1ms.

Estruturas de dados específicas: Leaderboards (sorted sets), rate limiting (contadores atômicos), contagem de únicos (HyperLogLog). Nesses casos, Redis não é “cache”. É a ferramenta certa para o tipo de dado.

O padrão mais comum é cache-aside:

1. Cliente pede dados
2. Aplicação verifica se está no cache (Redis)
3. Se sim (cache hit): retorna em <1ms
4. Se não (cache miss): busca no banco, guarda no cache, retorna

Números reais: Redis aguenta ~100-500k operações/segundo com latência sub-milissegundo. Mas o valor real não é só velocidade bruta. É evitar trabalho repetido no banco.

O desafio é invalidação. Quando o dado muda no banco, o cache fica desatualizado. Estratégias:

• TTL (Time-to-Live): Cache expira após X segundos. Simples, mas dados podem ficar stale.

• Write-through: Atualiza cache junto com o banco. Consistente, mas adiciona latência na escrita.

• Invalidação explícita: Deleta do cache quando atualiza o banco. Preciso, mas requer coordenação.

4. CDN: Cache na borda para conteúdo estático

Para arquivos que não mudam (imagens, vídeos, CSS, JS), nem cache nem réplicas são necessários. Use uma CDN.

CDN = rede de servidores distribuídos globalmente. Quando um usuário em São Paulo pede uma imagem, ela vem do servidor mais próximo, não do seu data center em Virginia.

Números reais: Sem CDN, uma imagem pode levar 200-400ms para carregar (latência de rede). Com CDN, <50ms.

Framework de decisão:

O dado é estático (não muda)?
  → Sim: CDN

O dado é dinâmico e lido muito mais do que escrito?
  → Seu banco está otimizado (índices + connection pooling)?
    → Não: Comece por aí. Sério, isso resolve muita coisa.
    → Sim, mas não aguenta o volume:
      → Adicione read replicas.
      → Ainda não é suficiente? Tem hot spots ou queries caras?
        → Sim: Agora sim, cache externo (Redis).

Não é read-heavy?
  → Talvez você tenha um problema de writes, não reads.

Na entrevista (URL Shortener):

“URLs encurtadas têm um padrão de acesso muito específico: são escritas uma vez e lidas milhares de vezes. A relação read/write é provavelmente 1000:1.

Primeiro, a query de resolução é um key lookup simples — short_code com índice único. Com connection pooling, um PostgreSQL aguenta isso facilmente para volumes moderados.

Mas URLs populares criam hot spots: uma URL viral pode ser acessada milhares de vezes por segundo. Para isso, vou usar Redis como cache. Quando uma URL é criada, já guardo no Redis. Com uma TTL de 24 horas e as URLs mais populares sempre em cache, espero um hit rate de 90%+.

Com 90% hit rate, meu banco só precisa lidar com 10% do tráfego. Para o tráfego restante, read replicas garantem que o banco não seja gargalo. Isso escala para milhões de requests por dia facilmente.”

Tecnologias para mencionar: PgBouncer, pgcat (connection pooling). PostgreSQL streaming replication, MySQL replication (réplicas). Redis, Memcached (cache). CloudFront, Cloudflare (CDN).

Erros comuns:

• Adicionar Redis antes de indexar o banco. Eu já vi times adicionarem uma camada inteira de cache quando um CREATE INDEX teria resolvido em 5 minutos. Faça o básico primeiro.

• Cachear sem estratégia de invalidação. “Por que o usuário não vê a atualização?”

• Ignorar thundering herd no cold start. Quando o cache está vazio, todo mundo bate no banco ao mesmo tempo.

• Usar cache para dados críticos sem pensar em consistência. Saldo bancário desatualizado por 5 segundos pode custar dinheiro real.

2. Scaling Writes

O problema: Se escalar leituras é sobre “muita gente querendo a mesma coisa”, escalar escritas é sobre “muita gente querendo guardar coisas ao mesmo tempo.”

Pense em analytics: cada clique, cada page view precisa ser registrado. Um site com 1 milhão de usuários ativos pode gerar 100 milhões de eventos por dia. Isso é 1.157 escritas por segundo, em média. Em picos, pode ser 10x isso.

Um banco de dados relacional típico aguenta 10.000-20.000 escritas por segundo. Parece muito, mas acaba rápido quando cada interação dispara múltiplas escritas.

Quatro estratégias:

1. Sharding: Dividir dados entre múltiplos bancos

Se um banco aguenta 10k escritas/segundo, dez bancos aguentam 100k. A ideia é distribuir os dados de forma que cada banco receba uma fração do tráfego.

O segredo está na partition key, a chave que decide para qual shard o dado vai.

Boa partition key: user_id (distribuição uniforme)
Má partition key: país (Brasil e EUA sobrecarregam, Islândia fica vazia)

O desafio: Queries cross-shard. Se você precisa buscar dados de múltiplos shards (ex: “todos os posts do último mês”), cada query vira N queries. Escolha a partition key pensando em como os dados serão lidos também.

2. Filas: Buffer para absorver picos

Tráfego real não é constante. Black Friday, evento viral, horário de pico. De repente você tem 10x o volume normal.

Filas (Kafka, SQS, RabbitMQ) desacoplam quem escreve de quem processa:

Usuário → API → Fila → Workers → Banco
                 ↓
        Retorna "recebido" imediatamente

A API aceita a requisição e coloca na fila. Workers processam no ritmo que o banco aguenta. Se a fila cresce, você adiciona mais workers.

Trade-off: O dado não está no banco imediatamente. Para um like no Instagram, aceitável. Para uma transferência bancária, não.

3. Batching: Agrupar múltiplas escritas em uma

100 escritas individuais têm overhead: 100 conexões, 100 transações, 100 commits. Uma escrita com 100 registros tem overhead de uma.

Sem batching: 1000 likes = 1000 INSERTs
Com batching: Agrupa por 1 segundo, faz 1 INSERT com 1000 registros

Exemplo real: Contadores de view. Em vez de incrementar o contador a cada view, você acumula em memória por 5 segundos e faz um único UPDATE views = views + 47.

4. Agregação hierárquica para volumes extremos

Para milhões de eventos/segundo, você processa em camadas:

Edge servers (100) → cada um agrega 10k eventos/segundo
     ↓ envia resumo a cada segundo
Servidores regionais (10) → cada um recebe de 10 edges
     ↓ envia resumo a cada 10 segundos
Banco central → recebe 10 atualizações/segundo

Exemplo: YouTube view counts. 1 bilhão de views/dia = 11.500/segundo. Com agregação em 3 níveis, o banco central recebe ~100 escritas/segundo.

Framework de decisão:

Volume constante e previsível?
  → Sharding por partition key apropriada

Picos temporários (eventos, promoções)?
  → Filas para absorver bursts

Dados agregáveis (contadores, métricas)?
  → Batching + agregação

Volume extremo (milhões/segundo)?
  → Combinação: Sharding + Batching + Agregação hierárquica

Na entrevista (Analytics system, 1M events/second):

“1 milhão de eventos por segundo é sério. Isso é 86 bilhões de eventos por dia. Nenhum banco individual aguenta isso.

Minha estratégia combina três técnicas. Primeiro, uso Kafka como buffer de entrada, particionado por event_type.

Segundo, workers consomem do Kafka e fazem batching. Em vez de uma escrita por evento, agrupam por 1 segundo e fazem escritas em batch. Isso reduz 1 milhão de escritas para ~1.000 batch writes por segundo.

Terceiro, o banco é sharded por timestamp e event_type. Analytics geralmente consulta por período, então essa partition key otimiza tanto escritas quanto leituras.”

Tecnologias para mencionar: Kafka, SQS, RabbitMQ (filas). Cassandra, ScyllaDB, ClickHouse (bancos otimizados para escrita). DynamoDB, CockroachDB, Vitess (sharding nativo).

Erros comuns:

• Sharding prematuro. Um PostgreSQL moderno aguenta 64TB de dados e 20k escritas/segundo. Faça as contas antes de adicionar complexidade.

• Partition key com má distribuição. Cria hot shards.

• Achar que fila resolve problema de capacidade. Fila só resolve picos. Se o volume médio excede a capacidade, a fila só cresce infinitamente.

3. Long-Running Tasks

O problema: HTTP tem timeout. Load balancers, proxies, browsers: todos assumem que uma requisição deveria terminar em 30-60 segundos. Se não termina, algo deu errado.

Mas algumas operações legitimamente demoram:

• Transcodificar um vídeo de 1GB → 5-10 minutos

• Gerar um relatório PDF com milhões de registros → 2-3 minutos

• Processar upload de CSV com 100k linhas → 1-2 minutos

• Rodar ML inference em batch → vários minutos

Se você tentar fazer isso de forma síncrona, o usuário vê timeout, fica frustrado, dá retry (que piora tudo).

A solução: Separe “aceitar a requisição” de “processar a requisição”.

ANTES (síncrono):
Usuário → API → [processa 5 min] → timeout

DEPOIS (assíncrono):
Usuário → API → cria job → retorna job_id (50ms)
                    ↓
Fila → Worker → [processa 5 min] → atualiza status

O fluxo completo:

1. Usuário faz request: “Gere meu relatório anual”

2. API valida e enfileira: Cria registro no banco com status “pending”, coloca na fila, retorna job_id

3. Retorna imediatamente: “Seu relatório está sendo gerado. ID: abc123”

4. Worker processa: Puxa da fila, executa o trabalho pesado, salva resultado

5. Notifica conclusão: WebSocket, email, push notification, ou polling

Componentes essenciais:

Fila de Jobs: Onde as tarefas aguardam processamento. Precisa ser durável e suportar concorrência.

Workers: Processos separados que consomem da fila. Podem rodar em máquinas diferentes, escalar independentemente, usar hardware específico (GPU para vídeo, alta memória para relatórios).

Status Tracking: Tabela no banco com estado de cada job (pending → processing → completed/failed). Permite ao usuário consultar progresso.

Job Status Table:

abc123 → completed  (10:00:00 → 10:00:05 → 10:05:23) → s3://...
def456 → processing (10:01:00 → 10:01:03 → ...)
ghi789 → pending    (10:02:00 → aguardando)

Lidando com falhas:

• Heartbeat + timeout: Worker envia “estou vivo” periodicamente. Se para de enviar, a fila assume que morreu e disponibiliza o job para outro worker.

• Retries com backoff: Primeira tentativa falha → espera 1s → retry. Segunda falha → espera 4s. Terceira → espera 16s.

• Dead Letter Queue (DLQ): Depois de N falhas (geralmente 3-5), o job vai para uma fila separada. Jobs na DLQ precisam de investigação humana.

• Idempotência: O job precisa ser seguro para re-executar. Se você envia email no job, primeiro verifica se já enviou.

Framework de decisão:

A operação demora mais de 30 segundos?
  → Sim: Async workers obrigatório

A operação usa recursos diferentes (GPU, alta memória)?
  → Sim: Async workers para separar infraestrutura

O usuário precisa esperar o resultado para continuar?
  → Sim: Polling com progress updates
  → Não: Notificação quando pronto (email, push)

Na entrevista (YouTube video upload):

“Upload de vídeo tem duas fases bem diferentes: receber o arquivo e processá-lo.

Para receber, uso presigned URL direto para S3. O cliente faz upload sem passar pela minha API. Quando o upload completa, S3 dispara um evento.

Esse evento vai para uma fila. Workers de transcoding puxam jobs e geram múltiplas resoluções: 1080p, 720p, 480p, 360p. Cada resolução é um job separado que pode processar em paralelo.

O usuário vê ‘Processando...’ com barra de progresso. Consulto o status de cada job e mostro progresso agregado. Quando todos completam, o vídeo fica disponível.

Para workers, uso instâncias com GPU (para encoding rápido). Escalo baseado no tamanho da fila: se queue depth passa de 100 jobs, adiciono workers automaticamente. Falhas são tratadas com retry + DLQ.”

Tecnologias para mencionar: Kafka, SQS, RabbitMQ, Redis + BullMQ (filas). Lambda, Cloud Functions, Kubernetes Jobs (workers). Temporal, AWS Step Functions (orquestração).

Erros comuns:

• “Vou só aumentar o timeout para 10 minutos.” Conexões morrem, browsers fecham, load balancers reclamam.

• Status tracking como algo secundário. O usuário PRECISA saber o que está acontecendo.

• Fila única para jobs de 5s e jobs de 5min. Jobs rápidos ficam presos atrás de jobs lentos. Use filas separadas.

4. Real-time Updates

O problema: HTTP é request-response: o cliente pergunta, o servidor responde, a conexão fecha. Funciona perfeitamente para a maioria da web.

Mas e quando o servidor precisa avisar o cliente de algo que aconteceu? Quando um amigo manda uma mensagem no WhatsApp, você não fica fazendo refresh a cada segundo. A mensagem simplesmente aparece.

Exemplos onde você precisa de updates em tempo real:

• Chat: mensagens precisam aparecer instantaneamente

• Collaborative editing: Google Docs mostra o cursor de outros usuários

• Live dashboards: métricas atualizando continuamente

• Notificações: likes, comentários, menções

• Preços de ações: updates a cada segundo

O problema fundamental: como o servidor “empurra” dados para o cliente sem o cliente pedir?

A solução tem duas partes:

Parte 1: Como o cliente recebe (Servidor → Cliente)

1. Polling: Cliente pergunta a cada X segundos.

// Gringo fica perguntando "chegou mensagem?" a cada 2 segundos
// Mesmo quando ninguém mandou nada
setInterval(async () => {
  const mensagens = await fetch('/api/mensagens/novas');
  if (mensagens.length > 0) {
    atualizarChat(mensagens);
  }
}, 2000);

Simples, mas desperdiça requisições quando não há nada novo. Latência de até X segundos.

2. Long polling: Servidor segura a requisição até ter algo novo. Se não tiver, segura a conexão aberta por até 30 segundos.

Mais responsivo que polling, mas ainda tem overhead de criar nova conexão a cada update.

3. SSE (Server-Sent Events): Conexão HTTP permanece aberta. Servidor envia dados como “chunks” quando quiser.

// Servidor avisa Gringo quando tem novidade
// Gringo só escuta, não precisa ficar perguntando
const stream = new EventSource('/api/notificacoes');

stream.onmessage = (evento) => {
  const notificacao = JSON.parse(evento.data);
  mostrarNotificacao(notificacao); // 🔔 "Você tem um novo like!"
};

Comunicação unidirecional (servidor → cliente). Ótimo quando o servidor precisa enviar muitas atualizações, cliente raramente envia dados.

4. WebSockets: Conexão bidirecional persistente. Ambos podem enviar dados a qualquer momento.

// Chat do Gringo: conexão sempre aberta
// Pode mandar e receber mensagens instantaneamente
const chat = new WebSocket('wss://chat.nagringa.dev/ws');

chat.onmessage = (evento) => {
  const msg = JSON.parse(evento.data);
  adicionarMensagemNoChat(msg); // Ana: "Opa, tudo bem?"
};

// Gringo responde na hora
chat.send(JSON.stringify({
  tipo: 'mensagem',
  texto: 'Beleza! Estudando system design 🤓'
}));

Mais complexo. Conexões persistentes precisam de infraestrutura específica (load balancers L4).

Parte 2: Como o servidor descobre (Fonte → Servidor)

O cliente está conectado ao servidor via WebSocket. Mas como o servidor sabe que tem algo novo para enviar?

Pub/Sub: Servidores se inscrevem em “tópicos” (ex: chat:room123). Quando algo é publicado no tópico, todos os servidores inscritos recebem.

Ana envia mensagem → API → Publica em "chat:room123" (Redis/Kafka)
                                     ↓
Todos os servidores inscritos recebem
                                     ↓
Cada servidor envia para seus clientes conectados

Framework de decisão:

Latência de segundos é aceitável?
  → Sim: Polling simples

Updates são frequentes mas unidirecionais (servidor → cliente)?
  → Sim: SSE

Precisa de comunicação bidirecional de alta frequência?
  → Sim: WebSockets + pub/sub

Na entrevista (WhatsApp):

“Para mensagens em tempo real, vou usar WebSockets. Quando o usuário abre o app, estabelece conexão WebSocket com um servidor.

Para entregar mensagens, uso Redis pub/sub. Cada servidor se inscreve em tópicos por user_id. Quando Ana envia mensagem para Bruno, publico no tópico user:bruno. O servidor que tem a conexão de Bruno recebe e envia via WebSocket.

Para usuários offline, as mensagens ficam em uma fila persistente. Quando Bruno conecta, o servidor puxa mensagens pendentes e entrega em batch.

Para escalar, uso load balancer L4 para WebSockets. Isso mantém conexões persistentes no mesmo servidor. Heartbeats detectam conexões mortas.”

Tecnologias para mencionar: Socket.io, ws (WebSockets). Redis Pub/Sub, Kafka (pub/sub). SSE nativo em browsers modernos.

Erros comuns:

• WebSockets para tudo. Se você só precisa de updates ocasionais, polling é muito mais simples.

• Ignorar a comunicação entre servidores. Candidatos explicam WebSockets mas não explicam como o servidor que recebeu a mensagem notifica o servidor que tem a conexão do destinatário.

• Esquecer de usuários offline. Conexões caem. O que acontece com mensagens enviadas enquanto o usuário estava desconectado?

• Load balancer errado. Load balancers L7 terminam conexões TCP. Para WebSockets, você precisa de L4.

Metade do caminho. Esses padrões são a base técnica. Mas System Design é só uma etapa do processo. No curso Empresas Tier S, mostro a jornada completa: desde encontrar vagas até negociar oferta.

5. Large Files

O problema: Para arquivos pequenos, passar pelo servidor funciona. Mas para vídeos de 2GB, esse fluxo não escala:

1. Cliente envia 2GB para o seu servidor

2. Seu servidor recebe tudo (consome CPU, memória, conexões)

3. Seu servidor reenvia 2GB para o S3

4. Upload falha em 99%? Usuário recomeça do zero

Seus servidores viram intermediários. Não agregam valor, só movem bytes. E você paga banda de entrada E de saída.

A solução: Seus servidores não tocam nos bytes. Só gerenciam permissões.

Upload: Presigned URLs

Em vez de receber o arquivo, seu servidor gera uma URL temporária que permite upload direto para S3.

1. Cliente pede permissão para upload
2. Servidor valida user, gera presigned URL com validade de 15 min
3. Servidor retorna a URL
4. Cliente faz upload direto para S3 (seu servidor nunca vê os bytes)
5. S3 notifica seu servidor que upload completou (via evento)
6. Servidor atualiza status no banco

A presigned URL é uma URL normal do S3 com uma assinatura criptográfica que expira. Você pode adicionar restrições: tamanho máximo, content-type permitido.

Download: CDN com URLs assinadas

Para downloads, use CDN (CloudFront, Cloudflare). O arquivo é cacheado em servidores ao redor do mundo. Usuário em São Paulo baixa do edge server mais próximo.

Sem CDN: Usuário SP → Virginia → 200ms latência
Com CDN: Usuário SP → Edge SP → 5ms latência

URLs assinadas controlam acesso: só quem tem a URL válida consegue baixar. Expira em X horas.

Uploads grandes: Multipart/Chunked

Para arquivos de gigabytes, upload único é frágil. Se a conexão cair em 99%, perdeu tudo.

Solução: dividir em partes (5-100MB cada).

Arquivo de 500MB → 100 partes de 5MB
Parte 1 ✓
Parte 2 ✓
...
Parte 47 ✗ (conexão caiu)
→ Resume da parte 47, não do zero

S3 Multipart Upload, GCS Resumable Upload, Azure Block Blobs todos suportam isso nativamente.

Sincronização de estado:

O desafio: seu banco de dados e o S3 são sistemas separados. Como saber quando o upload realmente completou?

Confiar no cliente é arriscado. Cliente pode crashar depois do upload mas antes de notificar. Cliente malicioso pode dizer “completou” sem ter enviado.

Solução: S3 Event Notifications. S3 dispara eventos quando arquivos são criados. Configure para enviar para SQS ou Lambda. Worker recebe evento, atualiza status para “completed”.

Como rede de segurança, um job periódico verifica arquivos “pending” há mais de X horas e confirma se existem no S3.

Framework de decisão:

Arquivo maior que 10MB?
  → Sim: Upload direto com presigned URL

Arquivo maior que 100MB?
  → Sim: *Multipart upload* (resumable)

Arquivo será acessado frequentemente?
  → Sim: CDN com cache

Precisa validar conteúdo antes de aceitar?
  → Sim: Upload para bucket de quarentena, processa, move para bucket final

Na entrevista (Dropbox):

“Para uploads, vou usar presigned URLs. Quando o usuário quer fazer upload, o cliente pede permissão à API. A API valida o usuário, verifica cota de storage, e retorna uma presigned URL do S3.

Para arquivos grandes, uso S3 Multipart Upload. O cliente divide o arquivo em chunks de 10MB, faz upload de cada chunk para URLs separadas, e no final chama um endpoint de ‘complete’ que diz ao S3 para juntar os chunks.

Se a conexão cair, o cliente pode consultar quais chunks já foram enviados e resumir dali. Isso é crítico para arquivos de gigabytes.

Para sincronizar estado, S3 dispara eventos quando uploads completam. Um worker processa esses eventos e atualiza o banco de dados.

Downloads vão via CloudFront. URLs assinadas expiram em 1 hora.”

Tecnologias para mencionar: S3, Google Cloud Storage, Azure Blob Storage (object storage). CloudFront, Cloudflare, Fastly (CDN). S3 Event Notifications, Cloud Storage pub/sub (eventos).

Erros comuns:

• “Vou receber o arquivo e salvar no S3.” Red flag. Seus servidores não devem ser intermediários de bytes.

• Ignorar multipart para arquivos de GB. Upload único que falha = UX terrível.

• Confiar cegamente no cliente. Se o cliente diz “upload completo”, verifique via S3 antes de mostrar como disponível.

6. Contention

O problema: Último ingresso para o show do Taylor Swift. Ana e Bruno clicam “Comprar” no mesmo instante.

10:00:00.000 - Ana lê: 1 ingresso disponível ✓
10:00:00.001 - Bruno lê: 1 ingresso disponível ✓
10:00:00.050 - Ana pensa: "Oba, vou comprar!"
10:00:00.051 - Bruno pensa: "Oba, vou comprar!"
10:00:00.100 - Ana compra → ingressos = 0
10:00:00.102 - Bruno compra → ingressos = -1 💀

Resultado: dois clientes pagaram pelo mesmo ingresso. Um vai ser barrado na porta.

Isso é uma race condition. O problema acontece porque existe um intervalo entre “ler o estado” e “atualizar o estado”. Nesse intervalo, outro processo pode mudar o mundo.

Quanto mais escala, pior fica. Com 10.000 usuários simultâneos competindo pelo mesmo recurso, conflitos são garantidos.

Três abordagens:

1. Pessimistic Locking: Trancar antes de ler

“Assumo que vai ter conflito, então tranco o recurso antes de qualquer coisa.”

BEGIN TRANSACTION;

-- Ana tranca o ingresso ANTES de ler
-- Bruno vai ter que esperar na fila
SELECT ingressos_disponiveis FROM shows
WHERE show_id = 'taylor-swift-sp-2025'
FOR UPDATE;

-- Só Ana pode modificar agora
UPDATE shows
SET ingressos_disponiveis = ingressos_disponiveis - 1
WHERE show_id = 'taylor-swift-sp-2025';

COMMIT;
-- Agora Bruno pode tentar (mas já era, Ana comprou)

O FOR UPDATE adquire um lock exclusivo. Bruno fica bloqueado esperando Ana terminar.

Quando usar: Alta contenção, consistência crítica. Você sabe que conflitos são prováveis.

Trade-off: Pode virar gargalo. Se todo mundo tenta trancar o mesmo recurso, forma fila.

2. Optimistic Concurrency Control (OCC): Detectar conflito depois

“Assumo que conflito é raro. Se acontecer, detecto e tento de novo.”

-- Ana e Bruno leem ao mesmo tempo: 1 ingresso disponível
-- Nenhum dos dois trancou nada (otimista!)

-- Ana tenta comprar:
UPDATE shows
SET ingressos_disponiveis = ingressos_disponiveis - 1
WHERE show_id = 'taylor-swift-sp-2025'
  AND ingressos_disponiveis = 1;  -- "Só se ainda tiver 1"
-- ✅ Ana: UPDATE afetou 1 linha. Comprou!

-- Bruno tenta comprar (milissegundos depois):
UPDATE shows
SET ingressos_disponiveis = ingressos_disponiveis - 1
WHERE show_id = 'taylor-swift-sp-2025'
  AND ingressos_disponiveis = 1;  -- "Só se ainda tiver 1"
-- ❌ Bruno: UPDATE afetou 0 linhas (agora tem 0, não 1)
-- Sistema detecta: "Ops, alguém foi mais rápido. Esgotado!"

A chave é incluir o valor esperado no WHERE. Se o valor mudou desde que você leu, o UPDATE não afeta nenhuma linha.

Quando usar: Baixa contenção, leituras frequentes. A maioria dos updates não conflita.

Trade-off: Sob alta contenção, muitos retries. Pode ser ineficiente.

3. Reservations: Acesso exclusivo temporário

“Em vez de competir no checkout, reservo o recurso antes.”

Usuário seleciona assento → Sistema cria reserva de 10 minutos
                          → Outros usuários veem assento como "indisponível"
                          → Usuário tem 10 min para completar pagamento
                          → Se não completar, reserva expira automaticamente

Isso reduz a janela de contenção drasticamente. Em vez de competir durante todo o fluxo de pagamento (5 minutos), a competição acontece só no momento de criar a reserva (milissegundos).

Framework de decisão:

Os dados estão em um único banco?
  → Sim: Use locks ou OCC, não complique

Conflitos são frequentes (alta contenção)?
  → Sim: Pessimistic locking
  → Não: Optimistic concurrency control

É fluxo de usuário (não backend)?
  → Sim: Considere reservations para melhor UX

Na entrevista (Ticketmaster):

“O problema central aqui é contenção: milhares de pessoas competindo pelos mesmos assentos.

Vou usar um sistema de reservas. Quando o usuário clica em um assento, crio uma reserva com expiração de 10 minutos. O assento fica bloqueado para outros usuários nesse período.

Para implementar, uso um campo reserved_until no banco. Ao selecionar assento:

UPDATE seats
SET reserved_by = 'user123', reserved_until = NOW() + INTERVAL '10 minutes'
WHERE seat_id = 'A15'
  AND (reserved_until IS NULL OR reserved_until < NOW());

Se o UPDATE afeta 0 linhas, o assento já está reservado por outro.

Para a compra final, uso pessimistic locking para garantir atomicidade. Isso é aceitável porque a contenção real foi reduzida. Só quem tem reserva válida chega aqui.

Um job periódico limpa reservas expiradas.”

Tecnologias para mencionar: SELECT ... FOR UPDATE (PostgreSQL, MySQL), transações com isolation level SERIALIZABLE (locks). Version columns, conditional updates (OCC). TTL em Redis, campos reserved_until em SQL (reservations).

Erros comuns:

• Ignorar race conditions. “Vou só fazer UPDATE no banco” sem pensar em concorrência é red flag.

• Distributed locks para tudo. Se seus dados estão em um único banco, não precisa de Redis para locks. Transações resolvem.

• Pessimistic locking com transações longas. Se você tranca uma linha e depois faz chamada externa (pagamento), você segura o lock por segundos.

7. Multi-step Processes

O problema: E-commerce: cobrar pagamento → reservar estoque → criar etiqueta de envio → enviar email de confirmação.

O que acontece se o passo 3 falha? Você já cobrou o cliente e reservou o estoque. Precisa desfazer tudo.

1. Cobrar pagamento ✓ ($500 debitados)
2. Reservar estoque ✓ (item bloqueado)
3. Criar etiqueta ✗ (serviço de shipping fora do ar)
→ E agora? Cliente foi cobrado mas não vai receber o produto

Isso é um workflow distribuído: uma sequência de passos que:

• Envolve múltiplos serviços

• Pode falhar em qualquer ponto

• Precisa de rollback se algo der errado

• Pode demorar minutos, horas, ou dias

A solução tem duas abordagens:

1. Saga Pattern: Transações com compensação

Em vez de uma grande transação distribuída, você faz uma sequência de transações locais. Cada passo tem uma “ação de compensação” que desfaz o que foi feito.

Passo 1: Cobrar pagamento
  → Compensação: Estornar pagamento

Passo 2: Reservar estoque
  → Compensação: Liberar reserva

Passo 3: Criar etiqueta
  → Compensação: Cancelar etiqueta

Passo 4: Enviar email
  → Compensação: (não precisa. Email já foi)

Se passo 3 falha:

1. Cobrar pagamento ✓
2. Reservar estoque ✓
3. Criar etiqueta ✗
→ Executar compensação do passo 2 (liberar reserva)
→ Executar compensação do passo 1 (estornar)

Trade-off: Durante a execução, o sistema está temporariamente inconsistente. Depois do passo 1, o dinheiro saiu da conta do cliente mas ele ainda não tem o produto. Isso é eventual consistency. Você aceita inconsistência temporária em troca de simplicidade.

2. Workflow Engines: Orquestração durável

Escrever sagas manualmente é propenso a erros. Workflow engines (Temporal, AWS Step Functions) fazem isso automaticamente.

// Workflow de compra do Gringo
// Se qualquer passo falhar, desfaz os anteriores
async function workflowCompraGringo(pedido) {
  // Passo 1: Cobra o cartão
  const pagamento = await cobrarCartao(pedido);
  if (!pagamento.ok) {
    return { sucesso: false, erro: "Pagamento recusado 💳" };
  }

  // Passo 2: Reserva o produto
  const estoque = await reservarEstoque(pedido);
  if (!estoque.ok) {
    await estornarPagamento(pedido);  // Desfaz passo 1!
    return { sucesso: false, erro: "Produto esgotou 😢" };
  }

  // Passos 3 e 4: Finaliza
  await criarEtiquetaEnvio(pedido);
  await enviarEmailConfirmacao(pedido);

  return { sucesso: true }; // 🎉 Gringo feliz!
}

Parece código normal, mas o engine garante:

• Durabilidade: Se o servidor cair, outro continua de onde parou

• Retry automático: Falhas transientes são retriadas

• Estado persistido: Cada passo completado é salvo

Quando usar workflow engines:

• Processos que duram mais de segundos (interações humanas, aprovações)

• Coordenação complexa com muitos serviços

• Necessidade de audit trail completo

Framework de decisão:

Processo é simples (2-3 passos, tudo rápido)?
  → Saga implementada manualmente

Processo é complexo ou de longa duração?
  → *Workflow engine* (Temporal, Step Functions)

Precisa esperar por humanos (aprovações, etc)?
  → *Workflow engine* com *signals*

Na entrevista (Uber ride request flow):

“O fluxo de uma corrida envolve múltiplos passos com waits: request → match driver → driver accepts → pickup → ride → complete → charge.

Vou usar um workflow engine como Temporal. O workflow principal é:

1. Receber request do rider

2. Encontrar drivers próximos

3. Enviar request para driver mais próximo

4. WAIT: driver aceita ou timeout (30s) → Se timeout, voltar ao passo 3

5. WAIT: driver chega ao pickup

6. WAIT: rider confirma que está no carro

7. Ride em andamento

8. WAIT: driver marca como completo

9. Calcular e cobrar tarifa

Cada ‘WAIT’ é um signal no Temporal. O workflow fica suspenso sem consumir recursos. Quando o evento chega (driver aceita, rider confirma), o workflow continua.

Compensações: se o pagamento falhar no passo 9, o ride já aconteceu. Não dá para desfazer. Nesse caso, marco como ‘payment pending’ e uso um processo separado de cobrança retry.”

Tecnologias para mencionar: Temporal, AWS Step Functions, Google Cloud Workflows (workflow engines). Apache Airflow, Prefect (data pipelines). Bull/BullMQ (opções mais simples).

Erros comuns:

• Implementar saga complexa manualmente. Se você tem mais de 5 passos com compensações, use um workflow engine.

• Ignorar idempotência. Se um passo falha depois de executar mas antes de confirmar, o workflow vai re-executar. Cada passo precisa ser idempotente.

• Não pensar em compensações impossíveis. Nem tudo pode ser desfeito. Email enviado não volta. Ride completada não desaparece.

Juntando tudo

A maioria dos problemas de System Design são combinações desses 7 padrões.

Exemplo: “Design Instagram”

• Upload de fotos → Large Files (presigned URLs)

• Feed loading → Scaling Reads (cache + CDN)

• Like counts → Scaling Writes (batching)

• Notificações → Real-time Updates (push)

• Stories expiring → Long-Running Tasks (scheduled jobs)

Exemplo: “Design Uber”

• Ride matching → Multi-step Process (workflow)

• Driver location updates → Scaling Writes (batching)

• Rider vê driver se aproximando → Real-time Updates (WebSockets)

• Múltiplos riders pedindo mesmo driver → Contention (reservations)

• Histórico de corridas → Scaling Reads (cache)

Estratégia na entrevista:

1. Identifique o desafio central: Qual é o problema de escala ou complexidade aqui?

2. Mapeie para padrões: Isso é read-heavy? Write-heavy? Long-running? Competitive access?

3. Explique trade-offs: Não só “vou usar Redis”, mas “vou cachear com TTL de 5 min porque eventual consistency é aceitável aqui”

4. Quantifique quando possível: “Com 90% hit rate, o banco só precisa lidar com 10% do tráfego”

O que separa quem passa de quem não passa

Aqui está o segredo que ninguém te conta: o entrevistador já sabe a resposta. Ele não está tentando descobrir se você conhece Redis ou Kafka. Ele está avaliando como você pensa.

System Design é, tecnicamente, uma entrevista técnica. Mas na prática? É uma das entrevistas mais comportamentais que existe.

O entrevistador está avaliando:

• Você faz perguntas ou assume coisas?

• Você aceita feedback ou fica defensivo?

• Você explica seu raciocínio ou só joga tecnologias?

• Você colabora ou faz um monólogo?

Comunicação não é um diferencial. É requisito.

Se comunicação é seu ponto fraco, pratique:

• Brown bags / Tech talks: Apresente algo que você aprendeu para o time

• Liderar design meetings: Quando tiver uma feature nova, se voluntarie para facilitar a discussão

• Escrever design docs: Documentar uma decisão técnica força você a estruturar pensamento

• Gravar você mesmo: Resolva um problema de System Design em voz alta, grave, assista depois

A diferença entre eu falhando em 2021 e passando no PostHog não foi ficar mais inteligente. Foi aprender a mostrar como penso, não só o que sei.

Próximos passos

Para praticar:

1. Escolha 2-3 problemas clássicos (URL Shortener, WhatsApp, Uber)

2. Para cada um, identifique quais dos 7 padrões se aplicam

3. Pratique articulando a solução em voz alta

4. Faça mock interviews com colegas - você aprende dos dois lados

5. Use HelloInterview.com para feedback estruturado

E não esqueça das práticas do dia a dia que mencionei acima: design docs, tech talks, liderar discussões. Comunicação se desenvolve no trabalho, não só em simulados.

Leitura relacionada:

• Guia 2025: Entrevistas Comportamentais - a etapa que mais pesa na decisão final

• Design Docs e RFCs - como documentar decisões técnicas

• Dicas para Entrevistas de Live Coding

Para ir mais fundo:

System Design é só uma etapa do processo. Se você quer a jornada completa para entrar em empresas que pagam $100k+, criei o curso Empresas Tier S.

Desde encontrar vagas até negociar oferta, com artefatos reais: as offer letters que recebi, mensagens que mandei, e feedback das minhas entrevistas.

Ver detalhes do curso →

Os 7 padrões te dão o vocabulário. A prática te dá a fluência.

Boa sorte na próxima entrevista.

Na Gringa

Cresça rapidamente seu conhecimento sobre engenharia de software e o mercado internacional. Dicas concisas e úteis, semanalmente.

Por Lucas Faria

Nos últimos dois anos, centenas de pessoas me pediram pra dar uma olhada no CV delas. Assinantes, participantes da mentoria, gente do LinkedIn. Todo mundo com a mesma pergunta: “Lucas, o que tem de errado no meu currículo?”

E sabe o que eu percebi? Quase todo mundo comete os mesmos erros.

Gente com 10+ anos de experiência. Trabalhando em empresas conhecidas. Habilidades técnicas sólidas. Currículos que deveriam passar fácil. Mas não passam.

O problema nunca era falta de qualificação. Era como a qualificação estava sendo apresentada.

Cansei de repetir o mesmo feedback. Então resolvi documentar tudo.

Esses são os 5 erros que mais aparecem - e como consertar cada um.

✨ O que esperar do artigo

• Os 5 erros mais comuns que fazem CVs serem rejeitados na triagem

• Por que recrutadores descartam currículos em menos de 30 segundos

• A crise de confiança em CVs (e por que networking ficou ainda mais importante)

• Exemplos concretos de bullet points ruins vs. bons

O artigo de hoje é patrocinado pela Contabilizei.

💰 Virar PJ para trabalhar remoto

Virei PJ em 2020 para trabalhar internacional. Achei que seria complicado. Não foi.

A Contabilizei cuidou de tudo. CNPJ aberto em dias. Só precisei sair de casa 1x (certificado digital).

Desde então, 5 anos depois:

• Emito nota em 2 cliques todo mês

• Suporte disponível quando preciso

• Zero problema com Receita Federal

• Banco PJ integrado, com até modelo de invoice para quem trabalha no exterior

Virar PJ não precisa ser complicado. Precisa ter quem cuide da parte burocrática pra você.

Cupom NAGRINGA_2M para 2 meses grátis.

Primeiro, o contexto que você precisa entender

Deixa eu te dar alguns números - não meus, mas de quem vê o processo por dentro.

Charles Cook, que cuida de hiring no PostHog, escreveu recentemente sobre o que recrutadores realmente veem. Em 12 meses, o PostHog recebeu mais de 9.000 aplicações - uma média de 460 candidatos por vaga. De 300 aplicações pra uma única vaga de marketing, 12 conseguiram entrevista.

E o mais brutal: algumas aplicações levavam 5 segundos pra ele perceber que era um não. Cinco segundos. Outras ele gastava 5 minutos lendo com cuidado. A diferença? Como a informação estava apresentada.

Seu currículo não tá competindo só com gente da sua cidade. Tá competindo com engenheiros do mundo inteiro. E o recrutador não tem tempo de decifrar o seu potencial - você precisa deixar óbvio.

O que empresas realmente procuram são engenheiros “cracked” - gente que demonstra:

• Histórico de autonomia e ownership

• Curiosidade genuína sobre tecnologia

• Capacidade de entregar resultados com mínima supervisão

• Evidência clara de IMPACTO, não só responsabilidades

Mas tem outro problema que surgiu nos últimos dois anos.

A crise de confiança em currículos

Com a explosão de IA generativa, o mercado de recrutamento entrou em território desconhecido.

CVs gerados por IA viraram epidemia. Candidatos usam ChatGPT pra escrever currículos inteiros - inventando métricas, exagerando responsabilidades, criando bullet points que soam impressionantes mas não refletem a realidade.

O resultado? Recrutadores desenvolveram um ceticismo profundo.

Quer saber um feedback que eu dei três vezes na última semana? “Seu CV tá bom demais. Parece que o ChatGPT escreveu.” E o pior: em dois casos, eu tava certo. O cara confessou.

E não sou só eu. Nas próprias guidelines de aplicação do PostHog, a instrução é direta: “No ChatGPT, they’re really obvious.”

Recrutadores tão sacando isso também. Agora eles assumem que métricas são inventadas até você provar o contrário.

Estamos num cenário de baixa confiança.

Isso cria um paradoxo frustrante: você precisa ter um CV bem escrito pra passar na triagem, mas CVs bem escritos demais são vistos com desconfiança porque “parecem feitos por IA”.

O que isso significa na prática

Duas coisas:

1. Autenticidade virou diferencial. CVs que soam humanos, com linguagem natural, passam melhor que CVs “perfeitos” demais. Não significa escrever mal - significa escrever de forma genuína.

2. Networking ficou ainda mais crítico. Aqui entra o paradoxo: quanto mais os CVs parecem feitos por IA, mais o networking vale ouro.

Pensa assim: um recrutador vê 200 CVs. Todos parecem iguais. Todos têm métricas impressionantes. Como ele decide em quem confiar?

A resposta: referências e indicações.

Uma indicação de alguém de dentro corta todo esse ruído. O recrutador não precisa adivinhar se você é real ou se o ChatGPT inventou suas métricas - porque alguém que ele confia já confirmou. O CV vira só uma formalidade.

Lembra daquelas 12 pessoas que conseguiram entrevista no PostHog de 300 aplicações? Quatro delas eram referrals de membros do time. Um terço das entrevistas veio de indicações, não de aplicações frias.

Escrevi um artigo inteiro sobre como fazer networking de forma efetiva - especialmente pra quem é introvertido ou não sabe por onde começar:

Não tô dizendo pra ignorar o CV. Você ainda precisa dele. Mas entenda: o CV é necessário, não suficiente. A combinação de um bom CV + networking ativo é muito mais poderosa que qualquer um dos dois isoladamente.

Com isso em mente, vamos aos erros que você precisa corrigir.

Erro 1: Currículo com 3+ páginas

Regra de ouro: 1 página pra cada 10 anos de experiência.

Se você tem 5 anos de experiência e seu CV tem 3 páginas, tem um problema. Recrutadores não vão ler tudo. Eles vão fazer um scan de 30 segundos e decidir se vale a pena continuar.

O problema real: você tá incluindo informações que não agregam valor. Todo curso que fez, toda tecnologia que já encostou, toda responsabilidade de todo trabalho.

Quando seu CV tem 3 páginas, você tá diluindo suas melhores conquistas no meio de ruído. O recrutador pode nem chegar na parte que te diferencia porque desistiu antes.

Como consertar: Seja brutal na edição. Pergunta pra cada linha: “Isso me diferencia dos outros 200 candidatos?” Se a resposta for não, deleta.

Cursos de Udemy que todo mundo faz? Fora. Tecnologias que você usou uma vez há 3 anos? Fora. Experiência de estágio de 10 anos atrás? Provavelmente fora também.

Erro 2: Layout customizado (Canva, templates elaborados)

Eu sei que fica bonito. Aquele template do Canva com a barra lateral colorida, os ícones, as seções divididas em duas colunas.

O problema é duplo:

1. Sistemas ATS não conseguem ler direito. A maioria das empresas usa sistemas automatizados que parseiam seu CV antes de um humano ver. Layouts complexos quebram esse parsing. Seu template bonito do Canva vira texto quebrado e informação perdida.

2. Carga cognitiva desnecessária. Quando um recrutador tá vendo o 50º CV do dia, ele quer encontrar a informação rápido. Layouts criativos forçam o cérebro a trabalhar mais pra entender onde tá o quê.

Você pode pensar “mas meu design vai me destacar!” Na prática, destaca negativamente. Mostra que você priorizou estética sobre função - o oposto do que empresas de tech valorizam.

Como consertar: Use um formato limpo e padronizado.

• Nada de colunas laterais com habilidades

• Nada de ícones no lugar de texto

• Nada de fotos (a não ser que seja padrão no país da vaga)

• Nada de cores além de preto e talvez um azul escuro pra links

O melhor template é o mais simples: uma coluna, seções claras (Experiência, Educação, Skills), fonte legível. Boring funciona.

Erro 3: Currículo em português (ou inglês ruim)

Parece óbvio, mas vejo isso constantemente: currículos em português sendo enviados pra vagas internacionais.

CV em português = rejeição automática pela maioria dos recrutadores.

Não importa se a empresa tem escritório no Brasil. Não importa se a vaga diz “remote from anywhere”. Se você tá aplicando pra uma empresa internacional, seu CV precisa estar em inglês.

E quando o CV tá em inglês, frequentemente tem erros gramaticais ou frases que claramente foram traduzidas literalmente do português.

Exemplos que vejo toda hora:

• “Responsible for the development of systems” em vez de “Led development of...”

• “I worked in the company during 3 years” em vez de “3 years at Company X”

• “Actual position” em vez de “Current position” (actual = real, não atual)

• “I have knowledge in” em vez de simplesmente listar as skills

Erros assim sinalizam falta de atenção aos detalhes - exatamente o oposto do que você quer demonstrar. O recrutador pensa: “Se a pessoa não revisou o próprio CV, como vai ser o código dela?”

Como consertar: Seu CV deve estar em inglês impecável.

1. Escreva a primeira versão

2. Passa pelo Grammarly (a versão gratuita já ajuda muito)

3. Pede pra alguém que fala inglês fluentemente revisar

4. Leia em voz alta - erros ficam mais óbvios quando você ouve

E se seu inglês ainda não tá no nível necessário, esse é o gap que você precisa fechar antes de aplicar pra vagas internacionais.

Erro 4: Foco em responsabilidades, não em impacto

Este é o erro mais comum e mais prejudicial. Vejo em 90% dos CVs que analiso.

Ruim: “Responsável pelo desenvolvimento de features de pagamento”

Bom: “Liderei a implementação do Bill Pay auto-approve, usado por 91% de todos os pagamentos submetidos”

A diferença? O primeiro descreve uma tarefa. O segundo mostra um resultado.

Recrutadores querem saber: “E daí?” O que aconteceu porque você fez isso? Quantas pessoas usam? Quanto dinheiro economizou ou gerou? Quanto tempo reduziu?

A fórmula que funciona

Tem uma fórmula que o Google usa internamente - e eu vi funcionar dezenas de vezes nas revisões que fiz:

Conquista + Métrica + Como você fez.

Tipo: “Desenvolvi uma API RESTful que reduziu tempo de resposta em 40%, migrando de polling pra WebSockets”. Vê a diferença? Não é só “desenvolvi uma API”. É o que aconteceu por causa disso.

Exemplos reais de transformação

Essas linhas vieram de CVs de assinantes da newsletter. Iteramos juntos até chegar em versões que enfatizam o impacto.

(Nota: o ideal seria ter métricas específicas em cada bullet. Quando não tinha, focamos em pelo menos mostrar contexto e resultado. É o mínimo viável.)

Engenharia de Produto/Full-Stack:

❌ “Microservice development using Flask.”
✅ “Developed a RESTful API that streamlined workflows and enhanced team collaboration across departments”

❌ “Refactoring the code of a python application.”
✅ “Led a major code refactoring project, improving maintainability and reducing time for new feature releases”

❌ “Implementing CRUD operations for MongoDB.”
✅ “Engineered MongoDB CRUD operations, significantly improving data reliability and reducing data-related issues”

Engenharia de Dados:

❌ “Creating weekly dashboards with SQL queries.”
✅ “Developed weekly SQL dashboards that provided insights to boost overall team productivity”

❌ “Migration of data lake to the cloud.”
✅ “Migrated a 15-petabyte Data Lake to the cloud, enhancing data governance and optimizing costs”

E se eu não tiver acesso às métricas?

Eu ouço isso toda semana. E entendo - a maioria das empresas não dá visibilidade de métricas pra engenheiros individuais.

A boa notícia: você não precisa de números exatos.

Uma tática que funciona: pergunta pro seu tech lead ou PM. “Aquele refactor que fiz, que impacto teve no time?” Às vezes eles sabem números que você não tem. Outras vezes, dá pra estimar junto. “40% menos bugs em produção” pode ser uma estimativa do tech lead, não uma métrica de dashboard - e tudo bem.

Mesmo sem números, mostre IMPACTO. Frases como “improving maintainability”, “enhancing collaboration”, “enabling faster deployments” mostram que você entende o valor de negócio do seu trabalho.

O que você não pode fazer é só listar tecnologias ou descrever tarefas sem contexto. Isso coloca você na pilha de “candidatos genéricos”.

Se você quer se aprofundar em como identificar e articular o impacto do seu trabalho, escrevi um artigo inteiro sobre isso:

Erro 5: Hierarquia de informação ruim

Vi currículos onde a seção de “Cursos” vinha antes da “Experiência Profissional”. Onde “Objetivo” ocupava 5 linhas no topo. Onde a educação de 10 anos atrás tinha mais destaque que o trabalho atual.

A ordem importa porque recrutadores fazem scan de cima pra baixo.

Nos primeiros 10 segundos, o recrutador olha pro topo do CV. Se as primeiras coisas que ele vê não são relevantes, ele para de ler.

Você tá literalmente desperdiçando os pixels mais valiosos do seu documento.

A hierarquia ideal pra maioria dos casos

1. Nome e contato (1-2 linhas) - Nome, email, LinkedIn, GitHub se tiver projetos relevantes

2. Summary curto (opcional) - Só inclua se agregar valor real. “Software Engineer com 5 anos de experiência” é inútil

3. Experiência profissional (em ordem cronológica reversa) - 3-5 bullet points por experiência, foco em impacto

4. Skills técnicas (categorizadas) - Languages, Frameworks, Databases, DevOps. Não liste 50 tecnologias

5. Educação (breve) - Nome da instituição, curso, ano

6. Projetos pessoais ou open source (se relevantes)

O que NÃO colocar

• Foto - pra maioria das empresas americanas/europeias, isso é estranho

• Data de nascimento - irrelevante e pode gerar discriminação

• Estado civil - completamente irrelevante

• “Objetivo” genérico - “Busco crescimento profissional em empresa inovadora” não diz nada

• Referências “disponíveis mediante solicitação” - isso é assumido, não precisa dizer

Uma ferramenta pra aplicar tudo isso

Eu tava dando esse mesmo feedback tantas vezes que acabei automatizando. Criei uma ferramenta de IA que analisa CVs usando os mesmos critérios deste artigo:

• Idioma e profissionalismo: CV em inglês, sem erros gramaticais, formatação limpa

• Impacto sobre responsabilidades: Seus bullet points respondem “e daí?”

• Relevância do stack técnico: Tecnologias modernas e relevantes pro mercado internacional

• Progressão de carreira: Crescimento claro, sem red flags

• Prontidão competitiva: Seu CV se destacaria entre 200+ candidatos?

A análise te dá um score de prontidão (calibrado - a maioria fica entre 40-65, acima de 75 é genuinamente forte), pontos fortes, gaps, e ações concretas pra melhorar.

Importante: A ferramenta é pra te dar feedback, não pra escrever seu CV. Você entende onde precisa melhorar e faz as mudanças você mesmo. Assim mantém autenticidade - que, como vimos, virou diferencial.

Testa em nagringa.dev/app/analise-cv.

Todo mundo tem 2 análises gratuitas. Assinantes têm 30 por mês.

🌟 Resumo

• 1 página pra cada 10 anos de experiência - seja brutal na edição

• Layout simples e ATS-friendly - templates elaborados prejudicam mais do que ajudam

• Inglês impecável - CV em português é rejeição automática pra vagas internacionais

• Impacto, não responsabilidades - use a fórmula X-Y-Z: “Realizei [X] medido por [Y], fazendo [Z]”

• Hierarquia que faz sentido - experiência primeiro, informação irrelevante fora

• Networking em paralelo - num cenário de baixa confiança, indicações cortam o ruído

Lembra: seu currículo tá competindo com centenas de outros. Você tem 30 segundos pra convencer alguém que vale a pena continuar lendo. Cada linha precisa trabalhar a seu favor.

Mas não dependa só do CV. Construa relacionamentos. Participe de comunidades. Contribua pra open source. Essas coisas criam caminhos que nenhum currículo sozinho consegue criar.

Pra referência, meu CV tá disponível em cv.lucasfaria.dev. Aplico tudo que descrevi aqui.

📚 Pra aprofundar

• What startup recruiters actually see when you apply for a job - o artigo do PostHog que citei, direto de quem vê o processo por dentro

• Como otimizar seu currículo para vagas na gringa - guia mais detalhado sobre formatação

• Como e por que medir o impacto do seu trabalho - pra quem tem dificuldade em identificar métricas

• O que é networking e como fazer efetivamente - especialmente útil pra quem é introvertido

• Mil pessoas estão aplicando na mesma vaga que você - o contexto competitivo completo

Uma novidade: esse é o primeiro artigo com ilustrações do Gringo, nosso mascote. Tô experimentando esse formato pra deixar os artigos mais visuais.

Se tiver feedback sobre as imagens (ou sobre o artigo), deixa nos comentários - leio todos!

Se você conhece alguém que tá mandando currículo e não recebe resposta, compartilha!

Compartilhar

E, lembrando, pra ter sua análise pelo Gringo, basta acessar o nagringa.dev/app/analise-cv.

Três anos atrás, isso seria impensável. Eu teria que estudar a documentação do Phaser por dias, assistir tutoriais, fazer projetos pequenos antes de tentar algo real. Hoje, com Claude Code como meu par de programação, fui do zero ao deploy em uma tarde.

Esse é apenas um exemplo pessoal de algo muito maior acontecendo.

Em 30 de novembro de 2022, a OpenAI lançou o ChatGPT. Atingiu 100 milhões de usuários em dois meses, a adoção mais rápida de um produto de consumo na história. Agora, pouco mais de 1000 dias depois, estamos vivendo a transformação mais acelerada que a indústria de software já viu.

Não é hype. Os dados são inequívocos.

Em outubro de 2023, o Claude 2 resolvia 1.96% dos problemas reais de engenharia no SWE-bench, um benchmark que testa IAs em issues reais do GitHub. Em fevereiro de 2025, o Claude 3.7 resolvia 70.3%. Uma melhoria de 3.500% em 16 meses.

A pergunta não é mais “a IA vai mudar o desenvolvimento de software?”. A pergunta é: o que isso significa para você?

✨ O que esperar do artigo

• Os dados que mostram por que esses 1000 dias foram um dos mais disruptivos da história da engenharia de software

• O que “o custo da inteligência caindo” significa para sua carreira

• Como se posicionar para os próximos 1000 dias

💰Por que não troquei de contabilidade em 5 anos

O artigo de hoje é patrocinado pela Contabilizei.

Desde 2020 uso a Contabilizei. Mudei de empresa 3 vezes nesse período. A contabilidade? Mesma.

Não troquei porque não precisei. Funciona.

Abertura foi rápida - CNPJ em poucos dias, processo simples, só saí de casa 1x (certificado digital, que hoje pode ser online também).

Suporte sempre disponível - Quando tenho dúvida, consigo resposta. Via WhatsApp até 22h.

Zero problema - 5 anos emitindo nota todo mês, pagando impostos. Nunca tive multa ou pendência com Receita.

Simplicidade - Emitir nota leva 2 cliques. Consultar impostos é direto. Sem complicação.

Quando algo funciona, você mantém.

Cupom NAGRINGA_2M para 2 meses grátis.

A velocidade da mudança

Quando falamos de “mudança rápida” em tecnologia, geralmente pensamos em ciclos de anos. Uma nova linguagem pode levar mais de 10 anos até ser usada amplamente (lembra quando JavaScript era só meme?). Um framework se estabelece 5+ anos. Uma mudança de paradigma leva décadas.

O que aconteceu com IA generativa não segue esse padrão.

Os benchmarks não mentem (embora possam enganar)

O SWE-bench é um dos benchmarks mais rigorosos para avaliar capacidade de codificação de IAs. Ele usa issues reais de projetos open-source populares. Não exercícios de algoritmo isolados, mas problemas de engenharia de verdade, com contexto, dependências e edge cases.

Em 16 meses, saímos de “quase inútil” para “resolve 7 em cada 10 problemas reais de engenharia”. E isso continua melhorando.

Mas benchmarks têm limitações. Simon Willison, após testar o Claude Opus 4.5 em preview, fez uma observação importante:

“Benchmarks like SWE-bench Verified show models beating each other by single digit percentage point margins, but what does that actually equate to in real-world problems that I need to solve on a daily basis?”

Ele passou um fim de semana usando o novo Opus 4.5 no Claude Code, fazendo 20 commits, mudando 39 arquivos, com mais de 2.000 linhas adicionadas. Quando o preview expirou e ele voltou para o Sonnet 4.5, continuou trabalhando no mesmo ritmo.

“I’m not saying the new model isn’t an improvement on Sonnet 4.5, but I can’t say with confidence that the challenges I posed it were able to identify a meaningful difference in capabilities between the two.”

Tive uma experiência similar com o GPT-5. A OpenAI construiu uma expectativa enorme: “um assistente nível PhD”. Mas quando testei para meus casos de uso reais, ele não conseguiu substituir o Claude Sonnet que eu já usava. O lançamento acabou sendo controverso, com muitos desenvolvedores relatando experiências parecidas.

O ponto não é que os benchmarks sejam inúteis. Eles mostram uma tendência clara de melhoria. A evolução de 1.96% para 70%+ no SWE-bench é real e significativa. Mas a diferença entre modelos no topo do ranking é cada vez mais difícil de perceber no dia a dia.

O que importa para você não é qual modelo vence por 2% no benchmark. É como essas ferramentas mudam o que você consegue fazer.

Kent Beck, criador do TDD e Extreme Programming, com mais de 40 anos de carreira, resumiu o que sentiu ao testar o ChatGPT pela primeira vez em abril de 2023:

“90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.”

Ele não estava sendo dramático. Estava sendo preciso.

Os engenheiros que você respeita já mudaram

Armin Ronacher criou o Flask e trabalha no Sentry. Em setembro de 2025, ele escreveu sobre um novo projeto de infraestrutura:

“For the infrastructure component I started at my new company, I’m probably north of 90% AI-written code. I don’t want to convince you, just share what I learned.”

São 40.000 linhas de código em Go, com API REST, SDKs em Python e TypeScript, infraestrutura em Pulumi. 90% gerado por IA, mas com a arquitetura e revisão dele.

Simon Willison, co-criador do Django com 25+ anos de experiência, descreve o impacto na sua produtividade:

“It’s not about getting work done faster, it’s about being able to ship projects that I wouldn’t have been able to justify spending time on at all.”

Ele mantém um repositório com 77 ferramentas web, todas construídas com assistência de IA. Adiciona várias por semana. Projetos que ele nunca teria tempo de fazer agora existem porque o custo de implementação despencou.

O dinheiro confirma a tendência

Se os benchmarks e as experiências pessoais não convencem, o dinheiro convence.

O Cursor um dos casos mais impressionantes. Atingiu $100 milhões de receita anual em 12 meses, com apenas 12 funcionários. É a empresa SaaS mais rápida da história a atingir esse marco. Hoje vale $29.3 bilhões, um aumento de 73x em 15 meses.

Seus clientes incluem OpenAI, Midjourney, Shopify, NVIDIA, Adobe e Uber. As empresas que constroem IA usam IA para construir.

Kent Beck disse algo que ficou comigo:

“Technological revolutions proceed by radically reducing the cost of something that used to be expensive, then discovering what is valuable about what has suddenly become cheap.”

É exatamente isso que estamos vivendo. O custo da inteligência está caindo. A questão é: o que se torna valioso agora?

O custo da inteligência

Antes de “computer” ser uma máquina, era um cargo.

Na NASA dos anos 1950, salas cheias de mulheres brilhantes (conhecidas como “human computers”) faziam os cálculos complexos da corrida espacial. Elas eram as trabalhadoras de conhecimento originais, os processadores humanos no coração da empresa mais avançada do planeta.

Então o IBM 7090 chegou.

Em uma única tarde, o computador eletrônico fazia mais cálculos do que um humano faria em uma vida inteira. O cargo de “computer” desapareceu da noite para o dia.

Essa história não é apenas uma curiosidade histórica. É um preview.

Os knowledge workers de hoje, sentados em escritórios open-plan, trabalhando em laptops, são descendentes diretos daquelas mulheres. E o IBM 7090 deles chegou.

O que acontece quando automatizamos inteligência?

Durante toda a minha vida, eu estudei pensando que precisava ter conhecimento para “ser alguém”.

No passado, pré-revolução industrial, isso significava se tornar um artesão. Alguém que sabia fazer roupas, sapatos, móveis. Porém, conseguimos automatizar isso com máquinas.

Então os profissionais valorizados passaram a ser os de conhecimento. Advogados, médicos, engenheiros, programadores. Pessoas que vendem o que sabem, não o que fazem com as mãos.

Mas agora temos IA que está se tornando cada vez mais capaz de fazer atividades de conhecimento. Em apenas 1000 dias, os benchmarks melhoraram 3.500%.

E, diferente de mim, LLMs não ficam doentes, não têm variações de humor, não pedem aumento nem tiram férias. Se o trabalho pode ser feito com teclado e mouse, por que usar humanos no loop?

O mercado já está respondendo

Os dados mostram que a adoção está acelerando:

O Stack Overflow Developer Survey de 2025, com mais de 65.000 respondentes, mostra que 84% dos desenvolvedores já usam ou planejam usar ferramentas de IA. A Gartner projeta que até 2028, 90% dos engenheiros em empresas usarão assistentes de código.

O paper de Harvard sobre o mercado de trabalho mostra uma tendência preocupante para vagas junior. Quando o custo de produzir código cai drasticamente, a demanda por quem está começando (e ainda está aprendendo a produzir) também muda.

Isso não é apocalipse. É redistribuição de valor.

A pergunta que importa

Se inteligência era escassa e agora está se tornando abundante, o que passa a ser escasso?

Emad Mostaque, no livro “The Last Economy”, conta a história da Xerox PARC:

“In the 1970s, Xerox PARC invented the modern personal computer, the graphical user interface, the mouse, and the Ethernet. They invented the future. Their parent company, Xerox, ignored all of it. Why? The Xerox Corporation was an execution engine perfectly optimized for leasing copiers and selling toner. The personal computer did not fit their model. So they let a young man named Steve Jobs take their ideas for free and build Apple. Xerox’s execution engine was so perfect it executed itself.”

A Xerox tinha conhecimento. Tinha capacidade técnica. Tinha recursos. O que não tinha era a capacidade de ver além do que já sabia fazer.

Essa é a armadilha que precisamos evitar.

O novo diferencial

Se 90% das habilidades de Kent Beck, um dos engenheiros mais influentes da história, “caíram para zero”, o que são os 10% que valem 1000x mais?

O que a IA faz bem (e cada vez melhor)

Simon Willison descreve seu processo atual:

“For production code my LLM usage is much more authoritarian: I treat it like a digital intern, hired to type code for me based on my detailed instructions... I dictate the design, the LLM does the work of building the body to my specification.”

Ele dá um exemplo concreto: uma função Python assíncrona para download de arquivos com verificação de tamanho, validação de SQLite, e tratamento de erros. Algo que levaria 15 minutos para escrever corretamente, o Claude fez em 15 segundos.

A IA hoje faz muito bem:

• Gerar código boilerplate

• Implementar padrões conhecidos

• Refatorar código existente

• Escrever testes

• Debugar com acesso às ferramentas certas

E está melhorando em ritmo exponencial.

O que a IA não faz (ainda)

Armin Ronacher, mesmo com 90% de código gerado por IA, faz um alerta importante:

“None of this removes the need to actually be a good engineer. If you let the AI take over without judgment, you’ll end up with brittle systems and painful surprises: data loss, security holes, unscalable software. The tools are powerful, but they don’t absolve you of responsibility.”

Ele conta que pediu para a IA construir um rate limiter. “Funcionou”, mas faltava jitter e usava decisões ruins de storage. Fácil de corrigir se você entende rate limiters. Perigoso se você não entende.

A IA não faz bem:

• Entender o problema de negócio. Ela implementa o que você pede, não o que você precisa.

• Fazer trade-offs com contexto incompleto. Ela não sabe que o prazo é semana que vem ou que o cliente é sensível a latência.

• Construir relacionamentos e confiança. Ninguém vai te contratar porque sua IA é boa.

• Ter taste. Saber quando parar, o que é “bom o suficiente”, quando dizer não.

Os 10% que valem 1000x

Voltando ao Kent Beck, os 10% que sobraram são justamente o que a IA não replica:

“LLMs amplify existing expertise... Could anyone else have done this project in the same way? Probably not! My prompting here leaned on 25+ years of professional coding experience.” Simon Wilson.

A IA amplifica o que você já sabe. Se você sabe pouco, amplifica pouco. Se você sabe muito, amplifica muito.

Por que isso é positivo

O jogo em Phaser que eu fiz é um exemplo perfeito. Eu nunca teria investido uma semana aprendendo uma game engine para um projeto paralelo. Mas algumas horas? Isso eu tenho.

E isso não é apenas comigo:

“This way of working unlocks paths I’d normally skip or defer.” Armin Ronacher.

Simon Wilson também diz o mesmo:

“The fact that LLMs let me execute my ideas faster means I can implement more of them, which means I can learn even more.”

O custo de experimentar caiu. O custo de aprender caiu. O custo de criar caiu.

Para quem sabe aproveitar, isso é libertador.

Código para a era dos agentes

Uma das minhas recomendações mais específicas: comece a pensar em como seu código interage com agentes de IA.

O problema

“It is easy to create systems that appear to behave correctly but have unclear runtime behavior when relying on agents. For instance, the AI doesn’t fully comprehend threading or goroutines. If you don’t keep the bad decisions at bay early, you won’t be able to operate it in a stable manner later.” Armin Ronacher.

Agentes são poderosos, mas não são mágicos. Eles operam com base no contexto que você dá e nas ferramentas que têm acesso. Código ruim + agente = desastre em escala.

O que funciona

Depois de meses usando Claude Code intensivamente, como descrevi no meu artigo sobre a migração, identifiquei padrões consistentes:

Por que TypeScript e Go estão saindo na frente

Linguagens com tipagem explícita e boas ferramentas de análise estática funcionam melhor com agentes. O agente sabe o que esperar, consegue validar o próprio trabalho, e recebe feedback claro quando erra.

Armin fez uma escolha interessante no projeto dele: raw SQL em vez de ORM.

“I really like using an ORM, but I don’t like some of its effects. Once you approach the ORM’s limits, you’re forced to switch to handwritten SQL... The fact that I no longer have to write SQL because the AI does it for me is a game changer.”

Ele escolheu ser mais explícito justamente porque o agente consegue ver (e gerar) o que está acontecendo. Menos magia, mais clareza.

Ouça mais sobre esse assunto neste episódio do Pragmatic Engineer Podcast.

Leaf nodes: o segredo para reduzir contexto

Uma das técnicas que mais uso: pensar em “leaf nodes”. São partes do código que nada crítico depende. Lugares seguros para deixar o agente trabalhar.

No frontend: quebre componentes grandes em pedaços menores. Dashboard monolítico vira <DashboardLayout>, <ChartSection>, <FilterBar>. Cada um é um contexto focado.

No backend: divida APIs grandes em módulos. users.py, auth.py, payments.py. Cada módulo vira um leaf node independente.

Com TDD, fica ainda melhor. Você define os testes primeiro, garante que falham, e deixa o agente implementar até passar. É uma rede de segurança que permite confiar sem precisar revisar cada linha.

O que fazer agora

O investimento das big techs mostra a direção que o mundo está tomando.

Em 2025, Microsoft, Amazon, Google e Meta comprometeram mais de $325 bilhões em infraestrutura de IA. Isso é aproximadamente 1% do PIB americano. Em um único ano.

A NVIDIA, que fornece os chips para essa infraestrutura, viu sua receita de datacenter ir de $3.8B por trimestre (antes do ChatGPT) para $35.6B, um aumento de 9x. A empresa vale $4.3 trilhões hoje, 12x mais do que no fim de 2022.

Não é uma aposta. É uma certeza de quem controla o capital.

Para todos

Aprenda a usar IA de forma efetiva. Não é opcional.

“If someone tells you that coding with LLMs is easy they are (probably unintentionally) misleading you. It takes significant effort to figure out the sharp and soft edges of using them in this way.” Simon Willison,

Usar IA bem é uma habilidade. Leva tempo para desenvolver. Comece agora.

Invista em relacionamentos. O que a IA não replica é confiança entre pessoas. Networking real, não só no LinkedIn, vai valer mais do que nunca.

Desenvolva taste. Passe 10 minutos analisando por que o Linear parece tão bom. Estude como o Notion estrutura suas APIs. Leia os engineering blogs da Stripe e Figma. Taste se constrói por exposição deliberada, não por osmose.

Para quem está começando

O mercado junior está mais difícil. Isso é fato. Mas a diferenciação agora vem de mostrar que você sabe usar IA, não de competir contra ela.

Simon Willison chama de “vibe-coding” a prática de experimentar com IA de forma exploratória:

“Vibe-coding is a great way to learn... Throwing absurd ideas at them and vibe-coding until they almost sort-of work is a genuinely useful way to accelerate the rate at which you build intuition.”

Projetos pessoais importam mais do que nunca. Eles mostram que você consegue ir do zero ao deploy, que não precisa de um gerente dizendo o que fazer.

Para mid-level

Acelere a chegada em senior. A escada ainda existe, mas está mudando. As habilidades que te levaram até aqui não são as mesmas que vão te levar adiante.

Foque no que não é automatizável: comunicação, liderança técnica, capacidade de definir problemas, não só resolvê-los.

Como escrevi sobre o que aprendi ao não ser promovido, senioridade não é sobre tempo. É sobre impacto e julgamento.

Para senior+

Você é o orquestrador agora.

“I still review every line, shape the architecture, and carry the responsibility for how it runs in production. But the sheer volume of what I now let an agent generate would have been unthinkable even six months ago.” Armin Ronacher.

Seu valor está em decisões, não em linhas de código. Em saber o que construir, não em como implementar. Em mentorar outros a usar essas ferramentas de forma efetiva.

O futuro não é IA substituindo programadores. É amplificação. Quem souber orquestrar vai ter um impacto desproporcional.

🌟 Resumo

• 1000 dias mudaram tudo: SWE-bench melhorou 3.500%, empresas cresceram 400x+, $325B investidos em infraestrutura em um único ano

• O custo da inteligência está caindo: O que era escasso (conhecimento, capacidade de escrever código) está se tornando abundante

• O novo diferencial: Relacionamentos, taste, julgamento, e saber orquestrar IA. Os 10% que valem 1000x mais

• Prepare seu código: Tipagem explícita, feedback loops rápidos, arquitetura em leaf nodes, convenções documentadas

Aja agora. Em novembro de 2022, quem apostou cedo em IA ganhou uma vantagem que ainda está compondo. Daqui a 1000 dias, em agosto de 2028, vamos olhar para trás e ver que a janela de posicionamento era agora. A diferença é que dessa vez você sabe que ela existe.

📚 Referências

Análises e Comentários

• Kent Beck: 90% of My Skills Are Now Worth $0

• Simon Willison: Here’s how I use LLMs to help me write code

• Armin Ronacher: 90%

• Situational Awareness: Leopold Aschenbrenner

• AI 2027

Benchmarks e Pesquisas

• SWE-bench Leaderboard

• Stack Overflow Developer Survey 2025 (e de outros anos também)

• Papers With Code: HumanEval

Dados das Empresas

• Anthropic Newsroom

• OpenAI Research

• GitHub Blog

• Cursor Blog

Dados Financeiros e de Mercado

• CNBC AI Coverage

• TechCrunch AI

• The Information

Esse foi um dos meus artigos de pesquisa maiores, por isso demorou alguns dias extras para sair. Espero que tenham gostado 🙏

Se você acha que esse artigo pode ser útil para outras pessoas, compartilhe!

Compartilhar

Essa é a pergunta que separa devs que constroem carreiras sólidas daqueles que ficam pulando de galho em galho sem crescer de verdade.

Na carreira de TI, eu observo dois grupos principais:

• Grupo A: Troca de empresa atrás de +30% de salário

• Grupo B: Aprende tudo o que consegue numa empresa, depois troca fazendo saltos de 3-5x ao mudar de tier

Contra-intuitivo, mas Grupo B cresce mais rápido no longo prazo. Por quê?

Hoje trago o Yuri Flagare, um dos membros mais ativos da comunidade do NaGringa e autor da The Ignition Blueprint. Ele viveu ambos os lados: ficou 3 anos ganhando R$2.5-3k, mas depois multiplicou seu salário por 10 trabalhando remotamente pra gringa, trocando de uma empresa Tier 1 para Tier 3.

A história dele ensina quando ter paciência – e quando trocar imediatamente.

Agora é com o Yuri:

Você vê todo mundo crescendo rápido. Aquele dev que começou junto com você já tá ganhando o dobro. Outro pulou pra gringa em 6 meses. E você? Continua no mesmo lugar, com um salário que parece injusto comparado ao que você entrega.

Eu sei como é essa sensação. No meu primeiro ano eu programava C# numa startup minúscula, ganhando 2.5k. Passei os dois anos seguintes na Hotmart ganhando na mesma faixa 2.5-3k, onde eu tinha que escolher entre ser Frontend React ou Backend Java. Hoje trabalho remotamente pra gringa, multipliquei meu salário por 10, trampo com stacks totalmente diferentes das que eu comecei, depois de ter passado por todo tipo de tecnologia e produto.

Hoje posso me definir como Engenheiro de Software, alguém que não precisa ficar numa caixa, trabalha com problemas complexos e recebe muito bem por isso – exatamente o que eu corri atrás há 4 anos pra conseguir.

Só que tudo isso teve um preço. Um preço alto.

E o que eu aprendi nesses anos não foi sobre como crescer mais rápido. Foi sobre quando ter pressa te atrapalha e quando é hora de realmente trocar de empresa.

✨ O que esperar desse artigo

• Os 3 sinais claros de que é hora de trocar de empresa (e quando você tá só com pressa demais)

• Por que clareza sobre seu crescimento vale mais que salário alto no curto prazo

• O framework prático para avaliar se você tá sendo recompensado de acordo com o mercado

🪣 O balde de água fria: com 1-2 anos você ainda não sabe nada

E eu falo isso da forma mais respeitosa possível: com um ano e meio de dev, você tá na infância da sua carreira.

Não é diminuir suas capacidades. É a realidade. Nessa fase você ainda tá aprendendo:

• Como seu código impacta o negócio

• Como trabalhar com sistemas legados

• Como debugar problemas que não aparecem no tutorial

• Como se comunicar sobre tradeoffs técnicos

• Como estimar trabalho de forma realista

Tem uma distorção muito grande de valores de salários no nosso mercado. Principalmente em grupos de devs, onde só aparecem os casos fora da curva. Você vê gente pulando de 5k pra 20k em 6 meses, mas não vê as centenas que continuam crescendo de forma gradual e sustentável.

Você acaba achando que o baseline é a exceção à regra porque, nos tempos de hoje, o que destaca e faz barulho é só o extraordinário. E, eu arrisco dizer, é bem provável que você seja refém do bom e velho viés da confirmação: você quer que essa seja a realidade. Você precisa. E eu entendo, sou culpado do mesmo mal.

Digo, quem é que quer ouvir que não tá pronto pra ganhar mais? Que tá exatamente onde deveria estar?

A verdade é: o que você tá ganhando provavelmente tá condizente com sua experiência. Pode até estar acima da média, especialmente se for remoto.

Testemunhei mais de uma vez dev com 1 ano de xp ganhando 4k+ trabalhando de casa.

Deixa eu te contar: se você ganha isso, você tá fora da curva. Para quem mentora outros devs ocasionalmente como eu, testemunhei depoimentos mais de uma vez de uma realidade bem parecida com aquela que eu tive em 2018: presencial, 2k, sem benefícios. Às vezes até 6x1.

A fase mais crucial da sua carreira

Sabe qual é o maior perigo dessa fase inicial? Você cria débitos de carreira por pressa.

Débito de carreira é quando você:

• Pula de empresa em empresa atrás de salário sem aprender direito

• Escolhe trabalhos só por stack “em alta” sem entender o produto

• Ignora feedbacks porque “eles não reconhecem seu valor”

• Não documenta suas conquistas porque tá correndo pro próximo cargo

Eu não tenho uma habilitação formal como dev. Sou engenheiro mecânico. Sou (ou era) o típico esterótipo do dev de bootcamp. Quando saí da Hotmart eu nunca tinha ouvido falar em Leetcode, entrevista de projeto de sistema (system design), entrevista de code challenge, e, acredite se quiser em “Algoritmos e Estruturas de Dados” como uma disciplina.

Pense no cenário: 2020, auge da pandemia, faltando dev no mercado. A barra era mais baixa: se o dev competente, falava inglês e entrevistava bem, já era meio caminho andado. Foi assim que consegui minha vaga na Deliberate AI, a primeira pra fora numa startup de AI pra saúde mental.

Mas essa não é mais a realidade.

E eu paguei o preço.

Quando precisei sair, o mercado já tinha virado e todas as coisas que eu não sabia eram cobradas nos processos seletivos. Quando entrei na empresa seguinte, minha falta de conhecimentos fundamentais de engenharia de software limitou o potencial de crescimento e oportunidades que eu podia pegar. Virei uma mão de obra pra ticket. O eterno pleno.

Deixa eu te contar a regra básica da promoção e do crescimento: a empresa só promove alguém formalmente quando essa pessoa já opera acima do nível que ela tem como título. Quando você já provou que consegue assumir desafios maiores do que seu nível é que você é promovido. Não quando você tá apenas mandando muito bem nas coisas que faz – é o que a gente chama de promotion lagging, quando você já tem, por exemplo, responsabilidades de sênior, mas ainda é pleno. Você teve que provar que dava conta antes de ser oficialmente intitulado como alguém que dá.

Eu nunca tive essa oportunidade porque me faltava capacidade técnica. O que gerou outro débito de carreira comigo mesmo: meu currículo não tinha uma progressão clara, e eu não tinha uma história forte de crescimento pra compartilhar com recrutadores. Eu não podia me candidatar pra vagas acima da que eu estava, porque essencialmente não estava pronto.

Mas nem tudo foi pressa. Quando eu tava na Hotmart, tive várias propostas para sair para ganhar mais. Localiza ia dobrar meu salário. Tive proposta de 15k PJ. Podia ter saído antes? Sim. Mas usei aquele tempo pra entender como eu funcionava como dev. Aprendi a cometer erros num ambiente seguro. Explorei áreas diferentes.

E eu sabia que que eu estava onde devia estar naquele momento. Isso valeu cada centavo a menos que eu ganhei.

O que nos leva ao próximo tópico.

🚪 Os 3 sinais de que é REALMENTE hora de trocar

Agora, nem tudo é “tenha paciência”. Existe um momento certo de sair. E você sempre sabe quando chegou.

Sinal #1: Você cresceu além do que a empresa pode oferecer

Você sente que não tá mais aprendendo. Os desafios técnicos viraram rotina. Você já sabe como tudo funciona e não tem espaço pra crescer.

Como identificar: Você consegue prever exatamente como vai ser seu dia nos próximos 3 meses. Zero surpresas técnicas.

Sinal #2: Sua liderança limita sua prosperidade

Você tem certeza que teria mais potencial em outro lugar, mas não consegue mudar de time internamente. Seu gestor não te dá feedback claro ou bloqueia suas iniciativas.

Como identificar: Você propõe ideias e elas morrem na mesa do seu líder. Você não entende os critérios de promoção. Suas 1:1s não tem objetivo claro.

Sinal #3: Seus valores não se alinham mais aos da empresa

A empresa toma decisões que você discorda fundamentalmente. Pode ser sobre produto, cultura, ou como tratam as pessoas.

Como identificar: Você volta pra casa se sentindo mal com as decisões da empresa. Você não consegue mais defender o produto ou a cultura em conversas com amigos.

Hoje eu acho que poderia ter ficado um pouco mais na Hotmart, mas quando saí, um dos principais motivos foi que eu senti que precisava de um ambiente diferente para crescer. Mas ao mesmo tempo não me arrependo. A gente só consegue conectar os pontos olhando para trás.

A regra de ouro

Se pelo menos dois desses sinais aparecem, ou um deles torna sua vida absolutamente miserável, troque.

Mas quando você trocar, não troque só por salário. Troque pensando em qual lugar vai te dar o maior potencial de crescimento.

Um vai virar juros compostos de carreira. O outro vai te levar à estagnação, e daqui a 2 anos você estará no mesmo lugar.

Tem dev que gosta de entrar num lugar já pensando em quanto tempo vai ficar. Particularmente não é minha metodologia. Parece com aquele seu tio que só compra carro pensando no valor da revenda. Ele vive sempre num futuro hipotético. Ele nunca aproveita o que tem agora porque só tenta minimizar o prejuízo futuro.

E pra ser dono da sua carreira, você precisa decidir o que é que no seu dia a dia, no presente o que te dá mais potencial de crescimento no futuro. Qual carro, agora, vai te dar a melhor experiência no caminho que você tomou? Aliás, carreira dev é sobre isso: os melhores são aqueles que gostam da jornada.

É um jogo perigoso, esse de viver tentando minimizar riscos. De repente você tirou todo potencial de crescimento e trocou pela certeza tênue do agora.

📈 Como jogar o jogo longo (e ganhar de verdade)

Aqui está o que a maioria não entende: crescimento composto supera reconhecimento imediato.

A skill mais importante: clareza

A skill mais importante que você pode construir nos seus primeiros anos é clareza.

Clareza significa:

• Saber o quanto você tá aprendendo de verdade

• Entender se você tá crescendo tecnicamente ou só fazendo mais do mesmo

• Registrar suas conquistas de forma que virem material pra um CV forte

• Avaliar se você tá no caminho certo sem depender de validação externa

Tem o jeito inteligente, o jeito duro de construir clareza. Como tudo na vida, a gente vai tão longe sem um bom sistema, e tem uma frase do James Clear que é clássica, mas muito boa nisso.

• “Você não se eleva ao nível dos seus objetivos. Você fica no nível dos seus sistemas. – James Clear

O que quero dizer com isso? Eu aprendi quebrando a cara. Sendo reprovado em processo, sofrendo boicote de promoção, sofrendo demissão em massa e refletindo depois que o pior já aconteceu.

Tenho um amigo que documenta absolutamente tudo que ele faz desde o dia que ele começou a trabalhar, sabe cada entrega que fez e cada skill que aprendeu.

Hoje, eu faço journaling e estou desenvolvendo um app pra me ajudar, mas a palavra chave é: intencionalidade.

Eu adoto o princípio da engenharia reversa. Eu penso exatamente o que eu quero e faço de trás pra frente o caminho. Eu sou intencional com as minhas escolhas, pra onde quero ir, o que quero trabalhar e como quero crescer. Me coloco no lugar da minha liderança e me imagino do outro lado e reflito: o que é que esse cara ia querer de mim nesse momento? O que eu preciso fazer pra fazer a vida dele mais fácil?

Por que clareza importa tanto? Porque a comparação é a inimiga da clareza.

Isso tudo fez a minha vida muito mais fácil. No começo, lá na Hotmart, eu sofria constantemente porque via meus pares recebendo mais, crescendo mais rápido.

Não importa como a empresa trata aqueles dois colegas seus que ganham mais. Às vezes um negociou melhor (skill pra você colocar na lista). Às vezes o outro faz melhor propaganda do que realmente entrega (outra skill pra você aprender).

Hoje, eu olho pra dentro e ignoro o ruído. Só me preocupo com o que tá no meu controle. O mais importante aqui é o autoconhecimento. É ser assertivo no quão bem você está indo dentro dos seus objetivos.

E pra isso tem uma questão essencial, porque às vezes uma empresa, ou vaga, não está servindo aos seus objetivos.

A pergunta que muda tudo

Dado o que eu sei e, principalmente, o que eu NÃO sei, sinto que estou sendo recompensado em comparação ao MERCADO?

Se não, vá para o mercado. Teste. Entreviste. Valide.

Mas não compare com casos individuais. Compare com dados reais de mercado.

Você não é valorizado pela importância, mas pela raridade

Essa é uma das frases que mais moldaram como eu penso carreira.

Infelizmente, você não é valorizado pela sua importância. Se fosse, o professor ganharia uma fortuna. Você é valorizado pela sua raridade no mercado.

Então pergunte: quais skills eu preciso desenvolver pra me tornar um profissional de que as empresas precisam?

Às vezes nem se trata de uma skill técnica óbvia. Às vezes os profissionais mais impactantes têm skills não tradicionais. Particularmente, já ouvi mais de uma vez que meu ponto mais forte é minha habilidade de aplicar conhecimentos transversais, de comunicar assuntos complexos de forma simples, de usar histórias para causar impacto e de saber me colocar muito bem no lugar do cliente. O que eu não sabia é que essas skills eram essenciais pra me tornar um bom Engenheiro de Produto e que me renderam ótimos feedbacks em processos seletivos.

Talvez as que você precisa você até já tenha.

Como usar empresas de forma egoísta (e inteligente)

Pense em cada trabalho como um degrau. A pergunta não é “quanto vou ganhar?”, mas sim:

“Qual tipo de empresa vai ser o melhor degrau possível pra eu me tornar o que eu quero?”

É o renome/pedigree (empresas grandes e famosas)?
É a stack moderna?
É a tecnologia de ponta?
É o tipo de desafio técnico?
É o ambiente cultural?
É a indústria?

No meu caso, depois de 3 anos em startup pequena, eu sabia que precisava de:

1. Exposição a time internacional

2. Desafios mais complexos e maiores responsabilidades

3. Trabalhar com um produto complexo atuando de ponta-a-ponta

4. Trabalhar próximo do meu cliente final

O principal motivo que me fez escolher a Hotmart, a Deliberate AI e depois a eSpark Learning foi os produtos e a indústria. Eu sou o tipo de pessoa que precisa se importar com aquilo que trabalha, então só vou para lugares em que eu acredito na missão.

Por motivos como esses fui pra gringa. Não foi só pelo 10x no salário. Foi porque eu sabia que aquele ambiente ia me forçar a crescer de formas que eu não conseguiria onde estava.

O ambiente que te torna inegavelmente bom

Quando você tá num ambiente que te torna um profissional melhor, acontece uma coisa mágica:

Você se torna tão bom que as pessoas não conseguem te ignorar.

E aí a remuneração (seja do mercado ou da empresa) se torna uma consequência inevitável.

Não é sobre “trabalhar mais”. É sobre “trabalhar de forma estratégica” escolhendo os ambientes certos.

🎯 O que fazer agora

Se você tá se sentindo perdido ou com pressa:

1. Reavalie seu momento com honestidade

• Quantos anos reais de experiência você tem?

• Você já enfrentou problemas de escala? Sistemas legados? Incidentes de produção?

• Suas expectativas salariais estão alinhadas com o que você traz de diferencial?

2. Faça o teste dos 3 sinais

• Você cresceu além da empresa? → Busque desafios maiores

• Sua liderança te limita? → Procure ambientes com líderes fortes

• Valores desalinhados? → Vida é curta demais pra isso

3. Pense nos próximos 2 anos

• Que skills você precisa desenvolver?

• Que tipo de problemas você quer resolver?

• Que ambiente vai te tornar inegavelmente bom?

4. Construa clareza

• Documente suas conquistas mensalmente

• Compare com o MERCADO, não com indivíduos

• Teste o mercado regularmente pra calibrar sua raridade

🌟 Resumo

• Com 1-2 anos você tá na infância da carreira — é hora de cometer erros e explorar, não de cobrar reconhecimento máximo

• Troque quando pelo menos 2 dos 3 sinais aparecerem:

  • Você cresceu além do que a empresa oferece

  • Liderança limita seu crescimento

  • Valores completamente desalinhados

• Clareza é a skill mais importante — saber quanto você tá crescendo vale mais que validação externa

• Você é valorizado pela raridade, não importância — desenvolva skills que te tornam inegavelmente bom

• Crescimento composto > reconhecimento imediato — escolha ambientes que te forçam a evoluir, não só salário maior

📝 Sobre o autor

Sete anos como engenheiro em startups com propósito me ensinaram o que realmente importa para mim: ajudar a gerar valor para os clientes. Sou agnóstico de stack e tenho experiência prática em backend, frontend, devops, bancos de dados, IA — e mais coisas que eu nem mesmo lembro. Tenho até 3 anos de experiência como Product Owner!

Já trabalhei em empresas de EdTech (Hotmart, eSpark Learning), Saúde/Biotech (Deliberate AI) e Manufatura (PlantScanner).

No meu tempo livre, sou um indie hacker construindo meu primeiro produto, narrative designer e game writer prestando consultoria em histórias de jogos, desenvolvedor indie solo fundando meu próprio estúdio e trabalhando no meu primeiro jogo, além de autor de ficção e criador de conteúdo.

Você pode me encontrar no LinkedIn ou acompanhar minha jornada em https://theignitionblueprint.substack.com/publish/home.

Aqui é o Lucas de novo.

Muito obrigado ao Yuri por compartilhar todos os aprendizados que aprendeu nos últimos anos. Isso tudo veio de uma discussão que a gente fez no grupo do WhatsApp do NaGringa, onde conversamos sobre carreira e processos seletivos diariamente.

Nesse dia, eu me lembro muito bem de ver tudo que o Yuri havia escrito, e falei pra ele: por favor, venha publicar sobre isso na newsletter.

Espero que vocês todos tenham tirado um ótimo proveito do artigo de hoje. Foi o primeiro guest post que tivemos em nossa newsletter.

Se vocês gostarem, me avisem, pois posso tentar trazer outras pessoas também.

E, pra você, qual foi alguma lição de carreira que demorou alguns anos para aprender?

Deixe um comentário

Essa semana gravei o primeiro episódio do NaGringa Cast com Thiago Veras, engenheiro de software no Google. Eu passei os últimos 4 anos focando em startups (Brex, PostHog), enquanto o Thiago foi pro caminho das big techs (Microsoft, Google).

A conversa durou mais de 1 hora e me fez questionar várias coisas que eu achava que sabia sobre trabalhar em empresas grandes.

A verdade? Muita coisa mudou desde 2020. A “estabilidade garantida” das big techs não existe mais. Referrals não garantem nem que leiam seu currículo. E o processo de promoção pode levar 3 anos mesmo com performance excelente.

Mas também tem o lado bom: se você sabe o que esperar e como se preparar, entrar numa big tech continua sendo totalmente possível. Não precisa ser gênio. Precisa entender as regras do jogo.

✨ O que esperar do artigo

• Como funcionam os processos seletivos de Google, Meta e Microsoft na prática (com timelines reais e o que realmente avaliam)

• Por que big techs são mais lentas e o que isso significa pro seu crescimento de carreira

• Ações concretas se você quer tentar uma big tech nos próximos meses

O processo seletivo real: da aplicação até o primeiro dia

Vou ser direto: o processo de big techs é padronizado e previsível. Google, Meta, Microsoft, Amazon: todas seguem mais ou menos o mesmo roteiro.

Aqui está o que o Thiago passou ao entrar no Google:

1. Aplicação → conversa com recrutador

2. Online assessment (coding test sozinho, na plataforma deles)

3. Phone screen (45min-1h de coding ao vivo)

4. Googleyness Assessment (~40 perguntas comportamentais em 15 minutos)

5. Onsite (4 entrevistas seguidas: 3 técnicas + 1 comportamental)

6. Team matching (o famoso “Tinder de times”)

O que surpreendeu: depois de passar no onsite, você ainda não tem emprego. Você entra numa fila de “team matching” onde times olham seu perfil e decidem se querem conversar com você. Pode levar dias ou meses dependendo da sua performance.

O Thiago teve um pouco de sorte (ou arrasou demais na entrevista, o que eu acho mais provável). Recebeu o primeiro convite de time no mesmo dia que passou no onsite. Mas ele conhece gente que ficou meses esperando.

O que eles realmente avaliam

A conversa esclareceu algo que muita gente não entende: big techs não testam seu conhecimento de React, Django ou Kubernetes. Elas testam fundamentos.

“Cara, aprender uma arquitetura de microserviço, aprender uma linguagem de programação... a gente pega isso com o barco andando. Mas aquela noção de resolver problemas de baixo nível, aplicar toda essa parte teórica da faculdade — isso é o que eles valorizam.” — Thiago

Por quê? Porque eles têm ferramentas internas pra tudo. No Google, até o editor de código é interno. Você não usa VS Code, não usa GitHub, não usa Datadog. Tudo é custom.

Então eles focam no que é transferível: algoritmos, estruturas de dados, system design, capacidade de resolver problemas complexos do zero.

Ação concreta se você vai aplicar

Esqueça estudar frameworks específicos. Foque em:

• Algoritmos fundamentais: busca binária, DFS/BFS, programação dinâmica

• Estruturas de dados: arrays, hash tables, árvores, grafos

• Prática de coding: LeetCode, HackerRank, Codeforces

• System design (se for pra sênior+): como arquitetar sistemas que escalam

O Thiago recomenda o livro “Cracking the Coding Interview” se você gosta de ler. Mas a verdade? “Eu não sou pessoa de livro. Eu vou lá e faço questão atrás de questão até entender.”

A velocidade real: por que tudo demora tanto

Uma das maiores diferenças entre startups e big techs? Velocidade de execução.

No PostHog, onde eu trabalho, é esperado que você abra PRs no primeiro dia. No Google? Thiago levou 2 meses até começar a escrever código de verdade pro time dele.

Não é porque ele é lento. É porque o onboarding é gigante:

• Primeiro mês: aprende ferramentas internas do Google

• Segundo mês: aprende o código do seu time

• Daí pra frente: começa a trabalhar de verdade

E quando você finalmente escreve código, ele não vai direto pra produção. “Às vezes demora duas, três, quatro semanas desde o merge até que o código entre em produção. Tem várias camadas de teste. Se a gente montar um código sensível e quebrar produção, vai afetar a vida de muita gente.”

Na startup é diferente?

Completamente. Na Meta, por exemplo, você faz deploy no primeiro dia. É parte da cultura.

Mas isso tem trade-offs. Velocidade vs. qualidade. Big techs podem demorar mais porque trabalham em escala absurda. Um bug no Google pode afetar bilhões de usuários.

O que isso significa pra você

Se você está começando carreira e quer aprender rápido, startups podem ser melhores. Você vai errar mais, mas vai aprender na prática.

Se você quer aprender a fazer coisas complexas do jeito certo, big techs te ensinam processos que outras empresas ainda não descobriram.

Não existe certo ou errado. Existe alinhamento com onde você está.

Promoções: prepare-se para esperar

Aqui está a parte que mais me surpreendeu: promoções em big techs demoram MUITO.

Eu estava acostumado com startups onde, se você manda bem, pode ser promovido em 1 ano. No Google? 2-3 anos por nível é normal, não exceção.

“Eu fiz meu review agora. Estou longe de estar pronto pra ser promovido. Pra virar sênior eu vou precisar de pelo menos uns dois anos e meio a três anos. Tem gente que é pleno há quatro anos e meio na empresa.” — Thiago

Por que demora tanto?

Três razões principais:

1. Os requisitos são muito específicos

Pra virar sênior no Google, não basta programar bem. Você precisa:

• Liderar projetos complexos de ponta a ponta

• Mentorear pessoas júnior/pleno

• Participar de iniciativas de diversidade

• Melhorar o ecossistema interno da empresa

2. Você precisa provar consistência

Não adianta ter 1 trimestre bom. Você precisa provar que opera no próximo nível por 1-2 anos antes de ser promovido.

3. Budget e política entram na jogada

“Cada org é como se fosse uma empresa. Às vezes aquela org, o produto dela não está dando muito dinheiro, então o budget de promoção é menor. Não dá pra promover todo mundo, então tem que priorizar.”

O Thiago mesmo conhece pessoas afetadas por isso na Microsoft. Estavam prontas pra ser promovido, mas tinha gente no mesmo nível há mais tempo. Priorizaram os outros.

Isso é bom ou ruim?

Depende. A compensação vem junto. Big techs pagam bem e têm aumentos regulares mesmo sem promoção. Você não fica estagnado financeiramente.

Mas se você precisa de crescimento de título rápido (pra visa, pra próximo emprego, etc), startups podem ser melhor opção.

A verdade sobre referrals e networking

Deixa eu destruir um mito: referral não garante nada.

“Eu já dei referral pra uns 3 amigos na Microsoft e nenhum deles foi chamado. Já dei uns 2-3 referrals no Google, nenhum deles foi chamado também.” — Thiago

Antigamente, referral garantia que lessem seu currículo. Hoje? Nem isso. Com as ondas de layoffs e hiring freezes, até referrals vão pra pilha normal.

Mas networking ainda importa

Paradoxalmente, networking importou mais que nunca. Só não da forma que você imagina.

“Quando eu decidi sair da Microsoft, eu literalmente só mandei mensagem pros meus amigos no Brasil falando que ia mandar referral. E aí eu fui fazer o processo com eles.”

O networking não te garante o emprego. Mas te dá:

1. Informação interna sobre como é trabalhar lá

2. Alguém que conhece seu trabalho pra falar por você internamente

3. Portas que se abrem naturalmente quando você faz bom trabalho

“Você sempre está trabalhando em times impactantes com gente que é muito boa. Quando eu comecei na IBM, meu primeiro manager hoje está aqui no Vale do Silício. Me ajudou a descarregar caminhão de mudança. E o dia que eu quiser, ele me faz referral pra eu tentar o processo lá.”

Ação concreta sobre networking

Pare de pensar em networking como “ir em eventos”. Networking acontece no trabalho.

Faça seu trabalho tão bem que as pessoas com quem você trabalha queiram trabalhar com você de novo. Esse é o networking que importa.

A realidade de 2025: estabilidade não existe mais

Talvez a parte mais importante da conversa foi sobre mudanças na cultura de big techs.

“Eu acho que essa estabilidade foi embora já tem um bom tempo. Alguns anos atrás, beleza, você entrou na big tech, vai ficar tranquilo lá pra sempre. Mas as coisas foram mudando.”

O que mudou:

• Layoffs atingem até bons performers se o produto é cortado

• Pressão aumentou (mais projetos, mais responsabilidade, menos gente)

• Benefícios diminuíram (menos mordomias, mais cobrança)

Microsoft, por exemplo, era conhecida por work-life balance tranquilo. “Agora se você não tem performance boa, já está começando a rolar bastante layoff. Eles estão te delegando mais projetos. Às vezes você é owner de um serviço sendo júnior.”

O que fazer com essa informação

Não escolha big tech pela “estabilidade”. Escolha porque:

• Quer aprender a trabalhar em escala

• Quer mentoria de gente muito boa

• Quer compensação forte (que ainda existe)

• Quer nome da empresa no currículo

Mas sempre tenha plano B. Mantenha seu GitHub ativo. Mantenha contatos. Continue estudando.

“Eu foco mais em evoluir como pessoa, como programador, entregar bastante, me sentir desafiado. Isso é onde eu tenho controle. O resto não está no meu controle. Não tem muito que eu posso fazer.” — Thiago

🌟 Resumo

Sobre processos seletivos:

• Big techs testam fundamentos (algoritmos, estruturas de dados), não frameworks específicos

• O processo é previsível: online test → phone screen → onsite → team matching

• Prepare-se estudando LeetCode e praticando coding interviews

Sobre o dia a dia:

• Tudo é mais lento por design (processos, deploys, onboarding)

• Você trabalha com ferramentas internas. Nada de VS Code, GitHub, AWS padrão. E isso é por necessidade: essas empresas não tinham acesso a essas soluções quando começaram a ter os problemas que elas resolvem.

• Troque velocidade por aprender a fazer coisas complexas em escala

Sobre crescimento:

• Promoções levam 2-3 anos por nível (não 1 ano como em startups)

• Você precisa provar consistência, não só ter bons trimestres

• Budget do time afeta suas chances (política existe)

Sobre networking:

• Referrals não garantem nem que leiam seu currículo

• Networking real = fazer trabalho tão bom que as pessoas querem trabalhar com você de novo

• Mantenha contatos, mas não conte só com eles

Sobre estabilidade:

• “Big tech = emprego pra vida” é mito em 2025

• Layoffs acontecem mesmo com bons performers

• Escolha pelo aprendizado e compensação, não por segurança falsa

📌 Próximos passos

Se você quer tentar big tech nos próximos 6 meses:

1. Comece a estudar algoritmos hoje. LeetCode, HackerRank, um problema por dia

2. Aplique direto no site. Não espere ter “networking suficiente”. Mas, se você tiver, a referral pode sim ajudar.

3. Faça mock interviews. Com amigos, em plataformas como Pramp, ou sozinho com o ChatGPT/Claude/

Se você está decidindo entre big tech e startup:

1. Pergunte a si mesmo: você prefere velocidade ou profundidade? Promoções rápidas ou aprendizado estruturado?

2. Considere seu momento de vida: precisa de visto? Prefira big tech. Quer equity com potencial alto? Startup pode valer mais.

3. Lembre: não é pra sempre. Você pode começar em um e ir pro outro. O Thiago mesmo foi startup → big tech. Eu fui big tech → startup.

💎 Quer acelerar sua preparação para Big Techs?

Eu e o Thiago vamos lançar nosso guia de Como Conquistar sua Vaga em Big Tech.

Por enquanto, ele está em pré-venda e sendo vendido com 20% de desconto. Quem já for assinante do NaGringa ganha +10% de desconto em cima disso.

Quem não for assinante do NaGringa vai ganhar 30 dias de gratuitos na compra do guia. Com isso, você tem acesso a todos os benefícios incluindo 15+ práticas de system design e entrevistas comportamentais.

Para todos aqueles que seguirem todos os passos e passarem, devolveremos seu dinheiro. Temos confiança que vamos entregar um conteúdo de qualidade. E, se você fizer tudo e conseguir passar, a sua vitória é o único pagamento que precisamos.

Além disso, se você mudou de ideia, pode pedir o reembolso em até 30 dias após o lançamento do material. Sem justificativa nenhuma.

Você pode conferir na página os módulos em detalhes. Mas, resumidamente:

1. Por Que Ouvir a Gente?

2. Seu Plano de Imigração: para quem quer sair do país

3. Decifrando o Processo Seletivo

4. Seu Plano de Estudos Battle-Tested

5. Dominando Entrevistas Comportamentais

6. Q&A Ao Vivo

7. Módulo 2: Coding Interview Mastery. Esse será lançado em Janeiro do ano que vem, onde depois teremos um aumento de preço.

Se você já está convencido, pode comprar ele diretamente por aqui. Depois, me avise por WhatsApp ou LinkedIn para que eu já te adicione no nosso grupo exclusivo no WhatsApp.

E, se ficou alguma dúvida, pode responder a esse e-mail ou me chamar no LinkedIn também.

Novidades para assinantes pagos

Agora, no nosso portal de vagas, você consegue filtrar vagas pela tech stack. Ou seja, pode pesquisar por palavras-chave como “typescript”, “.net” ou “python”. Experimente. Tem várias possibilidades novas.

Adicionei também vários atalhos para deixar a navegação mais fluída.

Lembrando que o acesso é um benefício apenas para assinantes pagos. Se você quiser pagar via PIX ou parcelado, pode fazer por aqui. Temos também a opção de um plano vitalício, que pode ser parcelado em até 12x.

Assinantes pagos tem direito a:

• Acesso a nossa comunidade no WhatsApp (200+ pessoas ambiciosas que compartilham objetivos profissionais). Eu e várias outras pessoas interagimos aqui diariamente. Em particular, esse é o meu benefício preferido

• Acesso a todo o nosso repertório de entrevistas de system design (15 vídeos) e entrevistas comportamental (1 vídeo, com o próximo saindo semana que vem)

• Mentorias em grupo 3x ao mês

• Acesso ao portal de vagas com 850+ vagas. Elas são atualizadas diariamente, e ordenadas automaticamente por salário ou quando foram postadas. Algumas estatísticas de vagas por área de atuação:

Se está com a alguma dúvida, sinta-se a vontade pra me mandar mensagem. Pode ser aqui no Substack ou no LinkedIn. Se quiser fazer o upgrade da sua assinatura, pode fazer por aqui:

Assine agora

Nos falamos no próximo artigo! Abraços e ótima semana pra todos 🙏

O Zara me contou algo fascinante: depois de quase 10 anos focado em system design, arquitetura e gestão de pessoas (mal colocando a mão no código), ele voltou a programar. E a razão? LLMs.

Isso me chamou atenção porque não é um caso isolado.

Armin Ronacher, criador do Flask, passou de cético a entusiasta de LLMs em 6 meses. Kent Beck, criador do Extreme Programming, diz que está se divertindo mais programando do que em 52 anos de carreira. Peter Steinberger, fundador da PSPDFKit, voltou a codar diariamente depois de anos afastado.

Mais casos como esse você confere no artigo do Gergely do Pragmatic Engineer.

Algo mudou. E mudou rápido.

Mas aqui está o que poucos percebem: enquanto 88% das empresas já usam IA, apenas 33% conseguiram escalar essas tecnologias de verdade. Os outros 67%? Estão experimentando, testando, tentando descobrir como extrair valor real.

A fonte deste dados, e o minha análise, você vai ver daqui a pouco. Continue lendo!

Por que essa diferença brutal?

Porque LLMs não eliminam a necessidade de aprender profundamente. Elas multiplicam o valor de ter fundamentação sólida.

É como ter um assistente extremamente capaz. Se você não sabe o que pedir, ou não consegue avaliar o que recebe de volta, o assistente não ajuda. Pior: pode te atrapalhar.

Mas se você domina os fundamentos? Arquitetura, trade-offs, product sense. Então LLMs se tornam o acelerador mais poderoso que já existiu em engenharia de software.

Nos últimos meses, usei LLMs para construir toda a plataforma do NaGringa, chegar no top 3 do Google em várias keywords competitivas, e faturar R$ 90 mil com um side business. Tudo isso trabalhando em tempo integral em outra empresa competitiva.

Não porque sou especial. Mas porque aprendi a usar essas ferramentas em máxima eficiência. E o que descobri nesse processo pode mudar completamente como você pensa sobre sua carreira nos próximos anos.

✨ O que esperar do artigo

• Como veteranos céticos se tornaram os maiores defensores de LLMs (e o que isso revela sobre quem realmente se beneficia dessas ferramentas)

• O fluxo real de trabalho com agentes paralelos que me permitiu 10x meu output sem comprometer qualidade, incluindo os trade-offs honestos que ninguém fala

• Por que fundamentação técnica importa MAIS agora, não menos. E como diferenciar desenvolvedores que vão dominar essa nova era dos que vão ficar para trás

Por que veteranos com décadas de carreira mudaram de ideia

Um dado impressionante: 88% das empresas já usam IA regularmente. Mas aqui está o detalhe que importa: apenas 33% começaram a escalar essas tecnologias de verdade.

Os outros 67%? Estão experimentando. Testando. Ainda tentando descobrir como extrair valor real dessas ferramentas.

E sabe quem está no grupo dos 33% que realmente faz acontecer? Engenheiros com anos (às vezes décadas) de experiência. Ou, com uma curiosidade genuína pela capacidade destes sistemas.

Não é coincidência.

A virada dos céticos

Armin Ronacher foi enfático por meses: ferramentas de IA para desenvolvimento não valiam a pena. Até que, há alguns meses, algo mudou. Ele publicou um artigo chamado AI changes everything:

“Se você tivesse me dito há 6 meses que eu preferiria liderar um engenheiro virtual a simplesmente programar eu mesmo, eu não acreditaria. Agora, posso ir fazer um café e o progresso continua acontecendo. Posso estar no parquinho com meu filho enquanto o trabalho avança em segundo plano.”

Peter Steinberger, que construiu e vendeu uma empresa de US$ 100 milhões, estava afastado do código diário. Agora? Está programando todos os dias de novo. Ele descreveu como “o momento mais empolgante desde que aprendi a programar”.

Kent Beck, com 52 anos de carreira, resume: “Estou me divertindo mais programando do que nunca.”

O que mudou?

Não foi um salto súbito de capacidade dos modelos. Foi a combinação de três fatores:

1. Ferramentas maduras: Claude Code, Cursor, e outros agentes chegaram num ponto de confiabilidade onde você pode delegar tarefas não-triviais

2. Aprendizado sobre como usar: descobrimos que não é sobre substituir programação, mas sobre arquitetar soluções e dirigir execução

3. Infraestrutura pronta: ferramentas como MCP (Model Context Protocol) tornaram integração trivial

Mas aqui está o ponto crucial: todos esses engenheiros que mudaram de ideia têm algo em comum.

Eles têm 10+ anos construindo sistemas complexos.

Eles não aprenderam a usar LLMs porque assistiram um tutorial. Eles já sabiam exatamente o que precisava acontecer: o contexto necessário, os edge cases, os trade-offs. As LLMs apenas aceleraram a execução.

É como a diferença entre dar direções para alguém que conhece a cidade versus alguém que nunca esteve lá. Se você não sabe para onde está indo, o GPS mais avançado do mundo não ajuda.

O que os dados mostram

O relatório mais recente da McKinsey sobre IA empresarial confirma: apenas 6% das empresas são “high performers” com IA. São aquelas que realmente capturam valor significativo.

Por uma feliz coincidência, esse relatório saiu logo na semana onde eu quis escrever um artigo detalhado sobre isso tudo. 🙏

E o que diferencia esse 6%?

Eles redesenham workflows 3 vezes mais do que o resto. Não estão apenas usando a ferramenta. Estão repensando fundamentalmente como trabalham.

Isso não acontece por acidente. Requer entender profundamente:

• Onde está o gargalo real

• Que partes do processo podem ser aceleradas

• Que partes precisam de mais atenção humana

• Como validar que o resultado está correto

Tudo isso vem de experiência. De ter passado por centenas de situações diferentes. De ter construído features que funcionaram e features que falharam.

LLMs amplificam seu julgamento. Se seu julgamento é fraco, a amplificação não ajuda.

Esse é um assunto que já escrevi antes. Salve para ler depois:

Como máxima eficiência funciona na prática

Deixa eu ser direto sobre meu fluxo atual, porque é aqui que a teoria encontra a realidade.

Não estou sozinho quando trabalho. Uso múltiplos agentes em paralelo:

Durante o standup diário, um agente já está investigando uma issue não-crítica em produção. Analisando logs, identificando a query problemática, propondo solução.

Enquanto foco na feature principal, outro agente está na minha pasta da newsletter revisando o outline do próximo artigo. Sugerindo histórias reais que posso incluir baseado nos artigos anteriores.

Quando preciso de um plano de implementação, uso o Claude Code em modo “plan”. Ele desenha a arquitetura da solução, identifica as partes que precisam de atenção, sugere a ordem de implementação. Reviso o plano, ajusto, e então deixo ele implementar enquanto foco em code reviews.

Esse é o fluxo.

Não é mágica. Não é “IA faz tudo”. É orquestração. É usar múltiplos agentes em paralelo, cada um em uma tarefa específica, enquanto você atua como o gerente de projeto e arquiteto desse time virtual.

Os resultados concretos

Desde que dominei esse fluxo:

No trabalho: Minhas PRs aumentaram em velocidade e qualidade. Consigo pegar features mais ambiciosas porque sei que posso iterar rápido. Meu time me vê como alguém que desbloqueia problemas, não apenas entrega código.

No NaGringa: Construí a plataforma completa sozinho. Sistema de checkout com Stripe, Asaas e Abacatepay. Controle de acesso a conteúdo premium. Portal de vagas customizado. Tudo isso em paralelo ao trabalho full-time.

No marketing: Criei ferramentas (calculadora CLT vs PJ, gerador de invoice, calculadora juros compostos) que hoje me trazem milhares de visitantes orgânicos por mês. Estou no top 3 do Google para “calculadora clt pj”.

No faturamento: R$ 90 mil desde o lançamento do portal de vagas NaGringa, há 5 meses. Tudo isso enquanto trabalho em tempo integral.

Não estou falando disso para me gabar. Estou falando porque isso não seria possível há 2 anos. Simplesmente não daria tempo.

E aqui está o ponto: eu não sou o único. Dados da McKinsey mostram que os “high performers” (6% das empresas) que realmente capturam valor com IA fazem exatamente isso: redesenham workflows completamente.

Eles não usam IA para fazer as mesmas coisas 10% mais rápido. Eles repensam o que é possível quando código fica mais barato de produzir.

O que continua sendo caro

Mas nem tudo ficou mais fácil. Alguns gargalos continuam (ou até aumentaram):

1. Verificação

Code review continua sendo essencial. Talvez até mais importante agora. Porque é fácil gerar muito código rapidamente. Mas garantir que esse código é correto, maintainável, e não introduz bugs sutis? Isso requer atenção.

Hoje gasto mais tempo revisando do que programando do zero. E isso é OK. É onde meu valor está.

2. Saber O QUE construir

Essa é a parte cara agora. Com LLMs, fazer qualquer feature ficou barato. O risco? Encher o produto de features desnecessárias.

Product sense (entender o que realmente resolve o problema do usuário, o que pode ser ignorado, como priorizar) ficou mais importante, não menos.

É a diferença entre engenheiros que “entregam tickets” e engenheiros que “constroem produtos que encantam”.

3. Contexto e arquitetura

Para LLMs funcionarem bem, elas precisam de contexto. Muito contexto. E organizar esse contexto (ter uma arquitetura clara, documentação atualizada, testes que validam comportamento) não mudou.

Na verdade, ficou mais crítico. Porque se sua arquitetura é uma bagunça, a LLM vai produzir código que perpetua a bagunça. Garbage in, garbage out.

E aqui está algo que poucos percebem: uma cultura de excelência em engenharia de software acelera ainda mais o uso de LLMs.

Quando você tem:

• Arquitetura bem definida e documentada

• Testes que validam comportamento

• Padrões claros de código

• Processos de review estabelecidos

Não só as pessoas ficam melhores. Os agentes também. Porque o contexto está lá. A estrutura está clara. Os exemplos de boa prática estão visíveis.

Times que já tinham excelência técnica multiplicam seu impacto muito mais rápido com LLMs. Times que eram desorganizados continuam desorganizados, só que agora mais rápido.

É por isso que fundamentação importa tanto.

Nem tudo são flores

Não vou mentir: minha capacidade de trabalhar profundamente em problemas realmente desafiantes pode ter diminuído um pouco.

É mais fácil iterar com o Claude do que sentar por 2 horas pensando profundamente numa solução. E tem momentos que essa iteração rápida é o caminho certo.

Mas tem momentos que você precisa parar, desconectar, e realmente pensar no problema.

O segredo é saber quando usar cada abordagem.

Problemas bem-definidos? LLM pode acelerar muito. Problemas ambíguos que exigem criatividade ou trade-offs não-óbvios? Você precisa pensar primeiro, só então usar LLM para acelerar execução.

É como pair programming. Às vezes você dirige, às vezes você navega. Com LLMs, você está constantemente alternando entre esses papéis.

O que “fundamentação” significa agora

Se você chegou até aqui esperando que eu dissesse “não precisa mais aprender fundamentos, LLMs fazem tudo”, sinto desapontá-lo.

A verdade é exatamente o oposto.

Fundamentação técnica importa MAIS agora. Mas o que mudou é QUAL fundamentação importa, e COMO você a usa.

Você virou um Engineering Manager

Pensa assim: antes, você era um individual contributor. Você programava. Debugava. Implementava features do início ao fim.

Agora? Você gerencia um time de agentes extremamente capazes, mas que precisam de direção clara.

E o que faz um bom engineering manager?

1. Define o problema claramente: Não apenas “faz X”. Mas “resolvemos Y porque Z, e X é uma solução possível. Considera A, B, C no design.”

2. Valida o trabalho constantemente: Code review virou sua principal atividade. Você precisa identificar quando algo está errado, incompleto, ou pode introduzir bugs.

3. Desbloqueia quando necessário: Quando o agente trava, você precisa entender o problema e dar a direção certa. Isso requer expertise técnica profunda.

4. Garante qualidade: Arquitetura, testes, observabilidade. Você define os padrões que o time (de agentes) deve seguir.

Dados da McKinsey confirmam: high performers têm liderança 3x mais engajada com IA. Não é sobre “deixar a IA fazer tudo”. É sobre dirigir o uso de IA com clareza de propósito.

Você também virou um Product Manager

Além de gerenciar execução, você precisa saber O QUE construir.

E isso requer outro conjunto de habilidades:

Product sense: Qual feature resolve o problema real? Qual é nice-to-have? O que complica sem adicionar valor?

Entender trade-offs: Cada decisão tem custo. Complexidade, maintainability, performance. Você precisa avaliar esses trade-offs constantemente.

Medir impacto: Como saber se o que você construiu funcionou? Quais métricas acompanhar? Como iterar baseado em feedback?

Simplicidade intencional: Resistir à tentação de adicionar features só porque “agora é fácil”. Produtos que encantam são simples, não cheios de features.

Essas habilidades sempre foram importantes. Mas agora são críticas, porque a barreira para construir qualquer coisa caiu drasticamente.

Por que juniors têm mais dificuldade

Aqui está uma verdade difícil: juniors estão em desvantagem nesse novo mundo.

Não porque são menos inteligentes. Mas porque falta o mapa mental que vem de anos construindo sistemas.

Quando um senior vê um problema, ele imediatamente reconhece padrões:

• “Já vi isso antes, é um problema de N+1 queries”

• “Esse design vai causar race conditions no futuro”

• “Essa solução funciona agora mas não vai escalar”

Esse reconhecimento de padrões vem de experiência. De ter feito errado várias vezes. De ter visto sistemas quebrarem em produção.

LLMs não substituem esse conhecimento. Elas amplificam ele.

Se você não reconhece os padrões, não sabe que perguntas fazer. Não sabe quando a LLM está sugerindo algo problemático. Não sabe como direcionar melhor.

É como a diferença entre alguém que aprendeu a dirigir com GPS desde o dia 1, versus alguém que aprendeu lendo mapas. Quando o GPS falha, quem tem o mapa mental navega. Quem não tem fica perdido.

Por isso, se você está começando: não delegue seu pensamento para LLMs.

Use elas como um rubber duck extremamente capaz. Explique seu raciocínio para elas. Peça para validarem sua lógica. Mas VOCÊ pensa primeiro.

E se você tem 2-5 anos de experiência?

Você já está no caminho certo. Já debugou código em produção. Já refatorou sistemas legacy. Já tomou decisões de arquitetura. Esse mapa mental está se formando.

Não precisa de 10 anos para começar a usar LLMs com eficiência. Precisa do que você já tem: curiosidade, vontade de aprender, e experiência suficiente para reconhecer padrões básicos.

A diferença é que agora você pode acelerar sua curva de aprendizado. Cada projeto com LLMs te ensina mais rápido do que seria possível sozinho.

Arquitetura importa MAIS, não menos

Uma coisa que não mudou: a importância de projetar bons sistemas.

Na verdade, ficou mais importante.

Porque agora é trivial adicionar código. O que não é trivial? Manter o código organizado, testado, observável, evolutivo.

O custo do software não está em escrever código. Está em manter código por anos.

E LLMs só ajudam com a primeira parte. A segunda continua sendo sua responsabilidade.

Sistemas bem arquitetados têm:

• Boundaries claros: Cada módulo tem responsabilidade bem definida

• Testes abrangentes: Que documentam comportamento e pegam regressões

• Observabilidade: Você sabe quando algo quebra, e por quê

• Documentação: Contexto para humanos E para LLMs

Esse conhecimento (como projetar sistemas que evoluem bem) não vem de tutoriais. Vem de ter trabalhado em sistemas grandes por anos.

De ter feito refactorings massivos. De ter visto o custo de decisões ruins. De ter aprendido a equilibrar simplicidade com extensibilidade.

Essa experiência é o que separa quem vai dominar essa nova era de quem vai ficar para trás.

Os gargalos que não desaparecem

Vamos falar sobre a parte que muita gente ignora: os limites.

LLMs não resolveram todos os problemas de desenvolvimento de software. Na verdade, alguns problemas ficaram mais evidentes.

Verificação continua sendo cara

Você consegue gerar código 10x mais rápido. Ótimo.

Mas você ainda precisa:

• Revisar esse código linha por linha

• Testar em cenários que o agente não considerou

• Validar que a solução realmente resolve o problema

• Garantir que não introduz bugs sutis

E aqui está o ponto: verificação não escala da mesma forma que geração.

Um agente pode escrever 1000 linhas de código em minutos. Você não consegue revisar 1000 linhas com qualidade em minutos.

Então o gargalo mudou. Antes era “quanto código consigo escrever?”. Agora é “quanto código consigo validar com confiança?”.

Empresas que entendem isso estão investindo pesado em:

• Testes automatizados robustos: Para pegar regressões rapidamente

• Feature flags: Para lançar incrementalmente e limitar blast radius

• Observabilidade: Para detectar problemas em produção cedo

• Code review criterioso: Mais importante agora, não menos

Product sense é o novo diferencial

Aqui está onde o jogo realmente mudou.

Antes, fazer uma feature era caro. Então você pensava muito antes de construir. Fazia discovery. Validava com usuários. Priorizava cuidadosamente.

Agora? É tentador pular essas etapas. “Ah, é só 30 minutos para implementar, vamos fazer.”

Essa é a armadilha.

Adicionar features ficou barato. Mas features têm custos invisíveis:

• Complexidade: Cada feature torna o produto mais difícil de usar

• Manutenção: Código que você escreve hoje precisa de manutenção para sempre

• Confusão: Muitas opções confundem usuários

• Foco: Cada feature que você adiciona dilui seu posicionamento

Os melhores produtos não são aqueles com mais features. São aqueles com as features certas.

E saber quais são as certas? Isso requer:

• Entender usuários profundamente: Seus problemas reais, não o que dizem que querem

• Dizer não constantemente: A maioria das ideias deve ser rejeitada

• Medir impacto: Você construiu, mas resolveu o problema?

• Iterar baseado em dados: Ajustar baseado no que funciona, não no que “deveria” funcionar

Dados da McKinsey mostram o gap: 64% das empresas dizem que IA habilita inovação. Mas apenas 39% reportam impacto real no EBIT (lucro operacional).

Por quê? Porque construir é fácil. Construir a coisa certa é difícil.

E essa habilidade (product sense, taste, julgamento) não vem de LLMs. Vem de:

• Conversar com usuários

• Ver features falharem

• Aprender a simplicidade intencional

• Desenvolver intuição sobre o que funciona

Como acelerar (sem perder qualidade)

OK, mas e se você quer ser um dos 6% que realmente captura valor com IA?

Algumas práticas que funcionam:

1. Use o plan mode agressivamente

Antes de escrever qualquer código, peça para a LLM:

• Quebrar o problema em partes menores

• Identificar edge cases

• Sugerir ordem de implementação

• Apontar riscos potenciais

Esse planejamento custa 5 minutos e economiza horas de refactoring depois.

2. Contexto é tudo

LLMs são tão boas quanto o contexto que você dá. Então invista em:

• Documentação clara de arquitetura

• READMEs atualizados em cada módulo

• Comentários explicando “por quê”, não “o quê”

• Exemplos de uso em testes

Isso ajuda humanos E ajuda agentes.

3. Testes primeiro, sempre

Eu sei, eu sei. Todo mundo fala de TDD e ninguém faz. Eu mesmo nunca fui fã.

Mas com LLMs, testes ficaram ainda mais importantes. Porque você está gerando muito código rapidamente.

E a única forma de ter confiança nesse código? Testes robustos que validam comportamento.

4. Itere em ciclos curtos

Não dê tarefas gigantes para o agente. Quebre em partes de 30-60 minutos.

Valide cada parte antes de seguir para a próxima.

Isso evita que você perca 2 horas numa direção errada.

5. Aprenda com feedback rápido

Construa, lance (para um subset de usuários), mede, ajusta.

Não fique 2 meses construindo a feature perfeita. Construa a versão mais simples que resolve 80% do problema, em 20% do tempo.

E então itere baseado em feedback real.

É exatamente isso que separa produtos que encantam de produtos que são apenas “OK”.

Não é sobre ter mais features. É sobre resolver o problema certo, da forma mais simples possível, e continuar melhorando baseado no que aprende.

🌟 Resumo

• Fundamentação técnica vale mais agora, não menos: LLMs amplificam seu julgamento. Se seu julgamento é fraco, a amplificação não ajuda. Veteranos dominam essas ferramentas porque têm anos de experiência reconhecendo padrões e tomando decisões de arquitetura.

• Você virou eng manager + product manager: Seu trabalho mudou de “escrever código” para “dirigir agentes, validar output, e decidir O QUE construir”. As habilidades mais valiosas agora são: contextualizar problemas, revisar criticamente, e ter product sense para priorizar o que realmente importa.

• Os gargalos mudaram: Geração de código ficou barato. Verificação (code review, testes, validação) continua cara. Product sense (saber quais features construir) ficou crítico. Sucesso não é fazer mais features, é fazer as features certas com qualidade.

• Ação concreta para esta semana: Escolha UMA feature que você planejava construir. Antes de abrir o editor, gaste 15 minutos planejando com uma LLM: quebre em partes menores, identifique edge cases, pense nos testes. Então implemente usando agentes, mas revise cada linha. Compare a qualidade e velocidade com seu processo normal.

O futuro não é sobre escolher entre “aprender profundamente” ou “usar IA”. É sobre usar IA porque você aprendeu profundamente.

Dan Abramov, criador do Redux e membro do React Core Team, está certo em se preocupar com a educação técnica na era de IA. Mas a solução não é rejeitar essas ferramentas. É usá-las da forma certa: como aceleradores de quem já tem fundamentação, não como substitutas de aprendizado.

Os próximos anos vão separar dois grupos de engenheiros:

1. Aqueles que usam LLMs como muleta: delegando pensamento, aceitando soluções sem entender, ficando cada vez mais dependentes

2. Aqueles que usam LLMs como superpoder: amplificando expertise, acelerando execução, construindo coisas que antes eram impossíveis

A escolha é sua.

Mas se você escolher o caminho 2, as oportunidades são ilimitadas. Porque você vai poder construir mais, aprender mais rápido, e ter impacto maior do que qualquer geração anterior de engenheiros.

É o momento mais empolgante para estar em tecnologia. Não apesar de LLMs, mas por causa delas.

Desde que você saiba usá-las da forma certa.

Se esse artigo foi útil pra você, curta ou compartilhe ele com alguém. Me ajude muito. E se você indicar a newsletter para mais pessoas, você também ganha recompensas.

Compartilhar

1. Quantas pessoas isso afeta e com que frequência?

2. Como vou saber se deu certo?

3. É a coisa mais importante agora?

Essas perguntas podem te salvar de desperdiçar o único recurso que não temos como recuperar: tempo.

Passei um tempo refatorando um componente de form na Brex. Era tecnicamente interessante, envolvia patterns legais, e quando terminei, estava orgulhoso do código limpo que havia escrito.

Resultado? Ninguém notou. Zero impacto mensurável. O componente continuou sendo usado da mesma forma.

Umas semanas depois, investiguei por que usuários abandonavam o fluxo de Bill Pay no meio do caminho. Minha hipótese: o formulário tinha campos desnecessários que criavam fricção. Removi alguns campos, ajustei a ordem de outros, e adicionei smart defaults com base no histórico para facilitar o preenchimento.

A conversão aumentou 26%.

Tempo de desenvolvimento parecido. Impacto drasticamente diferente.

A diferença? No segundo caso, eu escolhi trabalhar no problema certo.

✨ O que esperar do artigo

• O framework de 3 perguntas que uso para decidir em que trabalhar

• Como medir se estou trabalhando nas coisas certas (com exemplo real de 26% de melhoria)

• Como balancear o que é urgente vs o que é importante

• Como propor problemas para resolver vs só executar tickets

O artigo de hoje é patrocinado pela Contabilizei.

🧾 Consegui uma vaga PJ, e agora?

Se você trabalha ou quer trabalhar como PJ (especialmente para empresas internacionais), vai precisar de uma contabilidade confiável.

Desde 2020 uso a Contabilizei e nunca tive problema. O que faz diferença no dia a dia:

Rapidez para começar - CNPJ aberto em poucos dias. Essencial quando você precisa começar logo em uma vaga internacional.

Plataforma simples - Emitir nota fiscal leva 2 cliques. Consultar impostos é direto. Sem complicação.

Suporte eficiente - Quando surge dúvida (e vai surgir), eles respondem rápido e resolvem, com suporte até as 22h via whatsapp.

Para quem trabalha remoto, especialmente pra fora, ter uma contabilidade que funciona não é luxo - é necessidade básica. Você precisa emitir notas todo mês, pagar impostos corretos, e não ter surpresa da Receita Federal.

Conheça mais sobre os serviços deles aqui.

Por que engenheiros trabalham nas coisas erradas

A armadilha é sutil: você está trabalhando duro, entregando código, fechando tickets. Mas no final do ano, quando olha para trás, percebe que nada que fez realmente moveu a agulha.

Isso acontece por três razões principais:

1. Você escolhe pelo que é tecnicamente interessante - “Vou refatorar isso usando o novo pattern X” soa mais divertido que “vou investigar por que usuários abandonam esse fluxo”

2. Você trabalha no que grita mais alto - O bug que o CEO mencionou ganha prioridade sobre o problema que afeta mil usuários silenciosamente todo dia

3. Você não tem um framework de decisão - Sem critério claro, você escolhe pelo feeling ou pela última coisa que apareceu no Slack

Na Brex, eu via isso acontecer constantemente. Engenheiros excelentes tecnicamente trabalhando em coisas que não importavam. Não por falta de habilidade, mas por falta de clareza sobre o que priorizar.

A virada aconteceu quando comecei a fazer três perguntas antes de comprometer com qualquer trabalho.

O framework de 3 perguntas

Antes de começar qualquer tarefa, projeto ou refactor, responda:

1. “Quantas pessoas isso afeta e com que frequência?”

Escopo = Número de pessoas × Frequência do problema

Um bug que afeta 5 clientes enterprise todo dia é mais importante que um bug que afeta 500 usuários free uma vez por mês. Não porque os clientes enterprise importam mais, mas porque o impacto acumulado é maior.

Quando identifiquei o problema no Bill Pay, fiz as contas:

• ~1000 usuários iniciavam o fluxo por dia

• ~40% abandonavam no meio

• Se eu aumentasse a conversão em 10%, seriam 100 usuários a mais completando o fluxo diariamente

Isso me deu clareza: valia a pena investigar.

Sinais de que você está trabalhando em algo de baixo escopo:

• “Isso vai ajudar o time de X” (mas X é um time de 3 pessoas)

• “Alguns usuários reclamaram” (mas você não consegue quantificar)

• “Isso vai ficar mais limpo” (mas ninguém além de você vai mexer naquele código)

Um dos melhores jeitos de descobrir esses sinais é iterando rapidamente. Falo mais sobre isso aqui:

2. “Como vou saber se deu certo?”

Se você não consegue definir sucesso antes de começar, você está navegando no escuro.

Para o Bill Pay, minha métrica era cristalina: taxa de conversão do formulário. Eu tinha a baseline (métrica antes) e sabia exatamente o que medir depois.

Para o dashboard que criei quando entrei na Brex, as métricas eram:

• Quantas pessoas do time acessam por semana?

• As métricas estão sendo usadas em discussões de produto?

• Conseguimos tomar decisões mais rápido?

Exemplos de boas métricas:

• “Reduzir o tempo de X de 30s para 15s”

• “Aumentar a adoção da feature de 20% para 35%”

• “Eliminar 80% dos erros do tipo Y”

• “5 pessoas do time usam isso semanalmente”

Red flags de métricas ruins:

• “Melhorar a experiência” (vago demais)

• “Deixar o código mais limpo” (não é outcome)

• “Os usuários vão gostar mais” (como você mede “gostar”?)

3. “Isso é a coisa mais importante que posso fazer agora?”

Esta é a pergunta mais difícil porque força você a admitir o custo de oportunidade.

Quando você trabalha em A, você não está trabalhando em B. E talvez B seja mais importante.

Uso uma regra prática: se eu não consigo articular por que isso é mais importante que as outras 3 coisas no meu backlog, provavelmente não é.

Perguntas auxiliares:

• “Se eu não fizer isso nas próximas 2 semanas, qual o impacto real?”

• “Tem outra pessoa melhor posicionada para fazer isso?”

• “Isso desbloqueia outros trabalhos importantes?”

Quando percebi que o refactor do formulário não desbloqueava nada e ninguém estava bloqueado por causa dele, ficou óbvio que não deveria ser prioridade.

Quando dizer sim (e quando dizer não)

Aplicar o framework é a parte fácil. A parte difícil é ter coragem de dizer não - especialmente quando a tarefa é interessante ou quando alguém importante pediu.

Diga SIM quando:

Alto impacto + mensurável + prioritário

Exemplo do Bill Pay:

• ✅ Afeta 1000 usuários/dia (escopo)

• ✅ Métrica clara: conversão do formulário (mensurável)

• ✅ Conversão era uma métrica-chave do time (prioritário)

Invisível mas estrutural

No PostHog, criei um arquivo CONTRIBUTING.md para o time de Surveys. Não era urgente, não tinha métrica sexy, mas:

• Reduziria tempo de onboarding de novos membros

• Centralizaria conhecimento tribal

• Prevenção (melhor que remediação)

Trabalho invisível é legítimo quando tem impacto estrutural claro.

Diga NÃO quando:

Interessante mas irrelevante

“Vou reescrever isso usando o novo framework X” - a menos que o framework resolva um problema real (performance, manutenibilidade crítica), é distração.

Urgente para alguém, mas baixo impacto geral

O CEO mencionou um bug que afeta 0.1% dos usuários. É tentador priorizar porque veio do CEO. Mas se você tem coisas que afetam 50% dos usuários, essas vêm primeiro.

(Obviamente há exceções - se o CEO está numa demo importante amanhã, contexto importa. Mas a exceção não pode virar regra.)

Quando você não consegue medir sucesso

“Vamos melhorar a arquitetura do sistema” - ok, mas como? Se você não consegue definir sucesso antes de começar, adie até conseguir.

A regra dos 30%

Uma heurística que aprendi: se mais de 30% do seu tempo é apagando incêndios ou fazendo trabalho não planejado, tem algo estruturalmente errado.

Ou você está em um sistema frágil que precisa de investimento em resiliência, ou você está dizendo sim demais para coisas urgentes mas não importantes.

A solução não é ignorar incêndios. É perguntar: “por que esses incêndios continuam acontecendo?” e atacar a causa raiz.

Medindo sucesso: a história dos 26%

Deixa eu detalhar como foi a história do Bill Pay, porque exemplifica o ciclo completo.

O problema que identifiquei:

Olhando o dashboard que estava construindo (que eventualmente virou a ferramenta central do time), notei que ~40% dos usuários abandonavam o fluxo de Bill Pay no meio do caminho. Especificamente, começavam a preencher o formulário e desistiam.

A investigação:

Fiz três coisas:

1. Analisei em que campo as pessoas abandonavam mais

2. Comparei nosso formulário com competidores

3. Pedi para algumas pessoas do time tentarem usar (sim, dogfooding funciona)

Descobri: tínhamos campos desnecessários que criavam fricção. Perguntávamos informações que podíamos inferir ou buscar depois.

A hipótese:

“Se removermos os campos X, Y e Z, e ajustarmos a ordem dos campos restantes para criar um fluxo mais natural, a taxa de conversão vai aumentar.”

A implementação:

• Removi 3 campos não essenciais

• Mudei a ordem dos campos restantes

• Implementei validação progressiva (mostrar erros mais cedo)

• Usei feature flags para testar com 10% dos usuários primeiro

O resultado:

Taxa de conversão subiu de ~60% para 76%. Um aumento de 26%.

Isso significava ~160 usuários a mais por dia completando o fluxo. Em um mês, quase 5000 usuários a mais.

As lições:

1. Defini sucesso antes de começar - sabia exatamente o que medir

2. Comecei com dados, não com opinião - vi onde estava o problema real

3. Testei progressivamente - feature flags me deram confiança

4. Medi o impacto - números concretos que pude compartilhar

Isso virou uma história que contei em revisões de performance, em entrevistas, e que me deu credibilidade no time para propor outros projetos.

Como falei em outro artigo sobre medir impacto, números concretos transformam “eu trabalhei nessa feature” em “eu melhorei X em Y%, impactando Z usuários.”

Trabalhando com PM sem ser só executor

A grande virada na minha carreira foi quando parei de esperar tickets e comecei a propor problemas.

Modelo antigo (executor):

1. PM escreve spec detalhada

2. Você implementa exatamente como está escrito

3. PM valida e aprova

4. Você faz deploy

Modelo novo (product engineer):

1. Você nota um problema (ex: usuários abandonando fluxo)

2. Você traz dados e uma hipótese inicial

3. Você e PM discutem a melhor abordagem

4. Você implementa, mede, itera

Veja a diferença: no segundo modelo, você está resolvendo problemas, não executando soluções.

Como iniciar essa conversa

Script que funcionou para mim:

“Ei [nome do PM], notei que 40% dos usuários abandonam o Bill Pay no meio do fluxo. Analisei os dados e parece que temos campos desnecessários criando fricção. Posso investigar mais e propor algumas mudanças?”

Por que esse script funciona:

• Traz um problema concreto (não uma solução)

• Tem dados (não é feeling)

• Pede permissão para investigar (não já chegou com a solução pronta)

• Mostra ownership (você tomou iniciativa)

O PM pode responder:

• “Sim, investiga” → você virou dono do problema

• “Não, temos prioridades X, Y” → você entende o contexto maior

• “Interessante, mas vamos focar em Z primeiro” → você aprende sobre priorização

Qualquer resposta é boa. Você saiu de “executor de tickets” para “pessoa que identifica e propõe soluções.”

O que PMs realmente querem

Conversando com PMs na Brex e PostHog, percebi um padrão: eles querem alguém que entende o problema, não alguém que apenas implementa a solução.

PMs não têm todas as respostas. Eles têm contexto de negócio e usuário. Você tem contexto técnico e de implementação.

A mágica acontece quando esses contextos se encontram.

Exemplos reais de colaboração:

1. PM diz: “Precisamos de relatórios customizáveis”
   Você questiona: “Que problema os usuários estão tentando resolver? Talvez um template com 5 opções mais usadas resolva 80% dos casos”

2. PM diz: “Precisamos melhorar performance”
   Você pergunta: “Qual parte específica? Tempo de carregamento? Responsividade? Isso afeta qual fluxo?”

3. PM diz: “Usuários reclamaram da busca”
   Você propõe: “Posso adicionar tracking para ver exatamente onde eles travam? Assim sabemos se é relevância dos resultados ou velocidade”

Você não está sendo difícil. Está sendo um engenheiro de produto.

Quando você não tem um PM

Em times menores ou startups early-stage, talvez você não tenha um PM dedicado.

Nesse caso, você precisa desenvolver o músculo de product thinking sozinho:

• Fale diretamente com usuários (ou leia feedback de suporte)

• Entenda as métricas de negócio que importam

• Faça as 3 perguntas do framework antes de cada decisão

• Teste suas hipóteses em pequena escala primeiro

No PostHog, engenheiros são esperados a pensar como donos de produto. Isso não é sobrecarga - é liberdade para ter impacto real.

🌟 Resumo

• Use o framework de 3 perguntas antes de qualquer trabalho: Quantas pessoas afeta? Como vou medir sucesso? É a coisa mais importante agora?

• Defina métricas de sucesso ANTES de escrever código - se você não sabe como vai medir, não comece ainda

• Seja proativo em propor problemas - não espere tickets aparecerem, identifique e traga problemas você mesmo

• Diga não estrategicamente - se mais de 30% do tempo é apagando incêndios, tem algo estrutural errado

• Trabalhe COM PM, não PARA PM - você tem contexto técnico que eles não têm, use isso

Seu desafio para essa semana

Pegue seu backlog atual (ou sua lista mental de “coisas para fazer”) e:

1. Liste todas as tarefas - tudo que você está considerando fazer

2. Aplique as 3 perguntas em cada uma:

   • Quantas pessoas isso afeta e com que frequência?

   • Como vou saber se deu certo?

   • É a coisa mais importante agora?

3. Escolha a top 1 baseado nas respostas

4. Descarte ou adie conscientemente as outras

Documente sua decisão. Na próxima revisão de performance, você terá clareza sobre por que trabalhou no que trabalhou.

E se você ainda não tem um sistema para medir o impacto do seu trabalho, comece simples: antes de começar qualquer coisa, anote “como vou saber se deu certo?”. Depois, volte e compare.

Como aprendi na prática: não é sobre trabalhar mais, é sobre trabalhar nas coisas certas.

Espero que tenha gostado do artigo de hoje!

Peço desculpas pelo sumiço nessas últimas semanas. Acabou que finalizar a tier list e mais outras coisas da vida me consumiram bastante tempo.

Espero estar de volta com o nosso cronograma regular semana que vem!

Ficou alguma dúvida? Pode responder esse email diretamente ou postar algum comentário no Substack! Eu leio todos.

Se esse artigo foi útil pra você, curta ou compartilhe ele com alguém. Me ajude muito. E se você indicar a newsletter para mais pessoas, você também ganha recompensas.

Compartilhar

Essa semana estou lançando a Tier List do NaGringa! Mais sobre ela na metade do artigo, leia até o final 🙏

Mil pessoas estão aplicando na mesma vaga que você.

E não, não é exagero.

Uma vaga de desenvolvedor em Nova York? 23.000 aplicações em 30 dias. No Spotify? 1.700 aplicações em 15 horas. Em startups na Suíça? 600 aplicações em 2 dias.

O mercado não acabou. Mas ficou brutalmente competitivo.

E se você está aplicando do jeito tradicional - manda currículo e espera resposta - você está invisível na multidão.

Hoje vou te mostrar 3 formas de sair dessa competição de volume e começar a ser notado. E vou te dar uma ferramenta para escolher onde focar seu esforço.

✨ O que esperar do artigo

• Por que você está competindo com mil pessoas por cada vaga (e como sair dessa briga de volume)

• 3 formas de se destacar que funcionam para desenvolvedores brasileiros buscando internacional

• Como escolher em quais empresas focar (+ acesso gratuito a 40+ empresas que pagam bem para brasileiros)

Antes de entrarmos num artigo, um pequeno FYI para quem já está recebendo pagamentos internacionais.

💰 Pare de pagar impostos que não deve

Se você trabalha como PJ exportando serviços tech, tem uma isenção que muitas plataformas não aplicam corretamente: IOF zero.

Durante 2 anos usei Payoneer pagando 2% de spread + 1,1% de IOF. Total: 3,1% de cada pagamento internacional.

O problema? Esse IOF não deveria existir.

Exportação de serviços tech como PJ tem isenção de IOF. Mas a Payoneer (e várias outras plataformas) cobram mesmo assim.

O custo real disso:

Em um salário de US$5.000 mensais:

• Payoneer: ~R$510/mês (2% spread + 1,1% IOF)

• TechFX: ~R$135/mês (0,5% spread + IOF zero correto)

Diferença: R$4.500 por ano.

Desde 2022 uso exclusivamente TechFX. Três motivos:

Taxa de 0,5% - A menor do mercado (tem até gente anunciando menor, mas cuidado com as taxas escondidas na cotação)

IOF zero aplicado corretamente - Porque exportação de serviços tech realmente tem essa isenção

Transparência total - Você vê exatamente quanto vai receber antes de confirmar

Para novos usuários: use este link para pagar apenas 0,1% no primeiro saque pela TechFX.

Agora, voltando ao artigo.

A realidade brutal do mercado em 2025

O mercado de tecnologia mudou.

E o sinal mais claro disso são os números de aplicações que empresas estão recebendo.

Exemplos reais

Startup em Nova York (8 vagas abertas): 23.000 aplicações em 30 dias

Spotify (1 vaga de engenheiro): 1.700 aplicações em 15 horas

Startup na Suíça (vaga de desenvolvedor sênior): 600 aplicações em 2 dias

Agência no Reino Unido (2 vagas): 100+ aplicações em 2 horas

Esses dados vem de um artigo recente do Pragmatic Engineer: State of the software engineering jobs market, 2025: what hiring managers see.

O que mudou

Em 2021-2022, era comum aplicar em 10 vagas e conseguir 3-4 respostas.

Hoje? Você aplica em 50 vagas e não recebe nenhuma resposta.

Não é porque você ficou pior. É porque a competição explodiu.

O que isso significa:

Você está competindo com desenvolvedores do mundo inteiro por cada vaga.

E pior: se você busca vagas remotas, a competição é ainda mais brutal.

O número de vagas remotas está diminuindo (empresas voltando para presencial/híbrido). Mas o número de pessoas interessadas em trabalho remoto continua crescendo.

Resultado: mais gente competindo por menos vagas remotas.

E se você só está “mandando currículo e esperando”, você é invisível.

Por que mandar currículo não funciona mais

Pensa comigo:

Você é gerente de contratação. Abre uma vaga. Em 2 dias, recebe 600 aplicações.

Como você vai revisar 600 currículos?

Resposta: você não vai.

Você vai usar filtros automáticos e olhar apenas os que passarem. A maioria dos currículos nunca é vista por um humano.

O problema não é seu currículo

É que “aplicar no site da empresa” virou uma loteria.

Você está competindo com:

• 600-1000 outras pessoas

• Bots que mandam aplicações

• Pessoas usando IA inteligência artificial para currículos e cover letters perfeitas

Todo mundo está fazendo a mesma coisa. Mandar currículo em volume e esperar.

Por isso você precisa de uma estratégia diferente.

Uma que te tire da competição de volume.

Ter um bom currículo ainda é essencial. E pra isso, você pode dar uma olhada aqui:

Mas você não pode confiar apenas nele.

3 formas de se destacar (que funcionam para brasileiros)

Ok, aplicar no site não funciona.

Mas e agora?

Você precisa fazer uma das 3 coisas que te tiram da pilha de 1000 currículos:

1. Networking: seja indicado por alguém de dentro

A indicação é o atalho mais poderoso.

Quando alguém de dentro indica você:

• Seu currículo vai direto para o gerente de contratação

• Você pula a fila de 1000 pessoas

• Sua chance de entrevista sobe drasticamente

“Mas eu não conheço ninguém em empresa internacional!”

Provavelmente você conhece. Pensa em:

• Ex-colegas que foram trabalhar fora (mesmo de empresas antigas)

• Pessoas que você conheceu em eventos ou comunidades de tecnologia

• Desenvolvedores que você já interagiu em projetos de código aberto

O melhor caminho: ex-colegas.

O que fazer esta semana:

1. Lista ex-colegas que trabalham em empresas internacionais (mesmo que não sejam próximos)

2. Para cada pessoa, pesquisa a empresa no LinkedIn: • A empresa tem vagas abertas? • Qual área está contratando? • Você se encaixa no perfil?

3. Se sim, manda mensagem contextualizada com currículo anexo:

   “Oi [nome]! Vi que a [empresa] está contratando para [área]. Trabalhei com [tecnologia/projeto similar] na [empresa anterior]. Estou mandando meu currículo anexo. Faz sentido eu aplicar? Se sim, você consegue me indicar internamente?”

Mandar o currículo desde o começo reduz fricção. A pessoa já tem tudo que precisa para te indicar, caso ela queira.

Por que ex-colegas funcionam melhor:

Eles conhecem seu trabalho. Sabem suas habilidades técnicas. A indicação tem peso real - não é favor, é recomendação baseada em experiência direta.

2. Seja encontrado: deixa recrutadores te acharem

Muitas empresas não postam vagas públicas.

Elas mandam recrutadores procurarem desenvolvedores diretamente no LinkedIn.

O problema: seu perfil não aparece nas buscas.

Por quê: recrutadores buscam por:

• Tecnologias específicas (React, Python, AWS)

• Localização (América Latina, disponível remotamente)

• Tipo de projeto (SaaS, fintech, inteligência artificial)

Se seu LinkedIn diz só “Desenvolvedor de Software na Empresa X”, você não aparece.

O que fazer hoje:

1. Abre LinkedIn → edita título do perfil

2. De: “Desenvolvedor de Software na Empresa X”

3. Para: “Fullstack Engineer | Python, Go, AWS, TypeScript | B2B SaaS veteran”

4. Adiciona projetos específicos com resultados: “Construí sistema que processa 1M requisições/dia / trouxeram $XXX de receita”

5. Ativa “Disponível para oportunidades” (só recrutadores veem)

Resultado: recrutador busca “fullstack AWS América Latina” → você aparece.

3. Aplica estrategicamente: não no volume, na qualidade

Ok, aplicar direto tem baixa chance.

Mas ainda funciona SE você fizer diferente.

Não funciona: • Aplicar em 100 empresas aleatórias • Carta de apresentação genérica • Mesmo currículo para todas vagas

Funciona: • Escolher 5-10 empresas específicas • Customizar cada aplicação • Demonstrar que você entende a empresa

O que fazer esta semana:

1. Escolhe 3-5 empresas do seu nível salarial alvo

2. Para cada empresa:

   1. Estuda o produto (cria conta, usa por 30 minutos)

   2. Lê a página de carreiras e cultura da empresa

   3. Identifica 1-2 tecnologias que você domina e eles usam

3. Na carta de apresentação, menciona algo específico:
   “Vi que vocês usam [tecnologia X]. Trabalhei com isso na [empresa/projeto anterior] e consegui [resultado específico, ex: reduzir tempo de resposta em 40%].”

4. Se a empresa tem código aberto: faz uma contribuição pequena ANTES de aplicar

5. Se possível: manda mensagem para o gerente de contratação no LinkedIn

Exemplo real:

Quando apliquei na PostHog (empresa de código aberto), eu:

1. Li todo o handbook

2. Vi o que eles estavam procurando, e procurei saber se tinham algum programa de referral

3. Mandei mensagem para uma pessoa daqui que conheci online

4. Falei o porque eu era um bom, e já enviei meu currículo, junto com o link da vaga que estava interessado

Resultado: todo o meu processo durou pouco menos que 4 semanas.

Uma outra oportunidade é através de contribuir com open-source. É uma das melhores maneiras de mostrar que você é competente e sabe ser independente.

Empresas de código aberto que você pode pensar em contribuir:

• PostHog

• Cal.com

• Supabase

O problema: onde focar seu esforço?

As 3 estratégias funcionam.

Mas você tem tempo e energia limitados.

Não adianta aplicar em 100 empresas aleatórias.

Você precisa escolher empresas que: • Pagam na sua faixa salarial alvo • Contratam brasileiros • Têm vagas abertas agora

É aqui que a tier list entra.

Como usar a tier list organizada por níveis

Há alguns meses, comecei uma planilha de empresas que contratam brasileiros.

Era para nossos assinantes. Depois virou nosso agregador de vagas.

Mas tinha um problema: sem contexto, é só uma lista aleatória de empresas.

Você não deve aplicar em todas. Você deve aplicar nas empresas CERTAS para seu momento de carreira.

Por isso criamos a tier list organizada por níveis salariais.

Os 3 tiers

Tier B ($50-89 mil/ano | R$23-41 mil/mês):

• Foco maior em contratar pessoas que estão na América Latina

• Salários competitivos no Brasil

• 40+ empresas → acesso gratuito

Tier A ($90-120 mil/ano | R$41-55 mil/mês):

• Começa a ser dominado apenas por big tech (FAANG) ou startups internacionais

• Podem ter modelo presencial ou híbrido

Tier S ($120 mil+/ano | R$55 mil+/mês):

• Exige nível sênior + histórico forte

• As empresas mais competitivas do mundo, pois aqui só entram vagas remotas

Lembrando que aqui o que vale é a compensação total (salário base + bônus + VA/VR + ações). E só entram empresas que contratam brasileiros.

Como usar baseado nas 3 estratégias

Se você é júnior ou busca primeiro emprego internacional:

• Foca 80% no Nível B, mas tente no tier A/S também, especialmente se tiver vaga πara new grad

• Qualidade sobre quantidade: melhor 5 aplicações bem feitas que 50 genéricas

Se você tem experiência (1-2 anos internacional):

• Divide esforço entre Nível B e A

• Usa estratégia 1 (networking) + 2 (ser encontrado)

• Priorize indicações de ex-colegas

Se você é sênior:

• Foca 70% em Nível A e S

• Use todas as 3 estratégias

• Código aberto + conteúdo público te destacam

Nível B está gratuito

Deixei 40+ empresas do Nível B completamente grátis porque:

1. Você precisa começar em algum lugar

2. Nível B já paga salário competitivo no Brasil

3. Primeiro emprego nessass empresas abre portas para A e S

Não é só uma lista. É ferramenta para você escolher onde investir seu tempo.

Acesse a tier list completa aqui..

Algumas empresas brasileiras estão no Nível B

Semana passada, postei no Reddit e no LinkedIn:

“Quais empresas brasileiras pagam R$23 mil+/mês de compensação total?”

Recebi dezenas de respostas. Tem empresas brasileiras pagando no tier B - e a nossa tier list incluí elas.

Ainda não achei nenhuma empresa brasileira que se encaixe no Tier A (R$40 mil+/mês). Se você souber, me avisa!

🌟 Resumo

• Competição brutal: 1000+ pessoas aplicando nas mesmas vagas

• Mandar currículo não funciona: você é invisível na multidão

• 3 formas de se destacar:

  • Networking (indicação de dentro)

  • Ser encontrado (otimizando o LinkedIn)

  • Aplicar com qualidade (5-10 empresas customizadas)

• Tier list: 40+ empresas Nível B (mínimo R$23k) disponíveis para todos

Esta semana:

1. Atualiza LinkedIn com tecnologias específicas e projetos com resultados

2. Lista 3 ex-colegas em empresas internacionais e pesquisa se têm vagas

3. Escolhe 2-3 empresas do Nível B, estuda o produto e aplica customizado

P.S.: Níveis A e S ($90-120 mil+/ano) disponíveis para assinantes. Mas comece pelo B ou por um marketplace como a G2i. O primeiro emprego internacional abre as portas.

Espero que tenha gostado do artigo de hoje!

Peço desculpas pelo sumiço nessas últimas semanas. Acabou que finalizar a tier list e mais outras coisas da vida me consumiram bastante tempo.

Espero estar de volta com o nosso cronograma regular semana que vem!

Ficou alguma dúvida? Pode responder esse email diretamente ou postar algum comentário no Substack! Eu leio todos.

Se esse artigo foi útil pra você, curta ou compartilhe ele com alguém. Me ajude muito. E se você indicar a newsletter para mais pessoas, você também ganha recompensas.

O motivo? High agency. Eu sempre estava disposto a fazer o que der para atingir excelentes resultados - mesmo que ninguém tivesse me pedido.

Isso não foi sorte ou personalidade. High agency é um skill que você pode desenvolver. E começa esta semana com uma ação: resolva um problema que você vê no seu projeto, sem esperar permissão.

Deixa eu mostrar exatamente como isso funciona na prática.

Eu estava olhando a página de Bills no app da Brex e algo me incomodava. Cada vez que um cliente abria a página, tinha que esperar cerca de 400-600ms de loading. Não era muito, mas era o suficiente para quebrar o fluxo.

Ninguém mais via isso como um problema.

Decidi investigar se aquilo realmente importava. Analisei as sessões mais de longas de power users do Bill Pay. E descobri que eles acessavam essa página até 500 vezes por sessão! Transformei o que parecia um incômodo pequeno em um gargalo gigante de performance.

A solução estava no Apollo Client. O gerenciamento de cache que tem embutido nele não estava sendo usado. Refatorei a página de Bills para usar cache do Apollo corretamente. Mantive as requisições rodando em background (crítico para fintech). Mas agora os dados aparecem instantaneamente do cache enquanto os dados frescos carregam.

Resultado: economizei aproximadamente 3 minutos de loading para heavy users do Bills Pay. E o aumento no nosso NPS (net promoter score) trouxe o impacto.

Foi algo que fiz que ninguém havia me pedido. Porém, eu coloquei nossos usuários em primeiro lugar. E fui atrás para descobrir se isso importava ou não.

E colhi os resultados com isso. Pois foi algo que acabei apresentando numa call com várias pessoas de nível director ou acima.

High Agency é acreditar que você controla os resultados, não importa suas circunstâncias. Você não espera permissão. Você não aceita bloqueios. Você age como dono, não como vítima. E quando você aplica isso à sua carreira, tudo acelera.

✨ O que esperar do artigo

• Como ownership te faz ver oportunidades que outros desenvolvedores não enxergam

• Por que agir sem estar completamente “pronto” acelera sua carreira mais rápido

• O framework para fazer engenharia reversa da vida que você realmente quer ter

Ownership: Ser dono dos seus resultados

Ownership é o primeiro pilar que define high agency.

Ter ownership quer dizer que você não espera por outros te dizerem o que fazer. Que você pode receber apenas alguma direção em alto nível e fazer as coisas rapidamente.

A maioria dos desenvolvedores espera que alguém priorize melhorias no roadmap. Owners criam suas próprias oportunidades.

Pense assim: quando você aluga um apartamento, você faz o mínimo. É um pouco mais descuidado. Não melhora nada porque não é seu. Mas quando você compra sua casa, você cuida. Melhora constantemente. Investe porque cada melhoria valoriza seu ativo.

Low agency people alugam suas carreiras. High agency people são donos.

No PostHog, eu trabalho no time de Surveys.

E, quando entrei, os filtros para as respostas não funcionavam bem. Foi uma das primeiras features em que trabalhei.

Porém, quando fui fazer, eu não fiz apenas o que estava na descrição da issue.

Eu vi uma oportunidade de implementar filtros melhores. Que elevassem a experiência de quem estava filtrando respostas. Fui mais a fundo.

Enquanto fazia isso, notei que o onboarding do Surveys não estava bom. As pessoas tinham dificuldade para criar surveys. Não esperei ninguém arrumar isso. E criei uma nova tela eu mesmo. Hoje, mais de 40% das surveys são criadas nessa nova tela que eu fiz.

Veja a diferença:

Low agency: “O onboarding está ruim. Alguém deveria arrumar isso. Vou mencionar na próxima retrospectiva.”

High agency: “O onboarding está impactando conversão. Vou investigar o quanto e criar uma solução.”

Aqui está o gap que você precisa fechar: na maioria das empresas brasileiras, você esperaria direção clara do seu líder. Esperaria que alguém priorizasse isso no roadmap. Em empresas tier 3 como a PostHog e Brex, esperam que você ACHE esses problemas e resolva.

Ownership significa ser a pessoa que resolve problemas que ninguém está resolvendo. Não porque mandaram. Porque você viu o impacto e decidiu agir.

Ação concreta para esta semana: Identifique um problema no seu projeto atual que te incomoda. Investigue se ele é relevante. Se for, resolva. Sem esperar que alguém coloque no seu sprint.

Se estiver buscando melhorar suas ideias de como liderar projetos:

Bias for Action: Agir sem esperar estar pronto

Ver o problema não é suficiente. A diferença entre quem cresce rápido e quem fica parado está em uma coisa: ação.

Ação vem ANTES de motivação, não depois. Você não espera estar pronto para agir. Você age e fica pronto no processo.

Voltando à história da Brex, deixa eu mostrar os passos exatos que tomei:

1. Vi o problema. 400-600ms de loading que incomodava.

2. Investiguei os dados. Analisei sessões de power users.

3. Descobri o impacto real. 500 acessos por sessão.

4. Identifiquei a solução técnica. Apollo cache não estava sendo usado corretamente.

5. Implementei mantendo precisão. Crítico para uma fintech.

6. Medi o resultado. Aproximadamente 3 minutos economizados para heavy users.

Ninguém me pediu isso. Não estava no roadmap.

Eu vi o problema, investiguei, provei e resolvi.

Essa é a diferença. Low agency people param no primeiro “não” ou na primeira desculpa. High agency people continuam perguntando: “O que mais eu posso tentar?”

Esse mesmo mindset se aplica quando você busca vagas internacionais. Você não espera o momento perfeito. Não espera ter 100% dos requisitos. Você aplica, faz follow-up, vai a eventos, contribui para open source, melhora seu portfólio.

Quer aprender como usar isso em entrevistas comportamentais? Veja meu guia aqui:

High agency people agem enquanto estão com medo. Fazem imperfeito. Mas fazem. Porque esperar estar “pronto” significa nunca começar.

Ação concreta para hoje: Escolha um problema pequeno no seu projeto e resolva ainda hoje. Não precisa ser perfeito. Precisa ser feito. Comece agora.

Claridade: Saber exatamente o que você quer

Você pode ser dono dos seus resultados e agir rápido. Mas se você não sabe pra onde está indo, está só correndo em círculos.

O conceito: Lifestyle-Centric Planning

Cal Newport, autor de “So Good They Can’t Ignore You”, tem um conceito que mudou como penso sobre carreira. Ele chama de lifestyle-centric career planning:

“Fix the lifestyle you want. Then work backwards from there.”

A maioria dos devs escolhe empresa pelo nome (Google! Meta!). Isso é errado. Escolha pela vida que a empresa te dá.

Meu exemplo: Como escolhi o PostHog

Quando eu estava buscando vagas internacionais, eu sabia exatamente o que queria:

• Trabalhar 100% remoto

• Empresa de produto próprio, não consultoria

• Autonomia para tomar decisões técnicas

• Liberdade para olhar métricas e avaliar direção

• Ganhar acima de R$40k por mês

• Trabalhar com stack atual e moderna

Com esses critérios claros, eu sabia exatamente que empresas buscar. Não era qualquer vaga remota. Eram startups de produto. Não era qualquer salário. Eram empresas tier 3+ de compensação.

O PostHog marcou todas as caixas. Não foi sorte. Foi clareza de objetivo.

Seu framework: 3 passos práticos

Passo 1: Descreva seu dia ideal em 2027

Seja específico. Onde você está trabalhando? Que tipo de problemas está resolvendo? Como é seu dia típico? Quanto você ganha? Como é seu equilíbrio vida/trabalho?

Passo 2: Faça engenharia reversa

Do seu dia ideal, trabalhe backwards:

• Que tipo de empresa proporciona isso?

• Que nível de senioridade você precisa?

• Que skills você precisa desenvolver?

• Que gaps você tem hoje?

Passo 3: Quebre em ações para este trimestre

Específico. Mensurável. Com deadline.

Exemplo prático:

Vida ideal: senior engineer remoto, R$50k/mês, full ownership de features.

↪ Tipo de empresa: Startup série B+, cultura de autonomia

↪ Skill gap hoje: Pouca experiência com sistemas distribuídos.

↪ Ação Q2 2025: Estudar sobre sistemas distribuídos (aqui uma recomendação). Estudar para entrevistas de system design. + contribuir para 1 projeto open source relevante

Se você não sabe o que quer, alguém decide por você. Seu manager te usa para as metas dele. Sua empresa, para a visão deles. Família bem-intencionada te empurra para a ideia de sucesso deles.

Clareza te dá controle. Você para de ser NPC na história de outra pessoa e começa a escrever a sua própria.

Ação concreta para hoje: Reserve 30 minutos agora para escrever como seria um dia típico da sua vida ideal em 2027. Seja absurdamente específico. Depois, faça engenharia reversa até chegar em ações concretas para este mês.

Leitura relacionada:

🌟 Resumo

Os três pilares de High Agency:

• Ownership: Você é dono dos seus resultados. Não espere que alguém resolva problemas por você. Se você vê o problema e tem capacidade de resolver, resolva

• Bias for Action: Aja antes de estar completamente pronto. A motivação vem DEPOIS da ação, não antes. Imperfeito feito é melhor que perfeito adiado

• Clarity: Saiba exatamente que vida você quer viver, então faça engenharia reversa até ações concretas. Se você não sabe o que quer, alguém vai decidir por você

Ou, resumindo tudo em uma frase dita pela , uma das dez primeiras pessoas a entrar pra comunidade do NaGringa:

É mais algo relacionado a: tentar rápido, tentar varias vezes, identificar o erro e voltar pra tentar rápido.

Ações para esta semana:

• Identifique um problema no seu projeto, investigue o impacto real, e resolva sem pedir permissão

• Resolva algo pequeno hoje mesmo. Imperfeito e feito vale mais que perfeito e nunca começado

• Escreva seu dia ideal em 2027 (30 minutos) e faça engenharia reversa até ações deste mês

Lembre-se: Empresas internacionais como PostHog, Brex e outras não esperam que você peça permissão. Elas contratam esperando que você tenha High Agency desde o dia 1. Essa é a característica que separa quem consegue as melhores vagas de quem fica esperando a “hora certa” que nunca chega.

Não tivemos artigo na semana passada pois eu e a minha noiva estamos em Lisboa!

Espero que tenham gostado do artigo de hoje.

E, pra quem ainda não sabe, eu tenho postado vídeos no YouTube! Recentemente consegui mil subscribers, e estou com a meta de postar mais nas próximas semanas.

E isso foi fundamental para que eu me destacasse no meio de outros candidatos.

Isso não foi coincidência. Em 2020, com apenas 3 anos de experiência, aconteceu a mesma coisa. Haviam muitos candidatos com mais bagagem técnica que eu. Mas fui escolhido devido à minha performance na entrevista comportamental.

Ainda assim, é o assunto que menos discutimos.

Falamos sobre leetcode, system design, linguagens de programação. Mas raramente sobre como contar nossas histórias de forma que demonstrem senioridade e preocupação com o produto.

Hoje vou compartilhar exatamente como me preparar para dominar essa etapa. O mesmo método que uso há anos.

✨ O que esperar do artigo

• A estrutura exata para transformar qualquer experiência em uma história de impacto

• As 7 perguntas que sempre aparecem (com templates de resposta prontos)

• Como nossa adaptabilidade brasileira é um superpoder em startups internacionais

Por que a comportamental decide seu nível (e salário)

Vou ser direto: para cargos senior+, a comportamental tem mais peso que a técnica.

Por quê? Senior é a primeira posição de liderança. Você deixa de ser apenas um executor. Passa a influenciar, mentorar, tomar decisões que impactam o time inteiro.

Se você falhar na comportamental, dois cenários possíveis:

1. Rejeição completa - não atendem as expectativas mínimas

2. Down-level - fez processo para senior, recebe oferta como pleno

Ambos custam caro. Literalmente. A diferença entre L4 e L5 pode ser R$10k/mês ou mais.

O que empresas realmente avaliam

Quando estão crescendo uma equipe, duas preocupações principais:

1. Caráter que se identifique com a cultura

2. Capacidade de aprender as habilidades necessárias

Note a ordem. Caráter vem primeiro.

"Hire for character, train for skill" - Peter Schutz, ex-CEO da Porsche

Ouvi essa frase num onboarding em 2016. Nunca esqueci.

É muito mais difícil mudar o caráter de alguém do que ensinar uma nova tecnologia. Um desenvolvedor tóxico com código perfeito destrói times inteiros.

Por isso entrevistadores são aversos ao risco. Preferem perder uma boa contratação do que fazer uma contratação ruim.

Como exploro no artigo sobre senior de 3 vs pleno de 10 anos, senioridade não é sobre anos de experiência. É sobre impacto e liderança.

A Estrutura U-Shape + SBI que sempre funciona

Esqueça o método STAR. Use-o apenas como um linter para suas histórias.

Vou te ensinar duas estruturas poderosas: U-Shape e SBI.

O Framework U-Shape

Suas histórias devem formar um "U" narrativo:

*1. Anchor Your Status*
Comece estabelecendo seu papel e responsabilidades. Use termos da própria vaga quando possível.

"Como único desenvolvedor frontend da squad de pagamentos..."

*2. Layer in Conflict*
O vale do U. Descreva o problema REAL e os obstáculos. Quanto mais profundo o vale, maior o problema que você consegue resolver.

"Nossa página de pagamentos levava 500ms para carregar. Descobri que power users acessavam ela 500 vezes por sessão. Isso significava 4 minutos de espera só olhando loading..."

3. Achieve Success
A subida. Sua ação específica e o resultado mensurável.

"Implementei cache no Apollo que já tínhamos mas não usávamos direito. Reduzi o tempo de espera em até 195 segundos por sessão. Mantive a atualização em segundo plano para garantir precisão dos dados financeiros."

Se você quer ter mais exemplos de histórias nesse formato, recomendo esse vídeo do A Life Engineered.

O Framework SBI (mais simples)

Para respostas mais diretas:

• Situation: O contexto e objetivo

• Behavior: O que VOCÊ fez especificamente

• Impact: O resultado quantificado (mais sobre como quantificar em breve)

Os 3 pontos que sempre demonstrar

Em TODA resposta, reforce pelo menos um destes pontos:

1. Paixão pela Engenharia de Software - entusiasmo genuíno pelo que faz

2. Contribuição para o Sucesso da Empresa - alinhamento com objetivos de negócio

3. Cuidado com as Pessoas - respeito e consideração pelos outros

Veja a diferença:

Resposta genérica:
"Sou desenvolvedor há 5 anos, trabalho com React e Node, já passei por 3 empresas..."

Resposta com propósito:
"Sou apaixonado por resolver problemas reais dos usuários. Nos últimos 5 anos, sempre busquei entender o impacto do meu código no negócio - como quando reduzi o tempo de checkout em 40% e melhorei a experiência para nossos usuários. Adoro compartilhar conhecimento e ver júniors crescerem..."

Ambas são honestas. Mas só uma avança a conversa.

O superpoder brasileiro: Fazer o que precisa ser feito

Nós nascemos no Brasil, e sabemos que não é um país para amadores.

Mas, isso trás uma vantagem: aprendemos a ser resilientes.

Sabemos nos adaptar para vários tipos de situações.

E isso é algo extremamente bem visto para vagas em qualquer startup.

Em várias empresas que já trabalhei, não tive o luxo de dizer "isso não é minha área". E isso trás aprendizados enormes e adaptabilidade imprescindível para vagas em empresas menores.

História real de adaptabilidade

"Quando entrei na Brex, notei que não tínhamos nenhuma analytics no serviço de pagamentos. Nunca tinha usado Amplitude antes, mas vi a oportunidade. Criei um RFC, implementei tracking em todos os pontos críticos do fluxo. O que começou como iniciativa pessoal virou o dashboard principal do time todo. Hoje usamos para todas as decisões de produto."

Isso demonstra:

• Identificou lacuna além das suas tarefas

• Aprendeu ferramenta nova por conta própria

• Criou solução que beneficiou time inteiro

• Ownership além do esperado

Empresas internacionais valorizam MUITO essa proatividade. É o que nos diferencia de devs de outros países que são mais especializados mas menos flexíveis.

O diferencial: Se importe com o resultado, não só com a entrega

A maioria dos devs entrega a feature e segue em frente. Seniors se importam se resolveu o problema de verdade.

Exemplo de ownership real

"Implementamos permissões customizadas para pagamento de boletos. Mas não parei na entrega - criei dashboard para medir adoção. Descobri que 40% dos clientes usavam a feature. Mais importante: desbloqueamos deal de $1M/ano que estava travado por falta dessa funcionalidade."

Perguntas que você deveria sempre fazer:

• Os usuários estão usando?

• Resolveu o problema original?

• Qual foi o impacto no negócio?

• O que aprendemos para próxima vez?

Como exploro em "Como medir o impacto do seu trabalho", métricas transformam "fiz X" em "gerei Y de valor".

Essa mentalidade de ownership é o que separa plenos eternos de seniors de verdade.

Sem acesso a métricas? Como demonstrar impacto mesmo assim

Nem todo dev tem acesso ao Google Analytics ou dashboards de negócio. Isso não é desculpa para não quantificar.

Opção 1: Estime baseado no que você observa

Em vez de: "Melhorei o sistema de login"

Diga: "O sistema de login que refatorei é usado por ~5000 usuários diários da plataforma. Reduzi de 3 cliques para 1, economizando aproximadamente 10 segundos por login."

Opção 2: Use métricas internas do time

Em vez de: "Criei ferramenta de debug"

Diga: "Criei ferramenta de debug para time de 8 devs. Antes, gastávamos ~2h para encontrar erro em produção. Com a ferramenta, 15 minutos. Economia de 10h/semana para o time."

Opção 3: Descreva o escopo do impacto

Em vez de: "Implementei novo relatório"

Diga: "Implementei relatório usado pelo C-level para decisões semanais. 5 diretores dependem dele toda segunda para definir prioridades da semana."

Opção 4: Use proxies visíveis

• Número de usuários afetados: "Feature usada por todos os 200 clientes enterprise"

• Frequência de uso: "Tela acessada ~50 vezes por dia por cada vendedor"

• Tamanho da empresa: "Sistema crítico para empresa de 500 funcionários"

• Redução de reclamações: "Não recebemos mais os ~5 tickets/semana sobre esse problema"

• Tempo economizado: "Processo que levava 1h agora leva 10 minutos"

Exemplo prático de como estimar

"Implementei cache na API de produtos. A empresa tem 10k usuários ativos. Se cada um acessa produtos 5x por dia, e economizei 200ms por request, são 10k 5 0.2s = 2.7 horas de espera eliminadas por dia."

Não precisa ser 100% preciso. O importante é mostrar que você pensa em impacto.

Frases úteis quando não tem números exatos

• "Baseado no tamanho da nossa base (~X usuários)..."

• "Considerando que o time tem Y pessoas..."

• "A feature é acessada aproximadamente Z vezes por dia..."

• "Eliminamos a principal reclamação dos usuários que era..."

• "O CEO mencionou que isso desbloqueou..."

"Mas eu só faço CRUD na consultoria"

Toda experiência pode virar uma história de impacto. Veja como transformar trabalho "simples":

CRUD básico →
"Padronizei componentes de formulário reduzindo bugs em 30% e tempo de desenvolvimento de telas novas de 3 dias para 1"

Manutenção →
"Identifiquei que 60% dos bugs vinham do módulo de autenticação. Refatorei por iniciativa própria, eliminando 15h/mês de retrabalho"

Feature simples →
"Implementei filtros no relatório. Mas também instrumentei analytics e descobri que salvava 2h/semana para o time de vendas"

Bug fixing →
"Criei documentação de 'bugs comuns e soluções' que reduziu tempo de onboarding de novos devs de 1 mês para 2 semanas"

O segredo: sempre conecte com impacto no negócio ou no time.

As 7 perguntas que sempre aparecem (com respostas práticas)

1. "Tell me about a time you disagreed with your manager"

O que avaliam: Sua capacidade de discordar respeitosamente e defender ideias com dados.

Template:
"Meu manager queria [solução A]. Eu propus [solução B] porque [dados/evidências]. Apresentei um POC demonstrando [benefícios]. Chegamos num meio termo que [resultado positivo]."

Exemplo real:
"Manager queria adicionar mais campos no formulário. Mostrei que 70% dos usuários abandonavam com os campos atuais. Propus primeiro melhorar conversão, depois adicionar campos. Teste A/B provou: conversão subiu 25%."

Nunca diga: "Meu chefe estava errado e eu provei isso."

2. "What's your biggest failure?"

O que avaliam: Autocrítica, aprendizado e responsabilidade.

Template com exemplo real:
"Estimei 4 semanas para projeto de permissões. Não mapeei todas as entidades afetadas - descobri conexões só durante implementação. Atrasou 4 semanas. Mas comuniquei semanalmente no canal público, criei documentação de todos os componentes afetados, e entregamos desbloqueando $1M em vendas. Hoje sempre faço system mapping antes de estimar."

Nunca diga: "Nunca falhei" ou culpe outros.

3. "How do you influence without authority?"

O que avaliam: Liderança informal e habilidades de persuasão.

Exemplo prático:
"Precisava convencer 3 times a adotar novo padrão de logs. Criei dashboard mostrando que levávamos 2h para debugar problemas. Com padrão novo: 15 minutos. Fiz demo em cada time mostrando o benefício específico deles. Todos adotaram em 2 sprints."

4. "Describe a project with ambiguous requirements"

O que avaliam: Navegação em incerteza e proatividade.

Exemplo real:
"Recebi pedido vago: 'melhorar experiência de pagamento'. Analisei dados: 30% abandonavam no upload de boleto. Prototypei 3 soluções. Teste com 5 usuários. Implementamos a vencedora: abandono caiu para 5%."

5. "What's your proudest achievement?"

Template com exemplo realista:
"Reduzi loading da página mais acessada de 500ms para instantâneo usando cache que já existia mas não usávamos. Usuários power economizavam 3-4 minutos por dia. Orgulho porque identifiquei o problema sozinho, aprendi a ferramenta e o impacto foi imediato."

6. "Tell me about a time you had to learn something quickly"

Exemplo prático:
"Cliente grande precisava integração com SAP em 2 semanas. Nunca tinha tocado em SAP. Montei plano: documentação oficial, videos YouTube, 1:1 com dev que conhecia. Em 3 dias fiz POC. Em 2 semanas, integração completa em produção."

7. "Describe a conflict with a teammate"

Template realista:
"Colega insistia em microserviços para projeto pequeno. Entendi a preocupação dele: escalabilidade futura. Propus monolito modular que poderíamos quebrar depois. Documentei prós/contras. Concordamos e economizamos 3 meses de desenvolvimento."

Diferença Cultural: Brasil vs Internacional

No Brasil: Valorizamos humildade, às vezes excessiva.
Lá fora: Esperado que você "se venda" mais.

O que parece arrogância aqui é considerado confiança normal lá. Ajuste seu dial:

• Brasil: "Ajudei um pouco no projeto..."

• Internacional: "Liderei a implementação que economizou R$200k"

Não é mentir. É dar crédito ao seu trabalho.

Como brasileiros se sabotam

• Minimizam conquistas: "não foi nada demais"

• Compartilham crédito excessivamente: "o time fez tudo"

• Evitam falar de números: "melhorou bastante"

• Pedem desculpa por sucessos: "tive sorte"

Corrija isso. Você trabalhou duro. Merece reconhecimento.

Preparação prática: Seu checklist completo

Passo 1: Documente suas histórias

Escreva 5-6 experiências diferentes cobrindo:

• Conflito resolvido

• Falha e aprendizado

• Liderança sem autoridade

• Projeto ambíguo

• Maior sucesso

• Mentoria oferecida

• Aprendizado rápido

• Adaptação/fazer além do esperado

Passo 2: Adicione métricas sempre (ou as melhores estimativas)

• ❌ "Melhorei a performance"

• ✅ "Reduzi tempo de resposta de 3s para 200ms (93% mais rápido)"

• ✅ "Sistema usado por ~1000 usuários/dia agora carrega 3x mais rápido"

Não tem analytics? Estime baseado em:

• Tamanho da empresa/base de usuários

• Frequência de uso da feature

• Tempo economizado para pessoas

• Tickets/reclamações eliminados

Passo 3: Pratique em voz alta

• Grave você mesmo contando cada história

• Objetivo: 2-3 minutos por resposta

• Natural > Perfeito

Passo 4: Misture seus exemplos

Não use a mesma história para todo entrevistador no mesmo dia. Se você tem 5 entrevistas, precisa de pelo menos 5 histórias diferentes.

O que NUNCA fazer

1. Mentir ou usar histórias dos outros
As follow-ups vão te expor. É impossível dar detalhes de algo que não viveu.

2. Criar "vilões"
"Meu colega era incompetente" = red flag gigante. Mantenha profissional sempre.

3. Descrever sucesso perfeito
Vida real é bagunçada. Adicione: "Não foi perfeito, tivemos que ajustar X, mas no final..."

4. Não ter histórias preparadas
"Hmm, deixa eu pensar..." repetido = despreparo.

5. Focar só na técnica
"Usei React com Redux" não impressiona. "Reduzi tempo de checkout em 40%" impressiona.

Recursos para praticar

• A Life Engineered - Canal excepcional no YouTube

• Tech Interview Handbook - Seção comportamental completa

• Método STAR - Use como "linter" para verificar se sua história está completa

• Nossa comunidade - Pratique com outros devs brasileiros. Mande sua história, peça feedback.

🌟 Resumo

• Prepare 5-6 histórias que cubram diferentes situações e demonstrem crescimento

• Use a estrutura U-Shape para criar narrativas impactantes (status → conflito → sucesso)

• Quantifique tudo - números convencem mais que adjetivos (estime se não tiver dados exatos)

• Mostre adaptabilidade - nossa vantagem competitiva como brasileiros

• Demonstre ownership - se importe com resultados, não só entregas

• Ajuste para cultura internacional - venda suas conquistas sem medo

• Pratique em voz alta - naturalidade vem com repetição

• Transforme qualquer experiência - até CRUD pode virar história de impacto

Lembre-se do melhor conselho: Se divirta. Tente não levar as coisas tão a sério.

A entrevista comportamental é apenas uma conversa entre dois profissionais. Você contando suas experiências para alguém genuinamente interessado em conhecer seu trabalho.

Como exploro em "Como se destacar em qualquer processo seletivo", o melhor sinal de sucesso é quando parece uma conversa entre amigos.

E como sempre digo: trate todo este processo como apenas uma quest no enorme RPG que é a vida.

Mesmo se der errado, você ganha experiência. E na próxima vez, suas histórias serão ainda melhores.

Checklist final de preparação:

• Documentei 5-6 histórias diferentes

• Cada história tem números/métricas específicas (ou estimativas razoáveis)

• Pratiquei em voz alta (2-3 min cada)

• Gravei e ouvi minhas respostas

• Tenho uma história para cada arquétipo

• Cada história mostra adaptabilidade ou ownership

• Tenho pelo menos uma história de "fiz além do pedido"

• Sei o impacto real (ou estimado) de pelo menos 3 projetos

• Ajustei tom para contexto internacional

Próxima vez que entrar numa comportamental, você não vai só passar - vai definir seu nível. E seu salário.

Boa sorte! 🚀

P.S.: Se você ainda está pensando "mas meu trabalho não é interessante", volte nas seções "Mas eu só faço CRUD" e "Sem acesso a métricas?". Toda experiência pode ser uma história de crescimento. É só questão de como você conta.

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.

Temos também um programa de indicação.

1. Indicando 5 pessoas: 1 mês grátis de acesso (valor de R$99,90)

2. Indicando 15 pessoas: 3 meses (valor de R$299,70)

3. Indicando 30 pessoas: mentoria individual comigo de 1h (valor de R$750)

O resultado? Uma ferramenta que uso até hoje no meu gerador de invoices. Mais importante: domínio completo de conceitos que teriam levado meses estudando teoria.

A diferença entre aprender com side projects e fazer cursos é brutal. Cursos te ensinam sintaxe. Side projects te ensinam a resolver problemas reais, lidar com bugs, fazer deploy, e ter algo concreto pra mostrar em entrevistas.

✨ O que esperar do artigo

• Metodologia 30/70 para aprender qualquer tecnologia nova através de projetos práticos

• Exemplos reais de como usei side projects para aprender web scraping, Go, multiplayer games e crescer minha audiência

• Framework prático para escolher, estruturar e executar projetos que realmente aceleram sua carreira

🎯 Por que side projects funcionam melhor que cursos

O problema dos cursos tradicionais

Cursos te colocam no piloto automático. Você segue instruções, copia código, e no final tem a falsa sensação de que aprendeu. Mas quando precisa aplicar o conhecimento em um contexto diferente, trava.

Exemplo: você fez um curso de React e construiu uma to-do list. Consegue fazer um dashboard complexo com WebSockets e autenticação? Provavelmente não, porque nunca enfrentou problemas reais.

A vantagem dos side projects

Side projects te forçam a tomar decisões. Qual biblioteca usar? Como estruturar o código? Como fazer deploy? Essas decisões - e os erros que você comete - são onde o aprendizado real acontece.

Quando construí meu agregador de vagas, aprendi web scraping na prática. Não existe curso que ensine a lidar com 20+ sites diferentes, cada um com sua estrutura HTML bizarra. Tive que resolver na unha, e isso resultou em 5x mais assinantes pagos.

📊 O método 30/70: Como estruturar seu aprendizado

30% - Fundamentos teóricos (Leitura direcionada)

Não pule a teoria completamente. Mas seja cirúrgico. Quando está aprendendo uma linguagem nova:

• Leia a documentação oficial sobre conceitos que você não entende

• Artigos específicos sobre problemas que está enfrentando no projeto

• Livros técnicos para entender o "por quê" por trás das práticas

O segredo: estude teoria quando precisa resolver um problema específico no projeto. Isso cria contexto e melhora a retenção.

70% - Prática aplicada (Construindo)

Aqui é onde a mágica acontece. Pegue um problema real - pode ser seu, de um amigo, ou até fictício mas realista - e tente resolver.

Meus exemplos reais:

Go + Kubernetes (3 semanas): Precisava de uma API para gerar PDFs. Escolhi Go porque complementava meu toolkit com uma linguagem de alta performance, Kubernetes porque toda empresa de tech usa e é uma skill valiosa para carreira. Documentei tudo aqui.

Web Scraping (4 semanas): Queria oferecer mais benefícios aos assinantes pagos. Criei um agregador que coleta 800+ vagas diariamente. Resultado: crescimento explosivo de assinantes (de ~50 para 250+).

Game Development (1 semana): Queria entender multiplayer em tempo real. Construí emojinx em um hackathon - um jogo de memória com temas de emojis.

A diferença dos resultados

Com cursos: "Sei React, tenho o certificado X"
Com side projects: "Construí um dashboard que gerencia dados de usuários usando React + WebSockets + Postgres, com deploy automatizado"

Qual impressiona mais em uma entrevista?

🚀 Framework prático: Como escolher e executar

1. Escolha problemas que te motivam

Rule #1: Resolva seus próprios problemas primeiro. Se você sente o problema na pele, vai ter motivação para terminar o projeto quando der errado (e vai dar).

Exemplos de problemas pessoais:

• Controlar gastos → App de finanças

• Organizar estudos → Sistema de spaced repetition

• Achar vagas → Agregador de oportunidades

• Compartilhar código → CLI tool personalizada

2. Defina escopo pequeno, mas completo

MVP funcional > projeto complexo pela metade. É melhor ter uma calculadora que funciona perfeitamente do que um ERP 30% pronto.

Template que uso:

• Problema: [1 frase descrevendo o que resolve]

• Features essenciais: [Máximo 3 funcionalidades]

• Tecnologias novas: [Máximo 2 que quer aprender]

• Prazo: [2-4 semanas máximo]

3. Use IA como mentor, não como substituto

Com ferramentas como Claude Code e Cursor, aprender sintaxe nova ficou trivial. Use IA para acelerar, não para fazer por você.

Como uso IA nos projetos:

• "Explique este erro em termos de React" (quando estou aprendendo Vue)

• "Qual a melhor prática para X em Python?" (quando venho de JavaScript)

• "Revise este código e sugira melhorias" (para aprender padrões)

4. Construa em público

Aprender em público multiplica os benefícios. Quando você documenta o processo, força você a entender realmente (não consegue explicar o que não entende), cria networking orgânico com pessoas que têm problemas similares, e gera oportunidades porque recrutadores veem que você shipa código real.

Por isso comecei a fazer vídeos semanais no YouTube compartilhando minha jornada e dicas práticas - como meu passo a passo completo para trabalhar como dev na gringa e como otimizar seu currículo para vagas internacionais. Ensinar é a melhor forma de consolidar conhecimento.

💼 O impacto na carreira: Muito além do aprendizado

Quando você tem side projects reais, as oportunidades começam a aparecer naturalmente.

Durante aplicações para vagas, em vez de falar "sei Python", você fala "construí uma API completa usando Python + FastAPI + Redis, com deploy automatizado". A diferença é que você pode mostrar o código, explicar as decisões técnicas, e demonstrar que consegue entregar.

Durante entrevistas técnicas, você tem histórias reais para contar. Quando perguntam sobre desafios, você não precisa inventar cenários. No meu projeto de web scraping, por exemplo, alguns sites bloqueavam requests muito frequentes. Implementei rate limiting com Redis e rotação de user agents. Resultado: 99% de sucesso nas coletas mesmo com 20+ sites diferentes.

Para construir marca pessoal, side projects viram portfólio natural. Cada projeto bem documentado prova que você identifica problemas reais, escolhe tecnologias adequadas, executa do zero ao deploy, e comunica resultados claramente.

A verdade é que a maioria dos developers nunca termina projetos pessoais. Quando você tem 3-4 projetos completos e funcionando, já se destaca da multidão.

🌟 Próximos passos: Seu projeto desta semana

Escolha UM projeto pequeno e comece hoje. Identifique um problema que você enfrenta semanalmente - pode ser organizar arquivos, controlar gastos, ou automatizar uma tarefa repetitiva. Defina o escopo em máximo 3 funcionalidades essenciais, escolha uma tecnologia nova que quer aprender, e documente o processo no LinkedIn ou blog pessoal.

A parte mais importante? Faça deploy em produção, mesmo que seja só no Vercel ou Heroku free tier. Um projeto rodando na internet vale mais que dez projetos no seu localhost.

Lembre-se: É melhor ter 1 projeto pequeno e completo do que 10 projetos pela metade. E se você não consegue explicar como construiu em 2 minutos, o projeto ensinou mais sobre copy-paste do que sobre programação.

TL;DR: Pare de colecionar certificados de curso. Comece um side project pequeno hoje. Documente o processo. Em 3 semanas você vai ter aprendido mais do que em 6 meses de tutoriais - e ainda vai ter algo real para mostrar em entrevistas.

Para quem quer acelerar ainda mais

Se você está sério sobre crescer na carreira, nosso programa de mentoria combina projetos práticos com orientação estratégica. Ajudamos você a escolher projetos que não apenas te ensinam, mas posicionam sua candidatura para vagas internacionais.

Inclui: Acesso ao nosso portal com 800+ vagas, mentorias em grupo mensais para revisar seus projetos, e uma comunidade de 250+ devs ambiciosos fazendo a mesma jornada.

Assine agora

Se você não tem o interesse no plano pago, não tem problema. Você pode também se juntar aos outros 7800+ que estão recebendo todos meus artigos, semanalmente.

Além disso, como mencionei no artigo, estou publicando vídeos semanalmente no YouTube! Se você gosta do meu conteúdo aqui, considere se inscrever por lá também.

🏗️ Oportunidades para assinantes

Estou ajudando uma startup tier A (salário $80-120k) a encontrar seu primeiro founding engineer. A stack é 100% TypeScript (backend e frontend).

Importante: Esta é uma posição de founding engineer - o primeiro hire técnico da empresa. É um papel muito diferente do que a maioria de nós está acostumada, com muito mais autonomia e responsabilidade.

Veja a descrição completa aqui. Esse link é acessível apenas para quem é assinante e já está no nosso Google Groups. Se você ainda não está, acesse seu perfil aqui para colocar seu Gmail e então sincronizar sua assinatura.

Qualquer dúvida, me avisa no nosso grupo do WhatsApp.

Lembrando que além dessa oportunidade, temos outras 875 vagas no nosso portal. Elas são dividas em três tiers:

• Tier B: $50-89k

• Tier A: $90-120k

• Tier S: $120k+

Este framework simples vai acabar com suas dúvidas sobre o que estudar.

Toda semana recebo mensagens parecidas: "Sou dev backend Node.js, estou aprendendo Go, faz sentido?" ou "Sou dev Angular, estou estudando React, o que mais posso melhorar?".

A maioria dos devs trata essas decisões como preferência pessoal ou curiosidade técnica. Mas cada hora que você investe estudando algo novo é um investimento na sua carreira. E como qualquer bom investimento, você deveria escolher o que dá melhor resultado.

🚪 O Framework: Máximo de Portas Abertas

Pense na sua carreira como suas escolhas de desenvolvimento. Cada hora que você gasta estudando, cada projeto que escolhe pegar no trabalho - tudo isso são investimentos do seu tempo e energia.

O retorno aqui não é só conhecimento técnico. É o número de oportunidades futuras que essa decisão vai gerar.

O framework é simples. Antes de qualquer decisão de carreira, pergunte:

"Qual escolha vai me expor a mais pessoas, projetos e responsabilidades?"

Como aplicar na prática

Escolhendo o que estudar: React dev pensando entre Vue ou backend? Backend ganha. Vue te conecta com mais projetos React. Backend te conecta com todo o sistema, outros times, outras responsabilidades.

Escolhendo projetos no trabalho: Entre uma feature isolada e um projeto cross-funcional? Cross-funcional sempre. Você vai trabalhar com PM, design, outros engenheiros. Vai entender o business melhor. Vai expandir sua rede interna.

Quando "tudo parece útil": Liste as opções e pergunte: qual me conecta com mais pessoas diferentes? Qual me ensina skills que funcionam em outras áreas? Qual me posiciona pra roles futuras que nem existem ainda?

Por que isso funciona

Numa conversa com um Principal Engineer na Brex, ele me disse: "Eu não aprendo nada realmente novo desde que era mid-level. Quando você tem os fundamentos sólidos, é questão de adaptar mudanças de paradigma."

A chave é construir uma base sólida de fundamentos que se transferem + uma rede diversa de conexões e experiências.

Não é sobre qual tech tá em alta no Twitter. É sobre qual decisão multiplica suas opções futuras.

👶 Nível Junior: Profundidade Ganha

Erros comuns que vi

Pular de tecnologia em tecnologia sem dominar nenhuma. Segunda-feira React, quarta-feira Vue, sexta-feira Svelte.

Fazer curso após curso sem construir nada real. Saber fazer to-do lists em 15 frameworks diferentes, mas nunca ter deployado algo pra produção.

Se preocupar demais com a stack: "Só me candidato pra vagas React" ou "Só aceito backend Java". As melhores empresas contratam quem resolve problemas, não especialistas em linguagem específica.

O que fazer

Uma stack, muito código: Escolha uma linguagem e fique ali. Se é frontend: React + TypeScript + Node.js. Se é backend: Python + Django + PostgreSQL. Não passe um dia sem codar.

É melhor ser muito bom em uma coisa do que mediano em cinco.

Procure mentores: Aprenda a fazer perguntas do jeito correto. Isso não só te ajuda a resolver problemas mais rápido, mas mostra maturidade profissional.

Exemplo prático

Você é dev React e tá pensando se aprende Vue ou Angular. Não aprenda. Em vez disso, aprenda TypeScript profundamente. Aprenda testes. Aprenda deploy e CI/CD.

Essas skills funcionam com qualquer framework frontend futuro. Vue ou Angular são só mais ruído na sua cabeça nesse momento.

⚖️ Nível Pleno: Hora de Expandir

Erros comuns

Zona de conforto técnica: Frontend que nunca mexeu com banco de dados. Backend que nunca tocou em CSS. Essa especialização excessiva limita suas oportunidades futuras.

Focar só em código: Ainda pensar que programação é 100% sobre escrever código. Ignorar que comunicação, documentação e mentoring são parte fundamental do trabalho.

O que fazer

Frontend → Backend ou vice-versa: Esse é o momento perfeito pra você explorar o outro lado. Se você é frontend, aprenda sobre APIs, bancos de dados, arquitetura. Se você é backend, entenda UX, performance no browser.

Desenvolver soft skills: Seu trabalho não fala por você. Comece a documentar seus projetos, apresentar demos, participar de decisões técnicas importantes.

Como convenci meu manager na Brex

Quando estava na Brex como frontend engineer, percebi que pra crescer eu precisava entender o sistema completo. Fui numa 1:1 com meu manager e argumentei:

"Quero aprender backend não só pra minha carreira, mas pro benefício da empresa. Com visão completa do sistema, vou conseguir contribuir melhor e colaborar mais efetivamente com o time de backend."

Resultado? Consegui trabalhar em projetos full-stack, desenvolvi relacionamento com engenheiros de outros times. Essa experiência foi chave para me fazer passar como senior no PostHog.

A chave foi mostrar como meu crescimento beneficiaria não só minha carreira, mas o resultado do time inteiro.

🎯 Nível Senior: Multiplicador de Time

Erros comuns

Tentar fazer tudo hands-on: Continuar pensando que sua contribuição principal é escrever código. Senior contribui mais através de outras pessoas.

Focar em skills técnicas: Achar que promoção pra Staff/Principal é sobre ser ainda melhor tecnicamente. Na verdade é sobre influência, visão de produto, e capacidade de tomar decisões que impactam múltiplos times.

O que fazer

System design e arquitetura: Aprenda a desenhar sistemas que escalam. Entenda quando usar microserviços vs monolito, quando otimizar vs quando reescrever.

Mentoring estruturado: Ajude outros engenheiros a crescerem. Isso multiplica seu impacto e desenvolve suas skills de liderança técnica.

Visão de produto: Entenda o business. Saiba por que certas features são prioritárias. Colabore com PM, design, e outros stakeholders.

A lição que mudou tudo

Numa sessão de pair programming com um Senior, resolvemos um problema rapidamente. Pensei: "Ok, está pronto, vamos pra próxima?"

Mas ele parou e continuou pensando: "Resolvemos, mas o código ainda tá meio confuso. Precisamos pensar em quem vai dar manutenção nesse código daqui 6 meses."

Senior não resolve problemas só pro agora, mas pensando na saúde do sistema ao longo de anos.

🌟 Teste Esta Semana

Passo 1: Liste 3 coisas que você está considerando estudar ou projetos que quer pegar.

Passo 2: Para cada uma, pergunte:

• Quantas pessoas novas isso me conecta?

• Quantos projetos diferentes isso me permite fazer?

• Quanto isso me posiciona pra roles futuras?

Passo 3: Escolha a opção com mais "sim".

Por que isso funciona a longo prazo

Sua carreira não depende só de você ser bom tecnicamente. Depende de você construir sua sorte aumentando suas oportunidades.

Quanto mais pessoas você conhece, mais oportunidades surgem. Aquele frontend que você ajudou pode te chamar pro próximo projeto. Aquele PM que você colaborou bem pode te recomendar pra uma vaga.

Quanto mais projetos diversos você trabalha, mais você entende o business. E quem entende business além de tecnologia tem muito mais opções de carreira.

O dev que só sabe React pode ser substituído quando React sair de moda. O dev que entende frontend, backend, produto, pessoas e business pode se adaptar a qualquer mudança tecnológica.

Invista na sua versatilidade. Trabalhe com pessoas diferentes, times diferentes, culturas diferentes.

📋 Resumo Rápido

O framework é simples: sempre escolha o que abre mais portas futuras.

• Junior: Profundidade numa stack > aprender várias tecnologias

• Pleno: Expandir horizontes e soft skills > ficar na zona de conforto

• Senior: Multiplicar através de outros > fazer tudo sozinho

O teste final: "Essa escolha vai me expor a mais pessoas, projetos e responsabilidades?"

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!