¿Por qué evaluar a los programadores?

Hay un factor común que ha tomado un papel protagonista en los procesos de selección de programadores: el código fuente del candidato. Desde habitissimo os queremos compartir nuestras reflexiones sobre esta potente herramienta y nuestra manera de usarla.

En los últimos años, las competencias han tomado el papel central en los procesos de selección. En un mundo en el que las tareas asociadas a un puesto de trabajo cambian con mucha rapidez se prefiere contar con personas que tienen lo necesario para adaptarse a las nuevas situaciones que con expertos en desarrollar una tarea específica.

Dada la situación actual se puede pensar que las entrevistas deberían ser suficientes para averiguar si un programador puede realizar bien sus tareas. Si bien la entrevista es la parte central del proceso de selección, quedarse solo con eso es un enfoque extremadamente negligente. ¿Alguien contrataría a un actor sin realizar un casting?, ¿un deportista sin realizar pruebas físicas?

Invertimos horas en el proceso de selección y entrevistas al aspirante para conocerlo a fondo, pero también dedicamos quince minutos a comprobar sus referencias. Del mismo modo es indispensable comprobar que el candidato está realmente capacitado para desarrollar la tarea que va a estar realizando durante, al menos, el 80% del tiempo.

Evaluar el código fuente nos aporta mucho más que una simple garantía de que esa persona sabe programar correctamente. Pedir y recibir código fuente del candidato nos da una buena idea de otras competencias como desarrollador. En nuestro caso buscamos a desarrolladores con pasión por lo que hacen y que les guste aprender, por lo que valoramos positivamente que nos envíen proyectos personales que han decidido compartir con la comunidad.

Por otro lado, la entrevista de código supone una barrera de entrada que permite descartar al candidato en una parte temprana del proceso, ahorrando así el tiempo de los entrevistadores. Como bien dijo Linus Torvalds, creador y responsable de desarrollo del Kernel Linux, «Talk is cheap, show me the code».

En los procesos de selección de desarrolladores nos encontramos con dos tendencias distintas en la evaluación de código: la primera está dirigida a los resultados y la segunda, a la calidad.

Los beneficios de evaluar técnicamente a los desarrolladores son evidentes y se ha incorporado a muchos procesos de selección a modo de prueba o test de programación.

Evaluar la habilidad de un programador no es fácil y a menudo se cometen errores. Hoy en día se obtiene esta información con exámenes de programación que buscan cazar al candidato en aspectos rebuscados del lenguaje o a partir de preguntas relacionadas con el ámbito académico, que nada tienen que ver con las competencias que se requieren para el puesto.

Algunas empresas como codility o mettl ofrecen soluciones integradas para la evaluación de las competencias técnicas de los candidatos. Esto permite a las empresas establecer, en poco tiempo, un proceso estandarizado y libre de sesgos: si el aspirante resolvió 4 de los 5 problemas propuestos lo consideraremos apto para el puesto.

La facilidad de integrar este tipo de prueba lo hace recomendable para procesos en los que se reciben muchas solicitudes y hay que separar el grano de la paja. En cualquier caso nos tendremos que asegurar de que estamos evaluando las competencias necesarias para el puesto.

Evaluar la competencia de un desarrollador en una prueba estandarizada tiene también sus riesgos. Por un lado es posible que acabemos descartando a un gran profesional por razones circunstanciales: nervios durante la prueba, desconocimiento de un aspecto específico del lenguaje, etc. Por otro lado, no estamos considerando la calidad del código resultante, solo su capacidad para resolver o no la tarea.

Habitualmente, los programadores que en un primer momento parecen más resolutivos son los denominados cowboys. Son capaces de entender el problema fácilmente y aportar soluciones rápidas y creativas. Este tipo de programadores pueden ser muy útiles para tirar un proyecto adelante cuando el tiempo es crítico. Sin embargo, su tendencia al código «espagueti» los hace poco apropiados cuando se trata de mantener un proyecto grande o de trabajar junto a otros programadores.

Una evaluación orientada íntegramente a resultados puede resultar un colador de programadores cowboy. Esto puede resultar poco importante, o incluso deseable, para una consultoría de desarrollo web en el que se desarrollan proyectos de unas pocas semanas o meses y que luego raramente se mantienen. Sin embargo, cuando se trata de desarrollar y mantener un producto es importante fijarnos también en otros aspectos del código.

Leer y evaluar el código fuente escrito por el candidato permite averiguar con qué tipo de programador nos encontramos y ajustar la evaluación a los intereses de la organización. Es una evaluación más meticulosa en la que tendremos el cómo se ha solucionado el problema y no sólo el qué ha solucionado. Buscaremos que el código sea claro y fácil de mantener.

En nuestro proceso de selección pedimos al aspirante que nos haga llegar un proyecto escrito por él y que crea que le representa como programador. Si el candidato no dispone de un proyecto que pueda enseñar le proponemos resolver un problema planteado por nosotros mismos. Desde un primer momento el aspirante sabe cómo se va a evaluar su código y se le permite seleccionar y editar el código que va a enviar en consecuencia. Los aspectos que evaluamos son:

Al evaluar estos apartados damos por supuesto que el programador ha sabido resolver la problemática a la que se enfrentaba. Vamos un paso más allá y nos fijamos en aquellos aspectos que harán que ese código sea fácil de mantener y poco propenso a errores.

El código es evaluado por al menos dos programadores, que desconocen la identidad del aspirante y utilizan una plantilla estandarizada. En la plantilla descomponemos cada apartado en varios ítems a evaluar. Por ejemplo, algunas de las preguntas que debe responder el evaluador en el apartado de utilización de estructuras y algoritmos adecuados son: ¿las clases tienen responsabilidades específicas? y ¿se utilizan los algoritmos, patrones y estructuras más adecuados para resolver el problema?

Por último, damos a cada apartado un peso distinto y sumamos todos los ítems de evaluación para obtener la puntuación final. La selección de elementos a evaluar y su peso no son casuales, sino que obedecen al tipo de programador que creemos más apto para nuestro equipo y para el software que desarrollaremos.

En un sector en el que es difícil encontrar programadores, algunos piensan que encontrar un programador con talento es cuestión de suerte o dinero. Hallar talento no es fácil, pero es prácticamente imposible si no somos capaces de detectarlo cuando lo tenemos delante. Pedir al aspirante que nos entregue su código fuente nos aporta una herramienta muy potente para juzgar su potencial.

La evaluación de código debe ser considerado como un elemento más del proceso de selección de un programador. Como tal, debemos diseñarlo para eliminar el máximo número posible de elementos subjetivos y para que esté alineado con los intereses y la cultura de la organización. Solo así lograremos maximizar nuestras probabilidades de éxito.

Para finalizar este artículo, comentar que hay empresas que utilizan diferentes métodos de evaluación para programadores, como por ejemplo estas preguntas capciosas de Google… ¿sabrías responderlas?

También te puede interesar: «Debemos incentivar la curiosidad y el interés por la tecnología»