Eu falhei no FizzBuzz, você me contrataria? [fechadas]

Sou desenvolvedor com experiência em CS e tenho experiência de trabalho em desenvolvimento em vários idiomas por quase 3 anos.

Hoje eu tive uma entrevista, no geral foi muito bem, me preparei para a maioria das perguntas e me senti pronto para qualquer coisa. No final da entrevista, eles me deram UMA pergunta de programação ... um problema como o FizzBuzz (sem a parte impressa do número). Acredito que cometi muitos erros e, portanto, "falhei". Toda a esperança está perdida para mim?

Aqui está o meu código:

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

Como você pode ver, eu errei os bools que deveriam ter a sintaxe i% 3 == 0; Se estou lembrando da pergunta corretamente, também coloquei um else em vez de um elseif com isThree && isFive. Fiquei bastante estressado, mas isso não é desculpa para perder um problema simples.

Portanto, a questão é: qual é a importância de poder produzir código de trabalho no local em relação a outros fatores, como experiência e personalidade? Por exemplo, o código acima seria um desagregador?

O objetivo do FizzBuzz é mostrar que você realmente sabe programar , não que memorizou todas as regras de sintaxe mais refinadas do idioma em que você foi convidado a programar (embora isso importe, se eles querem saber como é experiente você está no idioma).

Se você chegou até aqui no estresse de um ambiente de entrevista e pode mostrar que entende os erros que cometeu, eu diria que você passou.

sim

A maioria das pessoas que entrevistei que falharam na parte do exercício de código por causa de sintaxe menor ou lógica um pouco fora da lógica acabaram sendo as melhores contratadas.

Acertar a idéia central da lógica (o que você fez) e convertê-la em algo decente e conciso do ponto de vista do código (o que eu acho que você fez principalmente) é muito mais importante para mim do que deixá-la absolutamente perfeita.

Eu compro um IDE porque sua verificação de sintaxe não contrata um desenvolvedor para ele, e você teria percebido os outros erros dentro de momentos da sua primeira depuração.

Você passou do requisito inicial para uma primeira tentativa de maneira bastante direta e sem fazer nada de terrível. Isso é mais valioso em muitos ambientes do que a perfeição na ausência de feedback. Se o empregador está desconectado dos detalhes que você perdeu, pode ser um sinal de que o ambiente está por vir.

Se a tarefa fosse a variante dos números impressos, a falta dos detalhes pareceria um pouco ruim, mas não teria peso suficiente para mudar minha decisão se eu gostasse de você para a posição.

[Editar] Como Alex apontou, há também o aspecto de reação e compostura. Pessoalmente, tento evitar isso antes de começar os exercícios práticos, tentando encurralar o entrevistado em algo um pouco fora de sua experiência, mas alguns podem optar por combinar os dois. De vez em quando eu me deparo com alguém que só tem conhecimento de livros didáticos e eles navegam direto pelas questões teóricas e de fundo, mas ficam seriamente preocupados por onde começar com o exercício prático. Alguns nem conseguem descobrir por onde começar.

Essas pessoas são exatamente o que eu quero eliminar com este exercício.

Portanto, a menos que você tenha levado 20 minutos para fazer o entrevistador esclarecer o requisito, imagino que sua solução tenha sido mais ou menos sua primeira tentativa, possivelmente com algumas correções. Se você conseguiu o que colocou em menos de 5 minutos, mostrou que pode pensar o suficiente nos meus padrões.

O código acima provavelmente seria um problema para mim se eu não tivesse mais nada para continuar. Se eles seguirem o estilo de entrevista da Microsoft, a pessoa que fez essa pergunta provavelmente o bloqueará - e muitas vezes é preciso.

O que me deixa perplexo é que o entrevistador não perguntou sobre esse código. Um bom entrevistador viu seu próprio código o suficiente para saber que as pessoas cometem erros - especialmente quando estão com pressa. Geralmente eles dizem: "Agora você vê algo errado com esse código?" "Não? Bem, vamos testar". Você cria alguns conjuntos de resultados e o executa através da função Então você diz: "Oh, merda, isso não funcionou". "Ok, como você conserta isso ..." e assim por diante. Se você sobreviver a esse diálogo, ele é realmente impressionante e demonstra uma capacidade de pensar criticamente, apresentar casos de teste e depurar seu próprio código.

Observe também que eles geralmente não estão procurando por "código funcional". Quem produz que a primeira tentativa de qualquer maneira? Mas logicamente correto com tratamento de erros e bons conjuntos de testes é um bom objetivo.

Além disso, isso pode surpreendê-lo, mas você está competindo com muitas pessoas que nem conseguem iniciar o efervescimento. Nós tendemos a supor que todo mundo está atravessando árvores b + enquanto dorme ... mas, na realidade, eles não conseguem nem descobrir múltiplos de 3 e 5 e usam um operador de módulo. Você pode se deliciar surpreendentemente com o desempenho que fez com os outros candidatos.

