Entrevista Técnica de Dados: Por Que Seu Código Perfeito Pode Não Ser o Bastante Você passou 30 minutos escrevendo a query SQL perfeita para calcular cohort retention. Sintaxe impecável, lógica blindada, índices otimizados. E mesmo assim... reprovaram. Isso é mais comum do que você imagina. E não é porque seu código estava errado. É porque entrevista técnica não testa código. Testa como você pensa. 1. A Mentalidade Errada Na Preparação A maioria dos candidatos estuda assim: Memoriza sintaxe de SQL Pratica leetcode.com Decora window functions e CTEs Testa em localhost E depois entra na entrevista esperando provar conhecimento. Spoiler: entrevistador já sabe que você sabe SQL. Ele quer saber se você sabe quando usar SQL. Três candidatos escrevem a mesma query certa: Candidato A: tira de cabeça em 2 minutos Candidato B: digita em 8 minutos Candidato C: digita em 8 minutos E explica por quê cada linha existe Qual contratam? C. Sempre. Porque C demonstra que entende o negócio, não só a sintaxe. 2. Os 5 Sinais Que Separam Aprovados de Reprovados Sinal 1: Perguntar Antes de Codificar Errado: Certo: Por quê? Porque no mundo real, essas perguntas determinam a solução. Se é bilhões de registros, você precisa de índices. Se é 30 dias, você não precisa de particionamento. Se é retention por dia de vida, a lógica muda completamente. Entrevistador vê: "Este candidato pensa como sênior. Questiona antes de codificar." Sinal 2: Considerar Tradeoffs, Não Apenas Correto Errado: Entrevistador: "Qual é a complexidade dessa query?" Você: "Não sei." Certo: Entrevistador: "Qual você usaria aqui?" Você: "Depende. Se for um dashboard que roda 100x/dia, Opção A (rápida). Se for análise única com muito detalhe, Opção B. Qual é o caso de uso?" Entrevistador vê: "Este candidato não decora soluções. Avalia contexto." Sinal 3: Reconhecer Edge Cases Errado: Você escreve a query, entrega, acha que terminou. Certo: Por quê? Porque 90% das falhas em produção vêm de edge cases que "ninguém pensou". Entrevistador pode dar uma resposta, ou pode dizer "boa pergunta, defina você". Independente, você sinalizou que pensa em production, não em "query bonitinha". Sinal 4: Justificar Decisões Técnicas Errado: Você: "Achei que seria mais rápido." Certo: Você: "Usei INNER JOIN porque só quero usuários que têm eventos após signup. Se usasse LEFT JOIN, incluiria usuarios inativos, e meu retention cairia artificialmente." Por quê? Porque JOIN não é escolha arbitrária. Cada tipo tem implicação. INNER JOIN vs LEFT JOIN vs FULL JOIN mudam completamente o resultado. Entrevistador quer saber se você sabe as consequências. Sinal 5: Simplificar, Não Complicar Errado: A query tem 80 linhas. Entrevistador pergunta: "Por que tão complexo?" Você: "É que precisa ser preciso..." Certo: 8 linhas. Clara. Entrevistador: "Por que simples assim?" Você: "Porque a simpleza é sempre melhor. Se ficasse complexo sem necessidade, seria hard to maintain. Esta query faz em 2 segundos, então não precisava de otimização excessiva." Entrevistador vê: "Este candidato entende a diferença entre 'elegante' e 'correto'." 3. O Checklist de Preparação (Não o Que Você Espera) ❌ NÃO FAÇA (Armadilha comum): Decorar 100 queries no LeetCode Praticar "técnicas avançadas" sem entender caso de uso Estudar teoricamente sem nunca rodar em DB real ✅ FAÇA (Que funciona): Resolva 10 problemas reais de negócio (com dados verdadeiros) Para cada problema, escreva 2-3 soluções diferentes Justifique por quê cada uma é melhor em um contexto diferente Pratique explicar em voz alta ("rubber duck debugging") 4. Exemplo Real: A Entrevista Que Não Era Sobre SQL Estava em uma entrevista há poucos meses. Perguntaram: Entrevistador: "Temos 50M de pageviews/dia. Queremos uma métrica de retention diária. Qual é sua abordagem?" Minha resposta: Eu: "Depende. Qual é o latency aceitável? Se precisa em tempo real (< 1 minuto): Redis + pipeline de streaming, sem SQL Se pode ser hora/hora: warehouse query + cache de 1 hora Se pode ser diariamente: big query com particionamento por data, roda noturna" Entrevistador: "Interessante. Qual você escolheria?" Eu: "Perguntaria antes: qual é o objetivo? Se é dashboard interno, diário é ok. Se é ajudar a decisão de feature release em tempo real, precisa de < 5 minutos. Qual é?" Entrevistador: "Vamos dizer que precisa estar atualizado a cada 2 horas para decisões de marketing." Eu: "Então warehouse + cache de 2 horas é suficiente. Evita custo de pipeline real-time (que seria 5-10x mais caro) sem perder funcionalidade." Entrevistador: "Perfeito. Você já é aprovado, mas continue: qual seria a query?" Escrevi a query simples, sem exageros. Porque a conversa tinha sido sobre tradeoffs, não sobre "prove que sabe SQL". 5. Os Últimos 30 Dias: Treinar Certo Se você tem uma entrevista saindo: Semana 1: Resolva 3 problemas de retenção usando dados reais (seu próprio projeto ou Kaggle) Semana 2: Resolva mesmos 3 problemas com 3 abordagen