Revisión de códigos en la contratación de personal informático: ¿por qué y cómo utilizarla?

Uno de los aspectos más importantes, pero aún ignorados, de la contratación de un desarrollador de software es verificar cómo se maneja el candidato con el código y si es capaz de expresar sus pensamientos con un lenguaje de programación concreto. Normalmente, en la selección de personal informático, lo hacemos pidiendo al candidato que escriba código para resolver un problema concreto. El candidato puede hacerlo solo o en pareja con el reclutador (Dar en la diana con pruebas de codificación en entorno natural [estudio de caso].). Lo hacemos porque escribir código es una de las cosas más importantes que los desarrolladores hacen a diario. Sin embargo, también debemos recordar que los desarrolladores leen mucho más a menudo el código fuente que lo escriben. Así que no debemos olvidarnos de comprobar si el candidato es capaz de analizar y comprender rápidamente algunos fragmentos de código. Podemos simplemente mostrar algunas impresiones de código o (incluso mejor) dar IDE con algún proyecto y hacer preguntas relacionadas con lo que está sucediendo aquí. Ahí es donde el reto de revisión de código es realmente útil.

¿Cómo verificar los conocimientos de programación de los candidatos durante una entrevista técnica?

En cuanto a lo dicho anteriormente, vemos que la mayor parte del tiempo durante la entrevista/evaluación técnica lo dedicamos a verificar si el candidato es capaz de resolver algunos retos o problemas de programación. El candidato se centra en comprender y analizar el problema para luego encontrar una solución adecuada. Sin embargo, podemos darnos cuenta de que el candidato se ve obligado a pensar más en "qué hacer" que en "cómo hacerlo". Cuando pedimos al candidato que escriba un código que sea capaz de reservar un asiento para un vuelo en determinadas condiciones, el objetivo es enviar la funcionalidad correcta, y en la mayoría de los casos, debido al estrés y a la limitación de tiempo, es todo lo que el candidato es capaz de hacer. ¿Existe alguna opción para invertir esta situación y dejar que el candidato se centre en el "cómo"? Sí. Durante los muchos años en los que participé activamente en la contratación de desarrolladores y arquitectos de TI, utilicé revisiones de código.

¿Qué es la revisión del código?

Revisión del código es un proceso en el que los programadores verifican el código de los demás para detectar posibles problemas, errores o desviaciones de las mejores prácticas (si desea más información, visite Wikipedia). En los últimos años, la revisión del código es un elemento imprescindible del proceso de entrega de software. Nos proporciona una gran capacidad de auditoría y una mejor calidad del código, pero también permite compartir un conocimiento increíble: ahora la gente puede enseñar y aprender al mismo tiempo, compartiendo experiencias. Pero no quiero convencerte de que impongas las revisiones de código en tu proceso de desarrollo (algo que, por cierto, deberías replantearte si aún no estás utilizando), sino mostrarte por qué y cómo utilizar las revisiones de código durante la entrevista técnica.

¿Cómo se puede utilizar la revisión de código en los procesos de selección de personal informático?

Mostrando al candidato un código que ya está escrito y que funciona (en su mayor parte) como se esperaba, le permitimos centrarse en la calidad de la solución. Con una simple pregunta: "¿Qué opinas de este código?", hacemos que el candidato pase al modo de sólo lectura. Lo que es importante mencionar es que algunos desarrolladores están acostumbrados a este tipo de tareas que realizan durante los exámenes de certificación, etc. y buscan algunos errores tontos e intencionados como la falta de punto y coma, parámetros incorrectos, clases equivocadas, etc. En mi opinión deberíamos usar un enfoque diferente. Yo siempre he utilizado código funcional que compila correctamente. Hago hincapié al principio en que no hay errores "de certificación" y el candidato debe centrarse en las mejores prácticas, algunos problemas comunes que son difíciles de notar por las herramientas automáticas y pueden causar graves problemas de producción.

Ejemplo de reto de revisión de código

Por ejemplo en Java que podría estar invocando thread.run() en lugar de thread.start() que compila correctamente, las pruebas están pasando pero no estamos iniciando un nuevo hilo lo que puede degradar el rendimiento final. También podemos comprobar si el candidato se dará cuenta de que algún método transaccional es invocado fuera del aspecto transaccional, lo que puede causar serios problemas de consistencia en una base de datos.

¿Cómo evaluar los conocimientos de programación a partir de la revisión del código?

Basándonos en la primera impresión del candidato, podemos evaluar su enfoque de la calidad. Si para nosotros el código es realmente feo y lleno de problemas y el candidato dice algo como "a mí me parece bien", podemos asumir que no ayudará a mejorar la calidad del código en nuestra empresa e incluso la degradará. También es bastante fácil evaluar la experiencia del candidato. Por ejemplo, en un código fuente de 60 líneas, los desarrolladores junior fueron capaces de encontrar alrededor de 4-5 problemas. Los desarrolladores con más de 8 años de experiencia eran capaces de encontrar 10. Y los mejores candidatos tenían alrededor de 15-20. Y los mejores candidatos encontraron entre 15 y 20 problemas. El mejor candidato me señaló 2 problemas de los que yo no era consciente, y cuando estaba escribiendo el código se incluyeron más de 30 problemas.

¿Qué debemos esperar que comenten los candidatos? Lo más importante son las cuestiones mencionadas anteriormente, es decir, los problemas comunes a una tecnología concreta y que no son visibles a primera vista. Lo siguiente es la legibilidad. El código tiene que estar limpio, bien estructurado y bien nombrado para que cualquier otro desarrollador (no sólo el autor) sea capaz de entenderlo y modificarlo. Los nombres de los métodos o variables tienen sentido, no son demasiado largos, etc. ¿Los métodos no son demasiado grandes y no contienen demasiada lógica? ¿Son las tecnologías utilizadas en el fragmento una buena elección para resolver un problema concreto (por ejemplo, si nuestro código utiliza operaciones con cadenas para construir un XML, podemos esperar que el candidato señale que hay muchas bibliotecas creadas para hacerlo mejor)?

Revisión del código en las campañas de evaluación de DevSkiller

En DevSkiller creemos que la revisión de código debe incluirse en la evaluación de las habilidades de programación. Por eso la mayoría de nuestras campañas de evaluación contienen ese tipo de problema a resolver. También animamos a las empresas a construir sus propias pruebas de codificación que incluyan el reto de revisión de código. Es bastante conveniente para la mayoría de las empresas, ya que puede utilizar su antigua base de código para preparar dicha tarea. Sólo tiene que hablar de ello con su departamento de TI e incluirlo en su proceso de contratación.