Meu conselho, apenas ignore. Eu entrevistei recentemente grandes empresas de software (Microsoft, Amazon etc ...) e foi a primeira vez que passei por um processo de entrevista tão completo. Eu me enganei em uma entrevista no local da Microsoft em grande parte por causa dos nervos, mas também não sabia o que esperar ou o que exatamente eles estavam procurando. Eu preguei um problema de caminho mais curto apenas para resolver alguns problemas realmente simples. Retirei valores do lado errado de uma pilha, esqueci em uma int atoi(char* value)implementação queint val = value[i] - '0';me daria o valor inteiro do personagem e vários outros erros tolos. Fiquei feliz com a entrevista, mas ainda entendi por que não recebi uma oferta. Eu tinha que perceber que isso não era tanto uma reflexão sobre minhas habilidades, mas era um indicador de que eu só precisava continuar tentando até conseguir dominar meus nervos. Eventualmente, marquei algumas entrevistas com perguntas muito mais difíceis e consegui o emprego dos meus sonhos. Realmente é - para a maioria das pessoas que realmente sabe o que está fazendo - apenas uma questão de descobrir o que os entrevistadores querem, ter confiança em si mesmo e dar a eles. Leva um tempo.

Eu teria que dizer não, mas não pelo motivo que você deu, mas por colocar a seção FizzBuzz em último lugar. Com o funcionamento do seu código, ele nunca imprimirá o FizzBuzz quando você espera. Como comentou Lee, ele será impresso para todo valor não divisível por 3 ou 5.

Mas o ponto principal é que você aprende com isso. Gosto do fato de você estar aqui perguntando como poderia ter se saído melhor. Certifique-se de fazer alguns quebra-cabeças de código e pesquisar perguntas comuns da entrevista. Além disso, talvez tente cronometrar a si mesmo ou faça outra coisa que aumentaria a pressão, para que você possa imitar a sensação de que vai entrar em uma entrevista. E prepare, prepare e faça mais preparativos para a entrevista, se você realmente quiser eliminá-la.

Não. O objetivo do FizzBuzz é verificar se você é capaz de elaborar uma lógica condicional básica, que abrange todos os casos. Ao contrário das opiniões de algumas pessoas, o FizzBuzz não é sobre operador de módulo, conhecendo operações ternárias ou operandos booleanos. É um exercício simples de condicionais e você falhou.

O problema está estruturado para que todo o código de aparência "elegante" falhe em cobrir pelo menos um caso.

Respostas aceitáveis:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

Eu dou às pessoas problemas triviais de programação no quadro branco. Se o código resultante está livre de erros não é o ponto de decisão. Em vez disso, preocupo-me com vários comportamentos exibidos durante a escrita do código. É interativo e estou aprendendo bastante sobre candidatos enquanto está acontecendo.

Entro em mais detalhes no "teste" do quadro branco durante uma entrevista: maneira legítima de fazer backup do seu código (quadro branco)?

Claro, seu entrevistador pode não ser nada como eu. Mas é perfeitamente possível que você tenha passado uma entrevista comigo enquanto produzia um código muito pequeno, e é possível que tenha falhado com o código idêntico.

Se eu estivesse avaliando isso, procuraria o seguinte:

1. O candidato tenta entender claramente os requisitos antes de avançar para a implementação? O candidato procura resolver meu problema ou usar suas ferramentas de estimação em sua caixa de ferramentas de programação? Como o candidato resolve os problemas?
2. O candidato é fluente em pelo menos uma linguagem de programação?
3. O candidato tem uma noção da lógica booleana?
4. O que o candidato faz para garantir a qualidade de suas soluções?
5. Como o candidato responde ao feedback sobre seu código?

-

É difícil dizer no # 1. Sua pergunta afirma que seu problema não incluiu a parte "número de impressão" e sua solução não inclui isso. Não tenho escolha a não ser confiar na sua palavra, mas se, de fato, foi o problema clássico do FizzBuzz que incluiu imprimir os números que não eram divisíveis, parece que você pulou para uma solução antes de entender completamente os requisitos, o que seria uma marca fora.

Eu daria a você crédito parcial pelos itens 2 e 3. Você sabia usar o operador de módulo e tinha a estrutura de uma solução funcional, mas perdia partes de ambos.

Parece que você não fez o # 4, o que o marcaria. No futuro, eu recomendaria dar um passo atrás no quadro branco e examinar sua solução antes de terminar. Eu também (sem ser solicitado) percorria alguns testes de unidade da sua solução, que teriam demonstrado rapidamente onde você errou.

Eles não deram a você a chance de # 5, o que é lamentável. Mas o ponto é que eu não quero alguém que pense que toda linha de código que eles já escreveram seja ouro puro que não poderia ser melhorado, mas alguém disposto a aceitar comentários sobre suas soluções e se envolver em alguma conversa sobre sua abordagem .

-

Portanto, se eu estivesse avaliando isso sozinho, votaria "Sem contratação". Coisas como essa são meio que medir uma arte performática em vez de capacidade de programação , mas dominá-la ainda pode ajudar sua carreira. Portanto, minhas recomendações para futuras entrevistas técnicas seriam:

1. Antes da entrevista, pratique alguns desses tipos de exercícios a frio, usando o mínimo possível de recursos externos. Não para memorizar soluções, mas para ter certeza de que você está confortável com seu idioma preferido

2. Faça perguntas sobre o problema para validar suas suposições.

3. Antes de anunciar a solução completa, volte para o quadro branco, examine-o e passe por alguns casos simples de teste de unidade.

Pedir a alguém para resolver um problema sem dar a eles a capacidade de obter feedback sobre sua solução é uma abordagem questionável, porque eles não têm permissão para melhorar.

Todo esse teste nos diz que você não demonstrou habilidades muito boas na solução de problemas "top-of-the-head".

Esse poderia ser um dos elementos na decisão de contratar ou não você, mas para mim definitivamente não deve ser o único.

Se eles tivessem fornecido a você um ambiente de execução ou teste de unidade, os erros cometidos teriam sido menos desculpáveis.