Enigmas complicados de lógica - Eles são realmente úteis na avaliação de habilidades de programação? [fechadas]

Algumas pessoas perguntam na tentativa de avaliar sua capacidade e abordagem para resolver problemas. Pessoalmente, não acho que esses quebra-cabeças forneçam um indicador preciso. No "mundo real", você tem mais de cinco minutos para descobrir se está lidando com uma embalagem bin vs a < um problema de href="http://en.wikipedia.org/wiki/Knapsack_problem"> mochila , por exemplo. Inicialmente, às vezes é fácil entender mal o problema em questão até que você esteja aplicando a solução errada. Isso acontece com pessoas com 1, 5, 10 ou até 20 anos de experiência.

Os melhores enigmas da entrevista são aqueles em que você se senta em um computador para resolver um problema no domínio em que você afirma ter experiência. Eu também não gosto do "Bem, um programador deve ser capaz de ..." pensar porque não leva em consideração que as pessoas ficam ansiosas quando atingidas por algo inesperado em um cenário que já é estressante. Claro, você poderia resolver isso se você tivesse tempo para pensar sobre isso ... e talvez você pudesse resolvê-lo mais rápido se percebesse que sua vida terminaria se você não o fizesse. Você quer trabalhar em algum lugar onde sua vida acabará se não conseguir resolver problemas em cinco minutos ? Você será demitido se você não puder ?

Todos os grandes programadores também devem ser solucionadores de sudoku campeões? Tenho certeza de que muitas são, mas não é como um pré-requisito para a competência.

Eu não estou dizendo que você deve não ser testado sobre como você aborda os problemas, mas os testes devem ser divertidos e convidar o 'melhor' que o candidato deve dar, dada a sua área de atuação. perícia. Provar que você é tão inteligente quanto um personagem que Bruce Willis retrata parece meio sem sentido, considerando que os produtores gastaram uma quantia bonita para conseguir aquela cena exatamente correta.

Em outras palavras, se você detectar que está sendo entrevistado por alguém que tenha pouca compreensão sobre o que você realmente estará fazendo, peça licença para ir ao banheiro e nunca mais voltar. / p>     

A Microsoft começou a usar essas perguntas no início dos anos 80. À medida que a Microsoft se tornou notavelmente bem-sucedida, outras empresas começaram a copiá-las, mas alguns pontos-chave se perderam na tradução.

Na época, a Microsoft estava tentando preencher vários cargos técnicos, mas não relacionados a programação: redatores técnicos, testadores, suporte por telefone etc. Esses não eram trabalhos comuns no passado, e pessoas com experiência real nessas áreas eram difíceis de encontrar. Como alternativa, a Microsoft pensou que poderia contratar pessoas realmente inteligentes, inteligentes e flexíveis e treiná-las no trabalho. Uma vez que essas pessoas não tinham experiência em programação, fazer perguntas de programação na entrevista foi inútil. Os enigmas foram escolhidos para tentar identificar pessoas inteligentes e excepcionalmente boas habilidades analíticas. Em geral, os programadores recebiam problemas de programação no quadro branco, embora também pudessem ser questionados sobre charadas durante o almoço ou jantar.

Essas perguntas nunca foram feitas para passar de falhar. Eles pretendiam ser o início de uma conversa sobre como você lidaria com o problema e como você pensava sobre problemas que você nunca tinha visto antes. A única maneira certa de "falhar" era recusar-se a tentar resolver o problema. Na época, essa era uma estratégia nova e você não podia simplesmente procurar as perguntas no Google.

Editar:

Algum tempo depois de escrever esta resposta eu li The Computer Boys Take Over , uma história da computação institucional na década de 1950 e 1960. Aparentemente, a prática de pedir quebra-cabeças e enigmas de candidatos para trabalhos de programação remonta aos anos 50. Os EUA estavam tentando informatizar seu sistema de defesa aérea e a IBM estimou que precisariam de milhares de programadores para fazer o trabalho. A resposta foi choque e consternação: havia apenas algumas dezenas de "programadores profissionais" em todo o mundo. Diversas abordagens foram tentadas: testes abstratos de aptidões de programação, recrutamento de matemáticos como programadores, recrutamento de jogadores de xadrez e solucionadores de palavras cruzadas e seleção de candidatos com enigmas e quebra-cabeças.

Eles são úteis? Não, na verdade não. Eles já foram tão comuns na Microsoft que até foram chamados de "Microsoft questions", e tem havido livros escritos sobre eles, este é realmente uma boa leitura ..

