A pergunta nº 11 do Teste Joel é: "Os novos candidatos escrevem código durante a entrevista?". Quais são os argumentos a favor e contra para pedir aos novos candidatos que escrevam código durante a entrevista e tomem uma decisão sobre isso?
Respostas:
Eu não vejo os contras. Uma entrevista tem muitas partes, e um candidato deve ser endossado "na cadeia" algumas vezes.
Eu entrevisto ~ 10 pessoas semanalmente. Eu realmente, realmente, realmente aprecio o fato de que o RH fez todo o trabalho em segundo plano e me apresentou muitas anotações. Quando eles chegam a mim, é hora de eu marcar os testes.
Os testes dependem inteiramente da posição. Geralmente, tento sondar:
Habilidade de programação geral. Você pode usar operadores efetivamente? Você pode conceber um sistema numérico que tenha uma raiz que não seja 10?
Você sabe como fazer o que estamos contratando?
Avaliação de suas contribuições para qualquer projeto de código aberto que você listou
Eu tento mantê-lo curto e divertido. Quando entro no escritório, pego as respostas, as examino e conduzo uma entrevista secundária. Para ser contratado, você normalmente precisa passar por três entrevistas.
Também avalio o quão bem você irá se misturar com a equipe que o receberá. Essa equipe conta comigo para fazer isso de forma eficaz.
Uma coisa é responder a perguntas na forma meta; outra é realmente produzir código. Se eu vou contratá-lo, preciso ver você produzir código.
Com desculpas a Scott Whitlock:
Contras:
Prós:
Se você fosse contratar um malabarista, seria uma loucura não fazê-lo fazer malabarismos com você. Ou um músico você teria audição. Caso contrário, você recebe coisas como o impressionante ioiô "mestre" K-strass .
Percorrer algo em um quadro branco é o equivalente dos programadores de uma rápida demonstração.
Eu acho que é super útil, e sempre o faço, mas como os benefícios foram cobertos tão bem, vou discutir apenas os negativos (aparentes).
Acho que é pouco provável que os testes de código lhe dêem falsos positivos: as chances são baixas de que alguém que realmente não pode escrever código consiga falsificá-lo em uma entrevista, pelo menos se você tiver uma escala de perguntas de dificuldade crescente. (Talvez o cenário mais provável seja que eles trapaceiem perguntando a um amigo, se não for uma entrevista cara a cara.)
Os problemas estão mais no lado falso-negativo: os testes de código levarão você a rejeitar a pessoa que é realmente o melhor candidato?
Medo do palco
Você pode ter alguém que é realmente um desenvolvedor muito bom, mas que está muito nervoso com esta entrevista, e eles ficam basicamente assustados. Atuar sob pressão é importante até certo ponto, mas lidar com o medo do palco não é uma parte essencial de ser um programador (em comparação com outras profissões), e seria lamentável rejeitar alguém que sofre muito com isso. Isso pode se agravar: se a pessoa não puder responder a uma pergunta que sabe que deve responder, poderá ficar mais rígida. Ou, como nesta pergunta , eles sentem que não podem falar e codificar ao mesmo tempo.
mitigação: comece com algumas perguntas sobre como conhecer seus antecedentes, objetivos etc. antes de entrar em questões técnicas. Talvez comece com algumas perguntas técnicas mais fáceis, para que elas tenham algum momento. Não seja idiota durante a entrevista (discutindo sobre ponto e vírgula, etc.).
É uma medida barulhenta
Perguntas interessantes sobre código podem ter mais de uma resposta correta. Se uma pessoa escreve uma resposta correta e outra escreve uma resposta correta e mais eficiente, quanto peso você deve colocar nela?
Até certo ponto, esse é o problema de algumas perguntas "enigmáticas": a pessoa tem o insight ou não e você obtém um resultado quase binário. A inteligência provavelmente afeta a probabilidade de ter esse insight, mas a amostragem apenas algumas vezes fornece uma medida grosseira.
Isso me incomoda sobre as questões de código (embora eu ainda as use.) A melhor mitigação em que posso pensar é ter, na medida do possível, uma rampa de soluções possíveis: a pessoa pode pelo menos escrever uma resposta bruta de força bruta ou uma resposta para uma parte do problema. Perceber que é melhor que nada é um bom sinal. Então, se descobrirem mais, poderão torná-lo mais eficiente ou mais elegante. Na medida do possível, evite fazer perguntas que obtenham respostas binárias.
Não é realmente representativo
Programar não é tarefa de resolver problemas algorítmicos de dez minutos, um após o outro: há muito mais trabalho para entender e projetar sistemas maiores e se concentrar por longos períodos de tempo, para não falar das habilidades interpessoais. As questões de código realmente não testam isso.
Porém, as questões de código não são as únicas perguntas que você fará: você pode observar os antecedentes, as referências, o trabalho de código aberto (se houver), para encontrar evidências de esforço contínuo, criatividade e habilidades interpessoais.
Saber como resolver pequenos problemas algorítmicos e reduzi-los ao código é uma condição necessária, mas não suficiente: se você não pode resolver pequenos problemas e não pode escrever código não trivial, então todo o pensamento geral do mundo não é vai fazer de você um desenvolvedor produtivo.
Qualquer um poderia resolver isso
Não, aparentemente não. Como o famoso post do FizzBuzz aponta, os problemas que você pode pensar são uma armadilha trivial, não apenas para os recém-formados, mas para as pessoas com anos de experiência no setor. Não sei porque. Ou o teste de código é uma medida ruim (o que é possível, embora eu ache improvável), ou eles não estavam contribuindo muito para os projetos em seu currículo ou estavam fazendo muito por copiar e colar não- código algorítmico (o que é possível.)
Vale a pena reconhecer que você realmente pode fazer muito sem escrever nenhum código algorítmico. As pessoas ganham muito dinheiro com aplicativos cujo valor está nos gráficos ou na lógica de negócios e não no que você poderia chamar de "programação", e isso é bom. Mas, se você realmente precisa de programadores, não é um bom ajuste.
Pode não estar bem calibrado
Se você fizer uma pergunta, a resposta pode muito bem parecer fácil para você. No entanto, se você fizer alguma pergunta comparável do nada ou se não for direcionada a seus interesses e antecedentes, pode ser muito mais difícil.
mitigação: execute os testes em alguns desenvolvedores que você já conhece e veja como eles funcionam. Talvez alguém que já seja da sua equipe e que você conhece seja muito inteligente, tenha problemas com um deles e considere ajustá-lo. Talvez eles pensem em uma resposta melhor ou diferente.
É muito parecido com trivialidades
Eu acho que as questões de código certamente podem ser triviais, se você insistir que as pessoas conheçam APIs obscuras de cor, ou obtenha a sintaxe perfeita, ou lembre-se da definição exata de um algoritmo não trivial. É razoável confiar nesses documentos, pesquisas na Web ou erros de compilador e ter pouca correlação com os conhecimentos reais. Nem mesmo saber onde é provável que a API esteja talvez seja uma pista de que a pessoa não a usou recentemente, mas isso não é necessariamente um problema, desde que ela não esteja no currículo.
Portanto, a resposta para isso é bastante simples: não faça perguntas triviais e não fique preso a erros triviais. Lembre ao candidato como a API é chamada ou deixe-a procurar; corrigir erros de sintaxe; não teste para pessoas que memorizam definições de estrutura de dados.
Como você compara?
Se você tem dois candidatos e ambos respondem bem às perguntas, como escolher entre eles? Você pode escolher quem terminou mais rápido, mas talvez aí comece a escolher lebres em vez de tartarugas. Você poderia fazer outra rodada e fazer perguntas muito mais difíceis, mas também não tenho certeza. Talvez você apenas dê a ambos um A + e tente escolher entre eles de acordo com outros critérios (ou tente encontrar o dinheiro para contratar os dois).
Um argumento que consigo pensar é que é difícil "codificar em voz alta" na frente de outras pessoas. Acho difícil até digitar com alguém olhando por cima do meu ombro e não estou sozinha. Percebo que quando alguém me chama para sua estação de trabalho para ajudar em alguma coisa, de repente, começa a digitar erros de digitação, selecionando a conclusão incorreta do código e até mesmo cometendo erros óbvios - nenhum dos quais eles teriam cometido se eu não estivesse sentado ali. Inferno, já vi pessoas começarem a usar o menu para operações de recortar e colar, apenas porque estavam sob observação. Esse não é um comportamento normal, e os codificadores de que estou falando são excelentes programadores e bastante inteligentes.
Recentemente, tive uma entrevista na qual o entrevistador me perguntou como codificaria uma operação específica e ele disse: "Apenas me mostre a matemática". Bem, eu tive que pensar no problema primeiro antes de começar a matemática, de modo que eu estava me bajulando. O que eu coloquei no quadro branco no começo foi embaraçoso, e eu senti que estava perdendo naquele momento. Acabei tendo o momento do A-ha e encontrei a resposta (na verdade, quando finalmente me ocorreu o que ele estava realmente perguntando), mas a "bagunça" que eu fiz antes de chegar lá me fez sentir muito desconfortável. No entanto, consegui o emprego, mas se o entrevistador tivesse sido menos paciente, talvez não.
Acho que se você der aos entrevistados uma tarefa de codificação, dê-lhes algum tempo para trabalhar em um computador, talvez até em um IDE com o qual estejam familiarizados. Deixe-os escrever o código para você e depois falar sobre ele. Pergunte a eles por que eles fizeram as coisas de uma certa maneira e se outra maneira pode não ser melhor. Você descobrirá mais desse tipo de processo do que pedindo que eles (figurativamente falando) façam xixi em um copo bem na sua frente.
Contras: Nenhum. Sempre que você gasta configurando um PC, projetando um teste de código e analisando-o, você economiza dor de cabeça incalculável no futuro.
Prós: "Confie, mas verifique" - Ronald Regan. Tantas vezes eu já vi e ouvi falar de pessoas que finalmente se afastaram de uma posição em que, na entrevista, você pensaria que estava recebendo uma estrela do rock. A prova está no pudim; Eu quero ver o que eles podem fazer. Representará o que acontece depois que você investe tempo e dinheiro na contratação de alguém e coloca um novo projeto na frente deles.
Contras:
Prós:
Quando entrevistei para o meu trabalho atual, recebi uma lista de perguntas para escrever o código pelo recrutador. Fiquei muito impressionado, porque as perguntas foram obviamente escritas por alguém que tinha um profundo conhecimento de SQL, por isso funciona nos dois sentidos.
Você realmente deseja que a pessoa escreva o código na entrevista - melhor ainda, faça com que ela pareie o programa com um membro da sua equipe por um período de tempo X (o que você puder pagar confortavelmente em tempo / mão de obra).
É praticamente uma das únicas maneiras de saber se essa pessoa pode codificar ou não.
Eu prefiro um pouco a programação dos pares, pois mostra o trabalho da equipe, dá a eles um IDE real para trabalhar e permite que eles trabalhem em um problema 'real' (a outra pessoa do par pode orientá-los a superar quaisquer detalhes ambientais que o entrevistado nunca poderia razoavelmente saber sobre).
Começamos a usar essa política de contratação e estamos muito felizes com os resultados.
Você julga um pássaro por suas penas e um programador por seu código.
Quando comecei na empresa atual em que estou trabalhando, eles me pediram para escrever um código C que gera ou verifica o bit de paridade de alguma entrada binária (dependendo de você estar codificando ou decodificando). Esta foi uma pergunta de entrevista exatamente porque esses tipos de problemas são resolvidos durante o trabalho. Claro que estou pensando em não verificar a paridade, mas trabalhar em um nível baixo.
Todas as respostas até agora (que li) não tratavam do fato de que o Teste Joel NÃO é (apenas) uma lista de práticas recomendadas para empreendedores, mas uma lista de verificação para facilitar sua avaliação de um possível empregador .
O problema é que, se eles testam minuciosamente seus candidatos, provavelmente contratam pessoas que sabem o que fazem, o que significa para você
em vez de consertar os erros deles ...
Eu diria:
Prós
Contras
Reversemétodo interno ou similar, ou para testes escritos, coisas como" Quais são os argumentos para o Foométodo da Barclasse ", quando qualquer idiota poderia pesquisar no Google isso ou usar a documentação) em oposição às questões de arquitetura / design que mostram o candidato pode fazer as coisas e resolver problemas de negócios .Um profissional é que mostra que alguém tem conhecimentos básicos de programação ou o que quer que seja (a última vez que o encontrei, fiquei surpreso com o quão básica era a questão SQL). Também pode servir de base para uma discussão técnica, perguntando por que o candidato fez isso e aquilo e como poderia ser melhorado.
Leva tempo na entrevista, que pode ser usada para outras coisas. Além disso, escrever código em um quadro branco não é um ambiente natural e algumas pessoas terão problemas cada vez menos sérios. Isso pode fazer com que você perca um desenvolvedor que fica nervoso sem ferramentas ou referências normais.
A programação é uma habilidade altamente técnica, com um monte de "entregas" claras. Um candidato pode ou não pode entregá-los. Portanto, não há "contras" em fazer perguntas técnicas. É inteiramente para dizer: "mostre-me algum código para este aplicativo ou" mostre-me o código para um aplicativo que você JÁ escreveu. "
NÃO fazer isso pode levar a um resultado como o seguinte: Um homem rico entrevistou um tutor para ensinar seus filhos a jogar xadrez (como um exercício de expansão da mente). O tutor abriu um tabuleiro de xadrez e começou a falar sobre os 64 quadrados, mas não tocou em uma peça de xadrez. Pressionado pelo tempo, o pai contratou o tutor de qualquer maneira. E o tutor ensinou as crianças a jogar Damas.