O Método da Entrevista

"Projete um sistema de venda de ingressos como a BoxOffice. Você tem 45 minutos." O enunciado tem uma frase de propósito. Não existe uma única resposta correta, nem uma bateria de testes escondida, e o entrevistador não vai dizer o que fazer em seguida. O que ele avalia é como você sai de uma frase vaga e chega a um design defensável: as perguntas que você faz, os números que estima, a estrutura que impõe e como raciocina sobre trade-offs quando ele contesta¹.

Sem um método, 45 minutos somem rápido: 20 minutos no esquema do banco e depois o pânico para desenhar o resto. Esta página apresenta um método de sete passos com orçamento de tempo, aplica-o de ponta a ponta à BoxOffice e lista o que os entrevistadores procuram em cada passo. O mesmo método é útil fora das entrevistas — ele é o esqueleto de uma boa revisão de design ou de um documento de design.

O que o entrevistador procura

Os entrevistadores normalmente pontuam algumas dimensões, com nomes diferentes em cada empresa, mas conteúdo parecido¹²:

As expectativas crescem com a senioridade. Um guia aproximado:

O método num relance

Os tempos são um orçamento, não uma lei: se o entrevistador quiser passar 15 minutos num aprofundamento, acompanhe-o. Mas confira o relógio em cada transição — acabar o tempo antes de desenhar um design de alto nível completo é a forma mais comum de ser reprovado.

sequenceDiagram
    participant C as Candidato
    participant I as Entrevistador
    I->>C: "Projete a BoxOffice"
    C->>I: 1. Perguntas de esclarecimento (usuários, escala, consistência, escopo)
    I-->>C: respostas / "você decide"
    C->>C: 2. Estima em voz alta
    C->>I: 3. Propõe API e modelo de dados
    C->>I: 4. Desenha o design de alto nível
    I-->>C: "Como você evita venda duplicada?"
    C->>I: 5. Aprofundamento (com alternativas)
    I-->>C: "E se o tráfego crescer 10×?"
    C->>I: 6. Gargalos e trade-offs
    C->>I: 7. Fechamento: resumo e próximos passos

Repare nas setas que vêm do entrevistador: aprofundamentos e gargalos muitas vezes são conduzidos pelas perguntas dele. Trate cada pergunta como uma dica sobre o que ele quer avaliar, não como um ataque.

Passo 1 — Esclarecer os requisitos (≈ 5 min)

Objetivo: transformar o enunciado de uma frase num problema com limites. Pergunte e escreva as respostas no quadro.

• Usuários e escala: quantos usuários, usuários ativos por dia, eventos de pico?
• Funcionalidades principais: quais 3–5 devo projetar? O que está fora do escopo?
• Mistura de leitura/escrita e padrões de acesso: dominado por leituras ou por escritas? Em picos?
• Consistência: o que nunca pode estar errado? O que pode estar desatualizado?
• Expectativas de latência e disponibilidade; alguma regulação (pagamentos, dados pessoais)?

Essa última frase importa: dizer o que é difícil neste problema demonstra navegação do problema e avisa o entrevistador onde você vai gastar o tempo de aprofundamento.

Passo 2 — Estimar (≈ 5 min)

Objetivo: obter ordens de grandeza que mudem decisões. Arredonde sem dó e diga a conclusão, não só a aritmética. A aula 2 ensina o método; numa entrevista, soa assim:

Duas decisões saíram de quatro linhas de aritmética: um cache para o catálogo e uma sala de espera para o inventário. É para isso que se estima.

Passo 3 — API e modelo de dados (≈ 5 min)

Objetivo: tornar os requisitos funcionais concretos. Liste os principais endpoints (ou mensagens) e as principais entidades com suas chaves. Não escreva todos os campos — só o suficiente para raciocinar sobre padrões de acesso e consistência.

GET  /events?q=&city=&date=           search and browse (cacheable)
GET  /events/{eventId}/seats          seat map with availability
POST /events/{eventId}/holds          { seatIds }        → { holdId, expiresAt }
POST /orders                          { holdId }         → { orderId, paymentUrl }
POST /payments/webhook                provider → BoxOffice: paid | declined
GET  /orders/{orderId}                status and tickets

Mencione o padrão de acesso ao lado de cada entidade: o mapa de lugares é lido por event_id; reservas alteram alguns lugares de um evento; pedidos são lidos por fan_id. Esses padrões definem os índices e, mais tarde, as chaves de partição.

Passo 4 — Design de alto nível (≈ 10 min)

Objetivo: um diagrama que atenda todo requisito funcional de ponta a ponta. Comece simples e acrescente o que as estimativas pedirem. Percorra uma requisição de cada vez enquanto desenha ("o fã abre a página do evento: CDN, gateway, catalog, cache…").

