¿Es inapropiada la "codificación de pizarra blanca" durante las entrevistas? [cerrado]

Esta es una pregunta un tanto subjetiva, pero me encantaría escuchar comentarios / opiniones de los entrevistadores / entrevistados sobre el tema.

Dividimos nuestra entrevista técnica en 4 partes. Escriba el código, lea y analice el código, diseñe la sesión y el código en la pizarra.

En la última parte, lo que les pedimos a los entrevistados que hagan es escribir un pequeño fragmento de código (4-5 líneas) en la pizarra y explicar a medida que avanzan. Permítanme aclarar que el propósito no es atrapar a la gente. No estamos buscando una sintaxis perfecta. Demonios, incluso puede ser un pseudocódigo. pero el punto es darles un problema muy simple y ver si su cerebro puede comunicarnos la solución. Por problemas simples me refiero a "Invertir una cadena", "FizzBuzz", etc.

Tenga en cuenta que siempre pedimos primero un lenguaje explícito. Somos una casa .NET C #. solo hemos dicho "pseudocódigo" en el que alguien ha estado en blanco / realmente luchando con el código.

Mi pregunta es "¿Es inapropiado / irrazonable esperar que un programador escriba un fragmento de código en una pizarra durante una entrevista?"

En mi opinión, es muy apropiado. Si desea un trabajo para realizar una habilidad en particular, entonces es completamente apropiado esperar que demuestre esa habilidad en la entrevista.

El efecto de esta técnica en el proceso de reclutamiento es muy notable. El 90% de los candidatos no cumplen esta tarea. pero los desarrolladores reclutados son buenos, y los desarrolladores serán respetados dentro de la empresa.

Si como candidato enfrenta esta técnica, en primer lugar relájese. Se trata de evaluarlo como programador y sus procesos de pensamiento. No se trata de su sintaxis perfecta. Si comete un error de sintaxis, entonces podría desempeñar el papel de un compilador y decirle que el código no se compila en una línea determinada, y darle un mensaje de error, y ver cómo responde. Del mismo modo si agrega un; en un bucle o una declaración if que se compilaría, jugaría al depurador y lo guiaría a través de un solo paso a través del código. Nuevamente, no se trata del error, se trata de cómo lidiarías con el error y si tus procesos de pensamiento son buenos.

Mi pregunta es "¿Es inapropiado / irrazonable esperar que un programador escriba un fragmento de código en una pizarra durante una entrevista?"

Es muy razonable. Una alternativa a una pizarra podría ser una computadora portátil y un proyector, ya que los programadores están más acostumbrados a escribir código en un teclado que en una pizarra. Solo asegúrese de que un entorno de desarrollo como Eclipse o VS o Idle ya se esté ejecutando con un proyecto en blanco cuando se inicie el candidato, para que no tenga que perder el tiempo buscando entre las aplicaciones instaladas.

No es inapropiado, pero sepa que NO siempre puede revelar las verdaderas ideas sobre la programación o las habilidades de resolución de problemas de la persona que está entrevistando. Y supongo que eso es exactamente lo que buscas.

En segundo lugar, tenga en cuenta que siempre existe el miedo al fracaso, que constantemente irrita el cerebro de la persona. "¿Qué pasa si me equivoco?", "¿Qué pasa si me equivoco? La mayor parte del cerebro de la persona está ocupada constantemente inspeccionando cómo está saliendo; solo unos pocos pueden contener los nervios.

Entonces, en este tipo de situación, incluso los mejores podrían terminar vacilando.

Para la última parte, les pedimos a los entrevistados que escriban un pequeño fragmento de código (4-5 líneas) en la pizarra y expliquen a medida que avanzan.

Está bien. Pero nuevamente, el hecho de que alguien no pueda explicar algo correctamente no significa que no lo sepan bien. (La explicación es un arte del habla).

Si fuera tú, lo haría en la última parte ...

Contratarlos para un proyecto muy pequeño (pero realista). Vea cómo codifican, toman decisiones, asimilan las condiciones de trabajo y los miembros del equipo, etc., y luego, basándose en eso, toman la decisión final.

No es inapropiado, pero recuerda que algunas personas (y tal vez una mayor parte de la multitud de programadores) pueden estar muy estresadas en una entrevista. Creo que la mayoría de nosotros conocemos al tipo de la oficina que es un codificador brillante y una persona muy confiable, pero se derrumbaría en tal situación. Su rendimiento no se pudo medir en una prueba de este tipo, así que no haga de esta una prueba de ir / no ir.

