Programadores que son altamente recomendados, pero que no pueden manejar la pregunta de programación de prueba en papel

tl; dr: Cómo tratar con programadores que son altamente recomendados, pero que no pueden manejar la pregunta de programación de prueba en papel

Entrevisté a un candidato para un puesto de programación. Él es un recién graduado de una universidad en ciencias de la computación.

Tiene una excelente recomendación de su supervisor mientras estaba haciendo una pasantía para un trabajo de programación, y tuvo una serie de proyectos paralelos de programación en su haber durante su tiempo en la universidad. Proyectos no muy difíciles, pero definitivamente sitios web/aplicaciones móviles autónomos y utilizables. Basado en el currículum, parece un ajuste estelar.

El único problema es que cuando le hice una prueba en papel, básicamente tiene que usar lápiz y papel para responder algunas preguntas de programación, tuvo problemas y no pudo contestar una sola. Todas mis preguntas son preguntas de programación muy básicas, en algún lugar a lo largo del nivel de fizzbuzz, haciendo coincidir un elemento en la matriz, el tipo de preguntas que pueden responder fácilmente aquellos que toman un semestre de curso de programación de nivel de entrada.

Y ya mencioné que no me importa en absoluto la sintaxis/lenguaje. El pseudocódigo es lo suficientemente bueno para mí.

Pidió retirar las preguntas para obtener respuestas, a lo que acepté. Al día siguiente me envió las soluciones totalmente corregidas. Hizo las tareas en un IDE y logró obtener todas las respuestas correctas.

Esto me desconcierta: si es tan bueno como implica su recomendación de referencia, ¿por qué no puede manejar la prueba en papel? ¿Es posible que haya algunas personas que puedan codificar bien frente a la pantalla de una computadora, pero cuando se trata de escribir soluciones de programación en un papel, tengan dificultades?

Editar:

  1. No me importa la sintaxis, esto se le comunicó claramente.
  2. El nivel de preguntas solo hace uso de las construcciones más elementales como for, if... nada en absoluto sobre llamadas esotéricas de biblioteca. Cualquier cosa que requiera conocimientos prácticos en un determinado marco se considera no básica. Por lo tanto, no le pido al examinado que memorice ninguna llamada al httpmétodo.
Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
No entiendo por qué seguiría usando una prueba en papel. ¿Cuándo alguien codifica en papel? Debería haberlo dejado hacer la prueba en un IDE en un sistema con una pantalla reflejada y haber observado su proceso. Eso le dirá MUCHO más sobre con quién está trabajando. Su prueba es equivalente a poner a alguien frente a la batidora de pintura en Home Depot y usar ese resultado para decidir si la persona es un buen retratista.
Como mínimo, pensaría que podría darle al candidato un editor de texto y una computadora, no solo lápiz y papel. Editar en lápiz y papel es un fastidio. Los programadores estamos acostumbrados a poder insertar cosas.
Como programador, nunca creí en esas pruebas. Con demasiada frecuencia, contienen preguntas sobre cosas que nunca necesita usar y esperan que sepa por el simple hecho de saber cosas.
Cuando dice que no pudo resolver los problemas correctamente, ¿quiere decir que no obtuvo la sintaxis correcta o que ni siquiera pudo diseñar el pseudocódigo?
@DaveG, ni siquiera pudo diseñar el pseudocódigo
¿Es posible que el candidato confíe mucho en el ensayo y error? Los algoritmos informáticos se pueden ejecutar y depurar de una manera que los algoritmos escritos no pueden.
@Graviton Recuerdo que en la escuela intentaron enseñar pseudocódigo como si fuera otro idioma. Entonces, cuando le pregunto a alguien, digo algo como "¿puedes escribir algún pseudocódigo o escribir algunas declaraciones lógicas para explicar?" para dar una oportunidad de escribir cualquier cosa que parezca código y no algún nuevo estándar de pseudocódigo.
@Graviton ¿Puede decirnos cuáles fueron algunas de las preguntas? Eso nos ayudaría a determinar por qué no pudieron ser respondidas. FizzBuzz está mal redactado y no es lo suficientemente preciso como para dar instrucciones a un programador. Está en lenguaje de usuario.
@TrevorD, FizBuzz es literalmente una de las preguntas. Otras preguntas son como "obtener la posición de índice de un elemento en una matriz", "secuencia de Fibonacci".
Tengo problemas para determinar lo que está buscando con esta pregunta, razón por la cual no está recibiendo la atención requerida. ¿Puede repetir en la parte superior en un lenguaje claro lo que está buscando en Internet, por favor?
@Mirv, puse un tl; dr en la parte superior de esta pregunta

Respuestas (16)

