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.
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".
fonte
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.
fonte
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 :)
fonte
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.
fonte
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).
fonte
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.
fonte