Personalmente, creo que esta es una de las mejores cosas que puedes hacer. Como dijiste que no buscas la sintaxis correcta o algo similar, la parte más importante aquí es ver si alguien puede comunicarse ... He visto tantos buenos desarrolladores que solo pueden trabajar solos dentro de su propio espacio ... Desafortunadamente esto no es posible en una gran cantidad de casos, por lo que tener un tipo hábil que también sea capaz de decir lo que piensa de una manera clara y concisa es un miembro más valioso del equipo que alguien que piensa: "No lo entenderán de todos modos, lo haré yo mismo y lo demostraré más tarde ".

Comunicación, comunicación, comunicación, que es la base de cada proyecto de tamaño mediano a grande (incluso más pequeño una vez que lo necesita)

Creo que no es una cosa razonable. Tratamos de encontrar candidatos, que son buenos en la tarea que queremos que hagan. Escribir código en una pizarra no es uno de ellos y no creo que sea un filtro válido para encontrar buenos candidatos.

• El buen código no se escribe, se reescribe. Una pizarra blanca es prácticamente inmutable, ya que es difícil cambiarla una vez que la escribió. Debería ser lo más fácil posible cambiar de opinión en cuanto comprenda mejor el problema.
• Estar en una entrevista es una situación estresante, ya que no hay necesidad de ejercer presión adicional sobre el candidato. Muchas personas informáticas no tienen una buena letra. Los IDE modernos proporcionan muchas herramientas a las que estás acostumbrado. Y poder buscar en Google algo en el momento que lo necesites también es parte del estilo de trabajo de la mayoría de los programadores. ¿Por qué quitar todas estas cosas y crear un entorno artificial, en el que nunca tendrán que trabajar si les haces una oferta?
• También estamos muy interesados ​​en la capacidad de escribir buenas pruebas, tal vez incluso hacer TDD. Esto no es posible verlo durante la codificación de la pizarra.

La mayoría de las pistas que podría obtener de una sesión de codificación de pizarra también podrían obtenerse de una sesión de emparejamiento. Y creo que el emparejamiento es una herramienta mucho mejor para tener una idea, cómo un candidato resuelve un problema y cómo trabaja. Puede traer su propia computadora y trabajar en un entorno con el que se sienta cómodo. Y es mucho más fácil aplicar a la tarea que desea que hagan una vez que se unan. Por ejemplo, tenemos una gran base de código heredado, por lo que les pedimos que refactoricen algún código extraído para el proyecto real. Y en realidad nos emparejamos tanto como sea posible en nuestro trabajo diario, por lo que es adecuado.

Si bien una sesión de pizarra probablemente ayuda a filtrar a los malos candidatos, probablemente también filtra a muchos buenos programadores.

Personalmente, dejaría a cualquier entrevistador que me pidiera que hiciera FizzBuzz. No sé cuándo se convirtió en el nuevo estándar de la industria, pero es realmente una pérdida de tiempo. FizzBuzz es un filtro que se puede usar antes de una entrevista, aunque personalmente creo que si tuviera que elegir entre N candidatos que tengan suficiente código abierto o un blog que pueda ver, definitivamente preferiría eso como filtro .

En pocas palabras, creo que en una entrevista para un puesto de programación (excepto tal vez para juniors o pasantías), ya debería haberse establecido / determinado que el entrevistado puede programar.

Pero sí, la pizarra es perfecta, aunque creo que debería tomar un conjunto diferente de problemas. Tíreles un problema del mundo real y pídales que dibujen un montón de garabatos UML-ish para explicar su estrategia general para resolver ese problema. Dales una computadora con internet, para que puedan buscar bibliotecas de terceros que puedan usar como recuadros negros en su paisaje de squibbles.
Dentro de unos minutos, realmente verá cómo abordan los problemas. En realidad, puede hacer que esto sea algo muy interesante, eligiendo problemas para los que no necesariamente tiene una solución en mente e intentando "resolverlos" juntos, para ver qué tan bien se comunican y qué tan bien pueden incorporar aportes (sin embargo, no no los presiones demasiado, algunas personas podrían congelarse si lo haces). Y luego agregue algunos requisitos sobre la marcha. Esto es algo así como el desarrollo de software sin implementación y, lo más importante, sin depuración, por lo que 15 minutos es mucho tiempo.