Existem 2 problemas com eles. Em primeiro lugar, se o candidato fizer uma pesquisa (e ler o livro), ele irá conhecê-lo de qualquer maneira e, segundo, mesmo que possa resolvê-lo, como isso mostra que ele será um bom teste / teste / PM.

Por estas razões, eles raramente são mais solicitados na Microsoft. É muito melhor fazer perguntas de codificação ou questões de solução de problemas que não requeiram uma resposta "truque". Em outras palavras, você precisa fazer perguntas que lhe permitam explorar as habilidades e o comportamento do candidato enquanto tentam resolver o problema - como entrevistador, eu quero que eles façam perguntas, apresentem soluções e, em seguida, acompanhem quando descobrirem um problema, talvez nem mesmo encontre uma solução no tempo que eles têm, mas pelo menos faça isso de uma maneira sensata. Isso reflete o trabalho da vida real. Eu nunca tive que medir 3 litros usando 2 baldes e uma galinha (ou qualquer que fosse a pergunta).

Você pode querer ler o livro Como você mudaria o Monte Fuji? . Isso se aplica ao raciocínio de que muitas pessoas usam charadas em entrevistas, e minha opinião é que é uma combinação de comportamento de cultos de carga ( "A Microsoft faz isso, e se quisermos ser tão bem sucedidos como são, então é melhor fazer o que eles fazem ") e trote fraternidade (" por caramba !, eu tive que responder a essas perguntas e é melhor você acreditar que o próximo cara terá que respondê-las! ").

A história dessas perguntas como uma prática de entrevista começou com William Shockley na década de 1950. Eles eram uma pergunta de entrevista razoavelmente comum no Vale do Silício que os entrevistadores perguntavam porque outros entrevistadores estavam fazendo (e talvez eles soubessem algo que esse entrevistador não sabia?). Shockley pretendia que eles fossem um teste de inteligência, e a questão com os dois baldes era sobre um dos QAs originais de Stanford Binet: Stanley Binet IQ, Stanley Binet IQ, Stanley Binet IQ, Stanley Binet IQ, Stanley Binet IQ, Stanley Binet, Q1, Stanley Binet teste em 1916.

Muito possivelmente, as pessoas que estão fazendo as entrevistas realmente querem ver como você procura as respostas, então elas podem impossibilitar o cálculo de perguntas, como quantas bombas de gasolina existem em sua cidade. Esses tipos de problemas são Problemas Fermi . Dois posts interessantes de Jeff sobre este assunto são A pergunta mais difícil sobre quebra-cabeça de entrevista de todos os tempos e Como é bom um estimador? Parte III .

Outros forneceram respostas que eu inventei como must . A razão pela qual eu escrevo outra resposta é porque o que eu quero dizer provavelmente não vai caber em um comentário, e porque algo tem que ser dito sobre como uma boa entrevista de trabalho de programação pode ser.

Na primeira boa entrevista, lembro-me, conversamos muito, sem pressa. Primeiro por uma hora, no telefone, sobre o projeto orientado a objetos e os prós e contras de implementá-lo em C ++. Então, no site, falei com várias pessoas sobre suas práticas de desenvolvimento de software, integração, teste, controle de versão e gerenciamento de configuração, sobre equipes e responsabilidades, sobre tecnologia e sobre design. Foi uma entrevista de dia inteiro que incluiu o almoço com as pessoas que me entrevistaram. Em retrospectiva, era tudo sobre se eu me encaixaria produtivamente no que eles já estavam fazendo.

Desde então, as boas entrevistas foram longas, conversas de uma a duas horas sobre desenvolvimento de software. Não houve perguntas para solução de problemas, quebra-cabeças e desafios de codificação.

Se eu fosse entrevistar alguém para um trabalho de programação hoje, eu continuaria com os gostos. Eu pediria opiniões sobre uma variedade de tópicos e deixaria de lado a profundidade:

1. Quais são as suas preferências de linguagem de programação? Por quê?
2. Como abordar o tratamento de exceções?
3. Os benefícios do design em camadas não são um mito?
4. A integração contínua não é um fardo para a eficiência?
5. Quem escreveu um pedaço de código deveria ser o proprietário, certo?
6. O que você faz para entrar no "fluxo".
7. Como os defeitos relatados devem ser incluídos em um plano de projeto?
8. ...

Essas são perguntas com mais de uma resposta, e são todas sobre tópicos sobre os quais um desenvolvedor de software deve ter uma opinião informada. Eu sinceramente concordo com as respostas que mencionam problemas reais anteriores vivenciados como um tópico de conversa (não como perguntas).

