Necessita*** de um teste de programação. Mas devem ser 5-10 minutos. 30 minutos no máximo. Não há nenhum teste de 2 horas que lhe diga exactamente o quão bom é um programador. Não será capaz de dizer se eles escrevem continuamente código de manutenção, ou se comentam sempre de forma adequada, ou se surgem erros ilegíveis de soluções ‘inteligentes’ para problemas, etc. Em 2 horas, a única coisa que vai conseguir é descobrir quem está a mentir sobre conhecer uma língua/programação.

Excepto que deve ser capaz de detectar fraudes em muito menos tempo do que 2 horas. 5 minutos a escrever FizzBuzz e 2-3 perguntas rápidas sobre características específicas da língua dir-lhe-ão se são absolutamente inúteis. E isso é o melhor que pode fazer numa entrevista de emprego.

Deixe-me dizer-lhe o que eu pensaria se recebesse um exame de 2 horas pelo privilégio de conduzir uma entrevista:

“Ou estas pessoas pensam que isto tem valor, o que significa que não fazem ideia do que estão a fazer, OU, elas sabem que isto é uma perda de tempo, mas por alguma razão (provavelmente seguindo cegamente a burocracia dos RH), estão dispostas a desperdiçar o tempo dos candidatos antes mesmo de o candidato ser contratado. Imagine o que eles vão pensar que podem escapar quando me pagarem.

De qualquer forma, não quero trabalhar lá”

• *

Há outra coisa que pode estar a afastar os candidatos: A duração do seu processo de entrevista. Tem pessoas a fazer uma entrevista por telefone. Depois um teste para levar para casa que têm uma semana para terminar. Depois, passa por cima dos testes. Em seguida, organiza uma entrevista de rosto com a direcção. Depois (presumo) faz duas entrevistas de rosto. Depois volta a ter o tipo que quer contratar. O que é preciso para isso? 2 semanas? Mais tempo?

Nesse tempo eu já recebi 3 ofertas. Eu aceitei uma e começo na próxima semana. Achas que vou fazer o teu teste de 2 horas?

Permitam-me que comece por dizer que a contratação de empregados em geral é uma ciência pateticamente inexacta, e os senhores obterão vários resultados, independentemente do que tentem fazer. Dito isto, senti que devia partilhar as minhas ideias sobre este assunto.

Penso que os exercícios de programação são um fracasso, principalmente porque vão conseguir que as pessoas que estão desesperadas e têm demasiado tempo para o completar. Se tiverem um emprego a tempo inteiro, terão de perguntar quanto tempo/energia mental estão a tirar ao seu actual empregador para trabalharem para alguém que nem sequer lhes está a pagar. Quer que eles lhe façam coisas dessas?

Além disso, se forem bons, muito provavelmente estão a entrevistar muitos empregadores. Adivinhe quais vão dar prioridade? Os que não pedem para completar projectos antes mesmo de telefonarem a um gerente de engenharia.

Há também o problema do plágio. Claro, eles serão descobertos na entrevista presencial, mas até lá você já perdeu o tempo de (presumivelmente) pessoas altamente remuneradas na empresa entrevistando essa pessoa.

A minha empresa actual fez isso bem, e este é o caminho que eu seguiria na sua posição. Dê-lhes uma pequena tarefa, que talvez demore apenas 90-120 minutos a fazer, e diga-lhes para justificarem nos comentários o porquê de terem escolhido essa forma de resolver o problema. Isto é algo que pode ser feito numa noite, e dar-vos-á uma visão do pensamento deles.

Posso dizer-vos desde já que se conseguir um projecto que leve mais de 8 horas a fazer, digo-lhes obrigado mas não estou interessado. Eu tenho um bom emprego e uma vida. Se um gerente vê isso como um problema, isso diz-me que não se importam com o meu equilíbrio trabalho/vida no trabalho (especialmente se não se importam ** antes** de eu o ter). Nenhuma empresa, excepto talvez a Google, a Apple ou o Facebook, poderia safar-se com isso.

** Na minha experiência, os projectos take-home não eliminam os maus codificadores e provavelmente fazem com que os bons codificadores encontrem um emprego onde não tenham de saltar por um aro para falar com o gerente de contratação.**

Pense desta forma. Um bom codificador pode facilmente obter entrevistas telefónicas e presenciais. Cada vez que tiverem de saltar por um aro extra significa que vão seguir o caminho mais fácil e ser entrevistados (e contratados) por outra pessoa que pagará o mesmo valor. Se fizer as pessoas saltar através dos arcos, certifique-se de que elas vêem que vale a pena desde o início.

Um mau programador pode levar o tempo que quiser. Não os vai ver demorar 4x tanto tempo; apenas vai ver o teste completo. Também não os verá ir ao Google ou ao seu amigo para pedir ajuda com uma declaração if.

A minha última empresa fez isto, e a grande maioria das pessoas que trouxemos para uma entrevista presencial falhou Fizz buzz (cerca de 65%). Acho que isto aconteceu porque inadvertidamente eliminámos pessoas boas e ocupadas que não precisavam da entrevista de outra empresa e, ao mesmo tempo, fizemos uma entrevista fácil perante maus programadores.

** O que acho que devíamos ter feito em vez disso**

Em vez de dar às pessoas um trabalho que levava 15-20 minutos a avaliar, devíamos ter feito uma entrevista de 15-20 minutos pelo Skype onde fizemos perguntas como o Fizz buzz. Isto teria levado o mesmo tempo, mas eu provavelmente teria eliminado os maus programadores antes de uma entrevista presencial de duas horas.

FYI -> Aqui está um artigo muito detalhado sobre a Fizz-buzz e práticas gerais de entrevista.

Uma visão contrastante, de alguém que se encontra nas trincheiras de ambos os lados desta questão. Suspeito que esta resposta irá atrair votos contra, mas é uma opinião altamente informada, desenvolvida ao longo de várias décadas neste negócio. Porque gosto de o fazer, ainda escrevo código todos os dias para viver e como hobby no meu “copioso tempo livre”, mas também tenho sido o decisor final na contratação de algumas dezenas de programadores, e tenho ajudado a entrevistar e aconselhado sobre a contratação de um número bastante maior.

