Blog

Me pediram para falar com a minha turma de Engenharia da Computação sobre como é o meu trabalho hoje e sobre o que a IA mudou nele. Eu estou me formando agora, com umas três décadas de atraso em relação ao resto da sala, então foi uma conversa com os meus colegas e não para eles. Este texto é o que sobrou daquela conversa.

Antes de qualquer coisa: eu uso IA para programar todos os dias. Isto aqui não é um texto contra IA.

Sistemas sempre existiram

Antes de falar de IA eu preciso falar de sistema, que é uma palavra que a gente repete o dia inteiro sem nunca parar para definir. Um sistema é um conjunto de partes que se relacionam para produzir um comportamento que nenhuma delas produz sozinha. Ele tem entradas, tem regras que transformam essas entradas em alguma coisa, e quase sempre tem uma volta, porque o resultado de hoje vira a condição de entrada de amanhã. E ele tem um propósito, que nem sempre é o que está escrito no papel: o propósito de verdade é aquele que o comportamento do sistema entrega.

Repare que não tem computador nenhum nessa descrição. Essa ideia não é minha. Eu ouvi isso pela primeira vez do meu primeiro professor de análise de sistemas, na escola técnica, e demorei uns bons anos para entender o tamanho do que ele tinha dito — já escrevi sobre ele aqui. Ele dizia que análise de sistemas não é sobre computadores, é sobre sistemas, e que eles sempre existiram e sempre vão existir, com ou sem a gente por perto. Primeiro você analisa, entende e descreve o sistema. Depois, eventualmente, você é chamado para melhorá-lo. Algumas dessas melhorias podem consistir em automatizar etapas, e só nesse momento, como uma das opções de automação, a computação pode entrar como ferramenta. Pular direto para o computador tem nome: automatizar a burocracia. Vá num cartório e conte quantos computadores tem lá dentro.

O mercadinho do bairro é um sistema desses, e é o exemplo que eu usei com a turma. O cliente leva o que precisa, o dono anota na caderneta, existe uma regra sobre quem pode comprar fiado e até quanto, a dívida vai acumulando e no fim do mês tem o acerto. As partes são o dono, o cliente, a caderneta e a regra do fiado; o comportamento que emerge dessas partes juntas é uma linha de crédito, com análise de risco e tudo, só que sem banco, sem contrato e sem nenhum computador.

Esse sistema funciona muito bem enquanto o dono conhece todo mundo pelo nome. Com trinta clientes, ótimo. Com três mil, ele não sabe mais quem está devendo, e aí alguém propõe um relatório de saldos, um aviso de vencimento, uma lista de inadimplentes, um bloqueio no caixa na hora da compra. Nenhuma dessas melhorias nasceu de uma tecnologia. Todas nasceram de entender como o fiado funciona.

Três crachás

Quando eu comecei a trabalhar, o mercado contratava Digitador, Programador e Analista de Sistemas. Três profissões, três salários. O analista entendia o problema e escrevia a especificação, o programador escrevia o código a partir dela e o digitador passava aquilo para o computador.

Nos anos 90 o mercado juntou as funções no cargo de “Analista Programador”. Dois trabalhos, um salário, e a profissão de analista sumiu do crachá sem sumir do trabalho. A pergunta que eu faço para a minha turma é outra: depois dessa fusão, qual das duas metades a gente passou a treinar de verdade? A de escrever código. É isso que a faculdade cobra, é isso que o teste técnico mede, é isso que o GitHub mostra.

E agora apareceu uma ferramenta que faz exatamente o papel do programador antigo: recebe uma especificação e devolve código. Rápido, barato e sem reclamar do prazo.

Então a pergunta vira: quem escreve a especificação?

O mercadinho vai pra internet

Peguei esse mesmo mercadinho e propus para a turma que ele passasse a vender pela internet. A escala muda, o dono não conhece mais o cliente nem sabe onde ele mora, e o fiado vira crediário com cartão, parcelamento e Pix. Como a gente modelaria esse sistema?

A primeira resposta é sempre a mesma, e é a resposta que eu também daria: cliente, produto, carrinho, pedido. Depois alguém lembra de pagamento, entrega e estoque. Parece simples.

Aí a gente começa a perguntar.

Catálogo. A camiseta azul tamanho P e a azul tamanho G são o mesmo produto? Se dois vendedores oferecem a mesma camiseta, é o mesmo produto? O site vende produtos, afinal? Não vende. Ele exibe anúncios de itens (SKUs) de produtos de marcas, e cada uma dessas palavras significa uma coisa diferente para o estoquista, para o vendedor e para o marketing. Eu já contei naquele outro texto que caí nessa armadilha todas as vezes que modelei um e-commerce. Foram três. Caí nas três.

Carrinho. Carrinho é um pedido? Se o preço mudar amanhã, qual preço vale? O carrinho é intenção e o pedido é compromisso, então o preço do pedido é uma fotografia do momento da compra e não uma referência ao preço atual da oferta. E se o produto acabar enquanto ele está no carrinho?

Frete. Quem paga? A loja, o vendedor, a transportadora? Frete grátis não existe, alguém sempre paga. E tem a promoção clássica: frete grátis acima de cem reais. Guarde essa regra. Ela volta.

Estoque. Tem uma unidade e dois compradores no checkout ao mesmo tempo. No balcão do mercadinho, quem pegou primeiro levou. Na internet, os dois estão com a mão no produto. Quando reservar o estoque: no carrinho, no checkout, no pagamento? A reserva expira? E quem perdeu, como descobre? Vender sem estoque tem nome, overselling, e às vezes é bug e às vezes é decisão de negócio.

Pagamento. Autorização não é captura. A autorização reserva o limite no cartão, a captura efetiva a cobrança. Autorizo no checkout e capturo no envio? E se a autorização expirar antes de o produto sair? Se o cliente dividir em dois cartões e o segundo negar, alguém precisa cancelar a autorização do primeiro. O pedido tem um pagamento ou vários?

Entrega. Cinco itens, três vendedores, dois centros de distribuição. Um pacote foi entregue e o outro está em trânsito. Qual é o status do pedido? Aquela máquina de estados bonitinha, novo, pago, enviado, entregue, não serve mais: “enviado” é um estado do pacote, e o status do pedido passa a ser derivado dos pacotes.

