“Prueba” de pizarra durante una entrevista: ¿forma legítima de hacer una copia de seguridad de su código (pizarra)? [cerrado]

A medida que lo entiendo, tener un error (incluso un error tipográfico o ";" faltante) en el código de la pizarra a menudo le costará algunos puntos de entrevista. Evitar eso inevitablemente hará que un código de lectura de prueba una y otra vez (perdiendo tiempo y posiblemente energía / concentración neuronal) o incluso usando un algoritmo más simple (y por lo tanto menos efectivo), ¡y ambas formas son "costosas" nuevamente!

Entonces, ¿por qué no simplemente escribir un código rápido tan elegante y efectivo como lo haría con un marco de prueba (unidad) a su disposición y luego simplemente probarlo (solo en la pizarra)?

¿Alguien ha intentado / visto este enfoque? ¿Vale la pena toda la idea?

[esto también se aplica al caso de lápiz y papel, por supuesto]

Quiero absolutamente que pruebes el código de la pizarra que te pido que escribas. Quiero que hable en voz alta mientras lo escribe, lo revise, detecte la mayoría de los errores de sintaxis que cometió y señale cómo podría ser más eficiente. De hecho, ese es el punto de hacerlo en la pizarra. Es no un one-shot, escritura-lo-todo-fuera, eh-eh-que-hay-70 / clase 100 de cosa. Es una conversación, mediada por código y sostenida en la pizarra en lugar de en mi escritorio.

Aquí hay algunas maneras excelentes de fallar la prueba de "codificación de pizarra":

• rechazarlo
• no haga una sola pregunta aclaratoria (lenguaje, plataforma, algo sobre los requisitos) Y no me diga sus suposiciones sobre nada de eso Y haga suposiciones que están muy lejos de lo que hubiera respondido

(por ejemplo: escríbalo en Fortran, interprete "mostrar" o "imprimir" como "escribir en el registro de eventos", ese tipo de cosas. Podría permitirlo si me dijera de antemano que esas son sus suposiciones)

• pregúnteme en qué idioma lo quiero, reciba una respuesta que figura en la descripción del trabajo y luego escríbala en un idioma diferente porque no se siente cómodo en el idioma que solicité.

(Somos consultores aquí. Estoy probando el comportamiento del consultor tanto como la codificación. Preguntarle al cliente solo es correcto si el cliente realmente tiene una opción. Controlar las conversaciones con personas que le pagarán es difícil. Esta es la lección 1. Es un marque en su contra en cualquier tema, pero para el específico "está contratando un programador X pero no quiero escribir X para usted", ahora tiene dos grandes marcas negras).

• muéstrame qué astronauta de arquitectura eres llenando dos pizarras blancas con interfaces, patrones de fábrica, abstracciones, inyecciones y pruebas cuando quería que "imprimas los números del uno al 5".

(crees que estoy exagerando, pero tenía un tipo que generalizó mi problema dramáticamente; siguiendo el ejemplo anterior, digamos que en lugar de 1 a 5, su solución haría cualquier secuencia arbitraria de enteros (¿de dónde? Me preguntaba) y tenía 5 veces más larga que la de cualquier otra persona, y se olvidó de llamar a la función que hizo el trabajo. La repetición de indicaciones y sugerencias de que lo atravesara como si fuera el depurador no lo llevó a darse cuenta de que la función nunca se llamó).

Siempre digo "¿te gusta eso?" "¿Puedes mejorar eso?" "guíame por eso" y cosas por el estilo. Por lo general, el punto y coma que falta se ve, o el off-by-one, en esa conversación. Si no, generalmente lo marco a los nervios.

Otras cosas que quizás no pienses que importan en la pizarra que me importan:

• cuando termines, ¿puedo leerlo? ¿Te has manchado, garabateado, cambiado de color, dibujado flechas, tachado y en general has dejado un desastre que ahora no se puede usar? ¿O es consciente de que las pizarras blancas se pueden borrar, señalan líneas de código en el aire en lugar de rodearlas con un círculo / flecha y me dejan algo de lo que podría tomar una fotografía y guardarlo en el archivo de diseño?
• ¿Cuánto me preguntaste como lo hiciste? ¿Le gusta quedarse solo y no discutir su código, o lo ve como algo colaborativo? ¿Cómo respondiste cuando te pregunté cosas mientras aún lo escribías?
• ¿te burlaste de la tarea "fácil" o te desmayaste con la "difícil"? ¿Fuiste grosero al pedirte que mostraras que puedes codificar? ¿Te intimida fácilmente un problema técnico o eres arrogante con tu habilidad para crear un buen algoritmo?
• ¿Lo estás resolviendo en tu cabeza o recuerdas una solución que leíste en alguna parte? Por lo general, puedo ver los problemas difíciles.
• ¿Planeaste con anticipación sobre dónde comenzaste a escribir? Las personas que se quedan sin pizarra generalmente comienzan demasiado bajas o escriben demasiado grande; puedo decir que no sabían que serían 20 líneas de código y, por lo tanto, solo dejaban espacio para 5; créanlo o no, este pequeño detalle se refleja en tareas de estimación más grandes también.
• ¿Lo revisaste antes de decir que habías terminado? ¿Te vi señalando o tocando a través de él y probándolo antes de que te lo pidiera? Cuando te pregunté o te hice preguntas específicas al respecto, ¿volviste a mirarlo o simplemente te olvidaste? ¿Estás dispuesto a considerar que tu primer borrador podría no estar completo?