Lawrence tem razão: a contratação é terrivelmente inexacta. Mas estamos a melhorar ao longo do tempo. Mais do que conversas presenciais, mais do que perguntas triviais, os pequenos desafios de programação no local são uma parte cada vez mais essencial: não só pela habilidade, mas pela atitude.

Note-se que eu disse “curto ”. Damos aos candidatos um computador portátil com um Eclipse devidamente instalado (o nosso IDE escolhido) quando eles entram para a entrevista. A instalação correcta significa que eles têm acesso à fonte jdk, mas não tem Internet, e é-lhes pedido que não utilizem telemóveis durante o teste. Eles têm uma hora para resolver qualquer problema, desde o “FizzBuzz” até cinco problemas, passando pela complexidade, até algo na ordem de um simples sistema multi-threaded producer/multiple-consumer.

Nunca ninguém resolveu os cinco numa hora, e não espero que ninguém o faça (posso escrever soluções para cinco em menos de uma hora, mas claro que já vi os problemas e resolvi-os todos anteriormente, por isso não sou um teste justo).

A propósito, tivemos ostensivamente programadores experientes fail* para acertar no FizzBuzz. Deixem-me repetir: tivemos uma mão cheia de candidatos que não conseguiram completar correctamente o FizzBuzz. Normalmente não seguindo instruções, mas ler as especificações é uma parte essencial de se ser um programador.

Temos que escrever código enquanto aqui nas instalações em vez de lhes dar trabalho de casa por várias razões, em parte o risco de fazer batota, e em parte para dar a cada candidato uma oportunidade igual de trabalhar os problemas. Também fazemos a rotação dos problemas dentro e fora do desafio estabelecido e discutimos as soluções com os candidatos depois.

Sinto-me extremamente forte sobre esta questão. Nunca vi um candidato recusar uma posição ou desistir do processo de entrevista por causa do nosso teste de programação. Mas isso pode ser influenciado pelo facto de dizermos aos recrutadores que nos servem que o processo inclui programação no local. Por isso, podemos simplesmente não ver os candidatos que pensam que ser convidado a escrever uma hora de código é “trabalho não remunerado”. Se assim for, boa viagem. Se eles pensam que uma hora de código é mais como “trabalho” do que uma hora de resposta a perguntas triviais, ou que as suas respostas aos problemas do teste podem produzir qualquer coisa útil, não preciso da sua atitude.

Uma vez tivemos um candidato a queixar-se do teste, porque ele pensava que era demasiado sénior para ter de provar o seu valor (isso não é especulação - ele disse-o). E saiu-se bem nos desafios, e teve toda a experiência que nós queríamos. Mas ele era um funcionário terrível: aparentemente também pensava que era demasiado sénior para tomar a direcção ou aprender, e por fim tivemos de o deixar ir.

Uma das coisas que decidi ao longo dos anos que temos vindo a fazer isto é que qualquer empresa que ** não faça** teste tem menos probabilidades de me apanhar como funcionário. Tal como as suas respostas a perguntas como o que usam para o controlo de fontes, etc., se os testes de uma empresa me dizem muito sobre como são bons no negócio do desenvolvimento de software.

** Então, o que deve você fazer?** Deve fazer o que funciona para a sua organização, mas o meu conselho é continuar os testes, mas faça-os no local, como parte da entrevista. Diga-lhes com antecedência que isso faz parte do processo, e faça-o antes de se encontrarem com a gestão superior (mas deve encontrá-los primeiro para ajudar a pô-los à vontade). E realmente: salte a entrevista com a gerência superior se eles falharem. Não se preocupe com a popularidade com os candidatos ou com os cartazes na Internet. O custo de uma má contratação é muito pior do que o custo de adiar até que se faça uma boa contratação.

Mesmo que ignoremos a possibilidade de fazer batota, e o filtro invertido que faz com que candidatos bons e honestos evitem empresas com testes de codificação em casa, o valor dos testes de codificação em casa é limitado.

Se for para um senior cargo , um programador sénior com competências pessoais poderá dizer em menos de 10 minutos se o programador sénior do outro lado do telefone é qualquer bom, ou está apenas a inventar coisas. Não saberemos exactamente o quão bom, mas saberemos tanto, se não mais do que todos os testes de codificação concebíveis em casa nos dizem.

Se for para uma ** posição júnior*** , não esperamos muito em termos de conhecimentos técnicos. Estamos à procura de entusiasmo, vontade de aprender e talento - nenhum dos quais é detectado num teste de codificação em casa. Há demasiadas coisas a que os júniores podem ser alheios. Se os contratarmos precisamos de os treinar de qualquer forma.

Como testar em vez disso?

Como filtro, dê-lhes apenas 10 minutos para resolverem uma variação FizzBuzz no local durante a primeira ronda de entrevistas ou, se ficar atolado de bons CVs e precisar de outro filtro, faça-o pelo Skype antes da primeira ronda de entrevistas a sério.

Depois de passarem nos filtros, precisa de saber mais sobre as capacidades de codificação dos seus candidatos. Recomendo que gastem no máximo 30 minutos a 2 horas de programação de pares ou de revisões de código - trabalho real, em vez de um exercício. Repita 1-2 vezes com diferentes parceiros. A vantagem da programação em pares e das revisões de código é que o programador já tem conhecimentos suficientes para contribuir.

Não se preocupe que o teste seja diferente para cada contratação - o objectivo do processo de contratação não é encontrar a pessoa que melhor pontua num par de testes mensuráveis e repetíveis. O objectivo é contratar uma única pessoa que faça bem o trabalho.

Aqui está outro ponto que não vejo abordado nas respostas existentes (que penso que cobrem bem o tema em geral). Eu analisaria de perto e com seriedade o tempo que as pessoas demoram realmente a completar. Tive quatro entrevistas de emprego durante as quais tive de completar um exercício de programação, cada uma das quais foi feita de forma diferente (e cada uma tinha as suas próprias vantagens e desvantagens). Duas das quatro (números 3 e 4 abaixo) demoraram muito mais tempo do que deviam e ambas acabei por desistir por causa do nível difícil em causa. Descrevi-os abaixo e classifiquei-os do melhor para o pior da minha perspectiva.

