Perguntas de entrevista para analista de dados que testam honestidade sobre o que o dado não diz
SQL é testável direto e deve ser testado direto. O que um exercício técnico não mostra é a parte da análise que realmente causa estrago: se a pessoa vai dizer a um stakeholder que o dado não sustenta a conclusão que ele queria, se declara incerteza em vez de enterrar, e se consegue explicar um achado para quem vai agir em cima dele sem entender o método. Isso é conversa, e é para isso que esta página serve.
O que o trabalho envolve de verdade
O analista transforma uma pergunta vaga de negócio em algo respondível, busca o dado, confere, analisa e comunica o resultado para quem vai decidir. A análise costuma ser a menor parte; definir a pergunta e comunicar no fim levam mais tempo e importam mais.
As falhas caras não são técnicas. São um número apresentado sem a ressalva, uma correlação descrita em linguagem causal, ou um stakeholder que recebeu a resposta que queria porque ninguém quis dizer o contrário. Todas são problema de comunicação e de caráter, não de SQL.
As perguntas, e como soa uma boa resposta
Use as perguntas como estão. Cada uma vem com o que é uma resposta forte, para que duas pessoas avaliando o mesmo candidato cheguem à mesma conclusão pelo mesmo motivo.
1. A sua análise contraria o que um stakeholder sênior esperava. Me conta essa conversa.
Uma boa resposta: Começa pelo achado, mostra o método, e sustenta a conclusão enquanto convida crítica ao método de verdade. Resposta forte separa 'minha análise está errada' de 'você não gostou da resposta'. É a pergunta mais importante daqui.
2. Você encontra um erro num painel que as pessoas usam há meses.
Uma boa resposta: Avisa na hora, quantifica o impacto, e corrige. Qualquer hesitação merece ser explorada com firmeza. Correção silenciosa é como um time continua confiando num número que esteve errado o trimestre inteiro.
3. Como você explica um resultado para quem não vai entender o método?
Uma boa resposta: Começa pela resposta e pela confiança, mantém o método disponível mas fora do caminho, e é explícito sobre o que o resultado não diz. A última parte é o que separa analista de gerador de relatório.
4. Um stakeholder faz uma pergunta que não dá para responder com o dado que você tem.
Uma boa resposta: Fala isso, oferece a pergunta respondível mais próxima, e diz o que precisaria ser coletado. Produzir algo adjacente e deixar ser lido como a resposta é a alternativa comum e danosa.
5. Como você confere se a sua própria análise está errada?
Uma boa resposta: Hábitos concretos, bater com um total conhecido, checar ordem de grandeza, pedir para alguém rodar de novo, testar a hipótese contrária. Analista sem rotina de autoconferência erra numa taxa previsível.
6. Duas fontes de dado discordam.
Uma boa resposta: Descobre por quê em vez de escolher a mais conveniente, e documenta a divergência mesmo depois de resolver. Resposta forte trata a discordância em si como um achado.
7. Te pedem um número e você desconfia que ele vai ser usado de forma enganosa.
Uma boa resposta: Entrega com o contexto junto, e fala a preocupação em voz alta. A disposição de falar é o que importa, analista que entrega número sem ressalva é instrumento, não colega.
8. Me conta de uma análise que acabou se mostrando errada.
Uma boa resposta: Uma real, com como foi pega e o que mudou depois. Todo mundo tem uma. Quem não tem ou é novo ou não está conferindo.
Uma ficha de avaliação para pontuar
Dê de 1 a 4 em cada linha, e anote a nota antes de assistir ao próximo. A nota escorrega quando ela é dada em relação a quem você acabou de ver.
| Critério | Como é uma nota 4 |
|---|---|
| Sustentar achado indesejado | Defende a conclusão convidando crítica ao método. Nota 2 amacia o resultado. |
| Levantar o próprio erro | Avisa do erro no painel na hora, com impacto. Nota 2 corrige em silêncio. |
| Comunicar limite | Diz o que o resultado não mostra. Nota 2 apresenta só o número. |
| Recusar pergunta irrespondível | Fala e oferece a pergunta real mais próxima. Nota 2 produz algo adjacente. |
| Autoconferência | Cita hábitos concretos de verificação. Nota 2 conta com cuidado. |
Como rodar a triagem
- Teste SQL e análise separado e direto. Um teste curto com dado real e sujo é a avaliação; esta rodada não é.
- Use a rodada gravada para as perguntas de stakeholder. Se a pessoa vai sustentar um achado indesejado é pergunta de caráter e aparece em como ela fala do assunto.
- Peça para explicar um gráfico do exercício em voz alta. É a coisa mais próxima de amostra de trabalho para a metade de comunicação da função.
- Dê peso à pergunta do painel com erro. Correção silenciosa é sinal cultural que prevê muita coisa.
- Não faça prova de estatística decorada. É consultável e desloca as perguntas que de fato separam candidatos.
Rodar isso numa pilha grande de inscritos é onde a conta cresce. A VoxScreen manda essas perguntas num link só, transcreve e avalia cada resposta pelos critérios que você definiu e devolve a lista ranqueada — de graça para 50 candidatos por mês, sem cartão.
Erros comuns ao contratar para esta vaga
- Contratar por ferramenta. Qual BI a pessoa conhece é quase irrelevante e transfere em dias.
- Testar só capacidade técnica. As falhas caras em análise são de comunicação e franqueza, não de consulta.
- Premiar certeza. Analista que nunca expressa incerteza não é mais preciso, é menos honesto sobre o intervalo dele.
- Pular a pergunta do achado indesejado. É o melhor indicador de se a sua área de dados vai te contar o que você não quer ouvir.
- Usar rodada gravada como triagem técnica. Ela não pode ser. Junte um exercício real com dado sujo.
Perguntas frequentes
O que perguntar para um analista de dados?
Pergunte o que acontece quando a análise contraria o que um stakeholder sênior esperava, o que faz ao achar erro num painel usado há meses, como explica um resultado para quem não entende o método, e como confere o próprio trabalho. Isso cobre as falhas que realmente custam dinheiro, e nenhuma delas é falha de SQL.
Como testar SQL numa vaga de analista?
Direto, com um teste curto usando dado realisticamente sujo, duplicata, nulo, um join que não é bem um para um. Essa é a avaliação técnica. Mantenha separada das perguntas acima, que testam a metade de comunicação e franqueza que nenhum exercício de consulta alcança.
Qual a qualidade mais subestimada num analista de dados?
Disposição de dizer que o dado não sustenta a conclusão que alguém queria. Quase nunca é triada e determina se a sua área de dados é fonte de verdade ou serviço de produzir evidência de apoio. A pergunta do stakeholder é o jeito mais rápido de ver isso.
Vale fazer prova de estatística?
Não decorada. Definição é consultável e testar isso desloca pergunta com sinal real. Se julgamento estatístico importa para a vaga, teste em contexto. Apresente um resultado e pergunte o que precisaria ser verdade para ele estar enganando, que é a habilidade de verdade.