ti-enxame.com

Que técnicas você usa ao entrevistar desenvolvedores?

Sei que tem havido muitas discussões sobre esse tipo de coisa e muitas vezes elas se transformam em dogmas sobre se você faz perguntas do tipo "100 piratas lógicos" ou se você os faz escrever "burburinho".

Estou interessado em quais técnicas e perguntas têm sido eficazes para você ao entrevistar desenvolvedores em potencial para empregos.

Uma técnica por resposta para que possamos votar nelas, por favor.

28
Paddyslacker

Além de questões técnicas reais, e normalmente no final da entrevista, tento entender seu nível de interesse na indústria e sua cultura com questões como:

  • Você viu recentemente algo relacionado à programação que achou interessante e gostaria de recomendar a outros programadores? Uma nova linguagem, ferramenta, plataforma, técnica, site?

  • Você pode citar alguma pessoa conhecida em nosso setor cujo trabalho você goste ou considere 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 a programação você frequenta?

Embora deixar de responder a essas perguntas (infelizmente, isso acontece com muita frequência) não signifique uma "não contratação" para mim, eles dizem muito sobre a maneira como uma pessoa aborda a profissão de desenvolvedor de software.

21
Sergio Acosta

Faça-os escrever código, código real.

O entrevistador pode permitir que você escolha a linguagem de programação com a qual se sente mais confortável, seja C++, Java, C # ou qualquer outra e pedir que você resolva um problema simples, por exemplo, fazendo algum trabalho com uma string ou uma lista duplamente ligada ou qualquer outra coisa. Se você tiver problemas em usar seu melhor idioma para resolver um problema simples, então há um problema. Por favor, veja post do blog de Steve Yegge e especialmente a seção "Preparação Mental".

16
grokus

Faça com que várias pessoas de sua equipe os entrevistem independentemente. Depois, compartilhe seus pensamentos, não fale antes de entrevistá-los. Conversar entre um e outro influenciará seu julgamento e você não terá avaliações independentes.

Para os técnicos que os entrevistam, faça com que eles escrevam códigos. Se não for técnico, não tente perguntar coisas com as quais você não tem experiência. No entanto, certifique-se de ter pelo menos algumas pessoas técnicas entrevistando.

As entrevistas não devem ser conduzidas apenas por gerentes, devem ser extremamente importantes para todos os trabalhadores com quem trabalharão no futuro.

11
Brian R. Bondy

Gosto que um entrevistado explique seus projetos anteriores e o que eles fizeram. A partir dessa resposta, posso ter perguntas de acompanhamento: por que eles fizeram as coisas de determinada maneira, como resolveram um problema específico se mencionaram um, mas o mais importante, qual era o propósito do projeto e que problema de negócios isso resolveu.

Faço isso para ver se eles conseguem se articular de uma maneira que me faça entender o que estavam fazendo e para ver se também entendiam o que estavam fazendo.

É surpreendente que a última pergunta sobre o propósito do projeto e o problema do negócio tenha resolvido que tropeçou em muita gente. Eles não têm ideia de POR QUE o projeto em que estavam trabalhando estava sendo feito. Se você não sabe por que o seu projeto existe em primeiro lugar, me pergunto se você está contribuindo com soluções ou apenas fazendo o que mandam.

(Percebi que joguei este aqui, já que todas as outras respostas tendem a ser técnicas. Eu quero pessoas que saibam por que estão resolvendo os problemas que estão resolvendo também, caso contrário, tendem a resolver os problemas errados que o usuário final não não me importo :)

7
Jay

Pergunte a opinião deles 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 multiprocessos ou threading.

Quais são os benefícios/desvantagens de ambos. Eles funcionariam bem e como poderiam ser usados ​​para alavancar uma plataforma multi-core e multiprocessador, qual é a sua preferência pessoal? Os preconceitos pessoais podem ajudar a identificar se eles já tiveram que realmente aplicar o conhecimento e dar-lhes um ponto de partida para compartilhar suas experiências.

Existem inúmeras perguntas que um entrevistador pode fazer, como estas:

  • TCP ou UDP?
  • Linguagem com tipagem estática ou dinâmica?
  • Aplicativo monolítico ou vários aplicativos menores?
  • O que você usaria para a comunicação entre processos?
  • Procedimentos armazenados ou ORM?

A maioria desses tópicos 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 uma resposta definitiva, portanto, dão uma ideia de quão bem aquela pessoa é capaz de se adaptar ou superar os desafios em mãos. Não é o tipo de conceito que pode ser facilmente apreendido sem alguma experiência prática real.

Nota: Fazer com que o requerente escreva algum código de pesudo também é uma obrigação, mas a resposta já foi obtida.

6
Evan Plaice

Basta fornecer 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 o quão confortável eles estão com sua linguagem sem a ajuda do compilador e você pode julgar seu processo de pensamento (especialmente se eles nunca implementaram tal coisa - a maioria dos "novos" programadores nunca o fez).

1
Josip Medved

Tenha uma conversa, deixe-o vagar ao longo do caminho técnico e profissional e procure comentários perspicazes ou estúpidos ao longo do caminho. Com isso, você obtém 3/4 do que precisa em uma entrevista, uma avaliação de: habilidades pessoais e personalidade, inteligência geral e uma avaliação aproximada de habilidades técnicas.

Use as "perguntas" da entrevista como tópicos de partida e para manter a conversa concentrada em tópicos técnicos - você pode precisar reiniciar a conversa de vez em quando (como fazer um exercício de codificação) para investigar adequadamente as áreas de preocupação/interesse.

O verdadeiro truque desta técnica é certificar-se de eles fale tudo, caso contrário você corre o risco de uma avaliação favorável porque eles fizeram você se sentir inteligente ao ouvir/concordar com tudo que você disse.

0
Mark Brackett