1. Durante a entrevista técnica, eles sentaram-me num computador que tinha uma versão reduzida da sua base de códigos e fizeram-me resolver três problemas relativamente curtos relacionados com o mesmo (encontrar e corrigir um bug que eles tinham propositadamente acrescentado, adicionar um novo campo a uma tabela de informação, etc.). Deram-me exactamente uma hora para o fazer, e depois de uma hora passaram em revista a minha solução, bem como a forma como eu abordava os problemas. Isto deu-lhes uma maior visão sobre mim como programador, respeitando o meu tempo, mantendo-o curto e directo.
2. Durante a entrevista técnica fizeram-me trabalhar num problema que tinham encontrado durante o desenvolvimento num quadro branco, ao mesmo tempo que eram capazes de lançar ideias sobre eles. Esta foi a opção mais curta, ao mesmo tempo que lhes dava a oportunidade de verem como eu trabalhava através dos problemas e o quanto eu conseguia fazer o trabalho necessário.
3. Durante a entrevista técnica (para uma posição júnior da Ruby on Rails Web Development) eles me encarregaram de construir uma aplicação web do zero que navegaria para um website, preencher vários formulários à medida que eram apresentados, raspar os dados da página resultante e apresentá-los ao usuário. Disseram que este deveria ser um exercício rápido, e pode ter sido para um programador web de nível sénior, mas tendo tido apenas um ano de experiência profissional nessa altura, passei quatro horas a tentar que tudo funcionasse antes de desistir e ir para casa (todos os entrevistadores tinham saído horas antes de mim porque era uma entrevista de tarde, disseram que eu deveria apenas guardar o programa acabado quando eu terminasse). Esta é uma tarefa ridícula para a posição listada, não lhes deu qualquer ideia das minhas capacidades de codificação, e pareceu-me que eles estavam apenas a tentar obter trabalho gratuito do acordo. Escusado será dizer que eu nem sequer queria o trabalho na altura em que saí daquele dia.
4. Antes mesmo de ter uma entrevista técnica, eles deram-me um trabalho para criar uma aplicação web que aproveitasse uma API que a sua empresa utilizava para “fazer algo interessante”. Isto era exactamente tão amplo como parece. Isto obrigou-me a fazer o seguinte antes mesmo de tentar criar a aplicação: criar uma conta de desenvolvedor para a API, descarregar o kit de desenvolvimento da API, criar uma aplicação web publicamente acessível (com outra conta de desenvolvedor), aprender a API, e criar um repositório de dados para aceder com a API. Isto, claro, levou muitas horas apenas para começar, e pouco depois de ter começado a trabalhar na própria aplicação web, recebi uma entrevista de emprego diferente e, pouco depois, uma oferta de emprego, pelo que interrompi o trabalho na tarefa. Isto é uma loucura ter como parte de um processo de entrevista porque quem quer investir todo esse tempo e esforço no desenvolvimento de um programa só para ter uma pequena hipótese de avançar no processo de entrevista?

Então, para responder mais directamente à sua pergunta, deveria ter um exercício de programação? Sim, mas certifique-se de que é feito à sua medida para testar o que realmente lhe interessa, e de que não necessita de uma tonelada de trabalho externo para o entrevistado. Quer saber sobre o seu pensamento algorítmico? Dê-lhes um problema de algoritmo. Quer saber sobre o seu estilo de codificação? Dê-lhes um problema de codificação. Quer saber sobre o seu processo de desenvolvimento? Discuta o seu processo com eles à medida que trabalham através de um problema.

Deixe-me começar com:

• Fiz testes para completar em casa que variaram de 15 minutos a 10 horas.
• Fiz testes online.
• Fui incumbido de escrever a resposta à FizzBuzz e outros testes da moda na internet em quadros brancos.
• Fui questionado sobre as capas quadradas versus redondas.

Em resumo, lidei com praticamente todas as diferentes formas como os programadores gostam de lidar com entrevistas. Para ser honesto - duvido seriamente que a grande maioria das pessoas que me entrevistam tenha sequer compreendido quais foram os potenciais resultados de cada um desses testes e, em última análise, apenas contratou pessoas sobre se “gostaram” ou não deles.

Antes mesmo de colocar uma lista de empregos deve sentar-se e passar exactamente pelo que está a tentar contratar e “desenvolvedor” não é uma resposta, pelo menos, não é uma resposta adequada. Uma boa resposta a isto seria algo como “especialista em hipotecas”.

Encontrar alguém que possa escrever um pouco de código ou pesquisar no Google como aplicar um determinado padrão é trivial em comparação com encontrar alguém que tenha estado no negócio em que está e que possa alavancar esse conhecimento. Por outras palavras, se eu estivesse a contratar para uma empresa de documentação hipotecária, aceitaria alguém que pudesse falar sobre a diferença entre 15 anos fixos e empréstimo ARM sobre alguém que pudesse escrever um algoritmo de tipo bolha em 2 minutos. A razão é que os empresários “normais” fazem todo o tipo de exigências estranhas e os especialistas no domínio podem mais facilmente chegar ao cerne do que é necessário, enquanto alguém que não sabe nada vai alegremente acrescentar coisas que são inúteis ou tornar a aplicação realmente má.

Voltando às perguntas, somente pergunte go / no go perguntas.

É crítico que a pessoa possa dizer-lhe a diferença entre um método virtual e abstracto? Pode ser, normalmente não é. Aposto que uma boa parte dos programadores mal sabe quando usar essas palavras-chave, mas elas não são as suas superestrelas, são os rank and file que usam não conseguem codificar sem os designers visuais.

É crítico detectar quando uma consulta está aberta para injecção de sql? Para uma posição Sr - absolutamente; para uma posição Jr. não. Isto é algo que é facilmente treinável e manuseado através da revisão do código. Daí a razão porque quer que o sr. saiba por dentro e por fora - para que possam treinar os juniores.

É crítico que eles saibam o valor máximo exacto de um tipo de dados Int32? Normalmente não - esse nível de conhecimento trivial é para o que o google serve; mas talvez o seu requisito seja a codificação em dispositivos com limitações de memória - nesse caso: absolutamente.

Eu entrevisto e contrato desenvolvedores. Eu não envio testes para casa - é muito fácil ter a ajuda de um amigo. Eu não uso sites de testes online - dada a forma como a pontuação tem de ser automatizada é trivial para o jogo. Não peço aos candidatos para escreverem a resposta ao fizzbuzz - quase todos já viram esse teste e devem saber a resposta de cor; todos os outros entraram em campo no último ano e são jr.‘s de qualquer forma. Também não faço perguntas triviais - ser capaz de recitar a resposta geralmente significa apenas que já ouviu a pergunta antes.