Os estudos mais científicos sobre desenvolvimento de software eficaz desde Peopleware dizem que os melhores programadores são aqueles que entendem a dinâmica de desenvolvimento de software, mesmo que eles não tenham o QI mais alto. Eu prefiro ter um novato que está ansioso para aprender do que alguém com n de anos de experiência que se resumem a 1 de experiência repetida n vezes. Meu viés pessoal é para candidatos que tendem a pensar fora da caixa e, ao mesmo tempo, sabem como se encaixar na caixa atual (minha).

Eles podem ser úteis na avaliação de habilidades de resolução de problemas , o que é, obviamente, um dos aspectos-chave da programação.

Como entrevistador de muitas pessoas ao longo dos anos, eu não costumo fazer perguntas do tipo pegadinha parecidas com a que você descreve, mas posso perguntar algo e perguntar "como você resolver ... ".

Minhas expectativas nesse caso são ouvi-lo articular sua abordagem ao problema. Que outros dados você tentaria coletar? Como você testaria suas hipóteses, etc.

Estas são apenas práticas de contratação de vodu. Outras pessoas fazem essas perguntas para que sintam que devem. Eles sabem que não responder a pergunta é "ruim" e responder é "bom", mas eles não podem dizer por que além de não-respostas como "um desenvolvedor precisa dessas habilidades". Eles são uma perda de tempo e um indicador de que o entrevistador não é um entrevistador competente.

Esse é o raciocínio antigo de que você precisa ter habilidades lógicas básicas; qualquer outra coisa pode ser ensinada. Mas isso não é inteiramente verdade. Ler lógica booleana , condições e loops, não é o mesmo que ser capaz de resolver um quebra-cabeça lógico .

Dito isto, nos dias das linguagens procedurais, era provavelmente verdade que alguém que pudesse resolver estes problemas teria uma maior propensão a ser capaz de aplicar qualquer problema em termos de interruptores. Mas, em minha opinião, a programação OO / Functional requer uma mentalidade de engenharia, que é bem diferente (embora não contraditória).

Pessoalmente, não tenho certeza se gostaria de um emprego em uma empresa que ainda pensasse que a lógica fosse mais importante do que as habilidades práticas de programação.

O entrevistador deve estar se referindo à resolução de problemas e habilidades lógicas, o que faz parte do trabalho cotidiano de um programador. Quando dado um problema, você precisa ser capaz de analisá-lo, subdividi-lo e escrever uma solução para ele usando a abordagem mais ideal.

Você poderia argumentar o quão bem um quebra-cabeça como esse representa sua capacidade de fazer isso. Eu não vejo o mérito de fazer uma pergunta de quebra-cabeça, em vez de apenas fazer um problema de programação na vida real.

A programação não é sobre escrever linhas de código, trata-se de resolver problemas para e de outras pessoas (cliente, usuário, etc.).

Acontece que, para programadores, a solução assume a forma de um programa.

É por isso que é importante ter capacidade para resolver problemas e por que ela é testada.

Dito isto, não tenho a certeza que resolver quebra-cabeças complicados é a melhor maneira de avaliar alguém.

Quebra-cabeças em entrevistas se enquadram em duas categorias: "quebra-cabeças lógicos" (como o que você foi perguntado) e "pense diferente" categoria. A categoria pensar diferente (não tenho certeza se eles também são chamados de quebra-cabeças laterais?) Geralmente é desse tipo: quantas folhas existem nessa árvore? ou quantos alfaiates estão presentes em sua cidade?

Eu estou bem com "quebra-cabeças lógicos" porque eles têm uma ou talvez duas soluções no máximo e podem ser obtidas por lógica direta. E eu acredito que os enigmas lógicos são bons até certo ponto, porque o processo necessário para resolvê-los é muito mais do que um codificador precisa pensar na vida real.

O tipo "pensar diferente" não me incomoda, porque eles forçam você a fazer suposições e, depois, fazem alguns cálculos com base nas suposições. Simplificando, se seu entrevistador concordar com sua lógica, mas não com suas suposições, ou vice-versa, você perdeu. Há muito espaço para o entrevistador discordar da sua solução.

Quando dou entrevistas, não peço quebra-cabeças lógicos. Razão: A maioria dos candidatos, mesmo aqueles com 3-4 anos de experiência, falham ou desistem quando eu lhes peço para codificar problemas simples de livros didáticos, como a série Fibonacci ou palíndromos.

Dois pontos:

