Trabalho da entrevista: quanto tempo é razoável? [fechadas]

Então, estou contratando uma função de desenvolvedor / equipe sênior para um projeto ASP.NET MVC3. Essa é uma posição importante para nossa equipe, pois essa pessoa liderará um de nossos dois principais produtos - um produto que não vê muito amor pelos desenvolvedores há algum tempo.

Portanto, preciso garantir que meus candidatos façam coisas inteligentes com controladores, visualizações, modelos de exibição, DALs, testes de unidade etc. Uso alguns desafios triviais de programação durante as entrevistas, mas quero dar às pessoas que têm problemas no código do quadro branco a chance de brilho.

A melhor tarefa que posso pensar: implementar uma página trivial de logon, é provavelmente mais de uma hora de trabalho e, mesmo que eu o limite às 2 horas, é improvável que esteja 100% concluído.

Isso é justo? Estou tentando encontrar um equilíbrio entre manter a tarefa razoável e dar ao candidato a chance de mostrar a ampla gama de habilidades que um líder técnico exige.

Tendo atuado nos dois lados desta questão, como gerente e candidato a emprego, acho que você está certo com 1 a 2 horas. Qualquer coisa mais fica frustrante para alguns dos candidatos a emprego (se não a maioria). Qualquer coisa mais curta, por outro lado, provavelmente não fornecerá informações e insights suficientes sobre o conjunto de habilidades do candidato.

A única coisa que gostaria de acrescentar é garantir que o trabalho da entrevista não seja uma surpresa completa; talvez seja razoável dar ao candidato uma idéia geral do que deve preparar (mesmo que seja apenas uma idéia geral). Eis o porquê: Às vezes passo alguns meses sem fazer nada além de programação relacionada ao banco de dados. Eu entro em um certo ritmo e, por um tempo, estou praticamente no topo da programação relacionada ao banco de dados.

Então me pedem para implementar apresentações de vídeo, treinamento etc. de maneira que ninguém possa arrancá-los ... e eu entro nesse ritmo, praticamente sem fazer mais nada.

Portanto, mesmo que você esteja entrevistando um desenvolvedor / líder de equipe, se o candidato parecer um cara legal, dê a ele a chance de descobrir o que você procura, novamente, se for necessário apenas mencionar alguns problemas gerais ou se você sentir que generoso, dê a ele um punhado de tópicos específicos para pensar.

Você e / ou outros podem discordar dessa abordagem, mas as entrevistas de emprego são difíceis. Você quer ter certeza de que o candidato está pronto para o rapé, mas também quer dar a eles oportunidades para impressioná-lo e se sentir confiante. Muito provavelmente, você descobrirá que esses candidatos fornecerão informações muito mais genuínas do que aqueles que estão em estado de nervosismo, porque sabem que haverá algum tipo de tarefa ... mas eles não sabem o que será.

Em poucas palavras, sim, acho que você está sendo justo!

Deve-se supor que o currículo deles mostre que eles podem codificar; caso contrário, por que você os entrevistaria? Se você não consegue ver que o código não os traz, está desperdiçando seu tempo.

Dito isso, eu me preocuparia mais com o modo como eles abordam a solução do que com a parte mecânica da solução (o código) e como eles comunicam sua solução. É por isso que existem quadros brancos.

Se você fornecer a eles um conjunto básico de requisitos e a primeira coisa que eles não fizerem, começar a pedir detalhes, isso é uma greve. Você deve ter um conjunto específico de coisas que deseja ouvi-las dizer ou perguntar com antecedência, isso é mais trabalhoso para você, mas basear sua decisão em algo como isso é mais preciso do que ter alguém cortando algo que não deve funcionar de qualquer maneira .

Os membros seniores da equipe devem ser capazes de projetar uma solução, apresentá-lo e explicá-lo e defender quaisquer decisões, se necessário, ou adaptar qualquer decisão com base no feedback e comunicar o plano aos membros juniores da equipe e explicá-lo de uma maneira orientada.

