FizzBuzz: ¿en serio? [cerrado]

Cuando se trata de preguntas de "prueba de entrevista", a menudo surge el tema de FizzBuzz. También hay una publicación de Coding Horror al respecto.

Ahora, si se molesta en leer sitios como este, es probable que sea menos probable que se encuentre en la demografía de los programadores que encontrarían a FizzBuzz de otra manera que trivial.

¿Pero es realmente cierto que el 99% de los programadores tendrán problemas con él?

De Verdad?

¿Cuál es la evidencia para respaldar esto?

Algunos ejemplos de la vida real serían muy útiles para responder esta pregunta.

99%? No. ¿Un porcentaje significativo? Si. Desde mi propia experiencia directa de entrevistar a personas, puedo dar testimonio de esto. Puede parecer insignificante para usted, pero hay muchas personas en el campo de la programación que han fingido durante más o menos su camino durante años y se postulan en puestos de nivel no básico y fallan en este.

Incluso si PUEDES resolverlo fácilmente, pero me das una gran estática sobre que te pidan que haga una tarea tan servil contará en tu contra. Estar en un equipo significa tener que hacer a veces cosas que quizás no disfrutes pero que son necesarias. Si de inmediato, incluso antes de comenzar a trabajar juntos, cree que sería mejor tratar de afirmar su estado especial de estar por encima de hacer algo que le he pedido que haga, entonces actuará como una marca en su contra.

No me importa necesariamente cuán elegante sea su solución (aunque eso sería bueno), pero verlo apuñalarlo en una pizarra y hablar sobre él me muestra que al menos está dispuesto a apuñalarlo . Si te indignas y dices algo como "¡Soy un solucionador de problemas, no un mono código!" entonces serás derribado una clavija.

He tenido entrevistados que se niegan rotundamente a comenzar a intentarlo. Simplemente rechaza. No. Uh uh No lo hare. Hago una o dos preguntas educadas más, les agradezco su tiempo y cierro la entrevista.

Digo esto como gerente y como desarrollador.

Creo que el 99% de los programadores que solicitan un trabajo (y no lo obtienen) pueden tener dificultades para conseguirlo. Pero no el 99% de los programadores que tienen un trabajo productivo.

Esa es la naturaleza de nuestro moderno proceso de búsqueda de empleo. Muchas personas que solicitan no están calificadas.

Esa publicación de Coding Horror también habla de la forma en que enseñamos Ciencias de la Computación en la actualidad. En el pasado (particularmente en el MIT), se requería que aprendieras cosas como Lisp, que prácticamente requiere que comprendas conceptos como la recursividad.

Hoy en día, a las personas se les enseña Java porque es ampliamente utilizado en la industria, y el enfoque se ha desplazado a la sintaxis en lugar del pensamiento de programación profunda. No me disgusta Java; de hecho, creo que es un primer lenguaje de programación ideal. Pero no he visto a mis instructores enseñar principios de programación profundos con él.

Odio decir esto pero

La razón principal por la que he visto que las preguntas de programación no son respondidas es la culpa del autor de la pregunta y no del que responde.

Puedo recordar claramente una entrevista en la que me preguntaron cómo crear un algoritmo de búsqueda de colección particular que se ejecutaría en tiempo constante (el mismo número de búsquedas, independientemente de cuántos elementos de la colección). Traté y tropecé con él durante 20 minutos antes de rendirme. Fue entonces cuando este genio que hizo la entrevista procedió a demostrar que la respuesta era algo que operaba en un tiempo casi constante, pero aún no constante. Un poco como decir "Dame una respuesta de cero" y luego aceptar 0.1.

En resumen, he visto demasiados casos en los que alguien entrevistando hace una pregunta que no cumple con los siguientes criterios:

1. Saben todas las posibles respuestas correctas.
2. Saben por qué las respuestas correctas son correctas.
3. Saben cómo proporcionar suficiente información sin revelar la respuesta.
4. Las preguntas de "resolución de problemas" no se basan en el conocimiento de un hecho no revelado (este es el mayor problema que he visto).
5. Le tomaría menos de 1 minuto escribir la respuesta si no tuviera que resolverlo. Si tomara 5 minutos solo escribir el código, realmente requiere más resolución de problemas de los que caben en la parte verbal de la entrevista.
6. Las preguntas se basan en algo más que "un problema me encontré con una o me dieron en la escuela y lo que debe saber cómo resolverlo ahora ". Apuesto a que tienes más de 2 minutos para contestar, ¿por qué no le das la misma cortesía al candidato?

En serio (1), creo que pedirles a las personas que escriban código en la parte verbal de una entrevista es estúpido.

En serio (2), creo que entrevistar a las personas sin pedirles que escriban código también es estúpido.

