La mayoría de mis entrevistas fueron con estudiantes que buscaban un puesto de pasantía, y la mayoría de las veces no hicieron nada con 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 por mi cuenta y les mostré mis soluciones cuando terminaron con las suyas.

Tuve unas cuantas 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, solo al verificar 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 para preguntar, no perdería el aliento, pero La respuesta de @Yannis_Rizos es mucho mejor.

Las entrevistas son de ritmo bastante rápido. 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 fricción es ser consciente del operador%. Esperaría que alguien pudiera pensar en comparar (myInt / 3) == (myDouble / 3.0) , pero tal vez con el estrés de una entrevista ... Aún así, FizzBuzz Classic obliga a un enfoque de fuerza bruta, colocándolo en la categoría de los problemas de algoritmo más fáciles de resolver. Como sugerencia, ¿ha intentado pedirle a la gente que simplemente codifique "Fizz" para obtener medio crédito y tal vez agregar "Buzz" más tarde como una mejora?

Creo que la respuesta definitiva a tu pregunta es que es realmente difícil encontrar buenos candidatos.

Preguntas de la entrevista en general

A menudo me resulta más fácil y más productivo pedir a los candidatos que describan el último proyecto de programación con el que estaban entusiasmados. 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 contrataciones y quienes no pudieron, no lo fueron. Esto tiene los efectos secundarios agradables de tranquilizar al candidato y alentar la discusión abierta. Con esta pregunta, el candidato, en efecto, le dirá para qué es más adecuado.

Tal vez en un grupo de reflexión también son necesarias las preguntas, pero las he abandonado en favor de la pregunta del "proyecto favorito".

Suma (Hijo) de FizzBuzz

Su 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 un   función que encuentra la suma de todos los múltiplos de 3 o 5 por debajo de 1000.

Donde FizzBuzz Classic te obliga a pasar por iteraciones n (para imprimir todos los números o Fizz / Buzz), tu problema se puede resolver en n / 5 + < em> n / 3 + n / 15 iteraciones, o incluso sin iteraciones: es posible un cálculo directo de punto fijo. 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 más grande 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 rechazaron esto como fuera de tema

El punto de presentar una solución a esta pregunta es mostrar que mientras que la solución de fuerza bruta para Sum of FizzBuzz es similar a FizzBuzz Classic, hay mejores soluciones disponibles para el problema de Sum, lo que lo convierte en un problema fundamentalmente diferente. La suma de FizzBuzz es extremadamente complicada si no recuerdas la fórmula adecuada para la suma de una serie, o si no te das cuenta de que se aplica al pasar por 3 o 5.

Si re-deriva la fórmula para la suma de una serie dividiendo la serie a la mitad, invirtiendo una mitad, y emparejándolos, obtendrá (n + 1) (n / 2) lo que puede derribar a 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 manera de resolver el problema para que   que al menos podría aprender de la experiencia. Pero de nuevo, no lo hizo.   pedir. ¿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 moleste en pedirle la respuesta correcta , entonces no vale la pena su tiempo. ¿Cómo en el mundo podrías ser tan intelectualmente perezoso?

E incluso si apestas totalmente como programador y solo tratas de convertirte en un trabajo, ¿por qué no serías tan pragmático para obtener la respuesta correcta ahora, para que lo sepas para el próximo? entrevista?

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

Si alguien hizo estallar a FizzBuzz en una entrevista de desarrollo de nivel junior porque no podían recordar al operador de módulo y simplemente no podían seguir adelante sin él, pero se apasionaron por volver a hacerlo una vez que explicaste lo respuesta correcta, o al menos hablar con el código correcto contigo, entonces eso es casi tan bueno como responderlo correctamente.

Escribí fizzbuzz mientras hablaba por teléfono con el entrevistador durante una pantalla previa. Eso es algo que, incluso si nadie ha oído hablar, deberías poder improvisar después de un semestre de trabajo de curso pero definitivamente después de adquirir el estatus de "senior".

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

