Le fallé a FizzBuzz, ¿me contratarías? [cerrado]

Soy un desarrollador con un título de CS y tengo experiencia laboral haciendo desarrollo en varios idiomas durante casi 3 años.

Hoy tuve una entrevista, en general todo salió bastante bien, me preparé para la mayoría de las preguntas y me sentí listo para cualquier cosa. Al final de la entrevista, me dieron UNA pregunta de programación ... un problema como FizzBuzz (sin la parte impresa). Creo que cometí demasiados errores y, por lo tanto, lo "fallé". ¿Se ha perdido toda esperanza para mí?

Aquí está mi 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 puede ver, estropeé los bools que deberían tener la sintaxis i% 3 == 0; Si recuerdo bien la pregunta, también pongo un else en lugar de un elseif con isThree && isFive. Estaba bastante estresado, pero eso no es excusa para perderse un problema simple.

Entonces, la pregunta es, ¿qué tan importante es poder producir código de trabajo en el lugar en relación con otros factores, como la experiencia y la personalidad? Por ejemplo, ¿el código anterior sería un factor decisivo?

El objetivo de FizzBuzz es mostrar que realmente sabes programar , no que hayas memorizado todas las reglas de sintaxis más finas del idioma en el que se te ha pedido programar (aunque eso sí importa, si quieren saber qué tan experimentado es). estás en el idioma)

Si llegaste tan lejos en el estrés de un entorno de entrevistas y puedes demostrar que entiendes los errores que cometiste, diría que pasaste.

Sí

La mayoría de las personas a las que he entrevistado que fallaron en la parte del ejercicio del código por una sintaxis menor o por una lógica ligeramente desviada terminaron siendo las mejores contratadas.

Tener la idea central de la lógica (lo que hiciste) y convertirla en algo decente y conciso desde el punto de vista del código (que creo que en su mayoría lo hiciste) es mucho más importante para mí que hacerlo absolutamente perfecto.

Compro un IDE por su comprobación de sintaxis, no contratar a un desarrollador para ello, y te habrías dado cuenta de los otros errores en el momento de tu primera depuración.

Pasaste del requisito inicial a un primer intento de forma bastante directa y sin hacer nada terrible. Eso es más valioso en muchos entornos que la perfección en ausencia de retroalimentación. Si el empleador es tan obsesivo con los detalles que se perdió, de todos modos podría ser una señal del entorno.

Si la tarea fuera la variante de números impresos, perder el detalle se vería un poco mal, pero no tendría el peso suficiente para cambiar mi decisión si de otra manera me gustaras para el puesto.

[Editar] Como Alex señaló, también está el aspecto de la reacción y la compostura. Personalmente, trato de sacar eso del camino antes de llegar a los ejercicios prácticos tratando de arrinconar al entrevistado en algo un poco fuera de su experiencia, pero algunos pueden optar por combinar los dos. De vez en cuando me encuentro con alguien que solo tiene conocimientos de libros de texto y que navega directamente a través de los problemas teóricos y de fondo, pero en serio se obsesiona con dónde comenzar con el ejercicio práctico. Algunos ni siquiera saben por dónde empezar.

Estas personas son EXACTAMENTE lo que quiero eliminar con este ejercicio.

Entonces, a menos que haya tomado 20 minutos para que el entrevistador aclare el requisito, imagino que su solución fue más o menos su primer intento, posiblemente con un par de correcciones a medida que avanzaba. Si obtuvo lo que puso arriba en menos de 5 minutos, demostró que puede pensar lo suficiente para mis estándares.

El código anterior probablemente sería un factor decisivo para mí si no tuviera otra cosa para continuar. Si siguen el estilo de la entrevista de Microsoft, entonces la persona que le hizo esta pregunta probablemente lo bloqueará, y a menudo es suficiente.

Lo que me desconcierta es que el entrevistador no le preguntó sobre este código. Un buen entrevistador ha visto suficiente código propio para saber que la gente comete errores, especialmente cuando tiene prisa. Por lo general, dicen: "¿Ves algo malo en este código?" "¿No? Bueno, vamos a probarlo". Se te ocurren algunos conjuntos de resultados y luego lo ejecutas a través de la función. Luego dices: "Oh, mierda, eso no funcionó". "Ok, cómo lo arreglarías ..." y así sucesivamente. Si sobrevive a ese diálogo, en realidad es bastante impresionante y demuestra la capacidad de pensar críticamente, presentar casos de prueba y depurar su propio código.

También tenga en cuenta que generalmente no están buscando "código de trabajo". ¿Quién produce ese primer intento de todos modos? Pero lógicamente correcto con manejo de errores y buenos conjuntos de pruebas es un buen objetivo.

Además, esto puede sorprenderlo, pero está compitiendo con muchas personas que ni siquiera pueden comenzar a usar fizzbuzz. Tendemos a suponer que todos los demás atraviesan árboles b + mientras duermen ... pero en realidad, ni siquiera pueden calcular múltiplos de 3 y 5 y usar un operador de módulo. Es posible que se sorprenda de lo mucho mejor que lo hizo con los demás candidatos.