En serio (3), debe darles "tarea", pedirles que traigan muestras de código, o darles una computadora portátil y un par de preguntas y una oficina tranquila para trabajar en ellas. Luego déjelos solos mientras trabajan en ellos. Por lo general, elijo este último enfoque, ya que limita su capacidad de obtener ayuda externa (trampa) y puedo programarlo.

Todo lo que necesitas hacer es buscar en FizzBuzz. Hubo una gran ola de publicaciones en el blog. En general, el blogger dijo: "Le dije a la gente que lo escribiera en [algún idioma] y aquí están los tipos de errores que cometieron", y luego enumeró algunas trampas. La diversión comienza en los comentarios donde la gente dice "¡ja! Eso es trivial en [algún otro idioma], todo lo que tienes que escribir es esto:" seguido de un código. El siguiente comentario invariablemente encuentra errores en el primero. Parece que algunos desarrolladores muy buenos no lo hacen bien la primera vez, en ningún idioma. Algunos de los errores:

• Pedí de 1 a 100 e hiciste de 1 a 99 o de 0 a 99
• estropeando si imprimir el número junto con efervescencia y / o zumbido
• desacuerdos sobre "fizzbuzz" vs "fizz-buzz"
• optimizaciones perdidas, como comparar dos veces cuando una vez lo haría
• mucho más

Cuando estoy contratando, le pido a la gente que codifique en la pizarra por mí, nada tan complicado (lo sé, no crees que sea complicado) y muchos candidatos fallan por completo. Me refiero a escribir vb-style If, ​​Then, End If pero también poner llaves (solo para estar seguro, supongo) o escribir C # (y preguntar primero, ¿C #?) Pero sin tener un punto y coma en ninguna parte. ¡No me inicies con errores lógicos!

He leído el artículo de Coding Horror que mencionas, y mi opinión es que Jeff tiene razón ... pero ¿cuándo es la última vez que fue entrevistado?

Cuando lo entrevistan, generalmente está muy estresado, y a menudo tiene que responder a preguntas teóricas (sin inteligencia, sin google, sin resharper, ... solo su memoria preocupada por el estrés). Eso es lo mismo en las pruebas. El estrés no te ayuda.

Me di cuenta de que la única forma de saber si alguien es adecuado para un puesto es trabajar con él por un tiempo ... Solo tome las últimas 10 personas que contrató de cada 100 (tal vez más), cuánto fue realmente bueno ¿¿¿alquiler???

Un empleador debe contratar un solucionador de problemas, no un mono de código que sepa sobre módulos.

No puede evaluar "por un tiempo a todos los solicitantes", por lo que se requiere entrevistarlos. Es por eso que enfoco mis preguntas en eso (resolución de problemas) y hago una verificación de referencias pasadas.

Mi opinión es que el FizzBuzz es peligroso para la empresa que busca desarrolladores para respaldar su crecimiento.

Recientemente tuve la tarea de entrevistar a más de 50 programadores para un puesto senior en el que trabajarían principalmente con PHP.

Arrojé el problema del fizzbuzz en el examen de detección, principalmente para divertirme y porque quería diez buenas preguntas y solo tenía nueve. Mi intención, en ese momento, era mostrarle a la gente que también podemos divertirnos, incluso en las preguntas de la entrevista.

El 80% de los solicitantes resolvió el problema, pero no utilizó el operador de módulo.

El 15% de los solicitantes no pudieron resolver el problema.

El 5% de los solicitantes resolvió el problema utilizando el operador de módulo.

Si bien mi muestreo es bastante limitado (50 solicitantes de un país), puedo decirle que:

El 95% de ellos tenían un BS o superior en un plan de estudios de CS (las universidades aquí compiten tratando de hacer que el sonido de CS sea más espectacular).

Estaba realmente asombrado. Bueno, asustado ... pero asombrado. No pensé que estaría cerca de reproducir los resultados, ya que el problema se ha vuelto tan popular. Esto me muestra que el 5% de mis solicitantes pueden no ser súper programadores, pero al menos leen blogs relacionados con la programación.

En mi última ronda de contratación tuve 3 trabajadores de la construcción con 0, repito cero, la educación o experiencia en programación solicito un puesto de desarrollador de software. ^* Entonces ese es el fondo del barril. Si asume una distribución normal de habilidades, puede ver cómo el nivel de habilidad promedio será bastante bajo e incluso 'por encima del promedio' (entre los solicitantes) seguirá siendo relativamente malo.

Ahora, si solo estás fizzbuzzing a los solicitantes que tenían lo que parecía ser una habilidad de programación, verás que ahora tienes:

