FizzBuzz - sério? [fechadas]

Quando se trata de perguntas de "teste de entrevista", o assunto do FizzBuzz geralmente aparece. Há também um post sobre Horror em codificação .

Agora, se você se incomoda em ler sites como esse, provavelmente é menos provável que você esteja no grupo demográfico de programadores que considerariam o FizzBuzz nada além de trivial.

Mas é realmente verdade que 99% dos programadores terão dificuldades com isso?

Realmente?

Qual é a evidência para apoiar isso?

Alguns exemplos da vida real seriam muito úteis para responder a essa pergunta.

99%? Não. Uma porcentagem significativa? Sim. Da minha própria experiência direta de entrevistar pessoas, posso testemunhar isso. Pode parecer insignificante para você, mas há muitas pessoas no campo da programação que tentaram mais ou menos passar por anos e se candidatam a cargos que não são de nível de entrada e não são bem-sucedidas.

Mesmo que você consiga resolvê-lo facilmente, mas você me dá uma enorme estática sobre ser convidado a fazer uma tarefa tão insignificante contará contra você. Estar em equipe significa ter que fazer coisas que você pode não gostar, mas que são necessárias. Se logo de cara, antes mesmo de começarmos a trabalhar juntos, você acha que seria melhor tentar afirmar seu status especial de estar acima de fazer algo que eu pedi para você, então isso funcionará como uma marca contra você.

Eu não me importo necessariamente com o quão elegante é a sua solução (embora isso seria bom), mas ver você dar uma facada no quadro branco e falar o caminho mostra-me que você está pelo menos disposto a dar uma facada nele . Se você ficar indignado e disser algo como "Sou um solucionador de problemas, não um macaco de código!" então você será derrubado.

Já tive entrevistados que se recusam a começar a tentar. Simplesmente recuse. Não. Não vai fazer isso. Faço mais uma ou duas perguntas educadas, agradeço o tempo delas e encerro a entrevista.

Eu digo isso como gerente e desenvolvedor.

Eu acho que 99% dos programadores que se candidatam a um emprego (e não o conseguem) podem ter dificuldades. Mas não 99% dos programadores que estão produtivamente mantendo um emprego.

Essa é a natureza do nosso processo moderno de busca de emprego. Muitas pessoas que se inscrevem não são qualificadas.

Esse post sobre Coding Horror também fala da maneira como ensinamos Ciência da Computação atualmente. No passado (principalmente no MIT), você era obrigado a aprender coisas como o Lisp, que praticamente exige que você compreenda conceitos como recursão.

Atualmente, as pessoas aprendem Java porque ele é amplamente usado na indústria, e o foco mudou para a sintaxe, em vez de pensar profundamente em programação. Eu não gosto de Java; de fato, acho que é a primeira linguagem de programação ideal. Mas eu não vi meus instrutores ensinarem princípios de programação profundos com ele.

Eu odeio dizer isso, mas

A principal razão pela qual eu vi perguntas de programação não serem respondidas é culpa do autor da pergunta e não da pessoa que responde.

Lembro-me claramente de uma entrevista em que me perguntaram como criar um algoritmo de pesquisa de coleção específico que seria executado em tempo constante (mesmo número de pesquisas, independentemente de quantos itens da coleção). Eu me atrapalhei e me atrapalhei por 20 minutos antes de desistir. Foi então que esse gênio da entrevista começou a demonstrar a resposta como algo que operava em tempo quase constante, mas ainda não constante. Um pouco como dizer "Dê-me uma resposta igual a zero" e depois aceitar 0,1.

Além disso, já vi muitos casos em que alguém entrevistando faz uma pergunta que não atende aos seguintes critérios:

1. Eles conhecem todas as respostas corretas possíveis.
2. Eles sabem por que as respostas corretas estão corretas.
3. Eles sabem como fornecer informações suficientes sem dar a resposta.
4. As questões de "solução de problemas" não se baseiam no conhecimento de um fato não revelado (esse é o maior problema que já vi).
5. Levaria menos de um minuto para escrever a resposta se você não tivesse que descobrir. Se levar apenas 5 minutos para digitar o código, realmente é necessário mais resolução de problemas do que pode caber na parte verbal da entrevista.
6. As perguntas são baseadas em mais do que apenas "Um problema que encontrei uma vez ou fui informado na escola e, portanto, você deve saber como resolvê-lo agora ". Aposto que você teve mais de 2 minutos para responder, por que você não está dando ao candidato a mesma cortesia?

Sério (1), acho idiota pedir às pessoas que escrevam código na parte verbal de uma entrevista.

Sério (2), acho que entrevistar pessoas sem pedir que elas escrevam código também é estúpido.