¿Es posible? Seguro. Las personas pueden acostumbrarse tanto a un IDE con autocompletado de sintaxis y resaltado de sintaxis que se bloquean mentalmente si intentan escribir código en papel o en una pizarra.

¿Es posible que haya hecho que alguien más haga el trabajo? Seguro.

¿Por qué no pedirle que regrese y haga un conjunto similar de problemas con una computadora con cualquier IDE que desee configurar? Si es capaz de producir código de calidad en un entorno mucho más cercano al lugar de trabajo real, genial. En el futuro, puede ofrecer a los candidatos la opción de usar un IDE o hacer las preguntas en papel por adelantado si las personas tienen un bloqueo mental con las pruebas en papel.

+1 o las personas pueden tener discapacidades como yo. Tengo disgrafía, así que en realidad no puedo escribir mucho. (Se pierde entre mi cerebro y mi mano) pero puedo escribir muy bien. Cuanto más alejada esté una prueba del trabajo, menos valiosa será la prueba.
Una sesión de codificación en el sitio o una prueba de código donde obtengan una computadora y tengan que codificar algo sobre la marcha sería bueno, luego pídales que expliquen lo que hicieron. Esto también parece un mejor reflejo de cómo trabaja la gente. Si usa el emparejamiento en su trabajo, también puede hacer que se emparejen con un empleado.
@RichardU si tienes disgrafía, ¿cómo aprobaste los exámenes escolares?
Podría valer la pena dar ambos. O también podría cambiar a preguntas de opción múltiple un poco más difíciles. Sería genial hacer una de las posibles respuestas: ninguna de estas.
@Graviton Al menos en el Reino Unido, era posible que a los estudiantes se les diera tiempo adicional en los exámenes o incluso permiso para usar una computadora para responder las preguntas del examen, según las discapacidades que les hayan diagnosticado. Tenía un amigo que quedó tetrapléjico durante la escuela secundaria y dictaba todos los exámenes a un escriba con el 100% de tiempo extra.
Esto es lo que nos pasó. Invitamos a un candidato increíble después de que hizo más o menos problemas de codificación en la pizarra. Le dimos un IDE en línea con un entorno básico de compilación/ejecución y le hicimos una pregunta sobre el algoritmo nuevamente (la sintaxis seguía sin importar). Honestamente, la segunda entrevista acaba de confirmar la primera. El candidato estuvo demasiado tiempo en un liderazgo y estaba demasiado oxidado en la programación, incluso darle un IDE no ayudó.
@RichardU Si bien estoy parcialmente de acuerdo en que es bueno realizar pruebas cercanas a los requisitos reales, consideraría la discusión del pseudocódigo como una parte esencial de la mayoría de los trabajos de programación basados ​​en equipos. Ahora bien, si se le pide que escriba código en un papel, el entrevistado podría tener la mentalidad de "escribir un programa" en lugar de discutir la solución algorítmica general del problema. De acuerdo con la respuesta, al menos le daría otras opciones para explicar cómo lo resolvería: pizarra blanca, yo escribiéndole explicando, hablando, etc. pero la capacidad general de abstraerse del código lo consideraría un activo real.
@Darkwing Sí, no me va bien en esa configuración, sin embargo, ahorré a mi empresa 1,5 millones la semana pasada. Aunque no pruebo bien. nunca lo hizo.
@RichardU Felicidades. No digo que no puedas ser excelente si no puedes pasar esos, pero en muchos lugares la comunicación en equipo sobre lo que haces y por qué es importante y esa es una herramienta para evaluar esa habilidad (como dije, estoy de acuerdo en que la programación en papel está teniendo bastante éxito). muchos inconvenientes y solo tendría eso como opción entre otras opciones). Tampoco diría que debería ser la única habilidad que busca en una entrevista y, a veces, por ejemplo, si está buscando contratar a un solo desarrollador que cumple con sus deseos y no le importa cómo, no debería ser sobre la mesa en absoluto.
@Darkwing Sé que mi caso es único. Tengo algo llamado "disgrafía". Hay una ruptura en las vías neuronales de mi cerebro entre la parte que piensa y la parte que escribe. Puedo escribir a máquina, puedo hablar de una manera muy articulada, simplemente no puedo realizar el acto físico de escribir.
@RichardU Vi tu comentario original. Probablemente le irá bien explicar un algoritmo verbalmente y si siente que puede revelarlo en la entrevista, sin duda escribiré algo en una pizarra si es necesario o le dejaré usar una computadora/tableta para tomar notas Mi único punto fue que la codificación por sí sola no es la única habilidad requerida de un desarrollador de software en muchos trabajos, en particular, ser capaz de explicar cómo en un nivel abstracto también es una habilidad valiosa y me parece justo probar eso. (pero con juego de herramientas abierto).
Déle al candidato de 30 a 45 minutos, aléjese y controle su tráfico en la red. Vea si está visitando la especificación API/Stack Exchange o si comienza a enviar mensajes instantáneos a sus amigos a través de las redes sociales. Hágale saber que está siendo monitoreado.