Mi consejo, solo quítatelo. Recientemente me entrevisté en grandes empresas de software (Microsoft, Amazon, etc.), y fue la primera vez que pasé por un proceso de entrevistas tan exhaustivo. Me hice el ridículo en una entrevista de Microsoft en el sitio, en gran parte debido a los nervios, pero tampoco sabía qué esperar o qué estaban buscando exactamente. Clavé un problema de ruta más corta solo para resolver algunos problemas realmente simples. Saqué los valores del extremo incorrecto de una pila, olvidé en una int atoi(char* value)implementación queint val = value[i] - '0';me daría el valor entero del personaje y varios otros errores tontos. La mayor parte de la entrevista me hizo feliz, pero aún entendí por qué no recibí una oferta. Tenía que darme cuenta de que esto no era tanto un reflejo de mis habilidades como un indicador de que solo necesitaba seguir intentándolo hasta que pudiera dominar mis nervios. Finalmente, conseguí algunas entrevistas con preguntas mucho más difíciles y conseguí el trabajo de mis sueños. Realmente es, para la mayoría de las personas que realmente saben lo que están haciendo, solo una cuestión de averiguar qué quieren los entrevistadores, tener confianza en sí mismos y dárselos. Se tarda un poco.

Tendría que decir que no, pero no por la razón que diste, sino porque pusiste la sección FizzBuzz al final. Con la forma en que funciona su código, nunca imprimirá FizzBuzz cuando lo espera. Como Lee comentó, lo imprimirá para cada valor que no sea divisible por 3 o 5.

Pero el punto principal es que aprendes de ello. Me gusta el hecho de que estás aquí preguntando cómo podrías haberlo hecho mejor. Asegúrese de hacer algunos acertijos de código e investigar preguntas comunes de entrevistas. Además, tal vez intente cronometrarse o haga otra cosa que aumente la presión para poder imitar la sensación que tendrá en una entrevista. Y prepárate, prepárate y haz más preparación para la entrevista si realmente quieres sacarlo del parque.

No. El objetivo de FizzBuzz es ver si eres capaz de resolver la lógica condicional básica, que cubre todos los casos. Contrariamente a las opiniones de algunas personas, FizzBuzz no se trata de operador de módulo, sino de operaciones ternarias u operandos booleanos. Es un ejercicio simple en condicionales y lo has fallado.

El problema está estructurado para que todo el código de aspecto "elegante" no cubra al menos un caso.

Respuestas aceptables:

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;
    }
}

Le doy a la gente problemas de programación triviales para hacer en la pizarra. Si el código resultante está libre de errores no es el punto de decisión en absoluto. En cambio, me importan varios comportamientos exhibidos durante la redacción del código. Es interactivo, y estoy aprendiendo mucho sobre los candidatos mientras ocurre.

Entro en más detalles en la "prueba" de Whiteboard durante una entrevista: ¿forma legítima de hacer una copia de seguridad de su código (whiteboard)?

Por supuesto, su entrevistador puede no ser como yo. Pero es muy posible que usted haya pasado una entrevista conmigo , mientras que la producción de código que es un minúsculo pequeñito fuera poco, y muy posible que haya fallado con el código idénticos.

Si estuviera evaluando esto, estaría buscando las siguientes cosas:

1. ¿El candidato intenta obtener una comprensión clara de los requisitos antes de pasar a la implementación? ¿El candidato busca resolver mi problema o usar sus herramientas para mascotas en su caja de herramientas de programación? ¿Cómo hace el candidato para resolver problemas?
2. ¿Es el candidato fluido en al menos un lenguaje de programación?
3. ¿El candidato tiene una comprensión de la lógica booleana?
4. ¿Qué hace el candidato para garantizar la calidad de sus soluciones?
5. ¿Cómo responde el candidato a los comentarios sobre su código?

-

Es difícil decirlo en el n. ° 1. Su pregunta indica que su problema no incluyó la parte del "número de impresión", y su solución de hecho no incluye eso. No tengo más remedio que tomar su palabra, pero si de hecho fue el clásico problema de FizzBuzz que incluyó la impresión de los números que tampoco eran divisibles, entonces parece que saltó a una solución antes de comprender completamente los requisitos, que Sería una marca fuera.

Te daría crédito parcial por el # 2 y el # 3. Sabía utilizar el operador de módulo y tenía la estructura de una solución de trabajo, pero omitió partes de ambos.

Parece que no hiciste el n. ° 4, lo que te marcaría. En el futuro, recomendaría dar un paso atrás desde la pizarra y revisar su solución antes de llamarla. También (sin que se me solicite) pasaría por un par de pruebas unitarias para su solución, lo que habría demostrado rápidamente dónde se equivocó.

No te dieron una oportunidad en el n. ° 5, lo cual es lamentable. Pero el punto es que no quiero a alguien que piense que cada línea de código que han escrito es oro puro que no podría mejorarse, sino alguien dispuesto a aceptar comentarios sobre sus soluciones y entablar una conversación sobre su enfoque. .

-

Entonces, si estuviera evaluando esto solo, votaría "No Hire". Cosas como esta son una especie de medición de un arte de performance en lugar de la capacidad de programación , pero dominarlo aún puede ayudarlo en su carrera. Entonces, mis recomendaciones para futuras entrevistas tecnológicas serían:

1. Antes de la entrevista, practique un par de este tipo de ejercicios en frío, utilizando la menor cantidad de recursos externos posible. No para memorizar soluciones, sino para estar seguro de que se siente cómodo con su idioma preferido

2. Haga preguntas sobre el problema para validar sus suposiciones.

3. Antes de anunciar que su solución está completa, retroceda desde la pizarra y revísela, y recorra un par de casos de prueba unitarios simples.

Pedirle a alguien que resuelva un problema sin darles la posibilidad de obtener comentarios sobre su solución es un enfoque cuestionable, porque no se les permite mejorar.

Todo lo que esta prueba nos dice es que usted no demostró muy buenas habilidades para resolver problemas "de la cabeza".

Este podría ser uno de los elementos en la decisión de contratarte o no, pero para mí definitivamente no debería ser el único.

Si le hubieran proporcionado un entorno de prueba o ejecución de la unidad, los errores que cometió hubieran sido menos excusables.