Como fui de ‘Onde tá o README?’ a 2º lugar em Hackathon em 9 meses

Primeira semana como estagiário: clonei o repositório, nunca tinha visto uma aplicação tão densa. Kafka, Kubernetes, APIs. Pânico silencioso.

Nove meses depois: 2º lugar no hackathon interno de tech, competindo com mais de 90 times (maioria de senioridades pleno e seniors). Nossa solução? Plataforma que otimiza a alocação de subsídios — um dos maiores custos de foodtech, usando Machine Learning para sugerir alocação ideal, mas mantendo controle humano para ajustes estratégicos.

Como cheguei aqui? Não foi genialidade. Foi errar em produção em data importante, sobreviver a code reviews brutalmente honestos, fazer 10 mil perguntas e, principalmente, focar em resolver problemas reais, não em aprender tecnologias porque são hype.

Se você está começando e achando que “não é técnico o suficiente”, vem comigo. Essa é a história de 1 ano sem filtro com vários detalhes do processo: sensações de síndrome do impostor, primeiro deploy, primeiro incidente e uma medalha de prata que ainda me surpreende!

Quando a faculdade encontra a realidade (e dá tela azul)

Meu projeto final na matéria de Engenharia de Software foi um sistema de review sobre acessibilidade. Site simples. Três arquivos. Banco local. Rodava na minha máquina. Nota 10.

Primeira tarefa no iFood: migrar nosso serviço de Canary 1.0 para Canary 2.0. Minha reação: “Canary? Que pássaro é esse?” Depois de ler a documentação: “Ah, é só atualizar uns YAMLs no GitLab CI. Parece simples.” Foram 24 commits até funcionar. E cada commit foi uma lição sobre o que a faculdade não ensina. Só o dia a dia mesmo, com trabalho em equipe e muita dedicação!

Contexto rápido sobre o cenário:

• Canary deploy é rollout gradual — você sobe código novo para 5% do tráfego, monitora, vai aumentando (20%, 40%, 60%, 100%). Se quebrar? Rollback rápido, só 5% afetados. Diferença entre derrubar app para 500 mil vs 10 milhões de usuários.
• Canary 2.0 era iniciativa do time de Developer Experience, mais conhecido como DevX, para tornar o processo mais seguro e auditável — promoção/suspensão via FoodCTL (CLI padronizada) em vez de configurações livres no GitLab CI.

Passo a passo dos 24 commits (ou melhor, o resumo da dor)

Commits 1-8: Seguindo o guia certinho (ou quase)

Fui metódico. Li a documentação, segui passo a passo. Desativei configs antigas, uma por commit. Adicionei configs novas, uma por commit. YAML com indentação milimétrica. Abri MR. Rodei a pipeline. Quebrou.

Commits 9-18: Fase “por que esse trem não funciona?”

Documentação dizia que ia funcionar. Não funcionou. Comecei a fase de suposições:

• Será que é o nome da variável? (mudei, não era);
• Será que falta alguma configuração? (copiei de outros repositórios, não era);
• Será que é ordem no YAML? (mudei, não era);

Cada tentativa: um commit. Cada commit: esperança. Cada pipeline: frustração.

Commits 19-24: Pair programming salva vidas!

Depois do commit 18, travei. Totalmente perdido. Pedi ajuda. Dev sênior fez pair comigo. Em 20 minutos achamos: array de pesos configurado errado + variável antiga escondida no arquivo.

Sozinho? Levaria horas. Com ajuda? Resolvido antes do almoço.

O que aprendi:

• Produção ≠ faculdade: Erro não é nota baixa — são milhões de usuários afetados;
• Infra como código é código: YAML merece review, testes, atenção;
• Documentação é mapa, não GPS: Ela não te avisa de todos os buracos;
• Pair programming > sofrer sozinho: 20 minutos com ajuda > 3 horas travado.

Serviço migrado. Processo mais seguro. E a lição: “tarefa simples” não existe. Na primeira vez? Vai ter complexidade escondida. E 24 commits. E tá tudo bem.

Quando “Só Propagar um Header” Vira Algo Muito Maior

Migrar Canary foi escola intensiva de CI/CD. Mas o verdadeiro teste veio depois: fazer meu primeiro deploy de feature real. A tarefa: propagar header x-ifood-test-flag: loadTest em eventos Kafka de Delivery Order. E o principal, o contexto: quando o time faz load test (simula milhões de pedidos para testar capacidade), esses eventos não podem se misturar com dados reais. Senão? Métricas poluídas, alertas falsos, dashboards inutilizados.

Solução: propagar header por toda a cadeia de eventos. Se o pedido veio de teste, marca como teste. Simples, certo? Spoiler: não. O que parecia simples: “É só adicionar um campo attributes na entidade DeliveryOrder, receber o header, propagar pro Kafka.”

O que foi de verdade:

• Alterar schema do banco: Nova coluna em PostgreSQL, migration, rollback strategy;
• Atualizar contratos: Todo serviço que consome DeliveryOrder precisa saber que esse campo existe;
• Lógica de propagação: Receber header → salvar no banco → emitir no Kafka → garantir backward compatibility;
• Null safety: E se vier null? E se vier vazio? E se vier com formato errado?

Primeiro commit: código funcionando (achei eu).

Code review: “Faltam testes. E se attributes for null? Cobertura tá 60%, sobe pra 80%.”

Segunda rodada: adicionei testes, tratamento de null. Code review: “Esse if pode ser simplificado. Extrai essa lógica para função.”

Terceira rodada: refatorei. Finalmente aprovado. Deploy: hora de usar o Canary que migrei.

Lembram dos 24 commits pra migrar Canary 2.0? Chegou a hora de colher os frutos.