Este enlace de los comentarios https://blog.codinghorror.com/why-cant-programmers-program/ publica un problema interesante, uno que es francamente frustrante escribir en papel.

¿Por qué?

Aquí están los requisitos en el texto:

Escriba un programa que imprima los números del 1 al 100. Pero para los múltiplos de tres imprima "Fizz" en lugar del número y para los múltiplos de cinco imprima "Buzz". Para números que son múltiplos de tres y cinco, escriba "FizzBuzz".

Aquí están los requisitos como pasos

  1. Bucle del 1 al 100 e imprima el número
  2. Compruebe si hay múltiplos de 3 e imprima "Fizz" en lugar del número
  3. Compruebe si hay múltiplos de 5 e imprima "Buzz" en lugar del número
  4. busque múltiplos de 3 y también múltiplos de 5, imprima "FizzBuzz"

Aquí es donde se desmorona. Los programadores no piensan cómo hacer los 4 pasos a la vez, hacen un paso a la vez. En una computadora esto es fácil, escriba el primer paso, luego edite el segundo, luego edite el tercero, verifique si el cuarto funcionó.

Pero en papel, tendrías que escribirlo más de 3 veces, ya sea en papel o en tu cabeza. Esto toma una gran cantidad de tiempo porque no es así como los programadores han sido entrenados para pensar. Y cualquier pequeño error es otra reescritura.

La programación es un arte de hacer cientos de pequeños errores rápidamente y arreglarlos. Duplicar esto por escrito lleva un tiempo ridículamente largo. Un desarrollador senior que tarda 15 minutos es completamente razonable.

Esto también es mucho estrés para acumular durante el estrés de la entrevista regular, una actividad que generalmente ya es difícil para los programadores. Entonces se congelan.