Sério (3), você deve dar a eles "lição de casa", pedir que tragam amostras de código ou fornecer um laptop e algumas perguntas e um escritório silencioso para trabalhar com eles. Depois, deixe-os em paz enquanto trabalham neles. Eu geralmente uso a última abordagem, pois limita a capacidade de obter ajuda externa (trapaça) e posso cronometrar.

Tudo o que você precisa fazer é pesquisar no FizzBuzz. Houve uma enorme onda de postagens nele. De um modo geral, o blogueiro disse "Eu disse às pessoas para escrevê-lo em [algum idioma] e aqui estão os tipos de erros que eles cometeram:" e depois listaram algumas armadilhas. A diversão começa nos comentários em que as pessoas dizem "ha! Isso é trivial em [algum outro idioma], tudo o que você precisa escrever é o seguinte:" seguido pelo código. O próximo comentário invariavelmente encontra erros nesse primeiro. Parece que alguns desenvolvedores muito bons não acertam na primeira vez, em qualquer idioma. Alguns dos erros:

• Eu pedi 1 a 100 e você fez 1 a 99 ou 0 a 99
• bagunçando se o número deve ser impresso juntamente com fizz e / ou buzz
• desacordos sobre "fizzbuzz" vs "fizz-buzz"
• otimizações perdidas, como comparar duas vezes quando uma vez faria
• muito mais

Quando estou contratando, peço às pessoas que codifiquem no quadro branco para mim, nada tão complicado (eu sei, você não acha que é complicado) e muitos candidatos falham completamente. Quero dizer como escrever If, Then, End If ao estilo vb, mas colocar chaves também (só para garantir que eu acho) ou escrever C # (e perguntar primeiro, C #?), Mas não ter um ponto e vírgula em lugar nenhum. Não me inicie em erros de lógica!

Eu li o artigo sobre Coding Horror que você mencionou, e minha opinião é que Jeff está certo ... mas quando foi a última vez que ele foi entrevistado?

Quando você é entrevistado, geralmente está estressado e muitas vezes precisa responder a perguntas teóricas (sem inteligência, sem google, sem recarregador, ... apenas sua memória perturbada pelo estresse). É o mesmo nos testes. O estresse não ajuda.

Percebi que a única maneira de saber se alguém é adequado para uma posição é trabalhar com ele por um tempo ... Pegue as últimas 10 pessoas que você contratou em 100 (talvez mais), quanto foi realmente bom contratar???

Um empregador deve contratar um solucionador de problemas, não um macaco de código que saiba sobre módulos.

Você não pode testar "por um tempo todos os candidatos", portanto é necessário entrevistá-los. É por isso que concentro minhas perguntas nisso (resolução de problemas) e faço a verificação de referências anteriores.

Minha opinião é que o FizzBuzz é perigoso para a empresa que procura desenvolvedores para sustentar seu crescimento.

Recentemente, fui encarregado de entrevistar mais de 50 programadores para uma posição sênior, onde eles trabalhariam principalmente com PHP.

Joguei o problema do fizzbuzz no exame de triagem, principalmente para me divertir e porque queria dez boas perguntas e apenas nove. Minha intenção, na época, era mostrar às pessoas que também podemos nos divertir, mesmo nas perguntas da entrevista.

80% dos candidatos resolveram o problema, mas não usaram o operador de módulo.

15% dos candidatos não conseguiram resolver o problema.

5% dos candidatos resolveram o problema usando o operador de módulo.

Embora minha amostragem seja bastante limitada (50 solicitantes de um país), posso dizer que:

95% deles tinham um BS ou superior em um currículo de CS (as universidades daqui competem tentando fazer o CS parecer mais espetacular).

Fiquei verdadeiramente impressionado. Bem, assustado .. mas espantado. Não achei que chegaria perto de reproduzir os resultados, já que o problema se tornou tão popular. Isso me mostra que 5% dos meus candidatos podem não ser super programadores, mas pelo menos lêem blogs relacionados à programação.

Na minha última rodada de contratações, tive 3 trabalhadores da construção civil com 0, repito zero, educação ou experiência em programação para uma posição de desenvolvedor de software. ^* Então esse é o fundo do barril. Se você assumir uma distribuição normal de habilidade, poderá ver como o nível médio de habilidade será bastante baixo e até 'acima da média' (entre os candidatos) ainda será relativamente ruim.

Agora, se você está zombando apenas dos candidatos que tinham o que parecia ser uma habilidade de programação, verá que agora tem:

1. mentirosos
2. entusiastas de chavão (li um artigo sobre .NET uma vez)
3. programadores reais ruins
4. pessoas que usaram uma tecnologia para concluir um projeto, mas não aprenderam sobre ela (consulte perguntas efervescentes sobre o impossível de identificá-las)

