No cenário de uma entrevista: Qual é a melhor maneira de identificar com segurança quando alguém é um excelente programador ? Com isso, quero dizer que ele é um daqueles que é 10 a 15 vezes mais eficiente / rápido / melhor do que seus pares na extremidade inferior do espectro.
Muitos de nós já ouvimos falar do problema do FizzBuzz como uma maneira de eliminar os fracos. Certamente, levar de 5 a 10 minutos para resolver esse problema é um indicador sério de que um candidato é um candidato fraco. Eu acredito que um bom indicador é capaz de resolver isso o mais rápido que você pode escrever. Isso não parece suficiente, no entanto.
Talvez seja algo como dar a ele um programa de buggy moderadamente complicado e ver com que rapidez ele consegue entender e identificar todos os problemas com ele?
fonte
Respostas:
Peço desculpas a quem não se importa com respostas longas, mas acho muito importante qualificar seus candidatos antes de contratá-los. Qualquer pessoa que tenha conduzido uma quantidade significativa de entrevistas nesse setor sabe que a maioria dos candidatos não vai durar até os primeiros 15 a 30 minutos de uma entrevista; portanto, a maior parte dessa lista não será necessária. Lembre-se de quão caro é (tanto financeiramente quanto emocionalmente) demitir alguém antes de descartar minha lista como um exagero. Tentei listar meus tópicos de entrevistas aqui por ordem de importância.
Inteligência geral (quebra-cabeças / quebra-cabeças lógicos)
Conhecimento em Ciência da Computação
Exercícios de programação
Conhecimento de técnicas de programação orientada a objetos e padrões comuns de projeto
Análise de algoritmo ( complexidade de tempo de execução O (n) e requisitos de armazenamento)
Uso de ferramentas e metodologias
Conhecimento de vulnerabilidades e ataques de segurança comuns
Matemática Básica
Criptografia
Matemática Discreta
Você também pode dar uma olhada no livro Programming Interviews Exposed . É uma boa referência sobre o assunto.
fonte
Ah, a eterna pergunta.
Fiz muitas entrevistas este ano (tenho dois candidatos agendados para amanhã) e, na minha experiência, contratar é mais sobre sentimentos e habilidades pessoais e menos sobre conhecimento técnico.
Leve o seu tempo com os currículos. Alguns currículos podem ser rejeitados em segundos, outros levam meia hora. Às vezes, penso no candidato com base no currículo muito mais tempo do que o entrevisto. Algumas vezes eu preparei perguntas da entrevista especificamente para esse candidato, mesmo que normalmente não tenha perguntas preparadas.
Conhecimento técnico - há um mínimo que eu quero, e isso geralmente é bastante fácil de dizer. Em caso de dúvida, durante a entrevista, fale sobre os projetos que ele mencionou no currículo e vá o mais profundo que precisar. Isso geralmente é mais do que suficiente para dizer o que ele sabe e o que o faz funcionar. A educação não é importante, os empregos anteriores são importantes, os possíveis projetos pessoais são altos.
Pergunte sobre o que ele quer fazer e para onde ele quer seguir sua carreira - você precisa do que ele tem e pode fornecer o que ele quer? Além disso, quase no final da entrevista, geralmente pergunto sobre um salário preferido. Se ele estiver fora do meu alcance, ou se eu não pagar tanto pelo que ele sabe, é aí que terminamos a entrevista.
Mais importante, o candidato deve se encaixar na equipe, e eu devo me sentir confiante de que seremos capazes de trabalhar juntos. Eu não preciso gostar dele, mas devo ser capaz de lidar com ele, e ele precisa ser capaz de lidar comigo. Se não for esse o caso, vou aprovar, porque não poderei usar o conhecimento técnico dele. Por outro lado, se esse for o caso, e se ele for um aprendiz rápido, sua falta de conhecimento técnico não me impedirá de contratá-lo.
Treinei as meninas do RH para me passarem os currículos assim que os obtiverem; Programei a entrevista pessoalmente, o mais rápido possível (idealmente, depois de amanhã, depois de receber o currículo de bons currículos). Depois, ele recebe uma entrevista de meia hora ou uma hora comigo e pelo menos um colega de trabalho (geralmente meu chefe ou membro da equipe), onde eu o conheço e respondo a qualquer pergunta. Mesmo que eu rejeite sua solicitação no local, ele faz um tour de 20 a 30 minutos pela empresa e eu falo sobre o que fazemos e como fazemos. Então eu o envio ao RH para testes psicológicos e um pouco de codificação de papel realmente muito básica / SQL. Ambos os testes quase nunca desempenham um papel significativo na minha decisão, é mais uma verificação que julguei corretamente na entrevista. Após os resultados, são 15 minutos de conversa em que eu faço uma oferta a ele e, se negociarmos os termos com os quais estamos felizes, ele será contratado.
Esse é um processo pelo qual eu tive que lutar pela burocracia da empresa, depois de perder alguns ótimos candidatos, e que funciona porque sou eu quem decide sobre a contratação (embora eu ouça os conselhos de RH e colegas de trabalho, meu palavra é final). Mais tomadores de decisão, processos mais longos. Quanto mais longo o processo, mais você precisa ser o Google para se destacar.
Assim que eu tenho certeza de que não é páreo, eu termino a entrevista, ele começa a turnê da empresa e acaba. Pode demorar apenas dois minutos no telefone durante o agendamento da entrevista. Mesmo se você rejeitar um candidato, venda a empresa. Se você fez um bom trabalho, um bom contratado pode ser divulgado pelo candidato rejeitado.
Além disso, uma dica. Envie cartas de rejeição (ou e-mails) para cada aplicativo que você receber. Na minha empresa atual, costumo deixar isso para o RH (além dos que eu conto durante a entrevista), mas a certa altura foi inestimável obter uma resposta encantada do candidato rejeitado nas linhas de "OBRIGADO! Você é a primeira empresa que realmente respondeu em vez de me deixar pensando se eles responderiam um dia! "
fonte
Essa resposta está um pouco fora da caixa, mas acho que é um ponto valioso.
Os melhores programadores raramente entrevistam. Eles não precisam . Se sua empresa está particularmente mudando o mundo, ou empolgadamente envolvida em sigilo, ou vários programadores que eles respeitam já foram para lá, então eles podem se inscrever, mas normalmente grandes programadores conseguem empregos através de sua rede de associados, não enviando currículos.
Então: a melhor maneira de contar a um excelente programador em uma entrevista de emprego é que ele não está lá .
fonte
Qualquer resposta deve incluir exemplos de código. Contratar um programador sem ver seu código é gostar de contratar um chef sem tentar cozinhar.
fonte
Possivelmente um programador "excelente" não está vindo para você para uma entrevista. Você provavelmente tem que roubá-lo de outra pessoa.
fonte
Uma maneira de diferenciar os programadores apaixonados dos programadores "Eu só quero um emprego" é perguntar a eles que livro eles estão lendo esta semana. Depois pergunte a eles sobre os livros que leram nas últimas semanas.
Eu descobri que os programadores apaixonados estão SEMPRE lendo, e geralmente a lista inclui alguns programas / Comp. Sci. livros na lista recente.
Não se trata apenas de acompanhar a profissão - programadores apaixonados têm um desejo e amor pela programação e tendem a devorar material sobre uma variedade de tópicos - não apenas o idioma que eles estão usando agora, mas metodologias e outros idiomas (especialmente novos ou "estranhos" ou antigos), outros aspectos da TI (talvez robótica, IA ou jogos ou ...)
Se eles não têm uma lista de livros recente, provavelmente não são muito programadores, na minha experiência.
Felicidades,
-R
fonte
Existem escalas de tempo diferentes nas quais alguém pode ser "rápido": algumas pessoas inteligentes podem resolver quebra-cabeças difíceis em segundos, mas algumas pessoas inteligentes produzem muito código bom em um mês, mesmo que não sejam tão rápidas nas perguntas da entrevista.
Pergunte aos candidatos se eles estão ativos em qualquer projeto de código-fonte aberto onde você possa revisar parte do código deles e gaste algum tempo lendo os arquivos da lista de discussão e os registros de confirmação desses projetos. Isso lhe dirá muito mais do que qualquer coisa que os candidatos possam demonstrar em uma entrevista. (É claro que isso não pode substituir a entrevista, pois nem todos os bons codificadores fazem trabalho de código aberto.)
fonte
O livro " Inteligência e realização das coisas: guia conciso de Joel Spolsky para encontrar o melhor talento técnico " pode ajudar a encontrar uma resposta.
Tabela de conteúdo:
O artigo de Joel "O Guia de Guerrilha para Entrevistas (versão 3)" também pode ser útil.
E o artigo "Concluído e Inteligente", de Steve Yegge, sobre o tema.
fonte
Faça a eles uma série de perguntas que exigem codificação e faça com que as perguntas se tornem mais difíceis. Se eles parecem gostar do desafio, você provavelmente tem um ao vivo.
Se eles não puderem responder à primeira pergunta fácil, como "escreva um loop for" ou algo estupidamente fácil, você saberá que essa pessoa não pode codificar.
fonte
Faça com que eles codifiquem em um quadro branco. A única maneira de saber se eles sabem escrever código.
fonte
Você deve julgar principalmente o trabalho que eles já fizeram. Qualquer código ou idéia que alguém gere durante uma entrevista cheia de ansiedade é um proxy ruim para o que eles podem realmente produzir em uma equipe.
Para enfrentar os desafios de codificação, use IM com algo como codepad.com e permita que eles façam isso no conforto de sua própria casa. Você escreve muito do seu código em um quadro branco na frente do seu chefe, com um prazo de 30 minutos e seu bônus em jogo? Eu não.
Então, a entrevista é inútil? Não, mas a ênfase deve estar nelas explicando o que fizeram e exatamente o que contribuíram.
Você também estará sujeito a todos os tipos de preconceitos psicológicos quando encontrar alguém pessoalmente. Não contrate acidentalmente um programador, porque ele fez um melhor contato visual ou é mais alto que alguém. Para contorná-las, eu realizaria o máximo possível da entrevista por IM / e-mail antes de encontrá-las pessoalmente.
fonte
A linguagem não importa. A lógica faz. Quero dizer, IDE e compliers são tão bons hoje em dia que qualquer bom programador pode pegar qualquer idioma (ok, talvez não seja assembler) em uma semana; tornar-se decente em algumas semanas e ser muito bom em alguns meses.
É o cérebro dele (dela) que você precisa confirmar. E você faz isso da minha maneira. Peço-lhes que resolvam problemas simples. Não escrevendo código, mas me guiando pela lógica deles para chegar a uma solução.
Mas admito que, se ele não pode escrever um loop simples, contando de 1 a 10, você tem problemas.
fonte
Primeiro de tudo, há uma maneira de você ter uma idéia antes mesmo da entrevista começar:
Se eles têm um blog ou contribuem para um ou mais projetos de código aberto, basta olhar para o código e os artigos que eles escreveram. Primeiro de tudo, se eles fizeram um desses, então eles têm a iniciativa de fazer as coisas. Além disso, você pode comparar essas coisas com a experiência de trabalho listada em seu currículo e ter uma idéia se for para casa e aprender mais depois do trabalho, ou se for para casa e esquecer o trabalho depois das 17h.
Essencialmente, eles têm paixão por programar ou não? Essa é a verdadeira questão.
fonte
Ter um bom programador presente na entrevista é melhor na minha opinião.
Somente um especialista pode julgar se o candidato conhece muitas perguntas da entrevista ou se está realmente pensando nos problemas e pode entrar em detalhes. Lembre-se, você não quer contratar pessoas para resolver quebra-cabeças de entrevistas, mas sim para contratá-las para realizar o trabalho real.
Os quebra-cabeças são para excluir pessoas que não entendem o básico. Se você quiser testar a habilidade, prepare algumas coisas sobre as quais você (ou seu "bom programador") pode entrar em detalhes e se concentrar naquilo em que o candidato deve pensar por um tempo. Como ele aborda problemas dos quais não conhece imediatamente a solução?
fonte
Eu não acho que você deva falar sobre paixão na entrevista. Francamente, parece que uma empresa que procura "paixão" realmente significa "trabalhar sem dinheiro para a idéia".
A paixão nem mesmo garante excelência. Quero dizer, passo quase toda a minha vida programando, lendo sobre programação, aprendendo idiomas malucos como Erlang ou Clojure e não sou pago por nada disso. No entanto, sou péssimo em programação.
Eu acho que um excelente programador deve ter uma trilha de projetos bem-sucedidos nos quais eles estão ativamente envolvidos. Assim, fazer um programador escrever algo acima do FizzBuzz básico é desnecessário na entrevista. Fale sobre seus projetos anteriores e o que eles fizeram. Você está contratando programadores para resolver os cubos de Rubik e contar bolas de gude ou trabalhar em projetos de software longos e grandes e exaustivos com mais de 50 linhas de código?
fonte
http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/
Do artigo:
Os critérios em marcadores
Portanto, em resumo, aqui estão alguns indicadores e contra-indicadores que devem ajudá-lo a reconhecer um bom programador.
Indicadores positivos :
Indicadores negativos :
Programar é um trabalho diário
Realmente não quero “conversar”, mesmo quando incentivado a
Aprende novas tecnologias em cursos patrocinados pela empresa
É um prazer trabalhar com a tecnologia escolhida, "todas as tecnologias são boas"
Não parece muito inteligente
Começou a programar na universidade
Toda a experiência de programação está no currículo
Focado principalmente em uma ou duas pilhas de tecnologia (por exemplo, tudo relacionado ao desenvolvimento de um aplicativo java), sem experiência fora dele
fonte
Um excelente programador também poderá trabalhar com esses pares de baixo espectro. Contanto que eles possam fazer o teste e não se afundem em seu ego, então você tem um bom candidato, não?
Esse teste fizzbuzz é meio engraçado. A solução em que consigo pensar usa o operador modulo. O que eu sei apenas ao elaborar as coordenadas de mapeamento das fichas de caráter (nunca mencionadas na escola ou faculdade). O programador médio saberia disso ou eu tive uma educação ruim?
fonte
Um critério que eu uso é ver o 'tipo' de idiomas e ferramentas em que ele trabalhou, em projetos acadêmicos ou profissionais e o que exatamente ele alcançou. Ele sempre trabalhou no nível do aplicativo usando bibliotecas padrão (sempre um cara em C # ou VB6?) Ou ele fez um projeto usando C no Linux lidando com coisas graves, como ponteiros, gerenciamento de memória, recursão, sincronização de processos, exclusão mútua, eventos etc. Se ele sempre usou esses conceitos fundamentais e fundamentais sob alguma camada de abstração, ficarei em dúvida.
Obviamente, isso além de fazê-lo escrever código. Nada é um substituto para isso. No entanto, atendo ao fato de que algumas pessoas podem escrever código mais rapidamente do que outras, e as pessoas têm um tempo de resposta diferente quando estão em uma entrevista em destaque.
fonte