Este es un punto muy bueno ya que dividir los requisitos en pasos es una buena idea. De hecho, alguien podría escribir un código y una prueba para cada requisito, lo que dificultaría aún más hacerlo en papel.
Pero aquí es donde permitir el pseudocódigo elimina la necesidad de reescrituras. Puede escribir en papel: LOOP 100 TIMESluego sangrar: CHECK MODULO 3y sangrar IF TRUE PRINT "Fizz", etc. La sintaxis en Python, por ejemplo, permite esto sin reescribir incluso en papel :)
No escribiste bien los requisitos ;)
@Juha Untinen, ¿el pseudocódigo demuestra algo útil? ¿La pregunta prueba algo más allá de que la persona entrevistada no puede cambiar de tema y ver todo el problema en su mente? Debido a que ese es un requisito muy específico, por lo general, para los clientes potenciales, esa habilidad es útil. Ahora bien, si estuviera contratando a un desarrollador web front-end, podría pedirles que escribieran una página web básica con un botón, un título y una etiqueta en negrita solo para ver si saben algo. Pero eso no requiere ninguna lógica.
@Chan-HoSuh Lo arreglé, pero eso dice mucho sobre la calidad de las instrucciones, ¿no? Lo pasé a algunas personas y obtuve varias interpretaciones.
Estoy algo de acuerdo con el principio descrito aquí (la pluma y el papel no se parecen en nada a un IDE ni al trabajo que se está probando) y estaría de acuerdo con él para un problema de complejidad significativa. Pero el ejemplo de FizzBuzz es muy, muy, muy fácil y la afirmación de que "un desarrollador senior que tarda 15 minutos es completamente razonable" es una locura.
@BittermanAndy Pruébelo usted mismo, tome su tercer idioma favorito y escríbalo. Mide el tiempo, asegúrate de que la sintaxis y la sangría sean exactas. Si comete un error, comience de nuevo pero no reinicie el temporizador. Cuando lo probé, me tomó 12 minutos construirlo mal después de volver a leer las instrucciones :(
@TrevorD Le pregunté al OP y él afirma que el candidato ni siquiera podía escribir un pseudocódigo. En otras palabras, no era un problema de sintaxis. Sospecho que el candidato normalmente podría hacerlo bien, pero simplemente se "congeló el cerebro" cuando lo pusieron en el lugar (a menos que de alguna manera sea un completo fraude).
@DaveG Estoy de acuerdo, suena sospechoso. El entrevistador debe poder detectar un bloqueo total y notar la diferencia. Escribir pseudocódigo no es difícil (en realidad no hay reglas, por lo que todos escribimos en algo parecido al primer idioma que aprendimos), por lo que hay pocas razones para ni siquiera garabatear en el papel.
Ser un pedante aquí. "Aquí están los requisitos como pasos" se expresa más correctamente como "Aquí hay una solución particular que implementa los requisitos". Hay múltiples arquitecturas que podrían implementar los requisitos y nada en los requisitos restringe qué arquitectura debe usarse.
@PeterM Lamento que hayas excedido mi inglés en eso, pero si quieres sugerir una edición, la revisaré y la aprobaré.
No es un requisito de edición... es más una broma/sarcasmo. Desde mi punto de vista, su lista de pasos no son requisitos, sino detalles de implementación, y puede haber muchas formas de implementar los mismos requisitos. Estaba tratando de ser inteligente al señalar eso, pero obviamente era demasiado inteligente para mi propio bien.
De improviso en mi primer intento: para N = 1 a 100 (si N uniformemente div 15, luego imprima FB más si N uniformemente div 3 imprima F más si N uniformemente div 5 imprima B más imprima N). Y era más bonito en mi papel que lo que estoy poniendo aquí.
@DarkMatter En mi cabeza, ya lo diseñé en exceso al preocuparme por el espacio entre líneas de la salida. La pregunta parece implicar que no quiere que las palabras se unan en una línea larga porque FizzBuzz ocurre los días 9 y 10, que no son los requisitos para FizzBuzz. ¿Necesita retroceder y asegurarse de que FizzBuzz nunca ocurra accidentalmente cuando no es un múltiplo de 3 y 5? Y me he encerrado en una entrevista tratando de pensar en esto
Como es un pseudocódigo, asumí que "imprimir" significa "línea de impresión" en la implementación.
@DarkMatter Si no está especificado en los requisitos, puede hacer lo que quiera. Tengo un cliente que está a punto de pegarse un tiro en el pie por esto.
@TrevorD Para algunas personas, escribir pseudocódigo es muy difícil, ¡especialmente porque es pseudo! Tienen la mentalidad de escribir un programa correcto sin la ayuda de su IDE, lo cual es frustrante ya que se dan cuenta de que realmente no conocen la sintaxis correcta. Puede ser de gran ayuda sacarlos de esa mentalidad, es decir, pedirles que expliquen el algoritmo que usarían para algo solo para que no intenten intuitivamente escribir un programa sintácticamente correcto. Es más fácil si ya está en una representación de problema abstracto, como un gráfico, donde pueden discutir algoritmos de gráficos en un ejemplo.
@Darkwing Ese es un punto interesante, me pregunto si sería beneficioso en una entrevista que la lógica del código se describa verbalmente en lugar de escribirla.
@TrevorD Siento que muchos de los que se encuentran con este problema tienen más probabilidades de entrar en el "nivel abstracto" de pensamiento, cuando les proporciona una pizarra blanca/negra, incluso mejor si ya tiene un pequeño ejemplo en el que pueden visualizar su algoritmo. . Todavía les dejaría la libertad de usar un papel o garabatear un algoritmo concreto en pseudocódigo en la pizarra o en el papel, pero les da un punto de partida. Sin embargo, si está buscando código, creo que proporcionar un IDE o permitir usar su propia computadora portátil es la mejor alternativa sobre el papel. En general, dejaría la elección de la herramienta lo más abierta posible.
@TrevorD Creo que nadie se ajusta a la mejor solución, por lo que tiendo a dejar la elección de las herramientas lo más abierta posible y tal vez sugiero una u otra herramienta para diferentes tareas para ver si pueden manejar todas o tienen fortalezas/fuertes particulares preferencias con uno.
Podría valer la pena mencionar que la única razón por la que las personas pueden escribir un FizzBuzz en unos minutos es porque han internalizado completamente cómo funciona exactamente, razón por la cual también es un mal ejemplo. FizzBuzz tiene más en común con un apretón de manos secreto que con un desafío de codificación. O te lo sabes de memoria, o parecerás un incompetente porque no puedes hacerlo sin pensar como los dos últimos.

Escribí mis primeros programas en 1967 y conseguí un trabajo de programación en 1970. Durante los primeros años de mi carrera, escribí mis programas en hojas de codificación.

Hay tres diferencias significativas entre entonces y ahora, cualquiera de las cuales podría ser un problema para un programador con solo experiencia en IDE:

  1. Recordando las estructuras externas. En un IDE, puede configurar, por ejemplo, un if-then-else antes de completar el contenido. En el papel, debe recordar dónde estaba con cada estructura incompleta.
  2. Buscando cosas: los IDE ofrecen opciones y finalización de palabras que no están disponibles en papel. A la hora de programar en papel necesitaba manuales de referencia al alcance de cualquier cosa que no tuviera del todo memorizada. Si debe hacer pruebas de programación en papel, proporcione las referencias apropiadas ya sea en una computadora o en árboles muertos.
  3. Escritura. Podía producir letras mayúsculas legibles muy rápido cuando hacía eso todo el día todos los días. Cuando me enfrenté hace relativamente poco tiempo a algunos exámenes académicos que había que hacer con lápiz y papel, me preparé practicando la escritura, incluida la escritura de notación matemática. Hacía muchos años que no había escrito mucho a mano.

A menos que realmente necesite la capacidad de programar sin un IDE, debe configurar un entorno de programación para sus pruebas.

si es tan bueno como implica su recomendación de referencia, ¿por qué no puede manejar la prueba en papel?

Porque no hay necesidad de recordar todo lo que puedes buscar en Google en poco tiempo. Encuentro preguntas sobre la complejidad del algoritmo, la búsqueda de elementos de matriz o la clasificación, etc. intimidantes y poco profesionales. Estas son cosas sobre las que puede leer muy rápidamente si las necesita.

¿Es posible que haya algunas personas que puedan codificar bien frente a la pantalla de una computadora, pero cuando se trata de escribir soluciones de programación en un papel, tengan dificultades?

Sí, es posible porque es mucho más importante tener una idea general de lo que está haciendo y ser capaz de pensar de forma abstracta, tener una visión a largo plazo o ver el panorama general y ser capaz de encontrar la información necesaria cuando la necesite que saber por corazón cada algoritmo. El conocimiento enciclopédico puro es inútil cuando la gente no sabe cómo aplicarlo correctamente.

Demasiadas entrevistas se enfocan en cosas tales como si sabe qué tan rápido es una clasificación determinada (que puede encontrar en unos pocos segundos) en lugar de evaluar cómo piensa la gente.

Entonces, si pedirle que resuelva un problema conceptual fundamental en ciencias de la computación libre de cualquier lenguaje o marco en particular no es una oportunidad para 'evaluar cómo piensa'. ¿qué es? :)
@Affe mhmm... No creo que estemos en la misma página todavía porque no es exactamente sobre lo que estoy escribiendo. Quiero decir que no se evalúa cómo piensas, sino tu conocimiento enciclopédico, que en la mayoría de los casos no prueba nada de todos modos.
Pido disculpas porque mi desencadenante sobre las personas que responden a todas las preguntas con "Simplemente buscaría eso en Google" se haya dirigido a usted;). Mis becarios son excelentes googleadores, a menos que quieran un salario de becario, denme algo. Entiendo lo que dices sobre las habilidades para resolver problemas frente a las trivialidades. No me importa si la respuesta es "correcta" o "incorrecta" para una pregunta específica, pero las entrevistas se han vuelto frustrantes en los últimos años cuando no puedo encontrar ningún tema sobre el que la gente realmente converse. ¡No son trivialidades sobre el marco que usaron más recientemente!
Hay un artículo sobre el desarrollo impulsado por desbordamiento de pila: dzone.com/articles/…
Tengo exactamente UNA gran pregunta O en mi conjunto de preguntas de entrevista habitual, pero le sigue una pregunta sobre cómo esperaría el candidato que funcione ese algoritmo en un procesador de PC realmente moderno. Lo que estoy buscando es cierta conciencia de la predicción de sucursales, el horrible costo de las fallas de caché y cosas similares. ¿Entiende el candidato que la gran O no es lo único que importa? Da miedo cuántos candidatos no pueden responder a la primera parte o se equivocan en la diferencia entre la teoría CS y las máquinas reales.

