Muestras de código y entrevistas? [cerrado]

He visto una serie de preguntas desde que he estado aquí donde, en la respuesta, alguien ha afirmado que nunca usaría carteras o muestras de código codificadas fuera del proceso de entrevista para juzgar a un candidato, porque existe la posibilidad de que código escrito por otra persona. Me encuentro sorprendido por esto.

A mi modo de ver, si le pido a alguien que venga y resuelva un problema simple en el acto, hay muy poco que pueda aprender de él. No trabajo para una empresa como Google donde se buscan trabajos y puedo exigir un día de tiempo de alguien. Pero una parte sustancial del código escrito por hobby puede decirme mucho.

Sí, existe la posibilidad de plagio, pero tendrán que estar muy bien entrenados para pasar una hora de discusión sobre ese código. Y si ese fuera el caso, tendrán que ser aprendices muy rápidos para superar su período de prueba de 3 meses (durante el cual puedo deshacerme de ellos sin razón y sin previo aviso). Si se convierten en buenos programadores que rápidamente, lo suficientemente justo, he sido engañado, pero todavía tengo un buen programador.

Al final, el costo para nuestra empresa y el beneficio para el candidato de plagio es muy mínimo.

Esto me llevó a pensar en otras industrias. Artistas, fotógrafos, diseñadores usan carteras y nadie se preocupa demasiado por el plagio allí. Un autor recibirá fondos para un libro basado en capítulos que ha escrito en su propio tiempo. No le pedirías a un arquitecto que viniera y dibujara especificaciones de diseño para una casa en la entrevista.

Entonces, ¿qué nos hace diferentes? ¿Por qué es tan importante poner a alguien frente a una computadora y hacer que codifiquen una combinación de datos o una calculadora factorial, a veces sin acceso a las herramientas que usamos día a día, como Internet? ¿Qué tiene de malo la idea de una cartera de códigos?

Estoy realmente interesado en saberlo, en caso de que potencialmente esté cometiendo un gran error que todavía no me ha quemado.

Mi objeción a una cartera no tiene nada que ver con el riesgo de que la empresa sea engañada por alguien que está copiando el código de Internet o, más probablemente, pasando código escrito por un equipo de desarrolladores como su trabajo. Como señala correctamente, puede aprender al menos lo mismo haciendo que un desarrollador hable sobre un proyecto con el que generalmente están familiarizados durante una hora, al hacer que codifiquen una calculadora factorial desde cero.

Mi objeción a una cartera es que requerir una cartera elimina la consideración de muchos desarrolladores talentosos. Dado que yo, a diferencia de un artista o fotógrafo, no retiene los derechos de autor del código que produzco (pertenece a mi empleador y / o a la empresa que contrató a mi empleador), no puedo mostrar la gran mayoría de los " interesante "código que he escrito. Si estoy codificando en mi propio tiempo, generalmente será un proyecto paralelo en el trabajo que me facilitará la vida o que simplemente me molestará, lo que nuevamente no podré mostrar en una cartera. Tengo toneladas de publicaciones en varios foros, pero la mayoría de ellas son, por diseño, relativamente poco profundas. Hay una población bastante considerable de desarrolladores sólidos que están en una posición similar: su código interesante es propiedad de otra persona. Y si tu'

Una entrevista técnica en la que se pide a todos los candidatos que codifiquen algo desde cero al menos proporciona un campo de juego nivelado. Suponiendo que usted hace un trabajo razonable al hacer la pantalla del teléfono y que puede reducir a los candidatos a una lista razonable, preferiría que, como candidato, se le dé un problema para resolver que sabe que tomará 8 horas de esfuerzo que crear una cartera coherente de aplicaciones de juguetes que no tengan problemas de derechos de autor.

En primer lugar, somos ingenieros, no artistas. Trabajamos en equipo, por lo que en nuestra experiencia laboral real, "nuestro" código a menudo es el resultado del trabajo en equipo, porque así es como generalmente se hace el trabajo real. No hay mucho código profesional para el que pueda reclamar la propiedad exclusiva.

Segundo, la mayoría del código en mi cartera hipotética sería código que no podría mostrar a nadie, porque es confidencial. El código que he creado para mis proyectos personales de mascotas no refleja necesariamente todas mis habilidades y mi comportamiento laboral típico.

He entrevistado a muchas personas durante mi tiempo como profesional de software. Llegué a un punto en el que creo que las pruebas y las tareas de programación de juguetes son una pérdida de ancho de banda valioso. Las pruebas y las tareas de programación de juguetes solo sirven para evaluar lo que sabe el entrevistador. No son una forma precisa de medir lo que un candidato sabe. En este punto de mi carrera, solo acepto este tipo de tonterías si, y solo si, tengo la oportunidad de administrar mi propia prueba al final de la entrevista.

La mejor manera de evaluar las capacidades de un profesional de software es hablar con él con una voz tranquila y tranquilizadora. Pídale al candidato que discuta qué implica su posición actual. Cuando el candidato menciona un área de interés, pídale que explique esa área. El objetivo aquí es lograr que el candidato baje la guardia. Ninguna cantidad de entrenamiento puede preparar a un candidato para el interrogatorio de "toque suave". Tarde o temprano, la soga se apretará alrededor del cuello de un candidato que esté tratando de abrirse camino a través de una entrevista.