Déjame responder con otra pregunta:

¿Escribir código en una pizarra blanca ofrece alguna ventaja real para evaluar la capacidad de programación, en comparación con escribir y ejecutar el código en una computadora?

Creo que es absolutamente apropiado pedirle a un candidato que escriba el código en una entrevista. Sin embargo, para mí, poder ejecutar el código es una parte crítica del ciclo de retroalimentación que constituye la programación. En una pizarra blanca, estás atando una mano detrás de mi espalda, y no estás entendiendo cómo trabajo con un problema.

No, pero en mi opinión, un mejor enfoque sería usar la pizarra para su propósito previsto y usar UML / bocetos / notas para algún proyecto ficticio, en lugar del viejo "escríbame una consulta sql para obtener todos los registros" o "escriba un método que invierte una cadena ".

Una de las mejores entrevistas que tuve fue pasar como 20 minutos discutiendo con el desarrollador principal la arquitectura (sin software) para la mansión de un científico loco (completa con escondite secreto, rayo de la muerte y perrera). Llegó a ver mi enfoque para resolver problemas, y el problema era algo divertido, no una típica rutina de programación 101 cosas que los lenguajes modernos han resuelto mil veces. Por cierto, también hice un código como este antes, pero me sentí mucho más "bajo presión" que con la parte de arquitectura.

En estos días, mucha programación se realiza en equipos. Para que los equipos funcionen, las personas deben poder comunicarse. Una gran parte de esto es poder comunicarse frente a una pizarra (lluvia de ideas, tutoría, revisiones de código, soluciones propuestas, etc.)

Me gustaría saber si el candidato explicó cómo solucionar el problema de programación utilizando el código de la pizarra para ayudar. Si la explicación es lo suficientemente buena, los otros buenos programadores en la sala corregirán mentalmente cualquier error tipográfico / error en la pizarra.

Para la mayoría de los tipos de puestos de equipo, no sería razonable NO esperar que un candidato pueda explicar y garabatear su intento de solución.

No, es bueno codificar para una entrevista, pero debe permitir el código en cualquier idioma razonable, ya que generalmente es más fácil capacitar a un codificador competente en otro idioma que obtener un codificador más o menos en el idioma que desee, arriba a un nivel competente.

Diría que es apropiado, pero en la mayoría de los casos no es una forma eficiente de averiguar quién es bueno en programación y quién no. Si desea realizar un trabajo (= contratar a alguien que sea capaz), la entrevista debe centrarse en medir las habilidades de la vida real. Hasta ahora, la mejor entrevista que había trabajado así:

• Saludos, bienvenidos por RRHH.
• Pocas palabras sobre mí, sobre la compañía, etc. ... y ella explicó el resto de la entrevista.
• Ella me dio una computadora portátil con un programa que faltó algunas partes, había fallado las pruebas unitarias por eso. Las partes faltantes se comentaron allí como textos, se trataba de implementar una tarea básica, como crear una conexión entre pocas clases e introducir una lógica de negocios simple.
• Si todo salió bien, las pruebas unitarias se volvieron verdes.
• Decir adiós y aceptar volver en unos días.
• Ese día, el líder se reunió conmigo y me preguntó sobre el programa terminado, qué hice y por qué.
• También este líder me preguntó sobre mis experiencias pasadas y algunas otras preguntas.

Para resumir: si está buscando mano de obra en un código de producción, pruebe sus habilidades en un entorno real. Si tiene curiosidad sobre sus conocimientos teóricos, es mejor preguntarles sobre estas cosas. Si está despojado de IDE, o está nervioso porque tiene que programar en la pizarra frente a alguien, puedo entender, especialmente en TI, las personas a veces son introvertidas y muchos de nosotros no podemos manejar bien estas situaciones, así que en blanco abordar nuestra eficiencia se verá peor de lo que realmente es.

No lo considero irrazonable a menos que el entrevistado tenga una mala letra mala (o debería decir escritura) :-). Además, la única diferencia en su enfoque es el uso de un tablero y un marcador. En algunos casos, los entrevistadores hacen esto, pero en su lugar dan un papel y un bolígrafo. En caso de que haya 3-4 personas realizando la entrevista, diría que su enfoque será mucho mejor y más adecuado.