si es tan bueno como implica su recomendación de referencia

Eso se debe a que sus expectativas son demasiado altas tanto para el candidato como para el supervisor. La carta de recomendación, si es imparcial, simplemente significa que el nivel del candidato es satisfactorio en relación con la persona que escribió la carta. Eso no significa que el candidato sea hábil en relación con sus estándares .

Por ejemplo, un niño de 14 años que puede compilar un programa de hola mundo puede impresionar a su abuela, pero no a usted.

Probablemente tenga mejores conocimientos técnicos que el supervisor, o al menos alguien que tenga mayores expectativas de excelencia.

¿Es posible que haya algunas personas que puedan codificar bien frente a la pantalla de una computadora, pero cuando se trata de escribir soluciones de programación en un papel, tengan dificultades?

Todo tipo de cosas son posibles, desde bloqueo mental hasta trampas. Pero ninguno de ellos se puede conocer con certeza y ninguno se aplica a lo que debe hacer, que es medir la competencia y la idoneidad. En igualdad de condiciones, el CV de este candidato debe estar al final de la pila.

Las recomendaciones son solo papel, mejor que nada, pero no se debe confiar en ellas por completo. He visto recomendaciones entusiastas dadas a personas que el recomendado apenas conoce o no conoce en absoluto.

Las pruebas en papel no son malas y son bastante estándar en toda la industria en el área de donde vengo. Mi sugerencia sería pedirle al candidato que escriba algoritmos en lugar de código real. Puedo comprar que el candidato no conoce la sintaxis exacta. Pero deberían poder proporcionar algoritmos/pseudocódigo.