O que faço para entrevistar pessoas:

• peço-lhes que descrevam um ou dois projectos anteriores. Tudo o que me interessa neste momento é deixá-las confortáveis e pô-las a falar. Isto é um go/no go porque se eu não consigo entender o que eles estão a dizer então não consigo trabalhar com eles.

• Faço-lhes algumas perguntas específicas na tecnologia que preciso que eles usem. Se for um servidor SQL, vou perguntar-lhes sobre a actualização num join. Se for HTML, vou entregar-lhes um ficheiro html de 10 linhas com um par de classes css e perguntar-lhes qual é a saída. Estas são perguntas triviais para pessoas com experiência nestas áreas e rapidamente eliminam os pretendentes.

• Se eu estou à procura de um Sr. dev então vou fazer perguntas de conhecimento de domínio. Não são coisas de casos de ponta, mas sim de princípios fundamentais. Se eu precisar que você lidere um projecto de contabilidade, então é melhor que você tenha uma compreensão dos princípios básicos de contabilidade.

• Se eu estou à procura de um Jr. dev então eu vou perguntar sobre projectos de animais de estimação. tudo o que eu quero saber é o tipo de tecnologia utilizada. Isto deve indicar-lhe o que eles realmente querem fazer. Por outras palavras, um desenvolvedor C# não é provável que esteja a fazer projectos de animais de estimação no php. Sinceramente, não espero muito de um desenvolvedor de jr, a não ser que seja treinável. Se eles estão a trabalhar activamente num projecto de animais de estimação, então eu posso treiná-los. Se eles são do tipo que precisa que as pessoas lhes digam o que fazer, há empresas muito maiores em que estes tipos podem trabalhar.

Eu não faço estas perguntas de improviso, as respostas potenciais são consideradas antes do tempo e encaixam num padrão de go/no go. Se uma pergunta não se enquadra nesse padrão, então não é relevante. Também pergunto a todos os candidatos as mesmas perguntas, a menos que esteja 100% convencido que não os estou a contratar, altura em que vou parar a entrevista.

Se por alguma razão ainda insistir em enviar para casa um teste - certifique-se de que as competências necessárias para completar com sucesso esse teste num período de tempo razoável são realmente competências que lhe interessam.

Pedi a uma empresa que me fizesse um teste de acesso a casa que envolvia escrever um fornecedor de serviços criptográficos personalizados. Completei o teste porque era um pouco interessante; eles contrataram-me. Em nenhum momento do meu tempo eu fiz nada mesmo remotamente relacionado com segurança, criptografia ou mesmo matemática além de adicionar alguns números. Pergunto-me quantas pessoas se foram embora com esse teste?

Eu costumava acreditar firmemente em testes de codificação e codificação de quadros brancos, mas comecei a perceber que eles são praticamente inúteis, porque

O que é que estás a testar, afinal?

Um teste de quadro branco, ou um teste de programação curto, dá-nos uma ideia do indivíduo, mas realmente não tanto assim. A não ser que planeies ter alguém que passe o seu tempo a escrever código num quadro branco ou código estilo FizzBuzz.

O que é que tu queres?

Queres alguém que seja:

• apaixonado
• disposto a aprender
• capaz de resolver problemas*
• ressoavelmente técnico
• vai ajudar a tua equipa improve

*Nota, a maioria dos programadores resolve os seus problemas sabendo que termos procurar no Google.

A last coisa que você quer contratar é alguém que não é um bom ajuste para sua equipe porque eles vão arrastá-la para baixo.

How Can You Test For These?

• Pergunte-lhes sobre um projeto que eles gostaram. Se eles parecerem relutantes em falar sobre ele, tente expressar uma ligeira descrença, por exemplo: “Não consegues fazer X, pois não?”. Se é algo pelo qual estão apaixonados, eles irão corrigi-lo. Isto também o ajudará a aprender se eles são técnicos ou não.
• Pergunte-lhes sobre coisas que aprenderam recentemente. Ou o que aprenderam com o projecto que trabalharam.
• Pergunte-lhes sobre a última vez (ou uma vez) em que lhes faltou algum conhecimento. Como conseguiram a informação de que necessitavam? Foram ter com um colega de equipa? Procuraram na internet?
• Pergunte-lhes se há algo que gostariam de ver melhorado na sua equipa actual/última equipa. Precisavam de mensagens de compromisso melhor? Mais revisões de código? Mais testes? Mais automação?
• Pergunte-lhes que tecnologia os excita, e porquê.

Se tem alguém que está tecnicamente empenhado nesta conversa, será a coisa mais fácil do mundo dizer se essa pessoa será a pior. Um exemplo: tivemos uma criança que entrou e entrevistou - ele disse que numa escala de 1-10, os seus conhecimentos de Java eram como um 7-8. Acho que ele nem sabia que o Java foi compilado para um ficheiro jarro, que mais tarde foi compilado em linguagem de máquina pela JVM. Eu próprio classificaria talvez um 2 ou um 3 e I sabia disso.

Foi-lhe feita a mesma pergunta pelo nosso CTO numa entrevista no dia anterior, e o nosso CTO telefonou-lhe e explicou que não havia maneira de ele ser um 7-8.

O nosso CTO também lhe perguntou sobre o seu projecto favorito, que tinha a ver com scanners portáteis. Mas ele não conseguiu explicar nada sobre como eles funcionavam, ou o facto de usarem as sondagens para evitar esperas ocupadas. Ele não conseguiu explicar uma única coisa técnica.

Aquele tipo não foi contratado.

Descubra o tipo de atributos que procura, e depois descubra como testar para aqueles

Mas eu realmente preciso de ver como ela codifica!

Ok, tudo bem - mas a não ser que ela vá codificar num silo, a melhor coisa a fazer será contratá-la como empreiteira para um projecto pequeno e bem definido. Talvez esteja a adicionar a capacidade de descarregar alguns ficheiros a partir de um FTP e depois atirá-los para a sua base de dados. Algo simples, que não exija muito/qualquer conhecimento de domínio.