Pós-venda. Comprei cinco itens em dois pacotes e quero trocar um. Troca é devolução mais um envio novo? Quem paga a logística reversa? Dá para estornar parcialmente um valor que já foi capturado? E, finalmente, a regra do frete grátis volta para cobrar: se a devolução derruba o pedido para noventa reais, o frete que foi dado de graça continua de graça? O Código de Defesa do Consumidor ainda garante sete dias de arrependimento depois do recebimento, então esse fluxo inteiro roda ao contrário também.

Quando eu olho para o desenho que sobra no quadro depois dessa conversa, ele não lembra em nada as quatro caixinhas do começo. E vale reparar em uma coisa: foram quinze minutos de modelagem e ninguém encostou num computador.

A IA trabalha com o problema descrito

Quantas dessas perguntas estariam no seu prompt?

Um agente escreve o código de um carrinho de compras em segundos, e escreve bem. Ele não vai perguntar sobre o frete grátis que quebra na troca, porque você não contou que existe frete grátis, nem que existe troca. O prompt descreve as peças. O problema mora nas conexões entre elas.

Isso não é uma característica da IA, é uma característica de sistemas. Tirar uma peça de um sistema costuma mudar pouco; mudar o jeito como as peças se conectam muda tudo. O John Gall escreveu um livro inteiro sobre isso, o Systemantics, e a frase dele que eu mais repito é a de que todo sistema complexo que funciona evoluiu de um sistema simples que funcionava. O código gerado pelo agente não cai no vazio: ele cai dentro de um sistema que já existe, com pessoas, regras, dinheiro e estoque. E quando esse sistema revidar, quem precisa entender o porquê é você.

Não vou repetir aqui o que já escrevi sobre o gargalo ter se deslocado de escrever para compreender e validar, nem sobre a dívida de compreensão que esse volume de código cria. Isso está no texto sobre agilidade em tempos de IA.

Como é o meu dia

Eu desenhei para a turma o ciclo que eu percorro em qualquer trabalho: entender o problema, refinar as histórias de usuário, propor alternativas de solução, detalhar as tarefas, produzir a solução, revisar e testar, entregar e monitorar. Aí volta para o começo.

O que a IA mudou nesse ciclo foi um pedaço no meio. De detalhar as tarefas até a entrega eu trabalho em par com um modelo, e trabalho bem. As duas pontas continuam comigo: entender o problema do cliente, refinar, propor alternativas, decidir o que monitorar depois que foi para produção. As pontas são exatamente o que a gente fez no exercício do mercadinho.

Antes de passar a bola para o agente eu preciso ter três coisas escritas: a intenção (o que eu quero), as restrições (o que não pode acontecer) e o critério de sucesso (como eu vou saber que deu certo). O frete grátis acima de cem reais é uma restrição. Se eu não consigo escrever isso, eu ainda não entendi o problema, e nenhum modelo vai entender por mim.

Também continua valendo a parte chata: a IA escreveu, mas quem entregou fui eu. Quando der errado em produção às três da manhã, “foi a IA que escreveu” não é resposta.

E quem está aprendendo agora?

Essa é a parte que me preocupa, e é por isso que o convite para falar com a minha turma me interessou.

Programação é uma atividade de prática deliberada. Eu repito isso neste blog há vinte anos, bem antes de existir agente nenhum: você não aprende a programar sem programar, do mesmo jeito que não aprende caratê lendo um livro de caratê. O problema é que agora existe uma ferramenta que entrega o resultado sem exigir a construção. Livro, aula, fórum e Stack Overflow davam insumo e você ainda montava; o agente monta.

E isso é medido. Um estudo da Anthropic (o paper está aqui) colocou desenvolvedores para resolver uma tarefa com uma biblioteca Python que eles não conheciam. Quem usou IA pontuou 17% menos no quiz de compreensão depois, sem ter terminado a tarefa significativamente mais rápido. A maior diferença entre os grupos apareceu nas perguntas de depuração, que é justamente a habilidade de reconhecer que o código está errado e descobrir por quê. Ou seja: a habilidade que mais cai é a mesma que você precisa ter para supervisionar o que a máquina produz.

O mesmo estudo mostra o outro lado. Os grupos que perguntaram conceitos antes de codificar, ou que pediram explicação do código gerado, aprenderam. É a mesma ferramenta, e o que decide o resultado é o processo em volta dela. A regra que eu uso com quem entra no time é essa: peça para a IA explicar, perguntar e revisar, mas não peça para ela fazer o que você ainda não sabe fazer. É a calculadora na aula de cálculo. Ninguém aprende derivada no Wolfram Alpha, aprende na mão, e depois usa a ferramenta pelo resto da vida. A ferramenta nunca foi o problema. A ordem é.

Três perguntas

Eu fechei a conversa com três perguntas que servem para qualquer momento da carreira, e que eu faço para mim mesmo com uma frequência razoável:

• Nesse problema, eu estou construindo ou assistindo?
• Se a ferramenta sumisse amanhã, eu ainda saberia fazer isso?
• Eu consigo explicar por que funciona, ou só que funciona?

Quem programa hoje? Em boa parte, a IA. Quem programará? Quem entender o sistema, fizer as perguntas que ninguém fez e responder pelo resultado.

Deixei de fora um monte de coisa que caberia aqui: spec-driven development e o risco de ele virar Waterfall disfarçado, o que acontece com o code review quando a máquina escreve e a máquina revisa, e o que vira a definição de pronto nesse cenário. Parte disso está no texto sobre agilidade, o resto fica para depois. Para quem quiser puxar o fio da análise de sistemas, os três livros que eu indicaria são o Pensando em Sistemas da Donella Meadows, o Systemantics do John Gall e o Domain-Driven Design do Eric Evans.

Eu me considero “agilista” desde os tempos do RUP. Sim, aquele RUP: iterativo no papel, mas tão cerimonioso que precisava de um documento para explicar os outros documentos. Foi a minha porta de entrada para a ideia de que software se constrói em ciclos, e de lá para cá acompanhei o Manifesto Ágil virar Scrum, Scrum virar “Scrum, mas…”, e Kanban virar a coisa que a gente faz quando cansa de Scrum.