1. A programação é principalmente diferente da resolução de quebra-cabeças. É perfretamente explicado por Steve McConnell em "Code Complete":

   O que? Você não precisa ser superinteligente? Não, você não Ninguém é inteligente o suficiente para programar computadores. Entender completamente um programa médio requer uma capacidade quase ilimitada de absorver detalhes e uma capacidade igual para compreendê-los todos ao mesmo tempo. A maneira como você focaliza sua inteligência é mais importante do que quanta inteligência você tem. Como o capítulo 5 mencionou, na palestra do Prêmio Turing de 1972, Edsger Dijkstra entregou um artigo intitulado “The Humble Programmer”. Ele argumentou que a maior parte da programação é uma tentativa de compensar o tamanho estritamente limitado de nossos crânios. As pessoas que são melhores em programação são as pessoas que percebem quão pequenos são seus cérebros. Eles são humildes. As pessoas que são as piores na programação são as pessoas que se recusam a aceitar o fato de que seus cérebros não são iguais à tarefa. Seus egos os impedem de serem grandes programadores. Quanto mais você aprende a compensar seu pequeno cérebro, melhor será um programador . Quanto mais humilde você for, mais rápido você vai melhorar.

2. Esses quebra-cabeças podem ser úteis durante a entrevista, mas somente se o entrevistador olhar o Processo , não o resultado em si.

Mas, idealmente, os quebra-cabeças devem ser mais complicados e relacionados à programação (como um pequeno projeto de 2 horas), na minha opinião. A coisa é que os entrevistadores são pessoas e não têm "habilidades de entrevista" perfeitas.

Existem algumas maneiras diferentes de examinar esses problemas:

1. Conhecendo uma solução anterior. No filme ... Duro com uma vingança ... explica isso para mim ...? sendo um exemplo de conhecer uma solução para o caso em que os blahs são 4,3 e 5 respectivamente. Algumas pessoas poderão explorar rapidamente seu conhecimento interno de uma solução anterior e adaptá-la, se necessário. Geralmente, é isso que acredito que um entrevistador esperaria, o que pode ou não ser uma boa ideia.

2. Habilidades criativas de improvisação. Esse seria o caso se você não conhece uma solução anterior ou até mesmo reconhece o problema como sendo algo que alguém poderia modelar como uma equação diofantina. Assim, a questão é a rapidez com que você pode usar o que é dado e encontrar uma solução para o problema de maneira criativa, além de explicar por que o que você tem é uma solução válida para o problema.

Qualquer um poderia ser o que satisfizesse a questão de maneira satisfatória, embora em cada caso haja também um pouco de teste de habilidades de comunicação, como também se poderia tentar responder: "Isso é realmente relevante para a posição que Estou me inscrevendo? Quando essas habilidades foram usadas pela última vez? " Isso pode levar a um diálogo interessante se o entrevistador se abrir sobre o que exatamente eles estão querendo ver que talvez uma abordagem alternativa possa ser vista como mais eficaz aqui.

Não é um problema particularmente complicado. Apenas três etapas são necessárias e há apenas duas opções em cada etapa. Eu ficaria surpreso se algum dos meus colegas não conseguisse resolvê-lo em pouco tempo. Não apresentamos tais problemas em entrevistas, mas acho razoável fazer essas perguntas. Eles são certamente mais úteis do que perguntas detalhadas sobre sintaxe ou bibliotecas.

OTOH, acho que problemas de programação são mais úteis.

Você precisa lembrar que não há como saber com absoluta certeza que alguém será bom em um trabalho. Especialmente um trabalho de CS, já que muitos desafios que o trabalho pode ter em estoque não podem ser previstos.

Assim, o potencial empregador deve adivinhar seu desempenho futuro.

Graus, recomendações e GPAs podem ser obtidos com tempo / esforço e engenharia social, a experiência de trabalho pode ser embelezada e / ou falsa, e testes padronizados são francamente básicos demais para serem excessivamente indicativos de habilidade. Assim, o currículo pode dar alguma indicação de níveis de esforço / comprometimento em sua história, mas nada disso falará com sua capacidade real de resolver problemas difíceis que surgem no mundo da ciência da computação. Não consigo pensar em uma maneira melhor de prever esse tipo de habilidade do que em alguns bons enigmas de lógica / matemática / CSy.

Lembre-se de que é um jogo de adivinhação, e a realidade é que todas as coisas são iguais a qualquer um de nós preferiria contratar alguém capaz de resolver esses enigmas do que um que não possa.

Sim, você poderia estudar enigmas de entrevista, mas eu acho que você vai se sentir queimado se o quebra-cabeça dado não coincidir com o que você estuda ... e contanto que você não memorize os enigmas e suas soluções, talvez Estudar os quebra-cabeças em si fará de você uma pessoa mais inteligente de uma forma real, como qualquer educação real deveria.