Este post é puramente opinativo. Adoraria saber o porquê discordou de mim!
Em algum momento da minha carreira os testes técnicos deixaram de ser apenas “resolva este exercício de código” e passaram a ser “projete um sistema integrado com múltiplas aplicações”. É o que ficou conhecido no mercado como “System Design”. Depois de tanto bater de cara em entrevistas sobre system design, decidi que era o momento de mudar e me mergulhei de cabeça sobre esse tópico. Naquela época, eu me sentia frustrado por não entender um sistema de ponta a ponta a ponto de conseguir explicá-lo. Ao mesmo tempo, aprender sobre isso e explorar diferentes temáticas me empolgava bastante.
As entrevistas mais comuns sobre System Design envolvem a construção de um sistema escalável e distribuído de ponta a ponta, endereçado com um tema específico. Mas a coisa mais legal dessa avaliação é que não é sobre código: é sobre conceito. Não há linha de código pois o foco está em desenhar uma aplicação de forma conceitual, abrangendo diferentes domínios e camadas — algo extremamente útil no dia a dia profissional. Em alguns casos, esse tipo de avaliação propõe desafios mais genéricos, como “construa uma aplicação de chat” ou “faça uma plataforma de pagamentos”. Em outros, os temas são bem mais específicos, como “crie um serviço de streaming como o Netflix” ou “desenvolva uma rede social como o Twitter”.
Veja bem, não me entenda mal. Todos os outros métodos de avaliação são válidos e, de alguma forma, conseguem demonstrar aspectos importantes das habilidades técnicas do candidato. Meu objetivo aqui não é desmerecer outras abordagens de entrevista técnica — na pior das hipóteses, elas até se complementam. O que quero afirmar é que o System Design extrai o melhor da entrevista — tanto para o recrutador quanto para o candidato. É uma habilidade que quando praticada com frequência, realmente faz diferença.
Mas afinal, por que esse método de avaliação me parece o mais eficaz, justo e confiável? Primeiro, para fundamentar meu ponto, preciso falar brevemente sobre os outros métodos mais comuns do mercado atualmente: teste técnico, leet code e live coding.
O teste técnico tradicional é aquele em que o candidato recebe um projeto para desenvolver em casa, com um prazo determinado. Geralmente envolve a criação de uma aplicação com requisitos específicos, integração com APIs e até mesmo testes automatizados. Embora esse método permita ao candidato demonstrar suas habilidades em um ambiente mais confortável, ele apresenta algumas desvantagens significativas. Em geral, exige uma dedicação excessiva, já que se espera algo robusto em função do tempo “em casa”. Há também uma dificuldade de avaliar autenticidade do código: qualquer outra pessoa pode ter feito, até mesmo uma inteligência artificial. Ou seja, esse método me parece pouco confiável e com baixa interação ao vivo com o entrevistador, o que compromete a essencial avaliação comportamental do desenvolvedor.
O live coding ou pair programming é quando o candidato programa em tempo real, geralmente com um ou mais avaliadores observando e interagindo. Embora seja uma abordagem mais interativa, também apresenta algumas questões negativas. A pressão psicológica costuma ser intensa e, mesmo isso também sendo útil como critério de avaliação, também pode prejudicar candidatos excelentes. Além disso, é um ambiente artificial de desenvolvimento, onde qualquer segunda aba aberta ou busca no google (normal no dia a dia do trabalho) podem ser mal vistas e dificulta mostrar o real potencial.
Já no LeetCode (e plataformas similares) focam em resolver problemas algorítmicos complexos. São exercícios que testam o conhecimento em estruturas de dados e algoritmos. Apesar de popular, especialmente em grandes empresas de tecnologia, esse método tem suas limitações. Há uma distancia da realidade do dia a dia, pois apesar de úteis, não revelam o potencial de um profissional entender bem de desenvolvimento ou de trabalhar bem em equipe: só mostra que ele é bom em decorar alguns exercícios.
Por isso, diferente de todos os agora citados, o System Design se diferencia por avaliar aspectos fundamentais que realmente importam no dia a dia de uma pessoa que trabalha com software. Apesar das outras etapas também terem seu espaço durante todo um processo seletivo, para o bem ou para o mal, me parece o método mais completo. Ele estimula frequentemente a capacidade de comunicação técnica, a tomada de decisão arquitetural e o conhecimento de trade-offs. Além disso, esse método permite uma discussão mais rica e próxima da realidade profissional. O candidato pode demonstrar não apenas conhecimento técnico, mas também maturidade em decisões de arquitetura, experiência com diferentes tecnologias e compreensão de requisitos não funcionais como escalabilidade, performance e segurança. A natureza da discussão do System Design também reduz o estresse da avaliação, transformando-a em uma discussão técnica produtiva onde ambas as partes podem aprender e trocar experiências. Não há respostas absolutamente certas ou erradas, mas sim decisões que precisam ser justificadas e defendidas com argumentos técnicos sólidos: demonstrando conhecimento necessário para o trabalho.
Pra falar a verdade, depois de alguns anos de carreira você simplesmente não pode abdicar de aprender isso: boa parte das empresas (grandes ou pequenas) que tive contato nos últimos anos tem como system design um fator determinante para você ser aprovado ou não. Existe uma razão para isso: system design grita experiência. É claro, você pode ver muitos vídeos no youtube, fazer cursos e ler muito mas nada vai te preparar pra uma pergunta bem específica de um recrutador no meio de uma entrevista sobre algum corner-case além de ter passado por algo parecido. As melhores pessoas em system design realmente construíram algo. Não tem macete, não tem cheat sheet e não tem IA generativa que vai fazer você ficar bom nisso a não ser sentar na cadeira e estudar. Por isso, pra mim, é a forma mais crua de como você conhece um desenvolvedor.
No final do dia, é simples. Saber como construir uma plataforma do zero te coloca na frente de outras pessoas. É fato. Entender toda a lógica por trás de sistemas distribuídos vai fazer ser um melhor desenvolvedor. Nada é preto no branco; por isso justificar suas decisões com embasamento técnico é uma das formas mais claras de demonstrar maturidade profissional.