1. mentirosos
2. entusiastas de la palabra de moda (una vez leí un artículo sobre .NET)
3. malos programadores reales
4. personas que usaron una tecnología para completar un proyecto, pero no aprendieron sobre ella (vea las preguntas de fizzbuzz sobre idisposable para identificarlas)

Además, algunas preguntas de 'fizzbuzz' que he visto son específicas del dominio. Puede desarrollarse progresivamente con un lenguaje / marco x durante varios años (de ahí la experiencia de z años con x) y no haber encontrado ciertas partes (los desarrolladores de bibliotecas no saben mucho sobre el desarrollo de componentes de UI, por ejemplo).

Del mismo modo, muchos desarrolladores realizan desarrollo de mantenimiento en estos días, por lo que sus habilidades de arquitectura / diseño pueden ser débiles en algunas áreas.

Ahora, no estoy seguro de si el 99% es correcto, pero IME sigue siendo bastante alto. Al menos en el rango del 80%.

^{* No, no llamamos ni dimos un segundo vistazo a estas aplicaciones.}

Sí, en serio. Probablemente no el 99%, pero sigue siendo bastante alto. Solía ​​entrevistar a estudiantes de informática para pasantías y contrataciones a tiempo completo. Entrevistaría a unos 25 estudiantes en una universidad. Nos dijeron que no hiciéramos las mismas preguntas, porque los estudiantes hablaron. Rápidamente aprendí que no importaba, porque solo obtendría 3 o 4 estudiantes de los 25 que podrían responder mi primera pregunta. "Escribir strcmp"

Les pedí que escribieran una función para comparar dos cadenas. Quizás usar la función para ordenar palabras para un diccionario. Se sorprendería de la cantidad de estudiantes que no entendieron cómo comparar dos palabras, y mucho menos saber cómo escribir la función. Y algunos de estos estudiantes afirmaron que obtuvieron todas las A en CSc.

La cosa es que la programación es MUY DIFÍCIL. A mucha gente le gusta pensar que saben programar, pero no lo hacen.

Algunos pensamientos:

• No lo consideraría en contra de alguien si su programa tuviera algunos errores, pero claramente tenían la idea correcta. La depuración es parte de la programación.

• Creo que es triste que tantas personas soliciten trabajos que no saben que no pueden hacer. Me parece un problema con la economía.

• Es realmente fácil hacerle a la gente malas preguntas, donde la única respuesta "correcta" es la que daría el entrevistador.

Esta prueba cubre muy bien varias cosas que quiero saber sobre un programador que podría contratar:

1. ¿Puedes incluso programar?
2. ¿Puedes escribir un programa desde cero (porque no todos pueden hacerlo!)
3. ¿Puedes resolver un problema sin pensarlo demasiado ?

Para dar más detalles sobre el último punto, hay innumerables soluciones para fizz-zumbido. ¿Vas por legibilidad? ¿Velocidad? ¿Brevedad? ¿Intentas terminar de escribir el programa rápidamente? Cómo un programador ataca este simple problema es muy revelador. Si un programador no puede elegir una solución y verla hasta el final, ¿qué le dice eso sobre cómo esta persona se desempeñará en una tarea real?

Desafortunadamente, muchas personas con currículums impresionantes parecen carecer de habilidades básicas de programación. He visto muchos casos en que las personas que enumeran C y C ++ en sus hojas de vida no pueden responder preguntas básicas sobre punteros.

Hay dos tipos de personas que espero que FizzBuzz me ayude a evitar.

1. Chancers sin conocimiento de programación o sin conocimiento relevante de programación. Por lo general, puede reconocerlos desde el CV, pero no siempre, y darles una tarea de programación simple es una buena manera de dejar en claro que no son programadores.
2. Graduados de la escuela Java, que han completado un curso o título de programación pero en realidad no saben cómo programar. Estas personas pueden ser más difíciles de filtrar porque pueden hablar de teoría pero simplemente no tienen habilidades prácticas. Poner un problema simple frente a ellos y pedir una solución y una explicación de la solución es una muy buena manera de ver la diferencia entre un Petra Java y un Paula Bean.

En cualquier caso, realmente no me importa una implementación perfecta. La prueba que debe hacer con las personas que solicitan trabajos de desarrollador es que pueden programar.

Dicho esto, probablemente no me molestaría con esa prueba en particular por varias razones ahora. En primer lugar, es muy conocido y cualquiera de los grupos anteriores lo probaría rápidamente. En segundo lugar, preferiría usar las preguntas de la pantalla del teléfono de Steve Yegge para descartar a los que no son programadores antes de llegar a ellos. Si alguien reconoce esas preguntas, implicaría que han leído el blog de Steve Yegge, lo que me sugiere que estaban en el el 1% superior de los desarrolladores que toman en serio su profesión y ciertamente merecen una entrevista. Del mismo modo, si alguien tuviera un buen representante aquí o en SO, me inclinaría a entrevistarlo.