Solicito una muestra de código para los solicitantes y se hace referencia durante la entrevista. Sin embargo, generalmente le doy más importancia a la codificación de pizarra que se realiza durante la entrevista.

Cada entrevista de desarrollador que hago implica ir a la pizarra para implementar la solución a un problema simple. Sin embargo, hay reglas:

El solicitante tiene que hablar sobre la implementación mientras lo hacen.

• Puedo evaluar cómo abordan un problema.
• Puedo ver qué tan bien pueden comunicarse.
• Puedo medir qué tan rápido son con un objetivo claro.

Tengo tres problemas cuyas implementaciones son todas similares y les dejo saber que pueden reutilizar o refactorizar el código que han escrito.

• Puedo ver si pueden retroceder para echar un vistazo a la imagen más grande.
• Puedo ver si implementan y refactorizan, o saltan a generalizar.
• Puedo tener una idea más firme de lo bien que ordenan sus pensamientos.

El punto de todo esto, de cualquier entrevista es tratar de tener una buena idea de las capacidades de los solicitantes y cómo pueden coincidir con el trabajo. La parte "práctica" de la entrevista en mi experiencia ha ayudado bastante en ese sentido. También me ayuda a evaluar el código de muestra porque sé mucho más sobre la forma en que funciona el programa.

Una muestra de código es una forma bastante eficiente de eliminar candidatos: puedo juzgar una muestra de código en 5 a 10 minutos, pero incluso una pantalla de teléfono tarda 15 minutos y necesita programación (y no es terriblemente útil para eliminar nada más que el mismo parte inferior de la pila en mi experiencia).

Creo que las principales objeciones a los ejemplos de código son dobles y se superan fácilmente:

• que requerir una muestra de código crea una barrera artificial para algunos desarrolladores talentosos

Obviamente, esto es cierto. Cualquier barrera en el proceso de solicitud o contratación puede eliminar a un candidato deseable. Lo importante aquí es conocer a su audiencia: si tiene 1000 currículums para su única apertura, puede permitirse algunos falsos negativos al servicio de la eficiencia. Si tiene cinco hojas de vida, puede permitirse algunas ineficiencias en el proceso de selección.

Sin embargo, lo que creo que la mayoría de la gente extraña es que entrevistar y contratar es básicamente un juego de "encontrar una razón para no contratar a esta persona". Para cualquier trabajo decente, hay muchos solicitantes calificados: el último en pie es generalmente el que no activó ninguna señal de alerta en el camino. Es fácil ver lo mejor de las personas o no comprometerse, pero eso no te sirve de nada en la contratación porque terminarás con 10 candidatos diferentes con los que te sientas cómodo. Eso no te acerca más a una decisión.

Cada dato que recopile a lo largo de la forma de revisar, evaluar, entrevistar, etc. podría desencadenar una decisión de no contratación. Debe equilibrar la sensibilidad de su disparador sin contratación con sus perspectivas actuales (y posibles futuras). Si se encuentra en una industria aburrida, con muchos códigos heredados, burocracia y salarios bajos (a menudo cosas fuera de su control), entonces su desencadenante debe ser menos sensible que, digamos, Google. De lo contrario, correrá el riesgo de nunca contratar a nadie.

Personalmente, creo que el compromiso más fácil para mí ha sido solicitar pero no exigirUna muestra de código. Si obtengo uno, es solo un punto de datos adicional para evaluar al candidato. Del mismo modo, si tengo un conocido que ha trabajado con el candidato en el pasado, atribuiré algo de peso a las opiniones de ese conocido. No haber trabajado con alguien que conozco ciertamente no descalifica a ningún candidato, solo significa que mi trabajo al evaluarlos es un poco más difícil (y probablemente incluirá un ejercicio de codificación si llegan a una entrevista). Si su muestra es pobre (o mi conocido le dice mal), es prácticamente imposible de contratar. Aquellos que proporcionan una muestra pueden o no tener una ventaja pequeña sobre aquellos que no lo hacen en la evaluación inicial, dependiendo de la calidad y cantidad de la pila de currículum y las muestras, más información puede ser mejor o peor que ninguna información.

• que las muestras se falsifican fácilmente

Bueno sí. También lo son los currículums, pero todavía los recopilamos. ¿Por qué? Por tres razones principales: un currículum o una muestra deficientes es fácil de no contratar, ser atrapado falsificando un currículum o una muestra es una fácil de no contratar, y son buenos temas de conversación en una entrevista. Cuanto más rápido pueda descubrir que el candidato es un imbécil, mejor para todos.

Si eres lo suficientemente inteligente como para plagiar una buena muestra sin que te atrapen, habla de manera inteligente al respecto y pasa la entrevista. No tengo ningún problema en particular sobre cómo superaste el examen. Puede haber algunas inquietudes éticas aquí, pero esa no es realmente mi área de especialización, por lo que no me saldré de mi camino para evaluar el carácter moral durante una entrevista. Para mí, es prácticamente lo mismo que mi jefe me pidió que entrevistara a alguien que no pasó por el proceso de selección como un favor. Una vez que estás en la etapa de entrevista, realmente no importa cómo llegaste allí, ya que hay mucha más y mejor información que saldrá durante la entrevista.

TL; DR : un ejemplo de código es una excelente herramienta de detección, pero debe pensar detenidamente si puede requerirlo o no. Una vez pasada la evaluación, pondera la entrevista mucho más que una muestra.