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.