Além disso, algumas perguntas 'fizzbuzz' que eu já vi são específicas do domínio. Você pode desenvolver progressivamente com uma linguagem / estrutura x por vários anos (daí z anos de experiência com x) e não se deparar com certas partes (desenvolvedores de bibliotecas que não conhecem muito sobre o desenvolvimento de componentes de interface do usuário, por exemplo).

Da mesma forma, muitos desenvolvedores fazem o desenvolvimento de manutenção atualmente, portanto, suas habilidades de arquitetura / design podem ser fracas em algumas áreas.

Agora, não tenho certeza se 99% é preciso, mas o IME ainda é bastante alto. Pelo menos na faixa de 80%.

^{* Não, nós não ligamos ou sequer demos uma segunda olhada nesses aplicativos.}

Sim com certeza. Provavelmente não 99%, mas ainda bem alto. Eu costumava entrevistar estudantes de ciência da computação para estágios e contratações em período integral. Eu entrevistaria cerca de 25 alunos em uma faculdade. Disseram-nos para não fazer as mesmas perguntas, porque os alunos conversaram. Eu aprendi rapidamente que isso não importava, porque eu teria apenas 3 ou 4 alunos dos 25 que poderiam responder à minha primeira pergunta. "Escreva strcmp"

Pedi que escrevessem uma função para comparar duas strings. Talvez use a função para classificar palavras para um dicionário. Você ficaria surpreso com o número de alunos que não entenderam como comparar duas palavras, muito menos saber como escrever a função. E alguns desses estudantes afirmaram ter todos os A's no CSc.

A coisa é programar é MUITO DIFÍCIL. Muitas pessoas gostam de pensar que sabem como programar, mas não sabem.

Alguns pensamentos:

• Eu não resistiria a alguém se o programa tivesse alguns erros, mas eles claramente tinham a idéia certa. A depuração faz parte da programação.

• Acho triste que muitas pessoas estejam se candidatando a empregos que não sabem que não podem fazer. Parece-me um problema com a economia.

• É realmente fácil fazer perguntas ruins às pessoas, onde a única resposta "correta" é aquela que o entrevistador daria.

Esse teste cobre muito bem várias coisas que eu quero saber sobre um programador que eu possa contratar:

1. Você pode mesmo programar?
2. Você pode escrever um programa a partir do zero (porque nem todos podem !!!)
3. Você pode resolver um problema sem mais -pensar-lo.

Para elaborar sobre o último ponto, existem inúmeras soluções para o efervescimento. Você procura legibilidade? Rapidez? Brevidade? Você tenta terminar de escrever o programa rapidamente? Como um programador ataca esse problema simples é muito revelador. Se um programador não pode escolher uma solução e vê-la até o fim, o que isso diz sobre como essa pessoa se sairá em uma tarefa real?

Infelizmente, muitas pessoas com currículos com aparência impressionante parecem não ter habilidades básicas de programação. Eu já vi muitos casos em que as pessoas que listam C e C ++ em seus currículos não conseguiam responder perguntas básicas sobre indicadores.

Há dois tipos de pessoas que eu espero que o FizzBuzz me ajude a evitar.

1. Chancadores sem nenhum conhecimento de programação ou nenhum conhecimento relevante de programação. Geralmente, você pode reconhecê-los no currículo, mas nem sempre, e dar a eles uma tarefa simples de programação é uma boa maneira de deixar claro que eles não são programadores.
2. Os graduados da escola em Java, que concluíram um curso ou diploma de programação, mas não sabem como programar. Essas pessoas podem ser mais difíceis de filtrar porque podem falar sobre teoria, mas simplesmente não possuem habilidades práticas. Colocar um problema simples na frente deles e pedir uma solução e uma explicação da solução é uma maneira muito boa de ver a diferença entre um Petra Java e um Paula Bean.

Em ambos os casos, eu realmente não me importo com uma implementação perfeita. O teste que você precisa fazer com as pessoas que se candidatam a empregos de desenvolvedor é que elas podem programar.

Dito isto, eu provavelmente não me incomodaria com esse teste específico por várias razões agora. Em primeiro lugar, é muito conhecido e qualquer um dos grupos acima tentaria rapidamente. Em segundo lugar, eu preferiria usar as perguntas na tela do telefone de Steve Yegge para filtrar os não programadores antes de chegarmos até eles. Se alguém reconhecesse essas perguntas, isso implicaria que eles leram o blog de Steve Yegge, o que sugeriria que eles estivessem no 1% dos desenvolvedores que levam sua profissão a sério e certamente garantem uma entrevista. Da mesma forma, se alguém tivesse um bom representante aqui ou no SO, eu estaria inclinado a entrevistá-lo.