Deploy gradual via FoodCTL: 5% → 20% → 40% → 60% → 100% em 1 dia (com muita cautela e café). Header propagando? Dados separados? A diferença? Confiança. Se algo quebrasse, rollback em segundos.

O que aprendi:

• “Adicionar um campo” nunca é simples: Tem banco, contratos, backward compatibility, testes;
• Code review é aula grátis: Cada rodada ensinou algo — cobertura, clean code, edge cases;
• Processo > código: Ter canary, testes, monitoramento me deu confiança pra fazer deploy sem pânico;
• Backward compatibility importa: Sistema tem que funcionar antes, durante e depois da mudança.

Resultado: header propagado, dados separados, dashboards limpos. E eu? Estagiário com primeira feature servindo milhões de eventos por dia.

Pequeno? Talvez. Mas era meu código, em produção, resolvendo problema real.

De quebrar monitores a otimizar milhões em subsídios: 9 Meses fazem diferença

Com 09 meses de iFood, houve o anúncio de um hackathon interno: 3 dias, 90 times, maioria plenos e seniores. Minha reação? “Será que estou pronto pra isso?” Estava. Mas não do jeito que imaginava. O desafio: iFood do Futuro.

Escolhemos atacar um problema que queima milhões por trimestre: alocação ineficiente de subsídios. O contexto: iFood investe pesado em cupons, cashback, frete grátis para conquistar pedidos. Mas a distribuição é complexa — regiões diferentes, elasticidade diferente, restaurantes em múltiplos apps.

A métrica que importa? Custo por pedido incremental — quanto você gasta em subsídio para conquistar cada pedido novo. Nossa solução: ML + controle humano.

Construímos plataforma que equilibra automação + decisão estratégica:

• Modelo de regressão linear treinado com 6 meses de dados históricos. Função objetivo: minimizar custo/pedido.
• IA orquestradora com simulação em tempo real. Usuário ajusta subsídio, sistema mostra impacto instantâneo: “Se você aumentar 20% na Zona Sul, ganha X pedidos com custo Y”.
• Dashboard interativo com monitoramento de merchants multi-app e comparação: alocação atual vs ótima sugerida.
• Stack: Golang (backend), React (frontend), dados reais de produção.

O diferencial: maioria dos times propôs soluções 100% automatizadas. A gente foi na direção oposta, por exemplo, machine learning como ferramenta de decisão, não substituto. Por quê? Porque a alocação envolve variáveis que modelo não captura: sazonalidade, estratégia competitiva, políticas comerciais.

Resultado: 2º lugar! Mostramos pro júri (CTOs, VPs) redução potencial em custo/pedido validado com backtesting. Focamos em: resolver problema real, com impacto mensurável, em prazo viável. E funcionou.

Outro fato pra se orgulhar:

Fui convidado para gravações do programa de estágio do próximo ano com foco em compartilhar sobre inovação no dia a dia. Vários candidatos me procuraram pelas redes para receber orientações e pude compartilhar minha experiência.

O que mudou em 9 meses:

Não foi conhecimento técnico — foi mindset. Exemplifico com as minhas perguntas no Slack:

Mês 1: “Como eu rodo isso localmente?”

Mês 9: “Latência P99 em 800ms no /orders, já verifiquei APM, parece query N+1. Faz sentido eager loading ou cache?”

A diferença? Aprendi a investigar antes de perguntar, contextualizar problemas, trazer hipóteses. Ainda faço muitas perguntas. Só que agora são melhores. Hoje tomo decisões técnicas sozinho com apoio do time, por exemplo, algoritmos, retry policy, rollback. Mas quando tenho dúvida? Pergunto sempre. Porque autonomia não é acertar sempre, mas saber quando você pode decidir e quando precisa de validação.

Reflexão:

Ainda sou estagiário. Ainda tenho muito a aprender.

Mas hoje, quando abro aquele repositório enorme, não sinto pânico. Sinto curiosidade. E às vezes — como no hackathon — sinto que posso resolver problemas que importam de verdade.

O que diria para o “Eu” de 1 ano atrás

Se eu pudesse voltar no tempo e falar com o estagiário nervoso do primeiro dia, diria:

1. Você não precisa saber tudo

Ninguém espera isso. O que esperam é curiosidade, vontade de aprender e humildade para pedir ajuda. Síndrome do impostor é real, mas todo mundo sentem até seniors.

2. Pergunte muito — mas aprenda a investigar antes

Devs experientes não sabem tudo de cabeça. Sabem onde procurar. Aprenda a ler logs, documentação, código. Depois pergunte com contexto.

3. Code review não é crítica pessoal

É a melhor aula grátis que você vai ter. Absorva cada feedback. Pergunte o “porquê” por trás de cada sugestão. E revise seu próprio código antes de pedir review.

4. Você VAI errar em produção

E está tudo bem. O que importa é ter processo para mitigar rápido, aprender e não repetir. Merge conflicts mal resolvidos acontecem. Aprenda e siga em frente.

5. Foque em resolver problemas reais, não em aprender hype

Machine learning, blockchain, IA generativa são legais. Mas resolver problema de negócio com tecnologia adequada > usar tech da moda sem propósito.

Se você está começando em tech: não compare seu capítulo 1 com o capítulo 20 de outra pessoa. Compare com seu capítulo anterior. Evolução é o que importa.

Um ano de experiência não te torna sênior. Te torna um estagiário mais confiante, com perguntas melhores e autonomia pra tomar decisões básicas.

E tá tudo bem. Porque engenharia é jornada, não destino.

Agora, se me dão licença, tenho um code review esperando. E sim, ainda reviso o diff três vezes antes de aprovar!