Yo diría que tiene sentido entregarlo como una pantalla previa, por lo que no está perdiendo el tiempo de todos para llevarlos a una entrevista.

  

Incluso lo entrené para que pensara en usar un bucle y eso 3   y 5 realmente valieron la pena considerarlos como casos especiales.

Sería interesante saber lo que usted piensa que es la respuesta "correcta" a su pregunta de FizzBuzz-ish. Desde donde me siento, una buena (en C) escrita a la letra 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 hacerlo cuando puedes calcularlo directamente?

El punto es que hay más de una forma de despellejar a un gato, y el hecho de que el candidato en cuestión no haya comenzado a escribir for loops y mod operadores no significa que sea estúpido. Si desea 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é. Él 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 para enseñar una lección al candidato . Si realmente no saben cómo escribir código, no hay absolutamente ninguna necesidad de avergonzarlos pensando en lo que no saben. Si están lo suficientemente interesados para preguntar, entonces, por todos los medios, siéntase libre de compartir. De lo contrario, termine la entrevista, agradezca su tiempo y continúe con el próximo candidato.

Su "problema" es que usted es un humano empático, por lo que es difícil ver a alguien que lucha con un problema al que sabe 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ñar al entrevistado cómo programar o resolver problemas, o la solución a un problema que pregunte.

Cuando entrenas a un entrevistado, no es para que puedan obtener la respuesta correcta. Es para que pueda ver si realmente no pueden resolver el problema o si simplemente se han quedado colgando de uno o dos errores o malentendidos.

Entonces, si quieres darle a un entrevistado la solución después del hecho, lo estás haciendo por ti mismo. 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 hacerte creer que la entrevista fue mejor que si lo hicieras (si te encuentras pensando, "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 se había equivocado 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 poder 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 se les presente en el camino; Ese tipo de cosas. Incluso si obtienen la respuesta incorrecta, pueden seguir siendo viables según estos criterios.

Está bien, no saber que el operador de mod es inexcusable, y por las métricas que he dado a este candidato parece ser una cancelación, pero no creo que solo dar la respuesta correcta a este candidato vaya a ser de cualquier beneficio.

Esto se reduce a tu propia opinión personal desde aquí. ¿Desea dar comentarios de la entrevista para ayudar al candidato a mejorar en futuras entrevistas (y para que los futuros entrevistadores no tengan que sufrir por lo que acaba de pasar)? Si es así, distribuya sus comentarios en los términos que acabo de describir: dígales que no solo se trata de la respuesta correcta, sino que la forma en que 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 una vez más, él no preguntó. ¿Cuál es la forma correcta de manejar esa situación?

La forma en que lo veo, no hay ninguna 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 hizo la pregunta, no le debes una explicación. Y si habló con su gente de Recursos Humanos al respecto, podrían aconsejarle que no es aconsejable seguir 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 preguntes. Si solicita la solución "más simple" y la solución "más eficiente", las mejores respuestas son radicalmente diferentes. Y esto puede colorear su juicio injustamente ... 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 que antes de comenzar a codificar ...)

Para responder a tu pregunta, no, yo 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 desarrollador senior? Esto varía entre organizaciones y países. Por ejemplo, una empresa con la que trabajé fue considerada Ingenieros de Software con 5 años de experiencia como seniors. No se hizo hincapié en la calidad de la experiencia, solo en la duración.

Hasta que creamos un estándar que categorice a todos los Ingenieros de Software, independientemente de su idioma, nos quedamos con el individuo decidiendo el nivel de sus habilidades. Y continuaremos escuchando que los "Ingenieros Superiores" no superan la prueba de habilidades más rudimentaria.

Hace un par de semanas se hizo la pregunta "Cuándo debería te llamas a ti mismo un Desarrollador Senior ". También escribí una publicación de blog sobre el tema.