Podría haber dos problemas potenciales

  1. El candidato en realidad puede estar haciendo trampa.

  2. El candidato tardará más tiempo en completar la tarea de lo habitual, lo que significa que pasa su tiempo leyendo la publicación que se le da el problema.

Todo se reduce a la forma en que te han arreglado. En nuestros días, gran parte del enfoque estaba en los algoritmos y nos enseñaron a escribir algoritmos en papel. Antes de que IDE apareciera, teníamos que escribir código en el bloc de notas, lo que hizo que nuestro dominio de la sintaxis fuera mucho más fuerte que alguien que haya aprendido en IDE. Obtener la sintaxis correcta no es muy importante, pero si el candidato está luchando hasta el punto de que no puede responder una sola pregunta, en mi opinión, entonces el candidato debe trabajar en los conceptos básicos de la programación. Lo más probable es que tengan dificultades y se tomen mucho más tiempo para completar su tarea de lo que normalmente se esperaría.

En el momento en que apareció el bloc de notas, hubo IDE. A menos que esté hablando del editor VI en UNIX. Además, algunos de nosotros somos anteriores a las GUI, pero aún es más fácil poner las cosas en un teclado que en un papel. Las pruebas en papel están obsoletas
Turbo Pascal se lanzó en 1983 y era un IDE. Sin cambiar los programas, puede escribir un programa, editarlo, compilarlo y ejecutarlo. Era mucho más fácil de usar que otros sistemas de desarrollo para computadoras domésticas. En algún momento, había un sistema que no te permitía escribir un programa Pascal sintácticamente incorrecto, pero que hacía que su uso fuera realmente doloroso.
En mis dos títulos (asociado y licenciatura) para desarrollo de software, no teníamos ni un solo curso de algoritmos. Mucho de esto estaba "incrustado" en el tema, pero nunca se dijo explícitamente que ahora estamos estudiando algoritmos. Nunca tuvimos nada como estudiar clasificación rápida, hacer btrees u O-notación y análisis. Se trataba de desarrollar soluciones a varios problemas utilizando cualquier método que consideráramos adecuado. Mayormente usando C.

"¿Es posible que haya algunas personas que puedan codificar bien frente a la pantalla de una computadora, pero cuando se trata de escribir soluciones de programación en un papel, tienen dificultades?"

Absolutamente posible. Diferentes personas trabajan de diferentes maneras. Sus cerebros funcionan de diferentes maneras. Y algunas personas simplemente tienen problemas para escribir las cosas a mano.

Puedo escribir cosas sin tener que pensar en el proceso de escritura, va directamente de mi cerebro a la pantalla. Escribir en papel es más difícil. (Hablar cosas es mucho más difícil, convertir los pensamientos en habla requiere un gran porcentaje de tu poder mental).

Entonces, si quieres observar a las personas, obsérvalas usando las herramientas a las que están acostumbrados, y allí ves qué tan bien pueden hacerlo. Si alguien es malo escribiendo en papel y bueno usando un IDE, contrátelo. Al revés, no.

Cualquier cosa que el solicitante podría haber hecho sin que usted lo vigilara tiene una relevancia más o menos nula cuando se trata de medir su desempeño. Cualquier cosa para la que no tengas control del entorno puede usarse para hacer trampa. En particular, le diste el examen para que se lo llevara a casa y lo aprobó. Entre el momento en que salió de tu oficina y cuando regresó, tuviste cero control de todo lo que hizo. Decir "él puede haber buscado en Google las respuestas" es realmente el menor de tus problemas; podría haberle dado la prueba a su amigo y pedirle que escribiera todas las respuestas para él, por lo que sabe.

Aquí hay algunas opciones de lo que puede hacer si está interesado en este candidato:

  1. Pídale que realice una prueba de programación adecuada, en un entorno de programación real. Configuras la computadora portátil, configuras el entorno, configuras el IDE, él hace el código. Obtiene acceso completo a autocompletar si lo desea, un compilador si lo necesita, etc. Luego puede ver si realmente puede codificar (en lugar de escribir en papel). En la vida real, todos usan las eficiencias que brindan los IDE modernos, por lo que no hay razón para no hacerlo en una entrevista.

  2. Invite al candidato a volver y enséñele que puede usar pseudocódigo; si escriben "List.append" en lugar de "List.add", o incluso "add X to list", está bien. Nuevamente, en realidad, en una situación laboral, tendrán acceso a cosas para hacer esto por ellos. Tal vez el candidato esté obsesionado con "¿obtuve la sintaxis correcta?" y no puedo darte lo que realmente quieres. Si dice que la sintaxis no importa, entonces puede obtener lo que desea.

  3. Haz preguntas de sondeo. "Escribir FizzBuzz" en realidad no te dice mucho; solo te dice si ha memorizado la solución de FizzBuzz. "Explícame cómo escribirías un programa para hacer X" te dice mucho más. Específicamente, te dice si esta persona tiene la aptitud mental para diseñar una solución a un problema que puede o no haber visto antes. Si ni siquiera pueden decirle, en palabras sencillas (y "decirle" es una palabra operativa, esto debería ser un ejercicio verbal, para evitar problemas como la disgrafía o la dislexia), cuál es el primer paso para resolver el problema, esa es la bandera roja que estás buscando para enviarlos a casa.