Tenha os seus candidatos a trabalhar com um ou dois funcionários já existentes, e pague-lhes pelo seu tempo. Poderá ver exactamente como eles trabalham, e como trabalham bem com a equipa. Eles comunicam bem? Ficam frustrados facilmente? Eles são persistentes?

Há áreas coisas que pode fazer para contratar melhores funcionários… mas um concurso de programação provavelmente não é uma delas.

Do ponto de vista de uma pessoa que procura emprego, geralmente evito lugares que demorem mais de 1 hora a codificar. Uma vez fui a este lugar que exigiu um projecto de codificação java de quase 3 dias. Eu fiz tudo e o tipo até ficou impressionado com isso, mas disseram-me que contrataram outra pessoa depois da segunda fase da entrevista. Por isso, depois disso, se eu viesse a uma empresa, ignoraria/passaria qualquer projecto que precisasse de mais de duas horas para ser concluído. O meu tempo é tão valioso como o deles e prefiro não o desperdiçar em coisas que não me levam a lado nenhum.

Dito isto, se o seu exercício de codificação for demasiado longo, talvez as pessoas não estejam dispostas a colocar o tempo. Eu tentaria reduzi-lo de tal forma que demorasse, no máximo, uma hora, mas ao mesmo tempo demonstrasse uma compreensão da codificação e talvez lhe pusesse um prazo do tipo: “Por favor, complete até ao COB amanhã” ou assim. Ainda podem “copiar e colar” algo online, mas dificultam as coisas sendo específicos em vez de algo que se lê online.

Como outros notaram, alguns programadores podem ser adiados por um exercício de programação de 1-2 horas para se candidatarem a um emprego. O que pode funcionar melhor é ter uma sessão de white-boarding, em que o candidato resolve um problema num white-board durante a entrevista. Isto dá-lhe a oportunidade de ter uma entrevista presencial, ao mesmo tempo que se certifica de que eles têm as escolhas técnicas.

Estes problemas não devem ser extremamente difíceis, ou concebidos para tropeçar num programador. Um exemplo clássico é FizzBuzz . Isto permite ver como eles pensam, e também saber que podem pelo menos programar e não precisam de pesquisar no Google como fazer um loop.

Na minha opinião, o problema que têm aqui não é necessariamente o teste de programação. Primeiro tem a entrevista técnica por telefone e depois um teste de trabalho em casa antes de uma entrevista cara a cara. Parece que está a manter os seus candidatos à distância e a deixar isso para o último minuto antes de os conhecer. Em que momento espera que os candidatos decidam que querem trabalhar para si?

Presumo que o seu anúncio de recrutamento é semelhante à maioria e, por isso, centra-se na localização, salário e uma lista (de desejos) de competências. Os candidatos não sabem realmente no que estariam a trabalhar, nada sobre o ambiente ou sobre as pessoas com quem teriam de interagir. Ainda não lhes vendeu o trabalho, aqui está a pedir-lhes para provarem as suas capacidades técnicas duas vezes antes de poderem fazer uma única pergunta sobre o trabalho.

Sugiro que tente mudar o formato da entrevista técnica por telefone para uma conversa de 30-45 minutos sobre o trabalho, incluindo muitas oportunidades de perguntas dos candidatos, depois 15 minutos de perguntas técnicas como ecrã para que ainda tenha a oportunidade de escolher os melhores candidatos sem tornar o trabalho demasiado oneroso.

Também consideraria mudar o desafio de programação para ser feito no local antes das entrevistas. Pareceria mais exequível para os candidatos, dar-lhes-ia um incentivo para se manterem no bom caminho com o processo e teriam o benefício de observar o verdadeiro tempo gasto no desafio (penso que poderiam ficar surpreendidos).

Quer contratar programadores que não sabem programar?

Vou arriscar que você não saiba.

Contratar programadores que não sabem realmente resolver problemas e escrever código é uma boa maneira de arruinar uma empresa de tecnologia. E você não vai ser eficaz a eliminar os programadores que não conseguem realmente programar (e há um monte desses por aí) se o seu processo de contratação não incluir algum tipo de teste de programação.

** Está disposto a baixar os seus padrões porque todos estão a tentar contratar programadores?**

Talvez esteja, mas acho que não deveria estar. Como já foi referido nos comentários e respostas, há candidatos por aí que não se vão dar ao trabalho de fazer exercícios de programação como parte de um processo de entrevista porque eles simplesmente não precisam de o fazer para conseguir um emprego.

Mas serão realmente essas pessoas que quer contratar de qualquer forma? As que seguem o caminho de menor resistência, fazem o que lhes é mais benéfico a curto prazo e não se preocupam o suficiente com a sua empresa para completar um simples exercício de programação? Esses não parecem ser atributos positivos, e não dão muita confiança em termos de ser capaz de manter esses candidatos a longo prazo (o que também é importante para uma empresa de tecnologia, uma vez que as curvas de aprendizagem tendem a ser íngremes e o custo de substituição do pessoal existente é muito elevado).

Então deixe que essas outras empresas tenham os programadores que nem sequer podem ser incomodados. De qualquer forma não os quer contratar. Ao contrário deles, você tem um plano. Um que não se baseia na falácia “um programador é um programador”. O seu foco deve ser a qualidade e sustentabilidade, não a contagem corporal.

I assustar os candidatos é um problema?

Geralmente não, desde que eles estejam a ser assustados por uma boa razão. Não se quer contratar pessoas que não estejam à altura. E algumas das pessoas que dizem que “não podem ser incomodadas” devido à grande procura podem estar a usar isso como desculpa para encobrir uma situação “não tão boa em programação, pelo que precisariam de toda a semana para completar um exercício de 1 hora”.

É bom afugentar esses candidatos. Quer contratar os candidatos capazes e motivados. Desde que não os afugente também, é bom.

Cada candidato que não afugenta é um candidato que tem de tentar avaliar. E isso pode ser difícil de fazer se não estiver a dar aos seus candidatos técnicos quaisquer exercícios técnicos para usar na avaliação.

** Como posso melhorar o nosso processo de contratação?**

Verifique o conteúdo do seu exercício de programação. É razoável e apropriado para um contexto de entrevista?

Você não quer que algo que vai levar dias (ou mesmo horas) a completar. O que você quer é algo simples para eliminar as pessoas que não conseguem programar, idealmente com espaço suficiente para nuances que as pessoas que conseguem programar realmente bem possam se diferenciar. Tenha em mente o que está a tentar realizar (eliminar candidatos não qualificados e não sérios), e assegure-se de que o seu conteúdo é adaptado a esse objectivo. Não exagere.

