Tuvimos un candidato de entrevista de alto nivel que falló un matiz de la pregunta FizzBuzz ^{1 2} .
Quiero decir, realmente, completamente, completamente, fallé la pregunta, ni siquiera cerca.
Incluso lo entrenó a través de pensar acerca del uso de un bucle y que 3y 5eran realmente vale la pena considerar como casos especiales.

Lo sopló.

Solo para fines de control de calidad, di la misma pregunta exacta a tres compañeros de equipo; les dio 5 minutos; y luego regresó para recoger su pseudocódigo. Todos lo clavaron y no habían visto la pregunta antes. Dos preguntaron cuál era el truco ...

En un ejercicio de lógica diferente, el candidato mostró cierta comprensión de algunas de las características disponibles dentro del lenguaje que eligió usar (C #). Entonces no es como si nunca hubiera escrito una línea de código. Pero su lógica todavía apestaba.

Mi pregunta es si debería haberle dado o no la respuesta a las preguntas lógicas.

Sabía que los sopló, y lo reconoció más tarde en la entrevista.
Por otro lado, nunca pidió la respuesta o lo que esperaba ver.

Sé que los ejercicios de codificación se pueden usar para preparar a los candidatos para el fracaso (nuevamente, vea el segundo enlace desde arriba). Y realmente traté de ayudarlo a volver a casa para responder el núcleo de la pregunta. Pero este era un candidato de alto nivel y Fizz-Buzz es, francamente, ridículamente fácil incluso después de tener en cuenta las inquietudes de la entrevista.

Sentí que debería haberle mostrado una forma de resolver el problema para que al menos pudiera aprender de la experiencia. Pero de nuevo, no preguntó.

¿Cuál es la forma correcta de manejar esa situación?

² _{Para ayudar a aclarar, este es el matiz de Fizz-Buzz que pregunté y es del primer problema del Proyecto Euler . Sustituto de impresión Fizz | Buzz por sumar los números y tienes la misma pregunta fundamental.
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Write a function that finds the sum of all the multiples of 3 or 5 below 1000.}

³ _{Esta pregunta atrajo más atención de lo que esperaba, y agradezco todas las respuestas. Algunas de las respuestas posteriores realmente han llegado al centro de mi pregunta, por lo que permitiré a la comunidad revisar y votar antes de asignar "la" respuesta.}

⁴ _{Seleccioné "la" respuesta basada en los votos de la comunidad en ese momento. Y creo que la respuesta de Yannis es apropiada para entrevistas con desarrolladores más nuevos. Creo que la respuesta colectiva centrada en la falta de pedir la respuesta también es acertada.}

La mayoría de mis entrevistas fueron con estudiantes que buscaban un puesto de pasantía, y la mayoría de las veces arruinaron ejercicios simples (?). Quería una forma fácil y amigable de comunicar sus errores, y lo que se me ocurrió fue bastante simple: resolví los ejercicios yo mismo y les mostré mis soluciones después de que terminaron con los suyos.

Tuve algunas discusiones extremadamente interesantes y reveladoras con candidatos que comenzaron comparando nuestros diferentes enfoques para resolver el mismo problema. Después de un tiempo, incluso anticipé algunos de los errores, simplemente comprobando a qué escuela asistía el candidato (algunos "profesores" son ... imbéciles). Y, bueno, en los pocos casos en que un candidato no pudo encontrar ninguna solución, ya les había dado una para la próxima vez.

Dando la respuesta

Iba a decir que si el candidato no está lo suficientemente interesado como para preguntar, no perdería el aliento, pero la respuesta de @Yannis_Rizos es mucho mejor.

Las entrevistas son bastante rápidas. Sé que a menudo busco cosas durante días después de una entrevista.

Personas que no pueden codificar FizzBuzz Classic

Me imagino que un gran punto de conflicto es ser consciente del operador%. Es de esperar que alguien pueda pensar en comparar, (myInt / 3) == (myDouble / 3.0)pero tal vez con el estrés de una entrevista ... Aún así, FizzBuzz Classic fuerza un enfoque de fuerza bruta, colocándolo en la categoría de los problemas de algoritmo más fáciles de resolver. Como pista, ¿ha intentado pedirle a la gente que solo codifique "Fizz" para la mitad del crédito y quizás agregue "Buzz" más tarde como una mejora?

Creo que la respuesta final a su pregunta es que es realmente difícil encontrar buenos candidatos.

Preguntas de la entrevista en general

A menudo me ha resultado más fácil y productivo pedirles a los candidatos que describan el último proyecto de programación que les entusiasmó. He tenido un 100% de éxito con esta pregunta, lo que significa que las personas que hablaron animadamente sobre un proyecto de programación y pudieron responder preguntas técnicas al respecto fueron excelentes contratados y aquellos que no pudieron, no lo fueron. Esto tiene los buenos efectos secundarios de tranquilizar al candidato y alentar una discusión abierta. Con esta pregunta, el candidato, en efecto, le dirá para qué es más adecuado.

Quizás en un algoritmo de think tank también sean necesarias las preguntas, pero las abandoné a favor de la pregunta del "proyecto favorito".

Suma (Hijo) de FizzBuzz

Tu pregunta de la entrevista no es equivalente a FizzBuzz:

Si enumeramos todos los números naturales por debajo de 10 que son múltiplos de 3 o 5, obtenemos 3, 5, 6 y 9. La suma de estos múltiplos es 23. Escribe una función que encuentre la suma de todos los múltiplos de 3 o 5 por debajo de 1000.

Donde FizzBuzz Classic lo obliga a pasar por n iteraciones (para imprimir cada número o Fizz / Buzz), su problema se puede hacer en n / 5 + n / 3 + n / 15 iteraciones, o incluso sin iteraciones, una corrección directa. El cálculo de puntos es posible. El siguiente programa compara estos tres métodos:

public static void main(String[] args) {
  long n = Long.valueOf(args[0]).longValue();
  long sum = 0;
  long ms = System.currentTimeMillis();
  // Brute force method  Performance: cn
  for (long i = 1; i <= n; i++) {
    if ((i % 3) == 0) { sum += i;
    } else if ((i % 5) == 0) { sum += i; }
  }
  System.out.print("Brute force sum:    " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
  ms = System.currentTimeMillis();

  // Second solution: iterate through only numbers we are
  // interested in.  Performance: c * (n/3 + n/5 + n/15)
  // We counted multiples of 15 twice, so subtract one of them
  sum = countSum(n, 3) + countSum(n, 5) - countSum(n, 15);
  System.out.print("Only multiples sum: " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
  ms = System.currentTimeMillis();

  // Third solution: Use high school algebra.  Performance: c
  sum = sumSeries(n, 3) + sumSeries(n, 5) - sumSeries(n, 15);
  System.out.print("Sum of series:      " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
}

// Iteravely sum all multiples of skip
private static long countSum(long n, long skip) {
  long skipTotal = skip;
  long grandTotal = 0;
  while (skipTotal <= n) {
    grandTotal += skipTotal; skipTotal += skip;
  }
  return grandTotal;
}

// Thanks to @Caleb for pointing this out!  High school algebra
// tells us that the sum of a series is: (n * (a1 + an)) / 2
// where a1 is the first term and an is the nth term.  E.g. The
// sum of a series of 3 is: (n/3 * (3 + n - (n % 3))) / 2
// Since we are thinking about performance here, we'll shift
// right one instead of dividing by 2 for style points.  ;-D
private static long sumSeries(long n, long skip) {
  return (n/skip * (skip + n - (n % skip))) >> 1;
}

Salida (suma de FizzBuzz <1000):

$JDK_HOME/bin/java FizzBuzzNot 999
Brute force sum:    233168 time: 0
Only multiples sum: 233168 time: 0
Sum of series:      233168 time: 0

Con una n mayor para la comparación de rendimiento:

$JDK_HOME/bin/java FizzBuzzNot 1000000000
Brute force sum:    233333334166666668 time: 4744
Only multiples sum: 233333334166666668 time: 818
Sum of series:      233333334166666668 time: 0

Nota para aquellos que votaron en contra de esto como fuera de tema

El objetivo de presentar una solución a esta pregunta es mostrar que, si bien la solución de fuerza bruta para Sum of FizzBuzz es similar a FizzBuzz Classic, existen mejores soluciones para el problema de Sum, lo que lo convierte en un problema fundamentalmente diferente. La suma de FizzBuzz es extremadamente difícil si no recuerda la fórmula adecuada para la suma de una serie, o no se da cuenta de que se aplica al pasar por 3 o 5.

Si deriva la fórmula para la suma de una serie dividiendo la serie por la mitad, invirtiendo la mitad y emparejándolas, obtendrá (n + 1) (n / 2) que puede llevarlo por un camino realmente desordenado en lo que respecta a la división de enteros y los restos truncados. La versión (n (a1 + an)) / 2 de esta fórmula es absolutamente crítica para una respuesta simple para todos los valores de n.

Sentí que debería haberle mostrado una forma de resolver el problema para que al menos pudiera aprender de la experiencia. Pero de nuevo, no preguntó. ¿Cuál es la forma correcta de manejar esa situación?

No me importa para qué nivel es la entrevista, ni siquiera si es una pregunta de nivel "FizzBuzz" o una pregunta avanzada. Si le pide a un candidato que resuelva una pregunta y no puede, pero ni siquiera se molesta en pedirle la respuesta correcta, entonces no vale la pena su tiempo. ¿Cómo demonios podrías ser tan intelectualmente perezoso?

E incluso si apestas totalmente como programador y solo estás tratando de llegar a un trabajo, ¿por qué al menos no serías tan pragmático como para obtener la respuesta correcta ahora, para que lo sepas en la próxima entrevista?

Así que no, no debe "dar" la respuesta, pero debe esperar que el candidato insista en escuchar la respuesta correcta después de que falle. Si no lo hacen, es una gran bandera roja en mi libro.

Si alguien explotó FizzBuzz en una entrevista de desarrollo de nivel junior porque no podía recordar el operador del módulo y simplemente no podía seguir adelante sin él, pero luego se apasionó por volver a hacerlo una vez que explicaba la respuesta correcta, o al menos hablar el código correcto con usted, entonces eso es casi tan bueno como contestarlo correctamente.

Escribí fizzbuzz mientras hablaba por teléfono con el entrevistador durante una pre-pantalla. Eso es algo de lo que, incluso si todos no han oído hablar, deberían poder improvisar después de un semestre, por supuesto, trabajar, pero definitivamente después de adquirir el estatus de "senior".

Realmente no hay recuperación de no poder hacer eso. Es una de esas molestias necesarias que debes evitar por si acaso.

Yo diría que tiene sentido entregar como una pre-pantalla para que no pierdas el tiempo de todos al traerlos al sitio para una entrevista.

Incluso lo entrené para que pensara en usar un bucle y valió la pena considerar 3 y 5 como casos especiales.

Sería interesante saber cuál cree que es la respuesta "correcta" a su pregunta de FizzBuzz-ish. Desde donde estoy sentado, uno bueno (en C) escrito en la carta de su pregunta es:

int f(void) {
    // sum the multiples of 3 and of 5 and subtract multiples of 15 so we don't count them twice
    return ((1000/3)/2)*(999+3) + ((1000/5)/2)*(995+5) - ((1000/15)/2)*(990+15);
}

Una mejor podría ser:

¿Por qué diablos escribirías un programa para hacer eso cuando puedes calcularlo directamente?

El punto es que hay más de una forma de desollar a un gato, y el hecho de que el candidato en cuestión no comenzó inmediatamente a escribir forbucles y modoperadores no significa que sea estúpido. Si quiere saber lo que sabe el candidato, discuta el problema, descubra lo que está pensando. Si está atrapado o confundido, averigüe dónde y por qué. Podría llevarte a un enfoque que nunca consideraste.

Mi pregunta es si debería haberle dado o no la respuesta a las preguntas lógicas.

Como entrevistador, no es su lugar enseñarle una lección al candidato . Si realmente no saben cómo escribir código, no hay absolutamente ninguna necesidad de avergonzarlos pensando en cuánto no saben. Si están lo suficientemente interesados ​​como para preguntar, entonces no dude en compartir. De lo contrario, termine la entrevista, agradézcales por su tiempo y pase al próximo candidato.

Su "problema" es que es un humano empático, por lo que es difícil ver a alguien luchar con un problema para el que conoce la respuesta (esto también es un problema si realiza estudios de usabilidad). Desde la perspectiva de los deberes como entrevistador, no está obligado de ninguna manera a enseñarle al entrevistado cómo programar o resolver problemas, o la solución a un problema que usted pregunta.

Cuando entrena a un entrevistado, no es para que pueda obtener la respuesta correcta. Es para que pueda ver si realmente no pueden resolver el problema o si simplemente se quedaron atrapados en uno o dos errores o malentendidos.

Entonces, si desea darle a un entrevistado la solución después del hecho, lo está haciendo solo para usted. En general, prefiero usar ese tiempo para permitir que el entrevistado intente otro problema. Pero un programador "senior" que no puede responder a FizzBuzz probablemente esté fuera de la lista. Si decides dar soluciones, asegúrate de no engañarte a ti mismo pensando que la entrevista fue mejor de lo que fue (si te encuentras pensando, "él no pudo resolver el problema, pero cuando lo expliqué lo entendió bien", entonces Estás en un camino peligroso).

Y sí, he sido un entrevistado que estaba por encima de su cabeza y ni siquiera podía hacer el primer intento de resolver un problema de entrevista. Eso simplemente significaba que necesitaba aprender mucho más para buscar un trabajo en ese campo.

Obtener la respuesta correcta no es la parte importante de esta prueba. Lo que estás midiendo es el enfoque de alguien para resolver problemas, cómo se involucran con la pregunta, cualquier cosa creativa o interesante que encuentren en el camino; Ese tipo de cosas. Incluso si obtienen la respuesta incorrecta, pueden ser viables según estos criterios.

OK, no saber que el operador mod es inexcusable, y según las métricas que le he dado a este candidato, parece ser una cancelación, pero no creo que dar la respuesta correcta a este candidato sea de alguna utilidad. beneficio.

Esto se reduce a su propia opinión personal desde aquí. ¿Desea brindar comentarios de la entrevista con el fin de ayudar al candidato a mejorar en futuras entrevistas (y para que los futuros entrevistadores no tengan que sufrir lo que acaba de pasar)? Si es así, exprese sus comentarios en los términos que acabo de describir anteriormente: dígales que no se trata solo de la respuesta correcta, sino de cómo funcionan para llegar a la respuesta es un factor crítico.

Sentí que debería haberle mostrado una forma de resolver el problema para que al menos pudiera aprender de la experiencia. Pero de nuevo, no preguntó. ¿Cuál es la forma correcta de manejar esa situación?

A mi modo de ver, no hay situación que manejar. Suponiendo que haya rechazado su solicitud, la falta de interés (aparente) del candidato no es algo de lo que deba preocuparse.

De hecho, incluso si él no pide, no debe él una explicación. Y si habló con sus amigos de RR. HH. Al respecto, podrían aconsejarle que no sea aconsejable continuar con el candidato por razones legales.

También vale la pena señalar que el problema de FizzBuzz tiene diferentes "mejores" respuestas dependiendo de cómo lo pregunte. Si solicita la solución "más simple" y la solución "más eficiente", las mejores respuestas son radicalmente diferentes. Y esto puede cambiar su juicio de manera injusta ... si no estaba claro en la forma en que hizo la pregunta. (Por otro lado, un candidato bueno / experimentado tendría la previsión de aclarar eso antes de comenzar a codificar ...)

Para responder a su pregunta, no, no daría la respuesta. Si la persona quiere ser un mejor ingeniero de software, encontrará la respuesta. Si les das una respuesta, les estás robando esta oportunidad.

La pregunta más relevante es ¿cuándo puedes llamarte un desarrollador senior? Esto varía entre organizaciones y países. Por ejemplo, una empresa con la que trabajé consideraba ingenieros de software con 5 años de experiencia como personas mayores. No se hizo hincapié en la calidad de la experiencia, solo en la duración.

Hasta que lleguemos a un estándar que clasifique a todos los ingenieros de software, independientemente de su idioma, nos queda la decisión individual del nivel de sus habilidades. Y continuaremos escuchando sobre "Ingenieros Senior" que reprobaron la prueba de habilidades más rudimentaria.

Hace un par de semanas se hizo la pregunta "¿Cuándo deberías llamarte Desarrollador Senior?" . También escribí una publicación de blog sobre el tema.