SQL que realmente aparece em entrevista

O problema

Muita gente trata SQL de entrevista como se fosse olimpíada.

Fica esperando:

• sintaxe obscura
• função estranha
• pegadinha de banco específico
• desafio que parece prova de certificação

Isso atrapalha por dois motivos.

Primeiro, porque gera ansiedade desnecessária.

Segundo, porque faz você estudar o pedaço menos frequente.

Na prática, o que mais aparece é bem mais terreno:

• buscar dado certo
• juntar tabelas certas
• não se perder em duplicação
• agrupar sem mentir resultado
• ordenar e paginar com algum critério

Ou seja:

o problema real não é “não sei SQL avançado”.

O problema costuma ser não conseguir traduzir uma pergunta de negócio em consulta clara.

Modelo mental

Pense assim:

SQL de entrevista quase sempre mede se você entende como o dado está organizado e como extrair uma resposta confiável dele.

Essa frase importa porque muda o foco.

A entrevista raramente quer ver se você decorou tudo o que o banco sabe fazer.

Ela quer ver se você consegue:

• ler tabelas e relações
• escolher o conjunto certo de linhas
• combinar dados sem bagunçar cardinalidade
• agregar quando a pergunta pede resumo
• perceber onde a query pode ficar errada ou cara

Então SQL aqui é menos sobre sintaxe e mais sobre raciocínio.

Quebrando o problema

select, where e order by ainda são o núcleo

Tem gente que acha isso básico demais para cair.

Mas cai justamente porque é onde muita resposta ruim aparece.

Exemplos:

• esquecer filtro importante
• ordenar pelo campo errado
• usar select * sem necessidade
• não limitar resultado quando a pergunta pede topo

Se a pergunta é:

• “quais foram os 10 pedidos mais recentes de um cliente?”

você precisa pensar em:

• qual tabela principal responde isso
• qual filtro identifica o cliente
• qual campo define “mais recente”
• como limitar para 10

Parece simples.

Mas é exatamente esse tipo de tradução que costuma ser avaliado.

Em muita entrevista, errar o básico com convicção pesa mais do que não lembrar um recurso mais raro.

join é onde muita entrevista separa clareza de confusão

Quase toda entrevista de SQL passa por junção.

Não porque join é avançado.

Mas porque ele revela se você entende relação entre tabelas.

Os dois mais comuns:

• inner join
• left join

O ponto não é decorar definição bonita.

É saber o efeito:

• inner join mantém só quem tem correspondência dos dois lados
• left join mantém todas as linhas da esquerda, mesmo quando a direita não casa

Se você não enxerga isso, responde a pergunta errada sem perceber.

Duplicação por join pega muita gente

Esse é um dos tropeços mais frequentes.

Você junta orders com order_items para trazer contexto.

Só que cada pedido pode ter vários itens.

Resultado:

• uma linha por item
• não uma linha por pedido

Daí surgem erros como:

• contar pedido duplicado
• somar valor duas vezes
• achar que a query “funcionou” porque retornou linhas plausíveis

Em entrevista, esse detalhe pesa porque mostra se você entende cardinalidade ou só encaixa sintaxe.

group by aparece bastante, mas quase sempre em versão humana

Raramente a entrevista vai exigir agregação muito exótica.

O padrão costuma ser:

• contar pedidos por cliente
• somar faturamento por mês
• achar média por grupo
• filtrar grupo com having

O ponto central é:

quando a pergunta deixa de ser sobre linhas individuais e vira resumo, você sai de seleção simples e entra em agregação.

Quem entende isso costuma caminhar bem.

Quem não entende tenta resolver tudo com subquery aleatória ou lógica fora do banco.

Paginação quase sempre aparece em versão prática

Outro tema muito comum é:

• trazer lista ordenada
• paginar
• explicar limite e offset

Não porque o entrevistador ama paginação.

Mas porque isso aparece em sistema real o tempo todo.

Também é onde você pode mostrar maturidade extra:

• offset grande degrada
• ordenação precisa ser estável
• cursor pode fazer mais sentido em algumas listas

Nem sempre vão pedir para escrever paginação por cursor.

Mas mencionar esse raciocínio, quando cabe, mostra repertório real.

Performance básica costuma aparecer como leitura, não como truque

Em entrevista, performance SQL normalmente aparece assim:

• “essa query pode ficar lenta por quê?”
• “que índice poderia ajudar?”
• “esse join pode explodir volume?”
• “isso pode virar N+1 na aplicação?”

De novo:

não é competição de otimização.

É teste de noção prática.

Querem ver se você percebe:

• filtro sem índice
• ordenação cara
• agregação em volume alto
• dado demais sendo buscado

SQL bom de entrevista costuma soar menos como truque e mais como leitura cuidadosa do formato do dado.

Exemplo simples

Imagine estas tabelas:

• customers(id, name)
• orders(id, customer_id, total, created_at)

Pergunta:

• “quais clientes fizeram mais pedidos nos últimos 30 dias?”

Uma solução plausível seria:

select
  c.id,
  c.name,
  count(o.id) as order_count
from customers c
join orders o on o.customer_id = c.id
where o.created_at >= current_date - interval '30 days'
group by c.id, c.name
order by order_count desc
limit 10;

O valor da resposta não está só na sintaxe.

Está em saber explicar:

• por que o join é necessário
• por que o filtro vem antes do agrupamento lógico
• por que precisa agrupar por cliente
• por que ordenar pelo agregado
• por que o limit atende o “top 10”

Esse tipo de explicação costuma valer tanto quanto a query.

Erros comuns

• Estudar só recursos raros e negligenciar join, group by e paginação.
• Escrever query que retorna algo plausível, mas responde outra pergunta.
• Ignorar duplicação causada por relação um-para-muitos.
• Tratar left join e inner join como quase iguais.
• Resolver no código o que estava claramente mais simples no SQL.
• Falar de performance de forma genérica, sem apontar o gargalo provável.

Como um senior pensa

Um senior normalmente começa nomeando a pergunta antes da query.

Ele pensa algo como:

• qual é a entidade principal?
• que relacionamento preciso atravessar?
• quero linha por quê: pedido, cliente, mês, item?
• estou trazendo detalhe ou resumo?

Essa ordem evita um monte de query torta.

Também é comum ele validar resultado mentalmente com poucos exemplos.

Algo como:

• “se um pedido tem 3 itens, isso vai duplicar linha?”
• “se um cliente não tem pedido, ele deve aparecer ou não?”
• “essa ordenação continua estável ao paginar?”

Ou seja:

ele não pensa só em escrever a consulta.

Pensa em provar para si mesmo que a consulta está correta.

O que o entrevistador quer ver

Na maioria dos casos, o entrevistador quer ver quatro coisas:

• se você entende o dado
• se você consegue montar uma consulta coerente
• se você enxerga armadilhas de resultado
• se você tem noção básica de custo

Uma resposta forte costuma soar assim:

“Eu começo identificando qual é a linha base da pergunta e quais relações entram. Depois vejo se quero detalhe ou agregado, porque isso muda totalmente a query. Em seguida valido cardinalidade para não duplicar resultado por acidente. Se a consulta for frequente ou em volume alto, olho filtro, ordenação e índice provável.”

Isso mostra raciocínio.

Muito mais do que despejar sintaxe rara.

SQL de entrevista costuma cobrar clareza sobre dado, não exibicionismo de banco.

Se você sabe o que quer contar, juntar e ordenar, metade da entrevista já ficou simples.