flowchart LR
    fan([Fã]) --> cdn["CDN<br/>estáticos + imagens"]
    fan --> gw["API Gateway<br/>auth, rate limit"]
    gw --> catalog["catalog"]
    catalog --> cache[("Cache")]
    cache --> catdb[("SQL do catálogo<br/>+ réplicas")]
    gw --> wr["Sala de espera"]
    wr --> inventory["inventory"]
    inventory --> invdb[("SQL do inventário<br/>primário")]
    inventory --> order["order"]
    order --> psp["Provedor de pagamento"]
    psp -->|webhook| order
    order --> stream["Event stream"]
    stream --> notification["notification"]
    stream --> search["search"]

Passo 5 — Aprofundamentos (≈ 12 min)

Objetivo: mostrar profundidade técnica nas 1–3 partes mais difíceis. Escolha-as você mesmo (as que nomeou no passo 1) ou siga o entrevistador. Para cada uma: enuncie o problema, apresente duas ou três alternativas, compare-as, escolha.

UPDATE seat
   SET status = 'HELD', hold_id = :holdId, version = version + 1
 WHERE event_id = :eventId
   AND seat_id IN (:seatIds)
   AND status = 'FREE';
-- rows updated = number requested → hold created; otherwise roll back and answer 409

Passo 6 — Gargalos e trade-offs (≈ 5 min)

Objetivo: criticar o próprio design antes que o entrevistador o faça. Percorra o diagrama e pergunte, para cada componente: o que quebra primeiro? qual é o ponto único de falha? o que acontece se ele ficar lento?

Depois, nomeie os principais trade-offs explicitamente: "Escolhi consistência forte para os lugares em vez de disponibilidade: se o primário do inventário estiver inacessível, as reservas falham em vez de arriscar uma venda duplicada. O catálogo é o oposto: aceito 60 s de atraso em troca de velocidade."

Passo 7 — Fechamento (≈ 3 min)

Objetivo: deixar uma imagem final clara. Em três ou quatro frases: o que você projetou, como cumpre os requisitos principais, o que faria a seguir com mais tempo (monitoramento e alertas de SLO, multi-região, o assistente de IA…) e quaisquer perguntas em aberto. Não introduza componentes novos agora.

Como se comunicar

A estrutura acima é necessária, mas não suficiente. Estes hábitos fazem a diferença³:

• Pense em voz alta. O silêncio é o pior sinal; diga o que está considerando e por quê, mesmo sem certeza.
• Primeiro amplo, depois fundo. Um design simples e completo vale mais que meio design perfeito.
• Declare as premissas. "Vou assumir 2 M de fãs por dia; me avise se estiver fora."
• Use o quadro como memória. Requisitos num canto, números noutro, diagrama no meio — volte a eles.
• Acolha a contestação. "Bom ponto — se o provedor ficar fora uma hora, as reservas expiram; deixa eu rever isso." Mudar de ideia com um motivo é um sinal forte.
• Conduza. Anuncie as transições: "Tenho o design de alto nível; queria me aprofundar no problema da venda duplicada e depois no pico."
• Quantifique os trade-offs. "Isto acrescenta ~1 ms por requisição, mas reduz a carga no banco em 10×."

Praticando com o playground

O playground é um bom parceiro de treino para os passos 4–6. Depois de projetar um problema no papel, remonte seu design de alto nível a partir da paleta, rode o perfil de carga que corresponde às suas estimativas (spike para uma abertura de vendas, soak para um serviço estável) e procure o primeiro componente saturado. Se não for o que você nomeou no passo 6, descubra por quê. Os problemas para praticar e o guia de entrevista simulada foram organizados para uso em duplas: um candidato, um entrevistador, depois troquem.

Como se conecta

flowchart LR
    S1["1. Esclarecer<br/>→ Requisitos"] --> S2["2. Estimar<br/>→ Estimativa"]
    S2 --> S3["3. API e modelo de dados<br/>→ Compute, Bancos de dados"]
    S3 --> S4["4. Design de alto nível<br/>componentes da paleta"]
    S4 --> S5["5. Aprofundamentos"]
    S5 --> S6["6. Gargalos<br/>e trade-offs"]
    S6 --> S7["7. Fechamento"]
    S5 --> D1["sem venda duplicada<br/>update condicional no sql"]
    S5 --> D2["o pico das 10:00<br/>fila da sala de espera"]
    S5 --> D3["pagar exatamente uma vez<br/>idempotency key, webhook"]
    S6 --> PG["ensaie no playground<br/>→ Estudos de caso"]

Componentes da paleta do design de alto nível da BoxOffice: cdn (arquivos estáticos e imagens) · apigw (autenticação, rate limit) · app (catalog, inventory, order) · cache (catálogo) · sql (primário do inventário, réplicas do catálogo) · queue (sala de espera) · payment (provedor e webhook) · stream (eventos para notification e search) · waf (bots). Cenários: flash-sale, payment-system, url-shortener (um primeiro problema de prática). Continua em: Estudos de caso, Ingressos — a venda relâmpago da BoxOffice, Bancos de dados — o bug da venda duplicada, Compute — idempotency keys, Preparação para entrevista — método.

Pontos-chave