System Design não é sobre a Resposta Certa
O que eu aprendi entrevistando e sendo entrevistado nos últimos 4 anos
Entrevistei dois engenheiros para a mesma vaga. Mesmo problema de System Design. Os dois resolveram. Só um passou.
O primeiro candidato sabia as técnicas certas. Mencionou OLAP, filas, as peças que a arquitetura precisava. Mas era difícil acompanhar o raciocínio. Ele pensava em voz alta sem estrutura e não escrevia nada no quadro. Quando questionei a diferença entre OLAP e OLTP, travou. Em nenhum momento considerou quem iria usar o sistema.
O segundo não mencionou OLAP sequer. Desenhou uma solução com PostgreSQL e read replicas. Mais simples, mas resolvia o cenário. Quando questionei a abordagem de AI (busca gerada por agente vs. SQL pré-definido), ele explorou os trade-offs dos dois lados, pesou, e decidiu. Tinha pesquisado o PostHog antes, olhado os perfis de quem ia entrevistar.
O primeiro sabia mais. O segundo passou.
Minha impressão do primeiro: “Would lower the bar for someone joining.” Do segundo: “Would raise the average level of the team.”
Esse artigo é sobre o que separou os dois.
✨ O que esperar do artigo
Vou usar dois candidatos reais que entrevistei para a mesma vaga, um passou e outro não, para mostrar o que fez a diferença.
O que entrevistadores realmente avaliam, e por que raramente é o que você imagina
Como estruturar os primeiros 5 minutos: a parte que define se você passa ou não
Como navegar pushback e incerteza: o momento que transforma “hire” em “strong hire”
A pergunta que ninguém te conta
Quando entrevisto, não estou verificando se o candidato sabe o que é Kafka.
Estou tentando responder perguntas diferentes:
“Eu gostaria de discutir um problema de produção com essa pessoa às 2h da manhã?”
“Se a gente discordar, a gente chega num consenso e sai da conversa melhor?”
“Eu confiaria nessa pessoa para tomar decisões sozinha? E ela sabe quando pedir ajuda?”
System Design é, tecnicamente, uma entrevista técnica. Mas é a mais comportamental das entrevistas técnicas. É uma simulação de colaboração.
É por isso que é minha entrevista favorita. É a mais próxima do trabalho real de engenharia. Não é uma prova com respostas certas. É uma conversa onde os dois lados exploram um problema juntos.
A diferença entre quem passa e quem não passa raramente é técnica. É sobre como a pessoa navega a conversa.
Em um artigo anterior, mostrei os 7 padrões técnicos que cobrem 90% das entrevistas:
Aquilo te dá o vocabulário. Hoje vou falar sobre como usar esse vocabulário numa conversa.
Comece pelo ser humano, não pela arquitetura
A maioria dos candidatos recebe “Design X” e já começa a desenhar caixas. Servidores, bancos de dados, filas. Red flag imediato.
Eu já escrevi sobre o que faz um engenheiro de produto. A ideia central é simples: “O código é o meio pelo qual alcançamos o sucesso do usuário.”
No artigo sobre o segredo dos produtos que encantam, abri com a história do engenheiro que implementou uma arquitetura impecável de microserviços. Os usuários continuaram exportando tudo para Excel, porque a solução não resolvia o problema real deles.
System Design interview é a mesma coisa. O sistema existe para servir alguém. Se você não sabe quem, tudo que vem depois é chute.
Antes de desenhar qualquer componente, entenda:
Quem é o usuário?
Onde ele está? (um país? global? rural com 3G?)
O que ele está fazendo enquanto usa?
Quando ele usa? (uma vez por dia? a cada segundo?)
Por que ele usa?
Essas perguntas mudam o design inteiro.
“Design WhatsApp” com todos os usuários nos EUA é um problema diferente de WhatsApp global. Se seus usuários logam uma vez por dia, você não precisa de refresh em tempo real entre acessos. Se estão em áreas rurais com 3G, cada byte que você envia importa.
O candidato que não passou? Passou a entrevista inteira falando de arquitetura sem considerar o usuário uma única vez. O que pensei na hora: “Did not consider the user. Spent most of the time talking about the problem, not really considering who it’s for.”
Perguntas que separam pleno de sênior
Existe uma diferença enorme entre:
Pleno: “Qual é a escala?”
Sênior: “Qual é a relação read/write? Que garantias de consistência os usuários esperam? Qual latência é aceitável para as operações críticas?”
A primeira é genérica. A segunda revela que você já está pensando em trade-offs antes de tocar no quadro. Como entrevistador, eu consigo saber nos primeiros 5 minutos se o candidato vai passar ou não. É quase sempre aqui que se decide.
Faça as contas: para decidir, não para impressionar
Back-of-the-envelope calculations não são teatro para mostrar que você sabe multiplicar.
São a ferramenta que decide qual arquitetura faz sentido.
Se você descobre que o sistema vai lidar com 10 QPS, o problema inteiro muda. Você não precisa de Kafka. Talvez nem precise de microserviços. Um monólito com PostgreSQL resolve, e propor isso mostra maturidade, não falta de ambição.
Se são 100k QPS, agora sim: filas, sharding, cache externo. Mas você precisa saber disso ANTES de desenhar.
Os números não precisam ser perfeitos. Use potências de 10 e pense no que muda com 10x de crescimento. Mas eles precisam existir. Quem chuta durante System Design me dá medo.
O candidato que passou? Escolheu PostgreSQL com read replicas. Sem OLAP. Mais simples. Resolvia o cenário. E ele sabia explicar exatamente por que aquela complexidade era suficiente. Deixe o entrevistador pedir mais complexidade. Isso é colaboração, não fraqueza.
Pensando em voz alta (e desenhando)
O entrevistador não avalia o que não vê.
Se você fica 2 minutos em silêncio pensando, eu não sei se você está tendo uma ideia brilhante ou completamente travado. O que pensei sobre o candidato que não passou: “Hard to follow the reasoning. Was thinking out loud without structure and didn’t write anything down.”
Ele sabia as coisas. Eu só não conseguia ver que ele sabia.
Pensar em voz alta não é monologar
É estruturar seu raciocínio de forma que o entrevistador consiga acompanhar e contribuir:
“Estou considerando X porque...” → mostra raciocínio
“Uma alternativa seria Y, mas o trade-off é...” → mostra que pensa em opções
“Faz sentido priorizar Z aqui?” → mostra colaboração
O equilíbrio: narrar demais vira ruído. Narrar de menos vira silêncio. A regra prática: verbalize as decisões e os porquês. Não cada micro-pensamento.
Desenhar é uma skill separada
O quadro (Excalidraw, whiteboard, papel) não é decoração. É ferramenta de comunicação.
O que desenhar: Comece com o usuário. Depois o fluxo de dados. Depois os componentes. Cada elemento no quadro deveria responder uma pergunta.
Quando desenhar: Quando a explicação verbal fica confusa. Um diagrama de 30 segundos substitui 3 minutos de explicação.
O que NÃO desenhar: Não encha o quadro de caixas e setas sem propósito. Quadro com 15 componentes onde 5 bastavam é tão ruim quanto nenhum quadro.
Quadro organizado = pensamento organizado. Quadro bagunçado = red flag.
Seu diagrama conta uma história. O entrevistador deveria conseguir olhar para ele e entender seu design sem você precisar explicar tudo de novo. Se não consegue, o quadro não está fazendo seu trabalho.
Navegando a conversa
Esse é o momento que separa “hire” de “strong hire.”
Pushback não é ataque
Quando eu questiono a decisão de um candidato, geralmente estou fazendo uma de três coisas:
Guiando para uma solução melhor (quero ver se você segue a dica)
Testando se você sabe defender suas decisões com argumentos
Verificando se você sabe mudar de ideia quando faz sentido
As três são sinais positivos. Pushback significa que o entrevistador está engajado. Silêncio é pior.
Quando questionei o candidato que passou sobre a abordagem de AI (agente gerando busca vs. SQL pré-definido), ele não cedeu nem cavou trincheira. Explorou os trade-offs dos dois lados, pesou as implicações, e tomou uma decisão. Me convenceu. Eu aprendi algo com a resposta dele.
Isso é o que colaboração real parece.
Os três erros fatais
Cavar trincheira. “Não, minha solução está certa.” Defensividade mata. Mesmo que você esteja certo, a forma importa mais que o conteúdo nesse momento.
Ceder imediatamente. “Ah, ok, vou mudar.” Sem entender por quê. Mostra que não tem convicção. Ou que a decisão original não tinha raciocínio por trás.
Entrar em pânico. Achar que pushback = reprovação. Você paralisa. Começa a duvidar de tudo que disse até agora.
O que fazer em vez disso
Ouvir completamente antes de responder. Depois:
Se você concorda: “Entendo o ponto. Posso ver por que Z seria melhor aqui dado [contexto]. Vou ajustar o design.”
Se você discorda: “Meu raciocínio foi X por causa de Y. Mas entendo a preocupação com Z. O trade-off que estou aceitando é...”
Se você não sabe: “Honestamente, não tenho certeza. Minha intuição é X, mas eu investigaria Y antes de commitar.”
A terceira opção, admitir que não sabe, é a mais subestimada.
“Eu não sei” é um sinal positivo
No mundo real, você quer que a pessoa peça ajuda quando precisa. Admitir os limites do seu conhecimento mostra maturidade. Muito melhor do que inventar e ser pego.
O candidato que não passou? Quando perguntei a diferença entre OLAP e OLTP, ele travou. Se tivesse dito “não tenho certeza da distinção exata, mas entendo que uma é otimizada para queries analíticas e a outra para transações”, teria sido infinitamente melhor que o silêncio.
Perguntas não significam que você está falhando
Se você resolve tudo de forma limpa, eu vou adicionar requisitos até você chegar num ponto que não resolve de forma limpa. Isso é by design.
Querem ver como você lida com incerteza. Chegar num ponto difícil e navegar bem é mais impressionante do que nunca chegar lá.
O mesmo vale para frameworks. HelloInterview, delivery frameworks. São ótimos para dar estrutura. Mas quando o entrevistador desvia do script, não entre em pânico. Se você só funciona dentro do framework, não praticou o suficiente. O objetivo é que a estrutura vire natural, não decorada.
Seja você, não o ChatGPT
Eu escrevi um artigo inteiro sobre como IA multiplica expertise:
A tese central: “LLMs não eliminam a necessidade de aprender profundamente. Elas multiplicam o valor de ter fundamentação sólida.”
Eu uso IA para tudo. Construí a plataforma inteira do Na Gringa com ajuda de LLMs. Mas o motivo de funcionar é que eu sei o que pedir e consigo avaliar o que recebo de volta.
Numa entrevista de System Design, isso se inverte. Se você usa LLM como muleta durante a conversa (e sim, entrevistadores percebem), o que você está sinalizando é que não tem a fundamentação. Que sem o modelo, você não chega em soluções originais. É como ter um assistente extremamente capaz sem saber o que delegar.
O entrevistador quer ouvir você. Sua forma de ver problemas. Suas experiências reais, mesmo que limitadas. Suas opiniões, mesmo que imperfeitas.
Na preparação? LLMs são o melhor tutor que já existiu. Use para estudar conceitos, entender sistemas que você nunca usou, simular entrevistas, praticar explicações em voz alta. Mas na hora, as ideias precisam ser suas.
Pesquise a empresa (de verdade)
Uma coisa que fez diferença com o candidato que passou: ele tinha pesquisado o PostHog. Olhou nossos perfis. Sabia o que a gente fazia. Isso mudou a dinâmica inteira. Não era mais entrevistador avaliando candidato, eram duas pessoas discutindo um problema real. O que pensei na hora: “Clearly did the homework, looked up PostHog and even saw our profiles.”
Pesquisar a empresa não é só para impressionar. Te beneficia: filtra mismatches de valores e te dá contexto para fazer perguntas melhores durante a entrevista.
Como praticar de verdade
Não vou te dizer para “ler mais engineering blogs.” Vou te dizer o que realmente funciona.
Mock interviews com colegas. A prática mais efetiva que existe. Combine com um amigo e alternem candidato e entrevistador. Você aprende dos dois lados. Eu aprendi mais sobre System Design entrevistando outros do que sendo entrevistado.
Uma dica de como eu faço: coloque um timer de 5 minutos para o requirements gathering. Se o candidato não perguntou sobre o usuário, não fez uma conta de padeiro, e já está desenhando caixas, isso já é feedback valioso. Na entrevista real, esses 5 minutos definem quase tudo.
Grave você mesmo. Escolha um problema do HelloInterview. Ou um capítulo Designing Data-Intensive Applications. Fale sobre em voz alta, grave, assista depois. Você vai perceber coisas que não percebe ao vivo: silêncios longos demais, monólogos sem estrutura, quadro vazio quando deveria ter diagrama.
Lidere design discussions no trabalho. Design docs, tech talks, facilitação de reuniões técnicas. A skill de System Design é a mesma skill de liderar uma discussão técnica. Cada design doc que você escreve é prática de entrevista.
Use HelloInterview para estrutura. Bom framework tático para organizar seus 45 minutos. Mas pratique até desviar dele ser confortável, não assustador.
🌟 Resumo
System Design é a entrevista mais comportamental das técnicas. O entrevistador quer saber se confiaria em você para resolver um problema de produção às 2h da manhã, não se você sabe o que é Kafka.
Os primeiros 5 minutos definem quase tudo. Pergunte quem é o usuário, faça as contas, e só depois toque no quadro. Começar desenhando caixas é red flag imediato.
Pense em voz alta com estrutura, e desenhe. O entrevistador não avalia o que não vê. Verbalize decisões e porquês, não cada micro-pensamento. Quadro organizado = pensamento organizado.
Pushback é sinal positivo. Não cave trincheira, não ceda sem pensar, não entre em pânico. Explore os trade-offs e tome uma decisão. Admitir que não sabe é melhor do que inventar.
Seja você, não o ChatGPT. Use IA para estudar, mas na hora as ideias precisam ser suas. Pesquise a empresa. Mude a dinâmica de “avaliação” para “conversa entre colegas.”
System Design é a etapa que mais me diverte. Não porque eu sei todas as respostas. Porque cada conversa me ensina algo novo.
O candidato que passou? Eu aprendi com ele também. Saí da entrevista com uma perspectiva diferente sobre o trade-off de agent vs. SQL pré-definido. Isso é o que uma boa conversa de System Design faz. Os dois lados saem melhores.
Os 7 padrões te deram o vocabulário. Este artigo te deu as skills de performance. Os dois juntos = você sabe o que dizer e como dizer.
📚 Para aprofundar
O vocabulário técnico que complementa este artigo:
A outra metade da equação, entrevistas comportamentais:
Dicas para entrevistas de live coding:
HelloInterview.com: prática estruturada com feedback
Designing Data-Intensive Applications de Martin Kleppmann (segunda edição sai em março 2026)
Se esse artigo te ajudou, compartilha com alguém que está se preparando para entrevistas. É o tipo de conteúdo que eu queria ter lido antes de falhar em 2021.
Uma nova parceria para o NaGringa
Semana passada, o Matheus Nasser foi contratado pela Amber, startup americana de PLM. Foi a primeira contratação direta do NaGringa. O diferencial dele? Tratou o take-home como produto real. Pesquisou todo mundo que ia entrevistá-lo. Mostrou que pensa como dono. Tudo que eu falei nesse artigo, ele fez na prática.
Essa vaga veio pela Laura Oliveira, minha nova sócia no NaGringa. Com anos de experiência em recrutamento, ela traz o lado que eu sozinho não consigo dar: o de quem contrata. Negocia direto com empresas, conecta membros com oportunidades exclusivas, e participa ativamente da comunidade ajudando na preparação de entrevistas e estratégia de carreira. Quem já interagiu com ela sabe.
Se você quer acesso a vagas exclusivas, simulados diários de entrevista, aulas de inglês e uma comunidade onde pessoas como a Laura e eu estamos ativamente investidos no seu crescimento:
Nossa próxima vaga exclusiva
A Laura já trouxe a próxima vaga que estamos publicando exclusivamente para os membros pagantes da comunidade.
A remuneração vai de $90k a $200k USD (R$39k até R$87k por mês) dependendo da experiência. Confira todos os detalhes da vaga aqui.