Podría tener DISGRAFÍA como yo. O autismo, o cualquier otra cosa que pueda causar problemas para escribir las cosas.

Aparte de eso, a menos que tenga la intención de que la gente programe una carpeta de tres anillos, deshágase de las pruebas en papel. Tome una computadora portátil de repuesto y haga que el programa/examen del solicitante esté en eso.

Además, no estamos en los días en los que tenías que verter libros y manuales y memorizar todo. Los lenguajes de programación se han vuelto mucho más complejos, matizados y detallados que en los días de COBOL.

Mi sensación es que las cosas se han simplificado, porque lo que COBOL hizo con la sintaxis se maneja mediante llamadas a bibliotecas en lenguajes modernos.

Puede ser que el tipo sea muy bueno con sus herramientas y muy malo sin ellas. O podría ser que el tipo sea simplemente un tramposo, robando en el trabajo de otros y simplemente ensamblando lo que pueda encontrar sin entender mucho.

Al final, cualquiera que sea la respuesta, todo se reduce a sus necesidades específicas. ¿Necesitas a alguien que se sienta cómodo con algún tipo de herramienta? ¿Alguien capaz de codificar un algoritmo en COBOL incluso como si nunca conociera el lenguaje y odiara la codificación de procedimientos? Entonces, por muy bueno que sea este tipo, no encaja bien.

¿Necesita a alguien que esté ensamblando código, porque la mayor parte del trabajo duro en su tienda lo realizan las API, y la parte difícil es encontrar las API inteligentes y usarlas de manera eficiente? Entonces este tipo, por malo que sea, en realidad encaja bien.

Decide tus necesidades. Decida por qué la prueba en papel es relevante o no. Decida por qué la prueba casera (con la posibilidad de solicitar soluciones en Internet) es relevante o no. Ahí está la respuesta. Para muchas posiciones, alguien que hace las preguntas correctas en Internet y tiene la habilidad suficiente para reunir las respuestas de manera significativa es suficiente. Para algunas otras posiciones, el mismo tipo es solo una responsabilidad.

Reconsidere lo que realmente necesita y tome su decisión en consecuencia.

Pidió retirar las preguntas para obtener respuestas, a lo que acepté. Al día siguiente me envió las soluciones totalmente corregidas. Hizo las tareas en un IDE y logró obtener todas las respuestas correctas.

Probablemente sucedieron dos cosas:

  1. Buscó en Google la respuesta. Probablemente lo tomó directamente de stackoverflow. Olvidé quién escribió el artículo, pero recuerdo que una persona mencionó que cuanto más elaborado/inteligente es su FizzBuzz, es más probable que sepa que buscó la respuesta en Google en lugar de pensar en ella desde la parte superior de su cabeza. La suposición es que las personas que entienden de programación no necesitarían buscar algo tan simple como FizzBuzz y obtendrían la respuesta más simple.
  2. Piensa mejor en el IDE que con lápiz y papel. También podía confiar en las funciones de autocompletado o búsqueda de IDE como las de phpStorm o msdn integradas en Visual Studio.

Estoy de acuerdo con la respuesta de Ertai87 en que la mejor manera es darles una prueba del mundo real. Después de todo, el propósito de la prueba FizzBuzz es determinar si al menos pueden programar, pero eso es algo diferente de obtener trabajo real, ingresar el código e implementar la solución adecuada.

Personalmente, programo bastante bien (creo); pero nunca he sido bueno con los términos o conceptos o explicándole cosas a la gente cuando me hacen preguntas sobre programación. Puede tener algo que ver con cómo aprendí o cómo pienso, no lo sé. Pero eso no significa que no sea un buen programador.

Por otro lado, he visto una cantidad de programadores que pueden explicar todos los conceptos, conocen todos los términos y parecen realmente legítimos hasta que se ponen a codificar y resulta que son bastante malos en eso.

¿Qué tipo de programador querrías, alguien que pueda programar bien o alguien que pueda hablar bien sobre programación?

