A menos que você tenha muita experiência trabalhando com testadores, leia os primeiros capítulos do "Testing Computer Software" da Cem Kaner para ter uma idéia dos tipos de termos que deseja ouvir: teste de limite, teste de erro, teste do caminho feliz, funcional, desempenho, segurança, integração etc. Se você não conseguir falar o idioma, não poderá realizar uma boa entrevista.
Especifique-os para um pequeno pedaço do seu sistema. Peça a eles para testá-lo. Você está procurando uma organização do pensamento e sua capacidade de apresentar testes interessantes. Você deseja vê-los dividir as áreas de teste de maneira ordenada e, em seguida, detalhar cada área, criando casos de teste cada vez mais interessantes. Testadores realmente bons podem fazer isso por horas com todos os problemas, exceto os mais triviais; portanto, você pode precisar cortá-los e passar para outra categoria para ter uma boa ideia de como eles pensam.
Descreva o comportamento causado por um bug real no seu sistema que foi meio difícil de entender. Pergunte a eles o que fariam se vissem esse bug durante o teste. Aqui, você está procurando redução de bug - a capacidade de encontrar o conjunto mais simples de circunstâncias que podem reproduzir um bug. Isso torna a depuração muito mais fácil para os desenvolvedores, uma vez que eles têm uma idéia melhor sobre o que causou o problema e demonstram uma capacidade clara de solucionar problemas e uma compreensão clara de quais fatores podem interagir para causar bugs. Com seu produto específico, discutir uma condição de corrida pode ser divertido.
Dê a eles um programa simples de linha de comando que você tenha hackeado (talvez semeado de bugs) e uma especificação simples, e deixe-os sentar no computador e brincar com ele, com o objetivo de encontrar problemas. Aqui você procura criatividade e capacidade de direcionar áreas problemáticas. Eles devem testar coisas como entradas grandes, entradas pequenas, entradas estranhas, entradas vazias. Se eles encontrarem um bug, peça que eles tentem descobrir exatamente quando esse bug acontece (novamente com a redução do bug!).
Pergunte o que eles fariam se um SDE responder a um bug com "No Repro" ou "Won't Fix", se eles achassem que o bug era importante. Aqui você está procurando alguém que não seja apenas uma tarefa fácil, mas também não seja antagônica. Respostas razoáveis incluem a adição de cenários de exemplo que demonstram mais claramente a gravidade do bug e a reabertura do ticket, conversando com o desenvolvedor para tentar entender por que as coisas foram resolvidas dessa maneira antes do fechamento, etc.
Converse com eles sobre seu aplicativo em um nível alto. Pergunte a eles que tipos de teste eles gostariam de realizar. Aqui você está procurando áreas gerais de teste, como teste de componente funcional, teste de integração, teste de desempenho e teste de segurança.
Se este é um engenheiro de SDET / automação, faça algumas perguntas para os desenvolvedores com aproximadamente 1/3 a metade do total de anos de experiência.
Se esta é sua primeira pessoa de controle de qualidade, verifique se eles podem iniciar automaticamente. Pergunte a eles como eles imaginam sua primeira semana ou mês de trabalho. Eles devem dizer algo sobre reunir requisitos e configurar ferramentas e descrever uma abordagem razoável para começar a testar. Você está procurando alguém que não precise de um chefe para dizer como iniciar os testes e que pode se autogerenciar. Se você já possui uma equipe de controle de qualidade, isso é menos importante.