Se já tem algum pessoal técnico, pode usá-lo para verificar a sanidade (e/ou ajudar na concepção) do seu exercício.

E considere também a forma como administra o exercício. Se apenas lhes der alguma documentação e disser “aqui, faça isto durante a próxima semana e envie-me por e-mail”, isso provavelmente só será minimamente eficaz.

É melhor se puder fazer o exercício através de um portal Web, que os candidatos podem consultar e iniciar o exercício, e assim que começarem a contagem decrescente a partir de 1 hora. Depois ou submetem algo dentro dessa hora, ou não. Isso é menos aberto, é melhor manter o foco do candidato, e fornece um prazo/caixa de tempo claro tanto para que 1) não fique à espera durante toda a semana por um resultado que nunca virá, e 2) os candidatos não qualificados não deitem fora uma semana do seu tempo a tentar completar o seu exercício de programação. Eles recebem 1 hora, ou resolvem o problema ou não, e você sabe o resultado imediatamente.

E ainda melhor seria trazê-los para uma entrevista no local. Apresente-os a um membro da sua equipa de desenvolvimento. Feche-os numa sala juntamente com uma estação de trabalho. Peça ao seu programador para começar com algumas perguntas gerais/macias da entrevista e depois eles podem fazer um par com o candidato para resolver o exercício de programação. Isto dir-lhe-á não só se o candidato pode ou não codificar, mas também o quão bem eles trabalham com a sua equipa. O seu programador também deve ser capaz de obter muita informação adicional que simplesmente não obterá ao olhar para um monte de código que um candidato escreveu e depois lhe enviou por e-mail.

Bottom line

Não, não se quer livrar do seu exercício de programação. Mas pode querer revê-lo para um conteúdo apropriado, certificar-se de que não demora muito tempo a resolver e também olhar para a forma como o está a enquadrar no seu processo de entrevista global.

Um exercício autodirigido de take-home provavelmente não é a melhor abordagem. Mas a solução para isso não é acabar completamente com o exercício. A não ser que esteja de acordo em contratar programadores de porcaria, pelo menos.

É melhor afugentar um monte de maus candidatos e um punhado de bons do que abrir as comportas e contratar alguns maus.

Uma coisa que ninguém parece ter mencionado; mesmo que o teste não seja o seu problema, deve procurar outras formas de atrair talento.

** Se está à procura de boas pessoas com base nos seus trabalhos publicados, não precisa de fazer o teste sobre elas**.

Se está apenas a ser enviado através de recrutadores e filtragem, é vulnerável ao facto de as suas necessidades e as necessidades dos recrutadores não se sinergizarem perfeitamente. Eles querem colocar alguém consigo. Você quer um engenheiro de alto nível. Se eles conseguirem encontrar um engenheiro de alto nível que seja fantástico, porque você vai voltar para eles, mas se eles não conseguirem (e os engenheiros de alto nível tendem a ter coisas a acontecer que deixam pouco tempo para entrevistas), eles vão contentar-se em colocar apenas um engenheiro moderado com um fato bonito. A perda para eles é um pouco de reputação a longo prazo, mas isso é menor quando comparado com a falta dos seus objectivos. Se isto não for provavelmente verdade no seu caso, agarre-se a esse recrutador e nunca os deixe ir_(*), os recrutadores que estão a dar prioridade a uma relação a longo prazo sobre os alvos são diamantes preciosos num oceano de pó de carvão.

O que quer fazer é encontrar candidatos provavelmente interessantes. Hunt through StackOverflow and GitHub for top engineers (Ouvi dizer que StackOverflow tem uma ferramenta para ajudar com isto ), procure empresas tecnicamente interessantes que produziram bom software mas que lixaram as suas finanças ou monetização, e acabaram de despedir 10 engenheiros de topo. Passe algum tempo a trabalhar nas universidades ajudando nos projectos do último ano. Identificar bons candidatos potenciais e fazer amizade com eles, de preferência pessoalmente, em alternativa, através de um contacto remoto; mesmo que tenham ofertas, os bons engenheiros andam com bons engenheiros. Além disso, eles podem dizer-lhe o que eles sentem sobre o seu processo de contratação.

Isto parece-lhe muito trabalho? Deve. Uma das razões pelas quais a contratação parece tão “difícil” é porque você está a tentar fazê-lo da forma mais eficiente possível. Quanto mais tempo, inteligência e recursos se desviar para ele, mais fácil será. Se esses recursos seriam melhor gastos no envio do produto é a eterna questão da gestão. Mas se você está gastando muito tempo com “filtragem de porcaria de programador”, isso é _queima de dinheiro. Pelo menos os passos descritos acima têm valor inerente para além do processo de contratação.

(*): Inferno, alugue-os.

Não gosto de testes em casa como parte das entrevistas, por muitas das razões já mencionadas - prolonga o processo de contratação, desvaloriza o tempo do candidato, pode não receber uma chamada de volta, etc.

A minha questão principal é que é irrealista a forma como a equipa realmente funciona e faz com que o processo de entrevista seja unilateral. Um candidato quer que este lugar seja adequado para ele, incluindo a cultura, a forma como a equipa aborda e resolve os problemas. Procura também, em primeiro lugar, a sua aptidão, incluindo a forma como trabalham e se têm as competências adequadas. Um teste para levar para casa não dá ao candidato a oportunidade de avaliar as qualidades suaves de um local de trabalho e os empregadores não aprendem como o candidato abordou o problema.

Uma melhor solução pode ser dar ao candidato um problema mais aberto que possa ser resolvido de qualquer tipo de forma criativa. Poderá mesmo restringi-lo à linguagem X. Em vez de o enviar por e-mail, convide-os a apresentá-lo a si próprio e à gestão superior. Dá-lhes autonomia e incentivo para se saírem bem, porque promete outra entrevista e mostra que se preocupam em saber o que pensam.

Se tiver de utilizar um teste para avaliar quais os candidatos que chegam à entrevista com a gestão superior, eu incluiria o teste na entrevista para que pudessem discutir em conjunto o processo de pensamento deles.