Es difícil creer que los desarrolladores no puedan codificar FizzBuzz hasta que vean los "nueve a cinco" que copian y pegan su trabajo juntos e intentan conscientemente no escribir código. No podía creerlo cuando escuché a uno de nuestros desarrolladores senior que enseñaba a un desarrollador de C #, con 3 años de "experiencia", cómo usar un Diccionario. Interfaces? ¿Patrones de diseño? stdout? YAGNI? ¡Mi líder nunca había oído hablar de YAGNI! Es sorprendente lo que estas personas no saben.

Lo creo ahora. También creo que hay demasiados desarrolladores haciendo lo suficiente.

Creo que parte de por qué es una pregunta tan popular es porque hay más de una forma de responderla, y dependiendo de la forma en que el candidato elija ir puede darle una idea de cómo codifican. Aquí se pueden ver algunos ejemplos excelentes si tiene 10K de representante en Stack Overflow.

En cuanto a la estadística del 99%, verifique de dónde proviene ese número. Probablemente sea parcial. Si se basa en programadores de nivel de entrada que se entrevistan para su primer trabajo, entonces sí puedo ver que eso sea posible, especialmente si la mayoría de sus candidatos salen directamente de la universidad. De hecho, puedo pensar en alguien que probablemente escribiría una condición 100 si la declaración es una solución a ese problema.

Encuentro la afirmación de que el 99% de los programadores no pueden programar o resolver una simple prueba de codificación muy exagerada. En el caso de la prueba FizzBuzz, o ha encontrado este problema anteriormente y puede resolverlo fácilmente con el operador de módulo o no lo ha encontrado antes y tendrá dificultades para resolverlo. No le dice al entrevistador nada sobre sus habilidades de programación.

Creo que el problema con muchos programadores que aparentemente dejan una mala impresión en una entrevista radica en la naturaleza de los métodos de entrevista técnica. Los entrevistadores esperan que los solicitantes memoricen y reproduzcan instantáneamente la sintaxis del lenguaje, los detalles y la complejidad computacional de las estructuras de datos, arquitecturas de hardware, patrones de diseño, etc. El área de la informática / ingeniería de software es vasta. Es imposible e insensible tratar de memorizar todo.

En el mundo real, la clave es poder comprender el problema de programación / diseño que se le asignó y saber dónde encontrar información (su IDE, páginas de manual, libros, google, etc.) para resolver su problema. Sin embargo, esto es algo que los entrevistadores nunca prueban.

Todavía soy un programador relativamente joven (he estado codificando dinero durante ~ 2 años y codificando en alguna capacidad profesional como una responsabilidad secundaria por aproximadamente 2 antes de eso), así que use suficientes granos de sal.

Tengo cierta experiencia haciendo una primera pantalla para codificadores para un Proyecto de Gran Empresa (sabíamos que el proyecto estaba condenado, pero bueno, querían pagar de todos modos). Como el único programador de la empresa que realizaba la contratación, me asignaron la tarea de revisar currículums y seleccionar a los solicitantes.

Esto era para un proyecto del gobierno por lo que tal vez , probablemente, no atrajo a los candidatos con más talento, pero no recibió una solicitud de cualquier persona con una cuenta de github que realmente había mostrado código, ni nadie que tuviera una cartera, por lo que utiliza FizzBuzz ( literalmente el problema exacto) como primer paso para cualquiera que pareciera que podría programar.

Lo presenté con una pseudo-disculpa que decía que sabía que era estúpido, pero que solo quería ver cualquier código que funcionara, y si quisieran, podrían enviar otro ejemplo de igual o mayor valor o realmente cualquier cosa, pero ese fizzbuzz sería suficiente.

El resultado: no obtuve una respuesta que fuera realmente correcta, lo cual es alucinante teniendo en cuenta el volumen de respuestas en Internet. Nadie se molestó en plagiar. Tuvimos que simplemente contratar personas que habían trabajado previamente en las iteraciones anteriores fallidas del proyecto.

Después de la conmoción inicial del ejercicio y la decepción acerca de cuán jodido fue el software / contratación del gobierno, me sentí mucho mejor con mis propias habilidades, ¿tan pequeñas victorias?

Editar: Por incorrecto no me refiero a un error off-by-one (es decir, solicité hasta 100, no 99) o algún otro error inocente que sea una solución fácil. Quiero decir que no es funcional, o no se ejecutará / compilará / etc. o mostró claramente que el problema simplemente no se leyó y no se entendió, también una parte significativa retiró la aplicación y ninguno envió otro código en su lugar.