Agora tem um agente de IA sentado na minha mesa escrevendo código mais rápido do que eu consigo ler. E a pergunta que não sai da minha cabeça é: os rituais que eu defendi durante vinte e tantos anos ainda fazem sentido?

Para responder isso eu precisei de um modelo mental e de uma volta no tempo. Tenha paciência comigo.

Quatro pontas de um diamante

O Harold Leavitt, lá em 1964, descreveu uma organização como um diamante com quatro pontas: estrutura, tarefas, pessoas e tecnologia. O detalhe importante do modelo não são as pontas, são as setas entre elas. Está tudo interligado: mexeu numa, as outras se mexem junto, querendo ou não.

Em desenvolvimento de software a gente costuma simplificar isso para um triângulo de pessoas, processos e tecnologia. É nesse triângulo que a nossa conversa acontece. A IA mexeu, e muito, na ponta da tecnologia. Não dá para fingir que as outras duas vão ficar paradas no lugar. E como as pessoas continuam sendo as mesmas (por enquanto), a ponta que mais vai sentir o tranco é a dos processos.

E processo, em software, sempre foi uma história sobre uma coisa só.

Sempre foi sobre feedback

Em 1959 a gente (a gente = programador e não eu, que nem era nascido 😛) programava em COBOL no estilo code and fix, sem método nenhum. Deu tão certo (#sqn) que em 1968 a OTAN precisou convocar uma conferência para inventar o termo “engenharia de software” e tentar colocar ordem na bagunça. Veio o Waterfall em 1970, o Modelo Espiral do Boehm em 1988, o RUP em 1999 e, em 2001, o Manifesto Ágil como reação a tudo isso.

Se você olhar essa linha do tempo de longe, percebe que ela conta uma história só: a briga contra o feedback tardio. O Waterfall congelava requisitos no início e só descobria que estava tudo errado na homologação, quando mudar ou corrigir alguma coisa custava uma fortuna. O Boehm desenhou uma curva mostrando que o custo de mudar cresce exponencialmente conforme o projeto avança: uma correção barata na fase de requisitos vira um pesadelo em produção. O Ágil foi, essencialmente, a decisão de encurtar os ciclos para pegar os erros enquanto ainda estavam na parte baixa dessa curva.

Guardem essa curva. Ela vai voltar.

O gargalo mudou de lugar

Durante toda a história que eu contei acima, escrever código era a parte lenta. Revisar era rápido, testar era relativamente rápido, discutir em reunião era… bom, reunião é reunião. Mas o trabalho pesado ficava na digitação. Estimativas, sprints de duas semanas, story points, tudo isso foi calibrado para um mundo em que o esforço de produzir era o esforço dominante.

O Armin Ronacher chamou o que aconteceu de “The Final Bottleneck”: a IA inverteu a relação e agora escrever é mais rápido do que revisar. O Avery Pennarun (apenwarr) foi mais longe e argumentou que cada camada de aprovação multiplica o tempo por 10, porque a IA acelera a produção mas não acelera a revisão. E não é só impressão: o relatório da Faros AI sobre o “paradoxo da produtividade” mostra quase o dobro de PRs abertas e o tempo de revisão crescendo na mesma proporção. Produzimos mais e entendemos na mesma velocidade de antes.

Aí vem a provocação: se um agente implementa uma feature em duas horas e a revisão leva cinco, o que exatamente estamos estimando no planning? A pergunta “quanto tempo para implementar?” perdeu relevância. A pergunta que importa virou “quanto tempo para garantir que isso está correto?”. Tem gente na AWS defendendo que o sprint planning deveria evoluir para algo como intent design: em vez de estimar tarefas, o time define intenção, guardrails e critérios de sucesso, e deixa a implementação para quem agora é rápido nela. Eu não sei se o nome vai pegar, mas a ideia de que o planning deixa de ser sobre esforço e passa a ser sobre intenção me parece certa.

Vale lembrar:

“Computadores são inúteis, eles só sabem dar respostas”. — Pablo Picasso

Se a IA dá respostas muito rápido o trabalho de fazer as perguntas certas e conferir se a resposta faz sentido continua sendo nosso, e ele não ficou nada mais rápido.

A curva de custo, de novo

Voltemos à curva do Boehm. Eu sempre gostei do argumento de que pair programming é a forma mais barata de revisão que existe, porque a validação acontece no exato momento em que o código nasce, lá na parte baixa da curva. O code review tradicional acontece bem mais à direita, quando a mudança já está pronta e o autor já foi fazer outra coisa.

Com IA, o “par” passou a ser humano mais agente, e o custo desse pareamento é praticamente zero. A dinâmica inverteu: o humano vira o navigator permanente (revisa, direciona, decide) e o agente vira o driver (digita, implementa). O Kent Beck chama isso de augmented coding: você escreve o teste, a IA gera a implementação, você valida. A validação é reposicionada no ponto mais barato da curva. Para mim esse é o ponto de virada de toda a discussão.

O problema é o que acontece do lado direito da curva. Se o volume de código gerado é impossível de revisar no ritmo em que chega, o revisor cai no dilema que chamam de cognitive debt: ou mantém o rigor de antes e vira o gargalo do time, ou aprova no ritmo que o código aparece e torce para os testes pegarem o que a revisão deixou passar. Nenhuma das opções é boa.

E aqui tem uma coisa que a gente costuma esquecer: code review nunca foi só sobre achar defeito. Era o jeito de distribuir conhecimento sobre o codebase, alinhar decisões de arquitetura, fazer sêniors ensinarem júniors e vice-versa. Era o jeito de manter um modelo mental (aka contexto) compartilhado de como o sistema funciona. Se a máquina escreve o código e a máquina também revisa, quem é responsável? E, mais importante, como o time aprende? Aquela ideia de collective code ownership do XP não se sustenta se ninguém do time leu o código.

E o “como o time aprende” não é preocupação de um programador velho rabugento gritando para a nuvem. Um estudo da Anthropic sobre formação de habilidades com IA mostrou que quem delega passivamente (pede o código, cola, segue em frente) sai com menos de 40% de compreensão do que foi feito, enquanto quem usa a IA para investigar conceitos passa dos 65%. A mesma ferramenta produz um profissional que aprende ou um que só delega, dependendo de como o processo em volta dela é desenhado. Mais um cenário onde o processo pode se tornar um problema.

Isso muda até a definição de pronto. “Done” deixou de ser “funciona e passou nos testes” e passou a ser “funciona, eu entendo por que funciona e sei o que monitorar”. O Casey West, no Agentic Manifesto, descreve como a passagem de verificação (fez o que eu disse?) para validação (fez o que eu queria?). E o pessoal da Mozilla AI aponta que a nossa cultura sempre ligou ownership a autoria; a IA quebra esse vínculo, e agora você precisa ser dono de algo não porque você escreveu aquilo mas porque você entende aquilo.

Pelo mesmo raciocínio, o WIP limit do Kanban precisa mudar de dimensão. Não adianta limitar quantas tarefas estão “em andamento” se um agente consegue mover dez delas para essa coluna ao mesmo tempo. O limite relevante virou “quantas mudanças o time consegue entender simultaneamente”. O projeto OpenClaw, com suas 2.500 PRs abertas, é o que acontece quando a entrada cresce mais rápido que a capacidade de processar: uma falha acumulativa.

O que levar desses questionamentos?

A IA não torna os processos obsoletos. Ela torna os processos errados mais perigosos, porque agora o erro é produzido em escala industrial.

O gargalo se deslocou de escrever para compreender e validar, e os rituais precisam acompanhar esse deslocamento. A daily deixa de ser “o que eu fiz” e passa a ser “o que eu entendi sobre o que foi feito”. A retrospectiva, que sempre foi o ritual mais negligenciado, virou na minha opinião o mais importante de todos: é o único momento formal em que o time para e pergunta “qual código gerado a gente não entende? que decisões técnicas o agente tomou sem a gente validar?”.

Também vale um alerta. Tem gente dizendo que documentação e specs agora importam mais que o código, porque viraram o insumo do agente. Pode ser. Mas se a resposta para tudo for “escreva uma spec bem detalhada antes de começar”, cuidado: isso tem nome, e o nome é Waterfall. Mais spec na frente não é sinônimo de mais controle. O que separa uma spec útil de um documento de requisitos de 1970 não é o tamanho dela, é o tamanho do ciclo até o primeiro feedback: se a spec alimenta um agente que devolve algo testável em uma hora, ótimo, isso é Ágil com outra ferramenta; se ela precisa estar “completa e aprovada” antes de qualquer código existir, é a curva do Boehm de novo, só que com um capítulo novo. Vinte anos para matar o Waterfall e seis meses para a IA trazê-lo de volta seria um final meio irônico para essa história.

O Ágil precisa evoluir, não ser abandonado. E o jeito mais barato de começar é o mesmo de sempre: revisando as suas práticas, uma por uma, e perguntando se elas ainda estão otimizando o gargalo certo.

Deixei de fora várias práticas que também merecem essa revisão (TDD, CI/CD, prototipação, demos, refactoring) desse texto porque ele já entrega o ferramental para refatorar os seus processos. Uma lista mais extensa pode ser encontrada nos slides da minha apresentação na Codecon 2026.

Artigo baseado na apresentação feita durante a PythonBrasil 2025 em São Paulo.

Por Que Isso Importa

Dominar processos seletivos é uma habilidade específica — e essa habilidade não tem nada a ver com trabalhar. Você pode ser um excelente profissional e ser péssimo em processos seletivos, e vice-versa. São competências distintas.

As coisas são como são

Esse texto não vai tentar idealizar o assunto. Os processos seletivos são injustos, falhos e desgastantes e nós, candidatos, sempre estamos na situação mais vulnerável.

Aceitar isso é o primeiro passo. O jogo tem regras, e conhecê-las é a sua vantagem.

Marketing & Venda

No processo seletivo o produto é você. E como qualquer produto, ele precisa ser bem posicionado e bem apresentado.

Durante um processo seletivo, o candidato precisa demonstrar interesse genuíno pela vaga (nem que seja pelo salário), que se preparou para aquela oportunidade específica, que tem as habilidades necessárias para o trabalho, que vai entregar o que é esperado, que cresce continuamente, e que sabe trabalhar com pessoas.

Cada ponto desses não precisa ser declarado explicitamente, precisa transparecer na sua postura e nas suas respostas ao longo de todo o processo.

Todo processo seletivo envolve muitas pessoas e uma característica humana importante é a de gostar de ouvir histórias. Por conta disso, uma forma bastante efetiva para trabalhar o seu marketing e seu processo de vendas é o storytelling.

Se você conseguir embalar suas qualidades, suas limitações e seus diferenciais dentro de boas histórias, as suas chances aumentarão absurdamente.

A Preparação

Existe uma expressão antiga que diz:

“Me dê seis horas para derrubar uma árvore e eu passarei as quatro primeiras afiando o machado.” — Abraham Lincoln(?)

Todo bom profissional precisa investir tempo na preparação. Uma boa preparação poupa muitas dores de cabeça e frustrações na nossa carreira e não é diferente para encarar uma jornada de processos seletivos.

“Cabeça”

O ponto mais importante de toda a preparação é mental: prepare-se para ser rejeitado. Processos seletivos são, na prática, um teste da sua capacidade de lidar com rejeição. O processo inteiro é feito de rejeições, afinal, quando você para de ser rejeitado é porque o processo está terminando.

A minha dica é tentar encarar cada “não” como “alguma outra pessoa tinha uma correspondência melhor com essa vaga”, não como “você é incapaz”. Você não é um conjunto de habilidades laborais. É uma dica mais fácil de oferecer do que praticar mas com o tempo você vai ficando melhor nisso.

Currículo e Presença Online

Tenha um Curriculum Vitae base genérico (ex. “Desenvolvedor Backend”), sem nível hierárquico, de uma ou duas páginas, focado no seu principal ponto forte, com contatos e sem firulas. Esse CV servirá de base para ser adaptado conforme a vaga.

Seu perfil no LinkedIn deve estar em Português e Inglês, com as experiências descritas usando a Técnica STAR (mais sobre ela abaixo). Complete o perfil com um hub de redes sociais profissionais como site pessoal e perfil no GitHub. Lembre-se de manter somente conteúdo profissional nessas redes. Política eleitoral, futebol e tretas ficam fora.

Não é obrigatório mas pode ser adequado fechar o seu perfil em suas redes sociais pessoais durante essa etapa. Não é incomum que recrutadores dêem uma espiada nas redes sociais pessoais dos candidatos. Eu sei que isso não é legal e não deveriam influenciar na sua candidatura mas, como eu disse, as coisas são como são e (ainda) não é o momento de lutar para mudá-las.

Técnica STAR para Descrever Experiências

A Técnica STAR é a forma mais eficaz de descrever experiências técnicas, tanto no LinkedIn quanto em entrevistas. A sigla representa Situação, Tarefa, Ação e Resultado:

• Situação: O sistema de deploy da empresa era manual e causava erros frequentes.
• Tarefa: Automatizar o processo para reduzir falhas e tempo de entrega.
• Ação: Implantei um pipeline de CI/CD no GitHub Actions com testes automatizados e integração ao Cloud Run.
• Resultado: O tempo de deploy caiu 70% e os incidentes pós-release reduziram em 90%.

O padrão funciona porque força você a contextualizar o problema, mostrar sua contribuição concreta e quantificar o impacto, exatamente o que um recrutador ou entrevistador quer ouvir.

Carta de Apresentação

Tenha um modelo de carta de apresentação pronto para ser personalizado. Um modelo eficaz é simples e direto:

Olá [nome do(a) recrutador(a)],

Meu nome é [...] e estou entrando em contato sobre a vaga [...] pois acredito que tenho as habilidades necessárias para contribuir com a [nome da empresa] no desenvolvimento de produtos como [lista de produtos
que você buscou no site da empresa].

Gostaria de participar do processo seletivo e ter a oportunidade de descrever minha experiência em [lista de experiências específicas relevantes para a vaga].

Em anexo segue meu CV e meu perfil no LinkedIn pode ser visualizado em [...].

Obrigado,
[seu nome]

Organizando os Processos

Mantenha um Kanban com as colunas Vaga, Contatado, Em Processo, Resultado. Em cada card, registre o link da vaga e o nome do contato.

Use uma agenda dedicada exclusivamente para compromissos de processos seletivos e nunca deixe uma entrevista passar despercebida. Perder a hora de uma entrevista pode ser fatal.

Equipamento para Entrevistas Remotas

Mesa, cadeira e computador: nada de celular.

A máquina deve estar estável (nada de software Alfa/Beta), com terminal e navegador abertos e prontos para uso, ou seja, esteja com o machado afiado e pronto para a ação mesmo se tentarem te pegar de surpresa.

A câmera deve estar posicionada na frente ou levemente acima do rosto, para que você olhe o recrutador nos olhos.

A iluminação deve ser direta para o rosto. A luz natural de uma janela funciona bem mas não descarte a possibilidade de uma iluminação dedicada.

Para o áudio, use microfone, fone ou headset com fio: bluetooth acabando a bateria no meio da entrevista é constrangedor.

Mantenha um fundo limpo ou um background virtual estático e neutro. Se tiver um fundo que deixe alguns hobbies aparentes tudo bem. Mas lembre-se: esses elementos do fundo podem causar distração no recrutador e tirar ele do que realmente importa: você.

Entre na sala de reunião alguns minutos antes e teste imagem e som. Tenha papel e caneta à mão para anotar perguntas.

A Prospecção

Onde Buscar Vagas

O LinkedIn, ao menos para programadores, continua sendo a fonte mais eficaz. O plano Premium ajuda, mas mesmo sem ele dá para filtrar boas oportunidades. Em seguida vêm os sites de vagas, depois networking e eventos, e por último indicações.

As vagas por indicações geralmente têm as melhores chances mas infelizmente são mais raras.

Tipos de Oportunidades

Nem toda vaga é igual. Eu classifico as vagas em três categorias:

• Vagas dos sonhos: são aquelas onde a empresa, o projeto ou o salário são exatamente o que você quer, mas a aderência às suas habilidades ainda não é total.
• Vagas qualificadas: são muito alinhadas com o que você sabe fazer, mas sem muita empolgação com a empresa ou remuneração.
• Vagas fraudulentas: geralmente são criadas para aplicação de golpes ou criação de base de dados. Fuja delas.

O Processo

Defina um número máximo de processos simultâneos: se estiver desempregado, quatro é um bom limite; se estiver trabalhando, dois. Gerencie tudo no Kanban e revise todos os cards toda manhã.

Nunca se atrase para compromissos, mas esteja preparado para atrasos do recrutador. Sempre mencione que você está em outros processos, mesmo que não esteja. Se estiver empregado, garanta que o recrutador saiba disso também.

Seja transparente com os recrutadores sobre o andamento desses processos e caso tenha algum imprevisto que te impeça de participar de alguma reunião avise o recrutador o mais rápido possível.

A Entrevista

Storytelling

A melhor forma de lidar com uma entrevista é embrulhar ela em uma boa história que descreva a sua jornada com seus avanços, obstáculos, superações, etc. Lembre-se que o recrutador é um ser humano como a gente.

Então, ao interagir com ele, apresente-se profissionalmente e construa uma narrativa de crescimento com as suas experiências. Se for seu primeiro emprego ou uma mudança de área, experiências indiretas também valem.

Respeito também é fundamental. O recrutador é um trabalhador tal como você e não um adversário.

Se você fica nervoso com entrevistas eu recomendo que você treine com um amigo antes de entrevistas importantes e não use LLMs durante a conversa, a menos que o entrevistador peça explicitamente.

Durante a entrevista tem uma regra: não minta. Mas se precisar omitir algo, vá em frente. “Enfeitar” pode 😛

Tenha “portos seguros” preparados para perguntas difíceis. Tenha um bom exemplo de trabalho em equipe, de superação, de aprendizado técnico, de colaboração, de projeto bem sucedido e de projeto fracassado. Quando uma pergunta difícil chegar é só sacar a carta certa e mostrar.

Invente um motivo alinhado com o contratante para o seu interesse na vaga: “preciso pagar as contas” tem que virar “vi que vocês estão trabalhando bastante com a tecnologia X e é exatamente a área em que quero focar minha carreira”.

Nunca fale mal de experiências anteriores. Resignifique essa experiência para algo como “uma experiência importante onde cresci muito com a ajuda do time”. Uma demissão injustificada se transforma em algo que “te deixou triste, pois tinha planos de ficar por muito tempo”.

Tenha também uma explicação natural para períodos de desemprego: estudando um idioma, sabático, empreendendo, etc.

Se for um problema de saúde pode mencionar mas lembre-se que ainda existe muito preconceito com alguns tipos de problemas (principalmente psicológicos/psiquiátricos). É uma merda, eu sei, mas… “As coisas são como elas são”.

Sempre que a entrevista abrir espaço, faça perguntas sobre a empresa. Ao menos uma pergunta para cada área:

• Pessoas: tamanho e perfil do time, organização das equipes, plano de carreira.
• Processos: metodologia ágil, pipeline de tarefas, time de produto.
• Tecnologia: stack, CI/CD, modelo de deploy, testes automatizados, code review.

Red Flags na Entrevista

Alguns comportamentos durante a entrevista indicam uma vaga problemática (aka vaga arrombada):

• Perguntas sobre filhos ou planos para tê-los (especialmente para mulheres)
• Comentários ou perguntas sobre aparência física
• Questões de foro íntimo: relacionamento, moradia, política
• Perguntas sobre saúde
• Histórico de layoffs recorrentes na empresa
• Sinais de precarização do contrato: PJ obrigatório, sistemas de tracking de trabalho, cultura de “trabalho duro” como valor

Se mesmo assim você precisar muito da vaga: omita planos de maternidade/paternidade, use roupa neutra, evite comentar sobre família ou tratamentos. E comece a procurar outro emprego assim que for contratado.

O Teste

Existem diferentes tipos de entrevistas técnicas e dinâmicas de avaliação técnica. Se algumas empresas adotam uma entrevista simples outras poderão pedir para você programar alguma coisa (live coding) ou até mesmo entregar algum projeto completo.

Entrevista Técnica

Tudo o que falamos sobre participar de uma entrevista com um recrutador e a importância de conduzir um bom storytelling se aplica também na entrevista técnica.

Para ter um bom resultado nessa fase é importante que você chegue sabendo tudo sobre as tecnologias usadas pela empresa. Também é importante que você “perceba” o seu entrevistador, por exemplo, programadores podem ser péssimos entrevistadores, ou o entrevistador pode ter menos experiência do que você. Nesses casos é importante que você faça a entrevista render bem. Você precisa ser mais proativo em expor suas habilidades.

Alguns entrevistadores querem ver como você trabalha; outros se importam mais com o seu conhecimento sobre ferramentas específicas.

Em toda a entrevista técnica é importante sempre pensar em voz alta. Mais do que saber sobre as coisas que você já sabe o entrevistador também está avaliando sua capacidade de pensar sobre os assuntos.

Ao longo da minha experiência eu consegui distinguir três tipos de perguntas técnicas nessa fase:

• Perguntas abertas: perguntas tais como “como você modelaria um CRUD de Clientes?” pedem que você percorra um raciocínio, não que chegue a uma resposta perfeita.
• Perguntas fechadas: são aquelas como “o que esse código imprime na tela?”. Elas têm uma resposta certa. Para esse tipo de pergunta é possível responder “não sei, precisaria consultar” sempre que você não souber a resposta.
• Perguntas opinativas: são feitas para saber se suas opiniões estão alinhadas com os valores da equipe, por exemplo, “o que você acha de SOLID?”. A resposta adequada para essas perguntas pedem que você seja genérico e equilibrado: “sei o que é, já trabalhei em projetos que usam e em outros que não. Como em tudo, tem prós e contras.”

Duas respostas curingas que salvam: “Não sei, mas imagino que…” e “Depende, pode me falar mais sobre…”.

Por último é importante evitar polêmicas sobre as escolhas técnicas da empresa, mesmo que eles deem abertura.

Live Coding

Treino é treino e jogo é jogo. Live coding é jogo. Pratique em plataformas como LeetCode, HackerRank, CodeWars ou Advent of Code.

No momento da prova, pergunte se o entrevistador quer ver testes automatizados ou só o código. Se ele pedir testes esteja preparado para escrever testes.

Como eu disse logo acima é importante que você diga tudo o que está pensando e fazendo em voz alta para o avaliador conseguir entender o seu jeito de trabalhar.

Quando estiver trabalhando no problema sempre faça o código funcionar primeiro, mesmo com um algoritmo ingênuo ou ineficiente, para depois tentar otimizar e melhorar. Deixe claro para o avaliador que você vai fazer isso: “vou resolver dessa forma mais simples para garantir que entendi o problema; depois eu otimizo.” Se conseguir explicar a ineficiência em termos de complexidade algorítmica (Big-O), melhor ainda.

Teste de Projeto

Este tipo de avaliação está caindo em desuso, mas ainda pode ser encontrada por aí.

Sempre “cobre” para fazer o teste. Empresas estrangeiras pagam por eles mas se a empresa não paga pelo teste peça que pelo menos você coloque o resultado no seu portfólio pessoal no Github. E fique atento a empresas que usam testes como trabalho gratuito.

Faça somente o que o enunciado pede, ou seja, cuidado com over-engineering. É muito comum que o candidato, por querer mostrar todos os seus conhecimentos de Design Pattern, SOLID, etc encha o código de complexidade desnecessária.

Foque no que é importante e poucas pessoas fazem: documentação, testes automatizados, arquivos de configuração, e padronização de código.

Esse projeto costuma subsidiar alguma entrevista futura então esteja consciente do que você programou e lembre-se que é muito difícil ter essa consciência quando o código foi escrito por um modelo de IA.

Red Flags no Teste

Fique atento a três comportamentos problemáticos durante avaliações técnicas:

• Dogmatismo: “só um modelo/linguagem/arquitetura presta, o resto é lixo” sem uma explicação ou justificativa sólidas.
• Desleixo: desprezo declarado pelas boas práticas de engenharia de software.
• Compartimentação extrema: times ou indivíduos muito segregados em funções específicas, o famoso “super-herói”.

A Negociação

Passadas todas as etapas do processo é chegada a hora da conclusão e da negociação.

Em Caso de Recusa

Agradeça o tempo e a oportunidade e não se esqueça de pedir feedback técnico: “poderia me dizer quais pontos não me qualificaram para que eu possa estudar mais sobre eles?” Pergunte sobre futuras oportunidades: “existe alguma política para aplicar a vagas futuras?”

O objetivo dessas perguntas é simples: registrar que você realmente queria a vaga.

Em Caso de Contratação

Ninguém está fazendo favor para ninguém. O seu trabalho tem valor e precisa ser remunerado adequadamente.

A pretensão salarial é sua.

Diga ela, qualquer que seja. É função do contratante decidir o que fazer com essa informação. Negocie sempre o salário e trate benefícios, bônus, ações/options, e outros adicionais como brindes.

Sobre PJ vs. CLT

Faça as contas direito considerando rescisões, impostos, multas e garantias. Pergunte-se sempre o motivo pelo qual o empregador prefere o risco trabalhista de uma contratação PJ? Porque vai te pagar mais ou porque vai gastar menos?

Se a empresa tiver um orçamento menor do que sua pretensão, negocie revisões salariais preventivamente: “aceito entrar por X, mas quero uma garantia para chegar em Y em Z meses.”

---

Créditos da imagem em destaque: JOB INTERVIEW ..” by Bill Strain, CC BY 2.0

Tem uma anedota que correlaciona o tamanho dos ônibus espaciais à largura da bunda dos cavalos. Se você pesquisar por esses termos vai encontrar várias referências a essa história que, claramente, é uma bobagem.

No mundo da computação a gente tem algumas dessas características que influenciam nossas vidas até hoje. Uma das mais óbvias é o teclado QWERTY que usamos até hoje (aliás, a história das teclas serem afastadas para evitar enroscos também é potencialmente falsa).

Muitos anos atrás, antes mesmo de eu ter sequer nascido, existiam computadores gigantescos chamados mainframes e uns computadores “menores” que eram chamados de minicomputadores.

Apesar de serem “mini” eles ainda eram enormes para os nossos padrões atuais.

Uma coisa interessante dos computadores dessa época é que a gente precisava usar um outro equipamento para interagir com eles: o terminal.

Os primeiros terminais se pareciam muito com uma máquina de escrever ou, para quem não conhece uma máquina de escrever, é só imaginar um teclado montado junto com uma impressora.

Você digitava os comandos para o computador no teclado e esses comandos eram impressos em um papel que vinha de uma espécie de bobina contínua (ou em formulário contínuo com picote, remalina, etc). As respostas do computador também eram impressas nesse formulário.

Para quem se perguntou por que os caracteres ASCII especiais \r se chamam “carriage return” (retorno de carro), \n “new line” (nova linha), entre outros, é porque eles comandavam essa impressora a retornar o carro para a coluna inicial e avançar o papel para uma linha nova em branco.

Com a evolução da tecnologia os terminais foram evoluindo e deixaram de usar papel para usar vídeo e, hoje, textos dentro de uma janela de um aplicativo de… “terminal”.

O sistema operacional Unix (papai do Linux e vovô do macOS) nasceu no mundo dos minicomputadores e foi desenvolvido inicialmente com terminais convencionais chamados de teletype (teletipo).

O Unix mapeia os dispositivos em arquivos. E o arquivo para mandar informações de/para um terminal TTY (teletype) é /dev/tty até os dias de hoje mesmo usando um terminal dentro de uma janela do nosso ambiente gráfico.

Nessa mesma época os usuários do Unix precisavam editar arquivos para fazer coisas básicas como, por exemplo, programar. O editor que eles usavam era o editor (sim, eles eram pouco criativos para nomes).

Imagine que em um teletipo não tem o conceito de navegar com um cursor pelo texto. Toda a edição era feita através de comandos para o ed.

Uma das coisas que todo editor precisa oferecer é uma ferramenta de busca de texto em um arquivo inteiro. Para fazer uma operação em um arquivo inteiro no ed eles usavam o comando g (global).

Para fazer uma busca de um texto não tem nada mais poderoso do que usar uma expressão regular (sim, elas já existiam naquela época). Então a gente delimitava uma expressão regular com um par de barras: /.../. Por último, a gente precisava instruir o ed sobre o que fazer quando ele encontrava o texto procurado. Uma ação comum era pedir pro ed imprimir a linha, ou seja, (print).

Então recapitulando os passos ficaria: global, /regular expression (re)/, print.

g/re/p

Se precisasse fazer isso na linha de comando, que nome eu daria para esse comando? grep!

E se eu precisasse aplicar comandos do ed em um stream de texto ao invés de só interagir com um arquivo? Eu criaria um stream editor ou somente sed.

Como vocês puderam ver, decisões de muitos anos atrás ainda influenciam o nosso dia a dia até hoje.

Eu sempre detestei aprender línguas. Só me esforço para aprender o básico de um idioma quando realmente não há outra forma de sobreviver sem ele. Foi assim que acabei aprendendo o suficiente de inglês e português.

Lembro que, na escola, eu odiava as aulas de português. A única parte que eu realmente curtia era Literatura. Todo o resto era um verdadeiro martírio.

Mas o destino, com seu senso de humor peculiar, colocou meus dois professores de português como vizinhos de muro. Em anos pares, eu tinha aula com uma professora; em anos ímpares, com um professor.

Como eu sempre ficava de recuperação nessa matéria, minha mãe acabava pagando aulas particulares — com o professor do outro ano. O resultado? Eu tinha o dobro de aulas de português com os dois vizinhos ao longo do ano inteiro.

Por conta disso, acabei aprendendo algumas coisas “úteis completamente inúteis”. Por exemplo, sei que toda paroxítona terminada em ditongo crescente era acentuada, mas que, com a nova reforma ortográfica, isso deixou de ser verdade. Se antes “idéia” tinha acento, agora não tem mais.

Outra coisa que aprendi, à base de muita dor e sofrimento, foi análise sintática. Toda aquela parte que disseca as sentenças e mostra como elas são compostas: os sujeitos e predicados, os verbos com suas “transitividades”, os objetos, e por aí vai. Tudo isso foi entendido, ainda que sem compreender o mais importante: por que, afinal, eu estava aprendendo isso?

Nessa época, eu já sabia programar e até tinha começado a trabalhar profissionalmente com programação (sim, comecei bem antes da lei permitir). Mesmo assim, eu não conseguia “conectar os pontos” e enxergar as relações entre a gramática e a programação.

Programação

Programar é comunicar. E, para comunicar, precisamos de uma linguagem comum entre todos os envolvidos no processo.

Ao longo dos anos, a computação desenvolveu uma infinidade de linguagens de programação, cada uma com suas próprias características e propósitos. Essas linguagens facilitam a comunicação entre programadores e computadores, além de permitir que os programadores se entendam entre si.

Por exemplo, qualquer programador que conheça Python e um computador com um interpretador Python será capaz de entender e executar códigos escritos nessa linguagem.

Assim como os idiomas e linguagens naturais, as linguagens de programação possuem gramática. Elas se preocupam com sintaxe, semântica, pragmática, entre outros aspectos que fazem parte do estudo das línguas. Além disso, também possuem um léxico e vocabulário próprios que, se não estão estritamente sob o guarda-chuva da gramática, fazem parte do domínio linguístico.

Python, assim como muitas outras linguagens de programação, é uma linguagem imperativa. Isso significa que você escreve comandos para instruir “como” as coisas devem acontecer. Nesse paradigma, o foco está em ações e etapas específicas.

Por outro lado, linguagens que seguem outros paradigmas — como funcional, declarativo, lógico ou de marcação — não se preocupam tanto com o “como”, mas sim com o “o quê” deve ser feito.

Aqui é possível traçar um paralelo interessante entre o paradigma imperativo na programação e o modo verbal imperativo na língua portuguesa: ambos lidam com comandos e ordens. No português, a conjugação dos verbos no imperativo é usada para instruir ou demandar ações — exatamente o que fazemos ao escrever código em uma linguagem de programação imperativa.

Tá, e daí?

Se programar é comunicar e usamos linguagens para transmitir algo, será que os conhecimentos de gramática de uma linguagem natural (português, inglês, alemão, etc.) podem ajudar a melhorar o nosso código?

Eu acredito que sim. E, a seguir, vou listar algumas práticas que adoto ao desenvolver meus projetos.

Vale lembrar: estou falando de projetos de software escritos em linguagens de programação imperativas, não de uma obra literária. As sugestões que vou apresentar podem melhorar o seu código, mas provavelmente seriam péssimas escolhas para seu conto, romance ou artigo acadêmico.

Sentenças simples

Escrever sentenças simples facilita a compreensão. A estrutura mais básica de uma sentença segue o padrão:

Sujeito — Verbo — Complemento

O sujeito pode assumir várias formas, mas geralmente é representado por um substantivo (nome/noun). Em linguagens orientadas a objeto, o sujeito é (quase) sempre um objeto. Assim, uma sentença simples em código poderia ser algo como:

objeto.verbo(complemento)  # ou...
objeto.verboComplemento()

Parece óbvio, não? Sim, é básico, mas dito dessa forma, fica claro que os métodos de um objeto devem necessariamente ser verbos, e que os parâmetros passados ao método funcionam como complementos — nos moldes da análise sintática da transitividade dos verbos:

• Verbo Transitivo: Requer um complemento (objeto direto ou indireto) para completar seu sentido.

Exemplo: “Ela comprou um livro.” (complemento: “um livro”).

• Verbo Intransitivo: Não precisa de complemento, pois possui sentido completo por si só.

Exemplo: “Ela dormiu.”

Se o verbo usado no nome do método for transitivo, é importante lembrar que ele exige um complemento para que a ação faça sentido. Essa escolha ajuda a tornar o código mais intuitivo e compreensível.

Single Responsibility

Observe que a sentença usada como exemplo contém apenas um verbo. Mantendo essa estrutura, também garantimos que cada método realiza apenas uma ação:

1 verbo → 1 ação → 1 responsabilidade

Trabalhar dessa forma nos ajuda a garantir que nossos métodos respeitem o Princípio da Responsabilidade Única (Single Responsibility Principle – SRP), que estabelece que cada método ou função deve ter apenas uma responsabilidade clara e bem definida.

Interfaces REST HTTP

Interfaces são um meio de disponibilizar o acesso a componentes do seu sistema. Existem diversos tipos de interfaces que podemos utilizar, e uma delas são as APIs REST, que usam o protocolo HTTP.

O protocolo HTTP trabalha de forma stateless: um cliente faz uma requisição (request) para um recurso/documento/objeto em um servidor, e o servidor retorna uma resposta (response) para o cliente. O formato de uma requisição HTTP é aproximadamente assim:

METHOD /url
Header1: ...
HeaderN: ...

<payload>

Alguns dos METHODs disponíveis são: GET, POST, PUT, PATCH, DELETE, etc. Perceba que todos os métodos são verbos, ou seja, indicam ações requisitando algo do servidor. Seguindo nossa lógica gramatical, podemos inferir que a /url é o complemento (geralmente representado por um substantivo).

Como mencionado anteriormente, é importante manter as sentenças simples, ou seja, com apenas um verbo por requisição. Uma boa interface deveria seguir este padrão:

GET /users/1
POST /users
DELETE /users/c0ffe

No entanto, é comum encontrar requisições que apresentam dois verbos na mesma sentença:

POST /contracts/1/remove
GET /documents/2/cancel

Percebe como isso soa estranho? Casos como esse geralmente aparecem quando a ação envolve processos mais complexos. Por exemplo, cancelar um contrato pode exigir várias etapas, e um simples DELETE /contracts/1 pode não ser suficiente. Quando isso acontece, uma boa prática é transformar o segundo verbo em um substantivo, tratando o processo como um objeto.

Por exemplo, ao invés de usar algo como:

POST /contracts/1/cancel  # verbo + verbo

Eu prefiro reestruturar assim:

POST /contracts/1/cancellation  # verbo + substantivo

Essa abordagem não só torna a requisição mais natural, como também reflete melhor a lógica gramatical e mantém a consistência da interface.