É difícil acreditar que os desenvolvedores não possam codificar o FizzBuzz até que você veja os "nove para cinco" que copiam e colam seu trabalho juntos e tentam, de maneira concisa, não escrever código. Eu não podia acreditar quando ouvi um de nossos desenvolvedores seniores ensinar um desenvolvedor C #, com 3 anos de "experiência", como usar um Dicionário. Interfaces? Padrões de design? stdout? YAGNI? Minha liderança nunca tinha ouvido falar de YAGNI! É incrível o que essas pessoas não sabem.

Eu acredito nisso agora. Eu também acho que há muitos desenvolvedores apenas fazendo o suficiente.

Eu acho que parte do motivo de ser uma pergunta tão popular é porque existe mais de uma maneira de respondê-la e, dependendo de qual caminho o candidato escolher, poderá fornecer uma visão sobre como eles codificam. Alguns ótimos exemplos podem ser vistos aqui se você tiver 10K repetições no Stack Overflow.

Quanto à estatística de 99%, verifique de onde vem esse número. Provavelmente é tendencioso. Se é baseado em programadores iniciantes que estão entrevistando para o primeiro emprego, sim, posso ver que isso é possível, especialmente se a maioria de seus candidatos estiver saindo diretamente da faculdade. Na verdade, posso pensar em alguém que provavelmente escreveria uma declaração de condição 100 como solução para esse problema.

Acho a afirmação de que 99% dos programadores não conseguem programar ou resolver um teste simples de codificação altamente exagerado. No caso do teste do FizzBuzz, você já encontrou esse problema antes e pode resolvê-lo facilmente com o operador do módulo ou você não o encontrou antes e terá dificuldades. Não diz nada ao entrevistador sobre suas habilidades de programação.

Eu acho que o problema com muitos programadores aparentemente deixando uma má impressão em uma entrevista reside na natureza dos métodos técnicos de entrevista. Os entrevistadores esperam que os candidatos memorizem e reproduzam instantaneamente a sintaxe da linguagem, os detalhes e a complexidade computacional das estruturas de dados, arquiteturas de hardware, padrões de design etc. etc. A área de ciência da computação / engenharia de software é vasta. É impossível e insensível tentar memorizar tudo.

No mundo real, a chave é ser capaz de entender o problema de programação / design atribuído a você e saber onde encontrar informações (seu IDE, páginas de manual, livros, google, etc.) como resolver seu problema. Isso é algo que os entrevistadores nunca testam.

Eu ainda sou um programador relativamente júnior (eu tenho codificado por dinheiro por ~ 2 anos e codificado em alguma capacidade profissional como uma responsabilidade secundária por cerca de 2 antes disso), portanto, use grãos suficientes de sal.

Eu tenho alguma experiência fazendo uma primeira tela para codificadores para um projeto de grande empresa (nós meio que sabíamos que o projeto estava condenado, mas, ei, eles queriam pagar de qualquer maneira). Como o único programador da empresa que contratou, tive a tarefa de revisar currículos e selecionar candidatos.

Isso era para um projeto do governo e, talvez, provavelmente não atraísse os candidatos mais talentosos, mas eu não recebi um aplicativo de ninguém com uma conta no Github que realmente tinha o código mostrado, nem de qualquer pessoa que tivesse um portfólio, então usei o fizzbuzz ( literalmente o problema exato) como uma primeira passagem para quem parecesse capaz de programar.

Eu o antecipei com um pseudo-pedido de desculpas afirmando que eu sabia que era estúpido, mas que eu só queria ver qualquer código em funcionamento, e se eles quisessem, poderiam enviar outro exemplo de valor igual ou maior ou realmente qualquer coisa, mas esse efervescimento seria suficiente.

O resultado: não recebi uma resposta realmente correta, o que é impressionante, considerando o volume de respostas na Internet. Ninguém nem se deu ao trabalho de plagiar. Tivemos que apenas contratar pessoas que haviam trabalhado anteriormente nas iterações anteriores com falha do projeto.

Após o choque inicial do exercício e o desapontamento sobre o quão estragado foi o software / contratação do governo, me senti muito melhor com minhas próprias habilidades, com vitórias tão pequenas?

Edit: Por incorreto, não quero dizer um erro de um por um (ou seja, eu pedi entre 100 e 99) ou algum outro bug inocente que seja uma solução fácil. Quero dizer, não funcional, ou não será executado / compilado / etc ou mostrou claramente que o problema simplesmente não foi lido e compreendido, também uma parte significativa retirou o aplicativo e nenhum outro código foi enviado.