Penso que formulou a sua pergunta um pouco mal, mas a forma como a formulou reflecte uma concepção errada comum sobre a contratação de programadores. Os candidatos estão a ser “assustados” pela tarefa de programação, ou estão a filtrar a sua empresa por causa da tarefa?

Uma anedota para demonstrar o meu ponto de vista: enquanto procurava emprego não há muito tempo, vi uma posição para uma empresa que parecia média. A forma como descreveram o seu processo de programação fez com que parecesse bastante bom, mas havia muito poucos detalhes, por isso estava céptico. Talvez fossem um bom lugar para se trabalhar, talvez não. Mas pensei em chegar a um ecrã telefónico para poder perceber os detalhes e ver se eram tão bons como pareciam.

Cliquei no anúncio de emprego e fui imediatamente solicitado a escrever uma carta de apresentação. Ugh. Acho que todos os candidatos odeiam cartas de apresentação. Eu não conhecia esta empresa ou usava os seus produtos, então o que poderia dizer sobre eles? Pesquisei-os no Google, li o seu site e ofertas de produtos, descobri onde é que eu poderia encaixar no seu organograma se contratado, e descobri alguns parágrafos “vendendo” eu próprio.

Em seguida forneci o meu currículo e acesso ao meu LinkedIn - mas imediatamente a seguir pediram-me para preencher a minha experiência de trabalho relevante com datas e descrições. Esta informação está tanto no meu LinkedIn como no meu currículo, foi ridículo ter de fornecer a mesma informação 3 vezes. Fechei o separador do browser. 5 minutos depois estava a candidatar-me a outra empresa que oferecia alguns benefícios muito fixes que a primeira não oferecia. Na verdade podia candidatar-me a outra empresa com melhores benefícios mais rapidamente do que podia saltar através dos hoops que a primeira empresa queria de mim.

Tem de ter a certeza que os seus candidatos estão a investir em a sua empresa em particular* antes de lhes apresentar qualquer hoops para saltar, caso contrário não saltarão. Fazem isto?

Exemplos de benefícios de qualidade que normalmente vejo empresas de tecnologia a oferecer:

1. Trabalho remoto.

2. Computadores/monitores gratuitos como bónus de assinatura.

3. A empresa contribui para projectos open-source respeitados.

4. Reembolso por formação profissional e/ou conferências.

5. Almoços com catering.

6. Horário flexível.

7. oportunidade de trabalhar com tecnologias novas ou desconhecidas.

8. “Cultura de arranque” - também conhecida por falta de política/burocracia.

9. Equidade da empresa.

10. Reconhecimento do nome: a sua empresa ou o seu produto é bem conhecido. Os candidatos gostam de mencionar onde trabalham e ouvir as pessoas responder com “Oh, puro! Eu gosto dos seus produtos”.

11. Objectivos/visão da empresa caridosa ou revolucionária. As pessoas gostam de escrever códigos que melhorem a vida das pessoas.

12. Remuneração acima da média. O dinheiro cobre uma multiplicidade de pecados organizacionais.

Esta lista não é abrangente, mas se a sua empresa não oferecer uma ou mais coisas como os itens dessa lista, então qualquer obstáculo no seu processo de contratação poderia enviar um candidato à procura de um que o faça.

Então digamos que, por qualquer razão, você não oferece ou não pode oferecer incentivos como os acima mencionados para que os seus candidatos os convençam a gastar a escrever código para si gratuitamente. Então o que pode fazer? Tenho duas alternativas que a maioria dos candidatos preferirá em vez de tarefas de programação ocupadas:

Alternativa #1 - Pague-lhes uma taxa horária para fazerem a sua tarefa de programação como se fossem um empreiteiro. Isto encoraja-os a levá-la a sério, tanto por razões profissionais como porque… eles estão a ser pagos. Isto custa-lhe dinheiro, mas o mesmo acontece com qualquer forma de recrutamento. Se você é realmente bom, pode até encontrar uma maneira de eles diagnosticarem e corrigirem um bug real no seu código, e nesse caso está a receber algo útil para o seu dinheiro.

Alternativa #2 - Eles provavelmente já escreveram código gratuitamente, que lhe mostrarão se você apenas pedir. A maioria dos programadores tem código em Github, Bitbucket, sites de perguntas e respostas como Stack Overflow, ou poderiam fornecer-lhe algum código que ainda não tenham publicado.

Porquê fazê-los escrever código que eles não se importam quando você poderia deixá-los partilhar um projecto de paixão consigo em vez disso? É certamente menos aborrecido do que ler mais uma solução para o mesmo problema genérico pela centésima vez. E como o código já está escrito, poupa-lhe a si e ao seu candidato tempo. Além disso, poderá ver que tipo de código eles gostam de escrever, o que lhes dá uma ideia da sua personalidade e de quão bem se adaptam à cultura da sua empresa.

Como resposta directa à resposta do Bobo (que é a resposta aceite porque o tipo a escreveu e aceitou-a ele próprio, o que francamente me parece um pouco patético):

Está a vir de uma premissa totalmente errada. Eu não desejo trabalhar para ti. De onde tiraste essa ideia de alguém que quere trabalhar para ti? Você é apenas uma das muitas empresas que oferecem um emprego. Eu não quero trabalhar para você. Eu quero avaliar a sua empresa, e se você sair em cima de todas as outras, é quando eu quero trabalhar para você.

Há uma dúzia de empresas onde eu posso trabalhar, você está apenas em algum lugar da fila. Primeiro olho para as empresas que existem, envio-lhes o meu CV, elas podem lê-lo e ficar devidamente impressionadas ou não, depois normalmente tem uma conversa telefónica rápida onde me mostram que têm um emprego interessante e eu mostro que tenho as competências, e qualquer teste de codificação pode vir no fim.

O seu teste de acesso a casa coloca-o no fim da fila. Para compensar teria que colocar uma faixa salarial que é £10k mais alta do que outras. Encontrar um emprego é demorado de qualquer forma; alguém que o faz dez vezes mais demorado está no fim da lista. Se eu tiver a escolha entre enviar um CV e ter uma entrevista por telefone com dez empresas, e fazer os trabalhos de casa para si, adivinhe o que vou fazer.

Então o que acontece é que encontra candidatos que querem trabalhar para si _ porque não vão conseguir um emprego noutro lugar_.

Penso que pode realmente ajudar a estabelecer quem realmente conhece as línguas listadas no seu currículo.

