O State of Skills-Based Hiring 2024 da TestGorilla, plataforma de avaliação pré-contratação, publicado em maio de 2024 com dados de mais de dois mil empregadores e profissionais, registrou que 81% dos empregadores já utilizam contratação baseada em habilidades e que 94% consideram esse modelo mais preditivo de sucesso no trabalho do que currículos. Pra mim o dado confirma uma direção que quem conduz entrevistas técnicas há décadas já observa empiricamente: o formato dominante de avaliação, centrado em sintaxe correta de uma linguagem obrigatória escrita sob pressão de tempo, mede uma capacidade com correlação fraca com a de projetar e manter sistemas em produção. O problema é que reconhecer essa fraqueza é fácil, e redesenhar o processo é caro.
A estrutura típica de uma entrevista técnica em empresas de tecnologia em 2025 ainda gravita em torno de coding challenges com linguagem restrita. Google restringe o coding interview a um subconjunto de linguagens que inclui Java, C++, Python e Go. Meta permite cinco linguagens (Python, Java, C++, C# e JavaScript/TypeScript). Amazon opera com uma lista ligeiramente mais ampla. Na minha avaliação essas restrições existem por razões operacionais legítimas, como padronização de ambientes e familiaridade dos entrevistadores, mas produzem um efeito colateral: candidatos otimizam pra linguagem do processo. Um engenheiro formado em ecossistemas como Haskell ou Rust precisa traduzir seu raciocínio pro subconjunto expressivo de Python ou Java antes de comunicá-lo ao entrevistador, e essa tradução consome tempo enquanto introduz erros de superfície que obscurecem exatamente aquilo que a entrevista deveria revelar.
Na minha análise, o pensamento computacional que importa na prática de engenharia opera em camadas que a sintaxe não alcança. O candidato precisa decompor um problema em subproblemas tratáveis enquanto identifica invariantes que precisam ser preservadas, e o raciocínio sobre complexidade de tempo e espaço já vem entrelaçado com modelagem de estados e antecipação de modos de falha. Nenhuma dessas capacidades depende de saber como a linguagem delimita blocos ou modela tratamento de erros. A sintaxe é a camada mais superficial e mais facilmente adquirível do repertório de um engenheiro, e no entanto é a camada que a maioria dos processos seletivos trata como pré-requisito eliminatório.
Já conduzi entrevistas onde pedi ao candidato que descrevesse a solução em pseudocódigo antes de tocar em qualquer linguagem, e o efeito é revelador. Engenheiros com pensamento computacional sólido produzem descrições claras do fluxo de dados enquanto identificam casos de borda antes de começar a codificar, e articulam decisões de estrutura de dados em termos de propriedades necessárias (acesso O(1) por chave, deduplicação eficiente). Engenheiros que construíram competência por memorização de padrões sintáticos ficam visivelmente desconfortáveis quando a muleta da linguagem familiar é removida. Pra mim, a diferença está na profundidade do modelo mental que o candidato carrega sobre o que está computando.
O formato de system design demonstra por subtração o que acontece quando linguagem sai da equação. Numa entrevista de system design o candidato discute arquitetura distribuída, estratégias de particionamento e modelos de consistência, junto com padrões de comunicação entre serviços e mecanismos de resiliência. A linguagem em que cada componente será implementado é irrelevante pra discussão. Quem conduz system design com frequência sabe que os melhores candidatos nessa etapa raramente são os mesmos que se destacam em coding challenges sintáticos. As competências avaliadas são distintas, e a de system design tem correlação mais forte com a capacidade de entregar software que funciona em produção.
Reformular o processo pra ser genuinamente language agnostic exige repensar o que está sendo avaliado em cada etapa. O modelo que aplico há anos começa por uma conversa técnica sobre um sistema que o candidato construiu ou manteve, focada em decisões de arquitetura e nos trade-offs enfrentados durante a operação. Em seguida vem um exercício de modelagem em que o candidato define entidades, relações e invariantes sem escrever código executável, com fluxos de dados desenhados como contrato e não como implementação. Só então entra o exercício de implementação, na linguagem que o candidato escolher, com um problema que exige raciocínio sobre concorrência ou tratamento de erros, e o que avalio é a clareza do raciocínio e a capacidade de identificar edge cases antes que o teste os exponha.
O custo desse modelo é real. Entrevistadores precisam de repertório técnico amplo pra avaliar soluções em linguagens que não dominam, o que exige senioridade e investimento em calibração. A conversa técnica sobre sistemas reais demanda preparação específica pra cada candidato, ao contrário de um coding challenge padronizado aplicável em escala. Na minha avaliação o trade-off é entre eficiência de processo e qualidade de sinal: processos altamente padronizados escalam bem mas capturam sinal ruidoso sobre capacidade real de engenharia, enquanto processos mais profundos escalam pior e exigem entrevistadores mais caros, em troca de uma taxa de acerto na contratação que sobe de forma mensurável.
O engenheiro que entende concorrência como disciplina vai implementar soluções corretas em qualquer ecossistema depois de consultar a documentação por algumas horas. O engenheiro que memorizou a API de goroutines mas não entende por que race conditions acontecem vai produzir bugs sutis em Go e bugs idênticos em qualquer outra linguagem que tente usar. O processo seletivo que distingue o primeiro do segundo precisa perguntar sobre o mecanismo, e não sobre a sintaxe. A maioria dos processos em operação ainda não implementou essa distinção, e na minha análise a distância entre saber o que avaliar e conseguir avaliar continua sendo o gargalo real da contratação técnica.