Em uma system design interview bem conduzida, o entrevistador nunca pergunta qual linguagem o candidato usaria, e o candidato nunca precisa escolher. O quadro enche de caixas, setas, filas, caches, partições e timeouts, e nenhum exige que alguém declare se a implementação será em Go, Java, Python ou Rust. A linguagem é invisível porque o problema está sendo tratado no plano onde linguagem não diferencia solução: o plano da topologia, da propagação de estado, das fronteiras de consistência e dos modos de falha. É exatamente nesse plano que a seniority fica observável, e é por isso que, na minha avaliação, esse formato se tornou o único filtro confiável pra posições acima de pleno em times que operam sistemas distribuídos em produção.
O comportamento que emerge dessa entrevista é estável o suficiente pra ser descrito como um padrão. Candidatos juniores tendem a saltar direto pra escolhas tecnológicas concretas ("eu usaria Kafka", "eu colocaria Redis aqui") antes de enunciar o problema em termos de requisitos de latência, throughput, consistência e tolerância a falha. Candidatos medianos conseguem desenhar uma topologia razoável, mas tratam cada componente como caixa preta, sem articular o que acontece quando a caixa degrada. À medida que a senioridade sobe, o comportamento muda: candidatos seniores constroem o sistema pela fronteira dos trade-offs, começando pela natureza da carga, da qual derivam o perfil de leitura e escrita antes de localizar onde o estado precisa viver pra nomear tecnologias, e mesmo assim as nomeiam como exemplos intercambiáveis dentro de uma categoria, em vez de decisões finais. A linguagem de implementação, quando mencionada, aparece como nota de rodapé sobre ecossistema de bibliotecas ou sobre o time existente, nunca como variável estruturante.
Pra mim, system design interviews avaliam a capacidade de raciocinar sobre sistemas como sistemas, e essa capacidade é ortogonal à linguagem que o candidato usa no dia a dia. O que o entrevistador observa é a ordem em que o candidato estabelece restrições e a precisão com que nomeia trade-offs, junto com a consistência com que mantém o modelo mental ao longo de extensões do problema. Nada disso é específico de stack. Um engenheiro que passou a carreira em Elixir e um que passou a carreira em C# chegam à mesma discussão sobre particionamento por chave, sobre replicação síncrona versus assíncrona, sobre o custo de um índice secundário distribuído, porque essas discussões acontecem em um vocabulário que não pertence a nenhuma linguagem.
O mecanismo é direto quando decomposto. O entrevistador apresenta um problema aberto (projetar um encurtador de URL, um feed de timeline ou um pipeline de ingestão de eventos) e observa como o candidato reduz ambiguidade. A redução acontece por perguntas sobre volume, sobre SLA de leitura e escrita, sobre tolerância a inconsistência eventual, sobre requisitos de durabilidade. À medida que as respostas chegam, o candidato ancora decisões arquiteturais em números concretos, e cada decisão subsequente herda as restrições das anteriores. Quando o entrevistador introduz uma extensão ("e se o volume crescer dez vezes", "e se uma região cair", "e se a latência de escrita precisar ficar abaixo de 50ms no p99"), o candidato precisa revisitar o modelo sem colapsá-lo. É nesse momento que se distingue quem desenhou um sistema de quem desenhou um diagrama.
Na minha análise, os trade-offs são o núcleo da avaliação. Toda decisão arquitetural troca algo por algo, e candidatos que não nomeiam o que está sendo trocado revelam que estão replicando padrões vistos em posts de blog sem entender por que os padrões existem. O candidato que enuncia com naturalidade os pares operacionais que sustentam cada decisão (latência de escrita contra consistência forte na replicação síncrona, frescor contra latência de leitura no cache, operações cross-shard contra escalabilidade horizontal no particionamento, acoplamento temporal contra complexidade operacional e janelas de inconsistência observável na fila) está demonstrando exatamente o repertório que linguagem nenhuma ensina. Repertório construído sobre leitura, operação e cicatriz.
Em um caso recente, avaliei um candidato com background majoritariamente em Python em um design de sistema de notificações com fan-out alto e deduplicação por janela deslizante. Ele nunca operou o problema em produção, mas estruturou a solução em termos de idempotência no produtor, hash consistente pra particionar por destinatário, e janela de deduplicação implementada como estado local no consumidor com checkpoint periódico. A discussão evoluiu pra failover entre regiões, onde ele articulou o trade-off entre replicar o estado de deduplicação sincronamente, com custo de latência, ou aceitar duplicatas marginais durante a janela de failover. Como nenhuma linha de código foi escrita e nenhuma linguagem foi nomeada, a decisão de contratação ficou trivial.
Pra mim, o que opera acima da mecânica da entrevista é o seguinte: system design é o formato que revela se o candidato pensa em sistemas ou se pensa em código que por acaso roda em sistemas. Essa distinção determina o teto de crescimento do engenheiro. Quem pensa em código continua produtivo enquanto o problema couber em um único processo, mas encontra limite quando o problema passa a envolver coordenação entre processos, entre regiões ou entre times. A entrevista expõe esse limite em quarenta e cinco minutos, sem exigir que o candidato escreva uma linha, e sem que a linguagem que ele conhece apareça como variável. O que aparece é a forma como ele enquadra problema, restrição e consequência, e essa forma é a mesma em qualquer stack, o que torna o formato o instrumento mais language-agnostic que o processo de contratação consegue produzir.