Se esse é realmente o seu objectivo, eu consideraria uma abordagem diferente. Como outras respostas indicam, SIM, deve ter sempre uma pergunta de codificação, mas as perguntas de codificação raramente entram em detalhes da língua. Algumas perguntas que vi são úteis para testar isto:

1. Comparar e contrastar Java e C (ou quaisquer que sejam as duas linguagens relevantes, estão no currículo do candidato, etc.)
2. Que características acha que devem ser acrescentadas à linguagem? (Ou melhor ainda, o que pensa sobre esta mudança específica proposta/recentrada na linguagem?)

Engenheiros que viram uma ou duas coisas que sabem como responder a estas perguntas muito facilmente, e em apenas alguns minutos.

Desconsiderando todos os argumentos a favor ou contra testes específicos, tudo se resume a uma troca - mais filtros irão afugentar alguns bons candidatos, menos filtros deixarão passar os maus candidatos que poderá ter de substituir pouco depois de contratar.

Tudo se resume a olhar para a sua situação empresarial em vez das práticas gerais.

Tem actualmente um problema em que não tem candidatos qualificados e não consegue contratar tão rapidamente quanto necessita para atingir os seus objectivos empresariais? Precisa de abandonar esta tarefa de programação inicial.

Tem actualmente um problema em que não está satisfeito com a qualidade das suas recentes contratações? Então precisa de implementar mais filtros como este.

Tem ambos destes problemas, e ambos são igualmente dolorosos? Parabéns, encontrou o equilíbrio certo para esta troca.

O IMHO tem quase 0% de probabilidade de um recém-licenciado poder fazer um código de programação rigoroso a um nível de entrada. Se o seu teste de codificação demora uma semana a completar, então deve mencionar claramente na sua exigência que está à procura de programadores com pelo menos 2+ anos de experiência, porque penso que deve ser necessária muita experiência para completar um trabalho de código que requer uma semana para ser concluído. E penso que se está à procura de recém-licenciados então desenhe o seu teste em conformidade e pode encontrar muita ideia na Internet ou então pode pedir aos programadores seniores que trabalham para si para desenhar um teste adequado para recém-licenciados.

Pensei que ia responder a esta pergunta, já passou um ano desde que foi publicada, e nós ficámo-nos por ela.

FINDINGS

Positivos de aproximação

1) Leve para casa os candidatos desmotivados e substitua-os por candidatos que realmente queiram trabalhar para si. Só isto faz com que valha a pena fazer, uma vez que pessoas motivadas = empregados produtivos. Se não se podem dar ao trabalho de 1 hora, isso diz muito sobre a sua atitude em relação à obtenção do emprego.

2) Concordo com os outros, que o teste de levar para casa não deve ser mais do que uma hora - o meu é muito simples. Tive os seguintes resultados ao adicioná-lo ao processo de recrutamento -

a) Alguns candidatos não o completam. Não vale a pena contratar.

b) Alguns candidatos tentam mas completam-no mal. Não vale a pena contratar.

c) Alguns candidatos fazem batota, pelo que vale a pena fazer perguntas de acompanhamento sobre a sua colocação. Fizemos isto com um candidato recente que depois não se deu ao trabalho de responder ao nosso e-mail sobre o trabalho. Não vale a pena contratar.

d) Alguns candidatos, ao serem ouvidos, retiram subitamente a sua candidatura, onde anteriormente apresentavam MUITO interesse. Provavelmente esquivaram-se a uma bala.

e) Alguns candidatos saem-se extremamente bem, comentam o seu código e em uma ou duas ocasiões fornecem documentação. **1) O abandono da candidatura por parte dos candidatos que foram adiados pela tarefa de levar para casa faz com que seja mais longo encontrar alguém adequado. MAS no outro lado positivo para a empresa uma vez que reduz a probabilidade de uma má contratação que é perigosa.

2) Nem sempre é possível dizer se alguém fez batota, mas é por isso que muitas vezes é apoiado por uma entrevista técnica por telefone.

** Resultado desta abordagem**

Um dos nossos colaboradores que contratei utilizando esta abordagem acabou por se revelar um colaborador estrela. Ele continua a trabalhar para nós depois de mais de um ano. Ele é de confiança e tecnicamente talentoso.

Rato não familiar ou layout de teclado inesperado (especialmente Mac vs PC), ou IDE diferente podem diminuir drasticamente o desempenho sem qualquer diferença na competência. Além disso, uma aplicação completa requer muitas vezes muito código de caldeira que um programador pode não ter tempo suficiente para digitar ou mesmo não se lembrar. Iniciar uma nova aplicação completamente do zero é na verdade uma tarefa muito rara; a maioria do trabalho concentra-se em ampliar ou melhorar o código existente.

Por isso, sugiro dar apenas tarefas muito curtas e mais cuidadosamente preparadas durante a entrevista. O melhor é pedir para escrever uma função que deve tomar determinados parâmetros e devolver o resultado explicado e eu aconselharia a fazê-lo em papel, evitando de todo o modo o computador.

Eu enviava-os para um questionário online onde se pode filtrar as pessoas que não fazem a menor ideia. Pelo menos teria uma ideia se elas sabem do que estão a falar.

No início da minha carreira, os caçadores de cabeças disseram-me “estás contra pessoas que lêem a caixa e colocam uma candidatura no seu currículo”. Presumo que isto ainda possa acontecer aos jovens e aos ingénuos, mas quando se é despedaçado em algumas entrevistas aprende-se que este é um mau conselho…

Recebi recentemente um teste de “levar para casa”. Era uma aplicação totalmente explodida que precisava de se ligar a um servidor socket que tinha de simular uma alimentação lenta. O cliente teve de se actualizar dinamicamente, poder cancelar o feed e escrever e ler XML.

Eu queria aprender soquetes de qualquer forma pois estou a pensar em usá-los para um servidor de poker que estou a escrever.

Eu queria aprender leitor e escritor de XML.

No início pensei em esquecê-lo. Mas depois vi isso como uma oportunidade de provar o que posso fazer. Não tenho um curso de CS, por isso sinto falta de algumas coisas teóricas. Eles perguntaram quais são os 3 pilares do OOP e quiseram dizer quem se importa.

A minha mensagem é que as pessoas que querem o trabalho devem completar o teste.