Además, no puedo recordar una mierda sin intellisense. ¿La gente realmente piensa que los programadores pueden recordar cada método de cada tipo de cada lenguaje con el que se supone que deben trabajar?

Además, las pruebas son estúpidas. FizzBuzz es estúpido. Dame una tarea que pueda hacer en un IDE, como cómo trabajaría si estuviera trabajando... y realmente no importa cómo lo haga si te lo devuelvo y es lo que quieres. Puedo usar google, stack overflow, c# corner... ¿qué importa eso? Un no programador no puede programar mirando el desbordamiento de pila. Un no programador ni siquiera sabría las preguntas correctas para obtener las respuestas que está buscando.

Realmente deberías seguir tu instinto, que estoy seguro te está diciendo que lo contrates.

¿Puedo preguntarle qué tipo de trabajos de programación ha tenido? Mi experiencia es que si está trabajando en un equipo en un proyecto complejo, debe poder codificar y explicar lo que su código está haciendo a sus compañeros de equipo.
@CharlesE.Grant No dije que no podía explicar qué está haciendo mi código. Lo que quiero decir es que no puedo explicar el concepto de programación orientada a objetos de ninguna manera que parezca correcta. O qué es el polimorfismo. Y si tiene que explicar lo que su código está haciendo a otra persona, no lo codificó correctamente y/o los otros programadores no pueden leer. Un buen programador debería ser capaz de ver un buen código y descubrir qué está haciendo.
Aunque como programador estoy de acuerdo con tu respuesta. La respuesta es muy negativa y suena como si descargaras tus frustraciones en la respuesta.
Necesita personas que puedan codificar bien y que puedan hablar sobre la codificación, a menos que esté contratando a una persona y no vaya a contratar a otra. Alguien que no puede expresar conceptos básicos es mucho menos útil que alguien que puede. Además, las pruebas como FizzBuzz son útiles como una forma rápida de eliminar lo completamente inadecuado.
Estoy de acuerdo en que no se puede esperar que los programadores recuerden cada método en cada clase en cada biblioteca que usan. Pero no necesita ninguna biblioteca para escribir FizzBuzz. Debe escribir un bucle for y usar el operador mod. FizzBuzz puede ser estúpido, pero si no puedes escribir un bucle for en tu cabeza, entonces no eres programador.
@Dan Como dije, una forma rápida de eliminar lo completamente inadecuado. Dependiendo de la calidad de los solicitantes, esto puede ser útil.

Existe la posibilidad de que haya hecho trampa en la universidad y su pasantía lo haya llevado a trabajar para un amigo de la familia en un puesto alto. Conozco a una amiga que consigue una buena pasantía, por el tiempo que quiera a la semana debido a las conexiones de su madre. También sé de alguien que hizo trampa para ingresar a la universidad y luego tuvo uno de los años en la universidad hecho por otra persona.

Sería muy cauteloso aquí, proporcionaría otra prueba con un límite de tiempo por correo electrónico y le haría saber que la obtendrá en un momento determinado y que tiene esta cantidad de tiempo para terminarla. Si él/ella realmente es todo eso, también podrían hacer algo mucho más difícil que la programación de nivel de entrada.

Dele algunas pruebas más, pero use una pizarra esta vez para que no sea tan diferente de un IDE. Si todavía no puede hacerlo, déjalo pasar.

Las pruebas en papel solo verifican el sobreaprendizaje: poder recordar rápidamente hechos que ha memorizado para que generalmente estén en su memoria de trabajo. Si eres bueno en el desarrollo, no hay razón para saber más que motivos porque cualquier conocimiento adicional que necesites puede buscarse en Docs. Deberías gastar tu poder mental aprendiendo nuevas tecnologías, no sintaxis y cosas básicas que simplemente no usas. Muchos de los desarrolladores con los que hablo no han tocado cosas como algoritmos de clasificación desde la universidad. Las pruebas en papel deben permanecer en la universidad donde pertenecen.

El zumbido de Fizz en una pizarra es mucho más fácil de resolver porque puedes borrar y hacer ajustes sobre la marcha. No siempre se puede hacer eso con papel. Las especificaciones de diseño también cambian mucho. Tal vez quiera poder ver a su desarrollador hacer otra cosa, o tal vez su desarrollador literalmente hizo lo más fácil que pudo haber hecho. Sobre el papel, tendría que hacer un juicio sobre los puntos de acoplamiento. En una pizarra, puede simplemente cambiar los requisitos en ellos y ver cómo responden sin preocuparse realmente por nada.

existe la posibilidad de que sea un programador inteligente de Google :)

https://www.hanselman.com/blog/AmIReallyADeveloperOrJustAGoodGoogler.aspx

Programadores que son altamente recomendados, pero que no pueden manejar la pregunta de programación de prueba en papel
RespuestasAquíPolítica de privacidad1y, 0v