Por muito tempo eu tratei esse assunto como uma espécie de teste social da nossa área, uma coisa meio caricata, meio exagerada, quase como se fosse mais marketing do que engenharia. Eu olhava para a obsessão por algoritmos e pensava que muita gente estava superestimando isso, principalmente quando comparado com o que eu sempre considerei mais útil de verdade: construir sistema, entender contexto, desenhar solução, tomar decisão com responsabilidade.
Só que, com o tempo, fui percebendo que muita da nossa segurança vem do contexto em volta do problema. Quando já existe framework, padrão, stack e um caminho mais ou menos esperado, a gente ganha velocidade quase sem perceber. A diferença aparece quando esse contexto some e sobra só o problema, pelado, sem trilha pronta e sem nada para se apoiar.
E aí começou a ficar claro para mim que uma coisa é entregar feature dentro de um contexto conhecido, outra coisa é sentar na frente de um problema que não vem com roteiro nenhum e ter que pensar de verdade antes de escrever qualquer linha.
Eu já critiquei LeetCode porque sempre achei que system design era uma medida mais honesta de maturidade. E eu também passei muito tempo vendo gente, muitas vezes acima de mim, tratar árvore, grafo, travessia ou otimização como se isso fosse overengineering, quando na verdade o problema estava sendo lido pela camada errada. O que faltava não era só resolver, mas entender a origem teórica da solução e a forma certa de abordar aquilo desde o começo.
Foi aí que eu comecei a perceber, na prática, que entrevista técnica não perdoa improviso. E eu digo isso também com a experiência de ter entrevistado outras pessoas tecnicamente, não só de ter passado por esse lado da mesa. Para cargos mais seniores, especialistas ou de gestão técnica, a conversa sobe de nível rápido: não adianta muito ter segurança para falar de arquitetura, produto ou stack se, na hora do problema, o raciocínio não se sustenta. Quando o exercício sai do trivial, sobra pouca margem para discurso bonito.
a realidade da entrevista técnica
Isso ficou ainda mais claro depois de experiências bem concretas. Teve um processo na Amazon em que eu fiquei mais de duas horas olhando para um problema que eu nem sabia que existia, e teve um processo na Uber em que eu cheguei muito perto de fechar os desafios, mas não o suficiente dentro do tempo que tinha. E eu não trago isso como derrota, mas como evidência de que existe um tipo de raciocínio que só aparece quando o problema te obriga a ler além da superfície. Às vezes eu até resolvia parte, às vezes chegava perto, mas o ponto nunca era esse. O ponto era perceber que eu ainda não dominava, com a mesma naturalidade, o tipo de pensamento que a plataforma estava cobrando.
Durante boa parte da minha carreira eu vi muita gente, inclusive eu em alguns momentos, deixar algoritmo e teoria de lado porque a pressão do mercado sempre empurra todo mundo para o que é mais vendável, mais rápido e mais imediatamente útil. Quando você passa muito tempo só no que entrega resultado imediato, começa a faltar repertório para ler com calma os problemas que exigem mais do que repetição. É por isso que livros como o Cormen continuam sendo fundamentais, mesmo que muita gente nunca tenha coragem de encostar neles. E também é por isso que existem portas de entrada mais amigáveis, como Grokking Algorithms (livro do ratinho), que ajudam a começar sem assustar tanto, ainda que não substituam a profundidade dos textos mais clássicos.
No fim, eu fui entendendo que LeetCode não é um julgamento de valor, mas um treino muito específico de raciocínio. Ele força a pessoa a pensar em padrão, custo, memória, estrutura de dados, estratégia e, principalmente, em como justificar uma escolha. Se eu não consigo explicar por que uma solução funciona, eu ainda não entendi completamente o que fiz.
Foi por isso que eu decidi transformar isso numa série. Eu quero documentar a minha jornada com mais direcionamento e, ao mesmo tempo, ajudar outras pessoas que estejam no mesmo caminho. A ideia é registrar o processo inteiro e compartilhar o que eu for aprendendo em blogposts, vídeos e no próprio repositório algorithm-solutions.
o mercado está uma merda
Então sim, eu vou assumir esse rant. Se a alternativa é continuar preso numa sequência de ATS, triagem automática e filtros cada vez mais opacos, talvez faça mais sentido eu me preparar para um processo onde minhas capacidades apareçam de forma mais direta. No fim, eu prefiro depender do que eu realmente consigo pensar e resolver do que ficar à mercê da determinação de uma IA qualquer.
ser nerdão é parte do jogo
Tem outro lado nisso tudo que eu gosto de admitir sem vergonha: eu gosto de ser nerdão. Eu gosto dessa sensação de pegar algo que parece simples e ir fundo o suficiente para mostrar que existe mais ali do que a primeira leitura entrega. É isso que melhora a qualidade da solução e a profundidade com que eu enxergo problema.
Se eu vou falar de LeetCode, eu quero falar direito. Do jeito que eu gostaria de ter lido quando ainda estava apanhando desses problemas. Se você também estiver nessa caminhada, fica por aqui que eu vou documentar o processo.