Existe uma diferença grande entre o que o mercado diz que quer e o que ele realmente avalia no processo seletivo. Se você está se preparando para uma vaga de analista de dados, entender essa diferença economiza semanas de estudo no lugar errado.
Este artigo analisa o que os recrutadores e gestores de dados brasileiros de fato pedem — baseado em descrições de vagas reais, relatos de processos seletivos e avaliações técnicas praticadas pelo mercado em 2025 e 2026.
O que aparece nas descrições de vagas
Uma análise de vagas publicadas no LinkedIn, Gupy e Indeed para posições de analista de dados no Brasil revela um padrão consistente:
Nível júnior (0-2 anos de experiência):
- SQL básico a intermediário:
SELECT,WHERE,GROUP BY,ORDER BY,JOINsimples - Excel ou Google Sheets (ainda é universal nesse nível)
- Alguma exposição a ferramenta de BI (Power BI, Looker Studio ou Tableau)
- Python “é diferencial” — mas raramente eliminatório
Nível pleno (2-5 anos):
- SQL intermediário a avançado: subqueries, CTEs, funções de janela básicas
- BI obrigatório, geralmente Power BI ou Looker
- Python começa a ser requisito, não diferencial
- Experiência com bancos como BigQuery, Redshift ou PostgreSQL
Nível sênior (5+ anos):
- SQL avançado: otimização de queries, modelagem de dados, stored procedures
- Python e/ou dbt para transformação de dados
- Conhecimento de arquitetura de dados
- Capacidade de mentorar e definir padrões técnicos do time
O padrão que emerge: para entrar no mercado, o mínimo funcional de SQL é mais do que suficiente. O que vai aumentando é a expectativa de autonomia e profundidade conforme o nível cresce.
O que as avaliações técnicas realmente testam
Descrições de vagas são uma coisa. Avaliações técnicas são outra.
Compilando relatos de processos seletivos compartilhados em comunidades de dados brasileiras (incluindo Dados para o Mundo, comunidades do Discord de dados e grupos no LinkedIn), os testes de SQL mais comuns para nível júnior e pleno incluem:
1. Filtragem e agregação básica
-- "Quantos pedidos foram feitos por estado em março de 2025?"
SELECT estado, COUNT(*) AS total_pedidos
FROM pedidos
WHERE DATE_TRUNC('month', data_pedido) = '2025-03-01'
GROUP BY estado
ORDER BY total_pedidos DESC;
Esse tipo de query aparece em praticamente todos os processos para nível júnior. Quem não consegue escrever isso sem consultar documentação não passa.
2. JOINs entre múltiplas tabelas
-- "Liste os clientes que fizeram pedido em 2025 com o valor total gasto"
SELECT c.nome, SUM(p.valor_total) AS total_gasto
FROM clientes c
JOIN pedidos p ON c.id_cliente = p.id_cliente
WHERE YEAR(p.data_pedido) = 2025
GROUP BY c.nome
ORDER BY total_gasto DESC;
JOINs entre duas e três tabelas são testados consistentemente, mesmo em vagas júnior. Para vagas plenas, espere JOINs com 4 ou mais tabelas e situações onde o tipo de JOIN (INNER, LEFT, RIGHT) importa para o resultado.
3. Subqueries e CTEs
Para vagas plenas, é muito comum encontrar questões que pedem uma abordagem com CTE (Common Table Expression) para resolver um problema mais complexo:
-- "Liste os clientes que gastaram acima da média em 2025"
WITH media_gasto AS (
SELECT AVG(valor_total) AS media
FROM pedidos
WHERE YEAR(data_pedido) = 2025
)
SELECT c.nome, SUM(p.valor_total) AS total_gasto
FROM clientes c
JOIN pedidos p ON c.id_cliente = p.id_cliente
CROSS JOIN media_gasto m
WHERE YEAR(p.data_pedido) = 2025
GROUP BY c.nome
HAVING SUM(p.valor_total) > m.media
ORDER BY total_gasto DESC;
CTEs tornam o código mais legível e são a abordagem preferida por times de dados maduros. Saber usá-las sinaliza que você já escreveu SQL no mundo real, não só em tutoriais.
4. Funções de janela (para plenos e sêniors)
-- "Qual o ranking de vendedores por receita dentro de cada região?"
SELECT
vendedor,
regiao,
receita_total,
RANK() OVER (PARTITION BY regiao ORDER BY receita_total DESC) AS ranking_regiao
FROM vendas_por_vendedor;
Funções de janela como RANK(), ROW_NUMBER(), LAG() e LEAD() aparecem em avaliações para nível pleno com frequência crescente. Para nível sênior, são praticamente obrigatórias.
As ferramentas que mais aparecem junto com SQL
O SQL raramente é avaliado sozinho. Entender o ecossistema de ferramentas que o mercado combina com SQL ajuda a priorizar o aprendizado:
Power BI
É a ferramenta de BI mais pedida no Brasil para analistas de dados. A integração com SQL é direta: Power BI se conecta a praticamente qualquer banco relacional e usa SQL (ou Power Query, que tem sintaxe próxima) para trazer dados.
Saber SQL não significa que você vai escrever queries dentro do Power BI o tempo todo — mas significa que você vai entender como os dados chegam até lá, o que é essencial para modelar corretamente.
BigQuery
O data warehouse do Google tornou-se padrão em empresas de médio e grande porte no Brasil. BigQuery usa SQL padrão com algumas extensões do Google. Para analistas que trabalham em ambientes de cloud, saber consultar no BigQuery é cada vez mais esperado.
dbt (data build tool)
Ainda mais focado em engenharia de dados, mas crescendo em expectativa para analistas sêniores. O dbt usa SQL como linguagem central para transformação de dados — então quem sabe SQL bem tem uma entrada natural.
Python
Python é complementar, não substituto. O mercado quer analistas que sabem SQL e Python — cada um para o que faz melhor. SQL para consultar e agregar dados em banco; Python para análises estatísticas, automação e visualizações mais complexas.
Para quem está decidindo entre os dois como primeiro passo, veja nossa análise de SQL ou Python: qual aprender primeiro.
Os erros mais comuns que eliminam candidatos
Compilando feedback de recrutadores e gestores técnicos:
1. Não saber fazer JOIN É o filtro mais básico em avaliações técnicas. Surpreende quantos candidatos que listam SQL no currículo não conseguem fazer um JOIN simples. Se você lista SQL como habilidade, esteja pronto para JOINs.
2. Confundir WHERE e HAVING
WHERE filtra linhas antes da agregação. HAVING filtra depois. Candidatos que não sabem a diferença mostram que aprenderam SQL superficialmente. Veja nosso guia sobre quando usar WHERE vs HAVING no SQL.
3. Não pensar em performance
Para vagas plenas e sênior, escrever uma query que funciona não é suficiente — ela precisa ser eficiente. Uso desnecessário de SELECT *, ausência de índices considerados, subqueries que poderiam ser CTEs — esses problemas aparecem em avaliações mais rigorosas.
4. Não comentar o código Em testes práticos que pedem uma solução mais elaborada, candidatos que não comentam o raciocínio perdem pontos. O código precisa ser legível para outras pessoas.
5. Colar resultado sem explicar Em processos onde o candidato apresenta a solução, não saber explicar por que fez cada escolha é eliminatório. SQL é uma ferramenta — o que o mercado quer é alguém que pensa em dados, não só alguém que escreve sintaxe.
O que saber para passar na maioria das avaliações técnicas de nível júnior
Se você está mirando sua primeira vaga de analista de dados, este é o checklist mínimo:
-
SELECT,FROM,WHERE,ORDER BY— básico de filtro e ordenação -
GROUP BYcom funções de agregação (COUNT,SUM,AVG,MIN,MAX) -
INNER JOINeLEFT JOINentre duas tabelas - Filtros com
AND,OR,IN,BETWEEN,LIKE,IS NULL - Funções de data básicas (extrair ano, mês, calcular diferença entre datas)
- Subquery simples no
WHERE - Alias de colunas e tabelas para legibilidade
Tudo isso está coberto em nosso artigo sobre os 10 comandos SQL mais usados no mercado de trabalho.
Para chegar ao nível pleno, adicione ao checklist:
- CTEs (
WITH) -
LEFT JOINvsINNER JOIN— saber quando usar cada um -
HAVINGpara filtros pós-agregação -
CASE WHENpara lógica condicional - Funções de janela básicas (
ROW_NUMBER,RANK,LAG,LEAD)
O diferencial que poucos candidatos têm
Nas entrevistas, o que separa candidatos com SQL similar é a capacidade de traduzir perguntas de negócio em queries.
O mercado não quer uma pessoa que sabe SQL abstrato. Quer alguém que, ao ouvir “precisamos entender a taxa de reativação de clientes inativos no último trimestre”, consegue quebrar esse problema em partes e escrever a query correspondente.
Isso se aprende com prática em dados reais, não com exercícios acadêmicos. Trabalhar com datasets reais — de vendas, marketing, finanças, RH — faz toda a diferença na hora de mostrar autonomia em um processo seletivo.
Como se preparar de forma estruturada
A diferença entre aprender SQL de forma fragmentada (tutoriais aleatórios) e de forma estruturada (currículo progressivo com projetos reais) aparece claramente na velocidade e na profundidade do aprendizado.
O Curso SQL do Zero ao Avançado da Blast foi desenhado especificamente para o mercado brasileiro, com projetos e datasets que espelham os casos de uso reais que aparecem em avaliações técnicas. O currículo vai do básico funcional até as funções de janela e CTEs que os processos seletivos mais exigentes testam.
É um caminho direto do zero ao nível de mercado — sem desvios para teoria que não vai aparecer no trabalho.
Perguntas frequentes
Quantas horas de prática preciso para passar numa avaliação técnica de SQL júnior?
Com um currículo estruturado e foco em prática com dados reais, 40 a 60 horas de estudo são suficientes para o nível júnior. O que importa é a qualidade da prática, não apenas o volume de horas.
O mercado testa SQL escrito ou SQL em ferramentas como Power BI?
A maioria testa SQL escrito puro, seja em plataformas como HackerRank, em testes enviados por email ou em pair programming durante a entrevista. Saber escrever SQL sem GUI é o que o mercado avalia.
Preciso saber otimização de queries para nível júnior?
Não de forma profunda. Mas conhecer boas práticas básicas — como evitar SELECT * e entender como índices funcionam superficialmente — mostra maturidade técnica que diferencia candidatos.
SQL em inglês ou em português?
SQL como linguagem usa palavras-chave em inglês (SELECT, FROM, WHERE). Os nomes de tabelas e colunas variam — algumas empresas usam inglês, outras português. O que importa é dominar a sintaxe da linguagem, independente do idioma dos dados.