Recomiendo practicar la codificación en la pizarra. Siempre advierto a los entrevistados que se les pedirá que lo hagan. Si tiene acceso a una pizarra real, entonces establezca algunos problemas simples y practique haciéndolos allí. Ayudará a su rendimiento y su confianza.

Lo siento, sé que estoy en territorio TL; DR, pero esta es la cuestión: codificar en la pizarra es más que codificar . Es una prueba de algo más que su comprensión de la sintaxis. Hay muchos comportamientos de buenos programadores que se demuestran en su respuesta a esta tarea. Si crees que solo se trata de codificar, estás perdiendo el punto.

En otras conversaciones sobre las pruebas de pizarra, la gente me dice que puedo rechazar a un buen candidato con ella. Honestamente, ese es un riesgo que estoy dispuesto a tomar. Cada ronda de contratación contiene varias personas que podría contratar. Algunas personas con excelentes currículums, que están bien en la parte de preguntas y respuestas de la entrevista, se desmoronan en la pizarra y claramente no pueden (con ninguna cantidad de indicaciones) escribir un código simple en el idioma que dicen saber. Podría haber contratado algunos de estos. Cualquier herramienta que lo impida es una herramienta que seguiré usando. Nunca terminé en un bote de nadie para contratar porque todos mis candidatos se equivocaron en la pizarra y no espero que lo haga.

Creo que has hecho una suposición incorrecta aquí. No hay forma de que espere que un candidato que escriba el código en una pizarra pueda obtener cada ';' perfectamente en su lugar. Si está entrevistando en un lugar que lo penaliza por eso, le sugiero que no sea una organización para la que quiera trabajar :-).

Las pruebas en papel o pizarra son extremadamente ineficaces. Recuerdo que una vez tuve una entrevista en la que tuve que buscar errores en algún código en papel. Una de ellas fue que la clase heredó de una interfaz pero le faltaba la implementación de un miembro. Sabía que este podría ser uno de los errores, lo estaba buscando y, por cualquier motivo en el acto, simplemente no podía verlo (aunque mencioné que lo estaba buscando como uno de los problemas).

De hecho, todavía obtuve ese trabajo, pero me hizo pensar en lo que había sucedido. En un escenario realista para ese tipo de cosas, obtendré líneas onduladas en el momento en que algo esté mal (esto es C # en Visual Studio) y la cosa no se compilará. Nunca verifico esto en la vida real porque nunca sucede (es imposible) y, por lo tanto, estoy desconectado de ver este tipo de cosas. Los puntos y comas faltantes son un ejemplo aún más extremo de esto: ¡totalmente irreal en el mundo real a menos que esté escribiendo en el bloc de notas y enviando su código por correo electrónico a otra persona para que lo compile!

Si alguien pide usar una pizarra blanca durante una entrevista para apoyar algo que quiere decir, entonces genial, pero nunca lo haría al revés.

Ya hice eso. En una entrevista, me pidieron que implementara la codificación de longitud de ejecución en la pizarra, y aunque acorté parte del código (que explicaba lo que estaba abreviando) para que se ajustara a la pizarra, aún encontré una colección de pruebas para esta unidad, y revisé uno de ellos para validar mi solución y mostrar cómo ayudarían las pruebas. Me ofrecieron ese puesto, así que supongo que las pruebas fueron útiles o, en el peor de los casos, no molestas.

Utilizo este enfoque cuando tomo exámenes para la escuela. Primero escribo la función, luego a un lado escribo una pequeña tabla de entradas, salidas y variables. He detectado algunos errores estúpidos de esta manera. Las pruebas, incluso las pruebas en papel / pizarra, siempre son mejores que no probar.

Sin embargo, no estoy de acuerdo con enloquecer con punto y coma en un entorno profesional.

Pedirle a un candidato que codifique en una pizarra es una tontería. Existen herramientas modernas como fragmentos, jsfiddle e intellisense. Además, no se debe requerir a ningún ingeniero que memorice la sintaxis. La sintaxis se busca y se hace referencia. Si está memorizando código, probablemente no pasó ningún tiempo en su carrera aprendiendo a codificar en un entorno de múltiples inquilinos, optimizando la sintaxis o incluso un entorno alojado.

Cuando un restaurante quiere contratar a un chef, el propietario no le pide que cocine una "olla al horno" con un palillo y una gorra.

No le pida a un desarrollador que codifique en una pizarra en una entrevista.

La codificación de pizarra blanca es difícil. Nunca me presentaron eso hasta que fui entrevistado por Disney. Sin saber qué esperar y no ser capaz de depurarlo, me topé con él para hablarlo y resolver el problema, pero de alguna manera pseudocódigo. Cuando preguntaron si podía correr.

Quiero decir, seguro, podría simplemente corregir los errores de sintaxis. Creo que perdieron un muy buen candidato si no me contrataron debido a la pizarra. Miro las calificaciones y parece que estoy muy calificado para el puesto y puedo hacer el trabajo. Me destaco en el trabajo actual en el que estoy y deseé poder con ellos.

Gracias por tu aportación Kate, leí cada palabra. Es solo para mí como programador, la pizarra realmente no muestra tus habilidades. Soy un gran programador que trabaja en varios idiomas. Sabía el idioma en el que me pidieron que programara, pero de repente lo olvidé.

Construyo integración compleja y procesamiento de tarjetas de crédito, pero en la pizarra no podía recordar cómo hacer una sintaxis adecuada, nada me incita.

Como empleador, me gustan las pruebas de pizarra; sin embargo, estoy contratando a un programador que quiero ver sus habilidades reales si hacen el trabajo. Es genial si pueden comunicarse, pero necesito ver que puedan resolver problemas.