Sei que tem havido muitas discussões sobre esse tipo de coisa e elas geralmente se transformam em dogmas sobre se você faz perguntas do tipo "100 piratas lógicos" ou se você faz com que escrevam "borbulhar".
Estou interessado em quais técnicas e perguntas foram eficazes para você ao entrevistar potenciais desenvolvedores de empregos.
Uma técnica por resposta para que possamos votar nelas, por favor.
Respostas:
Além de questões técnicas reais e, geralmente, no final da entrevista, tento entender o nível de interesse deles no setor e sua cultura com perguntas como:
Você viu algo recentemente relacionado à programação que achou interessante e gostaria de recomendar a outros colegas programadores? Um novo idioma, ferramenta, plataforma, técnica, site?
Você pode nomear qualquer pessoa conhecida em nosso setor cujo trabalho você goste ou ache inspirador e por quê? (desenvolvedor, fundador do site, autor, palestrante, etc.)
O que você está lendo agora ou qual foi o último livro relacionado a software que você leu?
Quais sites relacionados à programação você frequenta?
Embora não responder a essas perguntas (infelizmente acontece com muita frequência) não signifique um 'não-contrato' para mim, eles dizem muito sobre a maneira como uma pessoa aborda a profissão de desenvolvimento de software.
Faça-os escrever código, código real.
O entrevistador pode permitir que você escolha a linguagem de programação com a qual você se sente mais confortável, seja em C ++, Java, C # ou qualquer outra coisa, e peça para você resolver um problema simples, por exemplo, trabalhando com uma string ou uma lista duplamente vinculada ou o que seja. Se você tiver problemas para usar o seu melhor idioma para resolver um problema simples, existe um problema. Por favor, veja o post de Steve Yegge e, especialmente, a seção "Preparação mental".
Peça a várias pessoas da sua equipe que as entrevistem de forma independente. Compartilhe seus pensamentos depois, não fale antes de entrevistá-los. Conversar no meio vai influenciar o seu julgamento e você não terá avaliações independentes.
Para as pessoas técnicas que os entrevistam, eles escrevem código. Para não técnicos, não tente perguntar coisas com as quais você não tem experiência. Certifique-se de ter pelo menos algumas pessoas técnicas entrevistando.
As entrevistas não devem ser conduzidas apenas pelos gerentes; devem ser extremamente importantes para todos os trabalhadores com quem trabalharão no futuro.
Eu gosto de ter um entrevistado explicando seus projetos anteriores e o que eles fizeram. A partir desta resposta, posso ter perguntas de acompanhamento: por que eles fizeram as coisas de uma certa maneira, como resolveram um problema específico se mencionaram um, mas o mais importante era qual era o objetivo do projeto e qual o problema comercial resolvido.
Faço isso para ver se eles conseguem articular de uma maneira que me faça entender o que eles estavam fazendo e para ver se eles entendiam o que estavam fazendo também.
É surpreendente que tenha sido resolvida a última pergunta sobre o objetivo do projeto e o problema comercial que atrai muita gente. Eles não têm idéia do porquê do projeto em que estavam trabalhando. Se você não sabe por que o seu projeto existe em primeiro lugar, isso me faz pensar se você está contribuindo com soluções ou apenas fazendo o que é solicitado.
(Imaginei que eu joguei essa aqui, pois todas as outras respostas tendem a ser técnicas. Quero que as pessoas saibam por que estão resolvendo os problemas que estão resolvendo também; caso contrário, elas tendem a resolver os problemas errados que o usuário final não resolve '' não me importo com :)
Peça a sua opinião sobre uma importante decisão arquitetônica
Por exemplo. Aqui está o programa x que executa y número de subtarefas simultaneamente. Qual você escolheria, uma estrutura com vários processos ou threading.
Quais são os benefícios / desvantagens de ambos. Quão bem eles funcionariam e como poderiam ser usados para alavancar uma plataforma com múltiplos núcleos e processadores, qual é a sua preferência pessoal? Preconceitos pessoais podem ajudar a identificar se eles realmente tiveram que aplicar o conhecimento e dar a eles um ponto de partida para compartilhar suas experiências?
Há toneladas de perguntas que um entrevistador poderia apresentar como estas:
A maioria desses tópicos é do tipo que envolve um conhecimento íntimo de como / por que um sistema de computador funciona dessa maneira. Todos eles são questões / soluções para problemas que não têm resposta definitiva e, portanto, dão uma ideia de quão bem essa pessoa é capaz de adaptar ou superar os desafios em questão. Não é o tipo de conceito que pode ser facilmente entendido sem uma experiência prática real.
Nota: Também é necessário que o candidato escreva algum código de pesudo, mas essa resposta já foi aceita.
Apenas forneça a eles algum código básico para fazer no quadro branco - por exemplo, implementação de lista vinculada, classificação ou algo semelhante.
Você pode julgar quão confortáveis eles estão com o idioma deles sem a ajuda do compilador e o processo de pensamento deles (especialmente se eles nunca implementaram tal coisa - a maioria dos "novos" programadores nunca o fez).
Converse, deixe-o perambular pela rota técnica e profissional e procure comentários perspicazes ou estúpidos ao longo do caminho. Isso dá a você 3/4 do que você precisa em uma entrevista, uma avaliação de: habilidades e personalidade das pessoas, inteligência geral e uma avaliação aproximada das habilidades técnicas.
Use as "perguntas" da sua entrevista como iniciador de tópicos e para manter a conversa restrita a tópicos técnicos - talvez seja necessário redefinir a conversa de tempos em tempos (como fazer um exercício de codificação) para investigar adequadamente as áreas de interesse / interesse.
O verdadeiro truque dessa técnica é garantir que eles falem tudo, caso contrário, você corre o risco de uma avaliação favorável, porque eles fizeram você se sentir esperto ao ouvir / concordar com tudo o que disse.