Essa interação humana é mais importante do que fazer com que eles concluam parcialmente uma tarefa de trabalho ocupado no nível de entrada. O que a maioria não vai querer fazer; se eles o fizerem e se receberem uma oferta posteriormente, provavelmente recusarão, pois é uma tarefa humilhante.

Existem muitos codificadores veteranos de cowboys que não têm habilidades pessoais e nem trabalham em equipe; um teste artificial que você propõe não eliminará essas pessoas e confie em mim que você não quer um desses tipos de pessoas em uma equipe de qualquer tamanho!

Se o acesso ao banco de dados não fizer parte da pergunta, espero que 2 horas sejam suficientes para que um recurso mínimo de login funcione.

Mas não passe ou falhe com o candidato com base na integridade, mas revise a abordagem adotada.

Certifique-se de fazer muitas perguntas de acompanhamento sobre o código após o término da entrevista.

• o que você faria se eu tivesse o bloqueio do usuário após três tentativas?
• como você implementaria o acesso a dados?
• como você implementaria os testes de unidade?
• como você melhoraria esse código?

Parece razoável, mas convém incluir pelo menos outra página usada após o login na página de login.

Se você espera que eles façam essa tarefa em seu escritório durante a entrevista, informe-os com antecedência, para que eles possam planejar e alocar o tempo necessário para a entrevista. Na minha experiência, as entrevistas não duram mais de uma hora; portanto, é justo que eles saibam o que esperar e quanto tempo você lhes dará.

A outra opção é permitir que eles concluam sua tarefa em casa, mas isso lhes permite usar mais tempo e recursos (por exemplo, obter ajuda). No entanto, isso permite atribuir a eles uma tarefa mais complicada que pode mostrar tudo o que você espera que eles saibam.

Totalmente justo, desde que você informe antecipadamente quanto tempo é necessário para a entrevista. Se alguém não quiser escrever seu teste, não será necessário contratá-lo. Já fiz testes mais longos e apreciei pessoalmente. Um em particular foi difícil e mais longo do que o tempo alocado, mas foi uma excelente medida das habilidades de recursos, estabelecimento de prioridades e resolução de problemas dos candidatos. Esse empregador tinha desenvolvedores muito qualificados trabalhando lá.

Acho que você está no caminho certo com o que procura em um candidato. Com demasiada frequência, um currículo lista um milhão de coisas sobre as quais o candidato leu, mas na verdade não sabe. Às vezes, você pode eliminar essas coisas em uma entrevista regular, mas se quiser saber se alguém pode realmente fazer algo, faça-o.

Apenas verifique se as expectativas são claras e você está testando as habilidades mais importantes para o trabalho.

No seu cenário, também posso me preocupar com o quão bem o candidato entende HTML, javascript e layout.

Deseja atribuir a mesma tarefa a todos os candidatos. Você deve conseguir chegar a uma lista restrita de um. Você designação / teste, existe para mostrar que o candidato não pode apenas falar, mas também pode caminhar.

O que eu faria é trazer o candidato de volta, informar que ele está em uma lista curta (não diga 1), colocá-lo com um ou dois de seus colegas de trabalho em potencial (do dia-a-dia) e obter o " equipe "para resolver o problema. 1-2 horas será mais do que suficiente para a equipe informar que eles são bons o suficiente, líder ou seguidor, executor ou preguiçoso, competente ou .... etc.

Você é uma empresa pequena e nada destruirá sua organização mais rapidamente do que relacionamentos pessoais disfuncionais, escaladores, contrabandistas e psicopatas do local de trabalho (cerca de 1 em cada 20 são). Concentre-se em se o candidato tem a atitude correta, se ele é tecnicamente mediano e tem, ele executará 90% dos candidatos que são especialistas. A programação pode ser uma tarefa individual, mas o desenvolvimento de software requer uma equipe forte - e você procura um líder de equipe e um técnico.